Le 29 sept. 2013 à 21:28, /dev/rob0 a écrit :
On Sat, Sep 28, 2013 at 04:26:03PM +0200, Axel Luttgens wrote:
Le 27 sept. 2013 à 09:35, Mike Edwards a écrit :
I think I just fixed the problem but I am not sure if I did it the right way.. It seems that it is postfix that did it, not dovecot. I found this in the log for every local message...
Sep 26 11:10:10 zeus postfix/local[14565]: 9B0294AA15E: to=vmail@my.domain.com, orig_to=<vmail>, relay=local, delay=9, delays=9/0.01/0/0.02, dsn=2.0.0, status=sent (delivered to mailbox)
So, I went to the postfix master.cf and commented out this line...
#local unix - n n - - local
Was that the correct way to do it?
Hello Mike,
You probably have cured the symptoms... ;-)
I doubt it. The correct way to not route mail to local(8) is to take the domain in question out of mydestination. With no local transport available, but a domain is still listed in mydestination, Postfix will probably just complain about "transport not available".
Your cron command has very likely been built for making use of the sendmail command. When facing a "naked" recipient address such as "vmail", Postfix' sendmail will look for an alias, then for a system user bearing that name.
No, this is wrong. Where did you see this?
Thanks, I now understand I've probably been too quick in my description, by writing "sendmail" and implicitly considering the net effect of the whole chain starting with sendmail and ending with local (I made that same short-circuit in other parts of my reply as well).
And the net effect is that, with defaults settings, every system user is liable to receive mail through a local submission.
From Mike's description, it indeed appears that he initially had such default settings wrt the local domain class.
So, the symptom was: some messages are delivered locally. And curing the symptom was: disable the local transport. With now another symptom anyway: messages are accumulating in the queue.
A bare localpart address without domain has @$myorigin appended. See postconf.5.html#append_at_myorigin for details. The munged @domain shown above is Mike's $myorigin, and it is listed in his $mydestination.
There's probably no alias for "vmail", but you clearly have a system user named "vmail"; so, sendmail will proceed with a local delivery for user "vmail".
Nitpicking here, but sendmail does not do the delivery, only the acceptance and enqueueing.
Sorry: I meant local "submission". :-(
The now-commented local checks the alias_maps and does the delivery.
So, you could for example define an alias:
vmail: yourself@your.virtual.domain
since you're potentially more interested than user vmail in the messages emitted by the cron job.
This won't work if local_transport points to a service which is undefined.
Unless those settings have been reverted to their default values, of course; this was the point of my reply.
Or add such a line to your crontab:
MAIL=yourself@your.virtual.domain
so as to override the default recipient, ie the user the job runs as.
Probably a better idea, but that feature is not available in all known cron implementations. Mike should check his own crontab(1) manual.
Do you mean that some distributions are liable to mess with such a basic behavior of the venerable cron command? But yes, always a good idea to check the relevant man pages. ;-)
Once again, sorry for my over-simplifications, Axel