system email being sent to wrong domain

[Dirk]

I may have found something. If I type ldapsearch I get a full listing of the content of the LDAP tables, and I notice this entry:

# root, people, domain.co.uk
dn: uid=root,ou=people,dc=domain,dc=co,dc=uk
zimbraId: 3eb2c996-2d41-4b24-b34c-021dbd0f83a6
uid: root
objectClass: zimbraAlias

# root, people, mail.domain.co.uk
dn: uid=root,ou=people,dc=mail,dc=domain,dc=co,dc=uk
zimbraId: a6fa7ad4-02b3-403d-9b42-2cb2c45565fd
uid: root
objectClass: zimbraAlias

I'm thinking that either the second entry should be adjusted or deleted. Is this right, and if so, my ldap skills suck more than my linux skills so could someone provide the correct syntax to sort it?

[KevinH]

Do you show two domains when you view the domains in the admin UI.

[Dirk]

I do see two domains now yes, as I added one in order to be able to recieve the messages.

Initially there was just one domain, let's say domain.com but I added mail.domain.com so that I could make an alias against a real account with the incorrect address of user@mail.domain.com

By the way, I get the same problem on my home installation on suse10.1 as I do on the works installation on suse 10.0

[KevinH]

So the reason you see two root aliases is you've got two domains provisioned. If you don't want the other domain then you can remove it. In general having it there shouldn't be anything to worry about.

[Dirk]

Which brings us right back to the question of, if the machine is called 'mail' with a fully qualified name of 'mail.domain.co.uk' in a domain called 'domain.co.uk' and users with addresses such as 'user@domain.co.uk' why on earth does the server send it's daily stats to a user called 'root@mail.domain.co.uk' which clearly does not exist?

[KevinH]

It's a bug. I thought I mentioned that in this thread already but looking back I didn't make it clear. The crontab just sends to "root" which will default to root@HOSTNAME so mail wise it's doing the right thing. The fix is to have that email address for the report come from config. In the short term it's an easy fix to just change the crontab to have the fully qualified email address.

[Dirk]

I didnt realise it was a known issue, I'd have stopped sooner if I did!

I had changed the crontab to send to the full address rather than just root, but I had already created the additional domain and alias to recieve the mail before I did this. So I didnt realise I could remove that once I'd changed the crontab.

I've now removed the extra settings and the crontab is doing it's thing. The sent from address is still wrong, but that's really not too much of an issue.

Thanks for all the help.

[indymail]

This is in the crontab

# Daily reports
#
10 1 * * * /opt/zimbra/libexec/zmdailyreport | /opt/zimbra/postfix/sbin/sendmail root


We send to root by default so you can hack it to just edit this address. In general we need to make this configurable. If you domain name matches the system name then it would just work since the root account will alias to your admin account. So for now you can work around it but feel free to file a bug to correct this going forward.

How exactly does the root account alias to the admin account? The reason I'm asking is that I'm not getting any of the daily reports. They are all still in root's mailbox (i.e. I can log in as root and use the mail command to see them). I know I can edit zimbra's crontab to fix this but I'd like to avoid manually changing configuration files if at all possible.

[brian]

4.5.2 has a fix for this that delivers the dailyreport to the admin account via the configured smtphost. no more dependancies on the local system mailer or root account.

[wmswms]

Im running "4.5.3_GA_733.RHEL4_20070228100631 RHEL4 NETWORK edition" and had the same problem. The smtp_source and smtp_destination options were set to "admin@host.domain" instead of just "admin@domain". So my daily reports were bouncing as there's no local user called "admin" on the server. My crontab has the newer line I believe:

# Daily reports
#
10 1 * * * /opt/zimbra/libexec/zmdailyreport -m

I fixed it by changing the smtp_* options to "admin@domain" per other threads, but Im wondering if its a bug that the options got set to the full host.domain instead of using the mail domain only? Or is this just a transient bug from 4.5.2 that has been fixed?