[Dovecot] Using MailDir but local messages still save in mbox format
I am using MailDir format for all my virtual users and it is working well. However, if email comes in to a unix system user, it delivers in Mbox format. This is mostly cron jobs that do this. Mail addressed to my virtual users goes to the MailDir locations just fine. None of these mailboxes have ever been created, they are just incorrect assumed addresses. There should NEVER be any email to username@my.host.name because everything is virtual.
Does anyone know how to fix this?
Here is my config.
# 2.0.9: /etc/dovecot/dovecot.conf # OS: Linux 2.6.32-358.18.1.el6.x86_64 x86_64 CentOS release 6.4 (Final) auth_debug = yes auth_mechanisms = plain login cram-md5 ntlm auth_verbose = yes auth_verbose_passwords = plain disable_plaintext_auth = no listen = * mail_location = maildir:~/Maildir mail_privileged_group = mail managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date mbox_write_locks = fcntl passdb { args = /etc/dovecot/conf.d/dovecot-sql.conf.ext driver = sql } plugin { autocreate = Trash autocreate2 = Spam autocreate3 = Drafts autocreate4 = Sent autocreate5 = Archives autosubscribe = Trash autosubscribe2 = Spam autosubscribe3 = Drafts autosubscribe4 = Sent autosubscrube5 = Archives sieve = ~/.dovecot.sieve sieve_before = /home/vmail/movespam.sieve sieve_dir = ~/sieve } protocols = imap pop3 service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } unix_listener auth-master { mode = 0600 user = vmail } } ssl_ca = /etc/pki/dovecot/ca/dovecot.pem ssl_cert = </etc/pki/dovecot/certs/dovecot.pem ssl_key = </etc/pki/dovecot/private/dovecot.pem ssl_cipher_list = HIGH:MEDIUM:+TLSv1:!SSLv2:+SSLv3 userdb { args = uid=vmail gid=vmail home=/home/vmail/%d/%n driver = static } protocol lda { auth_socket_path = /var/run/dovecot/auth-master log_path = /home/vmail/dovecot-deliver.log mail_plugins = " sieve sieve" postmaster_address = postmaster@zeus.deltatechnicalservices.com } protocol lmtp { mail_plugins = " sieve" } protocol imap { mail_plugins = autocreate } protocol sieve { managesieve_implementation_string = Dovecot Pigeonhole } protocol pop3 { pop3_uidl_format = %08Xu%08Xv }
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 26 Sep 2013, Mike Edwards wrote:
I am using MailDir format for all my virtual users and it is working well. However, if email comes in to a unix system user, it delivers in Mbox format. This is mostly cron jobs that do this. Mail addressed to my virtual users goes to the MailDir locations just fine. None of these mailboxes have ever been created, they are just incorrect assumed addresses. There should NEVER be any email to username@my.host.name because everything is virtual.
Er: 1) What is done by "cron jobs"??
passdb { args = /etc/dovecot/conf.d/dovecot-sql.conf.ext driver = sql } userdb { args = uid=vmail gid=vmail home=/home/vmail/%d/%n driver = static }
Are the mbox files for the system users located in /home/vmail/... ? What Unix uid/gid do they have?
Do you have any entry in the Dovecot logs, that let you assume that messages to system users are delivered through Dovecot?
If you do not want, that your MTA accepts messages for username@my.host.name reconfigure it.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUkUnWV3r2wJMiz2NAQKwtQf+IlXqgy2ox7gbFaBmVhz4tUpbG8QzqxEA IyugBD3aZBNagVYBDyxcN10ZKlhxopDyExIKBxDOEd7NAgCY2BaKdwErgF5LMhu7 LX64/k36X0E+w6V7yoyQ7drqn//aKlzQw3knWiKKhvaLLqgdrz63bTarNCTMP3kX Un6UgkIT2U5H8bLjE8gr1cNHWAgE0ZaFbRl5aPZg1/QV2D6yMnSNGVCb2YwKq8hJ fGMub+Hv3RDjKxYcvC8EmKCV7CawdO3dwI1az8ErlQ5uqLV9fXzxmcXAL30d8NNI 8HkiIJDye/SpNPFHhco5S2dA/Hmmx3jVu3yzpn4TSWZmSgqeWfKKdQ== =E4EC -----END PGP SIGNATURE-----
Yes the mbox messages are showing up in /home/vmail and the ownership is vmail:vmail
The messages that come from cron and other system stuff that address
messages to root@my.host.name or to ownerOfCronJob@my.host.name
Nobody will ever check those boxes and they are not wanted. We would
like to either redirect them else where ( forward and not leave in the
mbox file) or just block all messages to anyone@my.host.name.
I did just find a way to put in a forward to forward everything to root@my.host.name to a virtual box and now the messages have stopped for that address. I suppose I could put in a forward each time a new mbox shows up but would rather just block all messages addressed to anyone@my.host.name if there is a way.
On 9/26/2013 11:36 PM, Steffen Kaiser wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 26 Sep 2013, Mike Edwards wrote:
I am using MailDir format for all my virtual users and it is working well. However, if email comes in to a unix system user, it delivers in Mbox format. This is mostly cron jobs that do this. Mail addressed to my virtual users goes to the MailDir locations just fine. None of these mailboxes have ever been created, they are just incorrect assumed addresses. There should NEVER be any email to username@my.host.name because everything is virtual.
Er: 1) What is done by "cron jobs"??
passdb { args = /etc/dovecot/conf.d/dovecot-sql.conf.ext driver = sql } userdb { args = uid=vmail gid=vmail home=/home/vmail/%d/%n driver = static }
Are the mbox files for the system users located in /home/vmail/... ? What Unix uid/gid do they have?
Do you have any entry in the Dovecot logs, that let you assume that messages to system users are delivered through Dovecot?
If you do not want, that your MTA accepts messages for username@my.host.name reconfigure it.
- -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUkUnWV3r2wJMiz2NAQKwtQf+IlXqgy2ox7gbFaBmVhz4tUpbG8QzqxEA IyugBD3aZBNagVYBDyxcN10ZKlhxopDyExIKBxDOEd7NAgCY2BaKdwErgF5LMhu7 LX64/k36X0E+w6V7yoyQ7drqn//aKlzQw3knWiKKhvaLLqgdrz63bTarNCTMP3kX Un6UgkIT2U5H8bLjE8gr1cNHWAgE0ZaFbRl5aPZg1/QV2D6yMnSNGVCb2YwKq8hJ fGMub+Hv3RDjKxYcvC8EmKCV7CawdO3dwI1az8ErlQ5uqLV9fXzxmcXAL30d8NNI 8HkiIJDye/SpNPFHhco5S2dA/Hmmx3jVu3yzpn4TSWZmSgqeWfKKdQ== =E4EC -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 26 Sep 2013, Mike Edwards wrote:
The messages that come from cron and other system stuff that address messages to root@my.host.name or to ownerOfCronJob@my.host.name Nobody will ever
ah, local messages. You still want to make sure in the MTA, these addresses are rejected from outside, to prevent spammers using them.
I did just find a way to put in a forward to forward everything to root@my.host.name to a virtual box and now the messages have stopped for that
Check out if your MTA handles catch-all aliases or forwards for the whole domain.
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUkU0fl3r2wJMiz2NAQKWMQgAoTUyaMW6Zu15Fidi9MrxqRE3yUYWJqRK GXWP9SvXJr/ywieYUZMm3M80kumhU7OMqOeS/ahrHRautHz/3q9RRuZsDTejlYPV 8IbrVbsjKpFJ2Uxvm4n/hHur5qeV3vq+NN9N4MJG2/DQf/nYJvDgLPGbaKDQUdnw 6gpS2NIx9de8QAejc+1gqhgrl9SdJI1I8mk5KuXVoQ5REfBLGvnhTzdlawcx3CQp XKIv0xciRxWeSuykf/EWUGeX8etOYwiVBCPkTp0vf+WczPIoR6cgiZGLax2rk7sb Hyop59COwPd2NWwP0O3I4crNR8201GdkSNHVaJlOp9tOo1L3XWDLkQ== =b5qI -----END PGP SIGNATURE-----
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?
On 9/27/2013 12:32 AM, Steffen Kaiser wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 26 Sep 2013, Mike Edwards wrote:
The messages that come from cron and other system stuff that address messages to root@my.host.name or to ownerOfCronJob@my.host.name
Nobody will everah, local messages. You still want to make sure in the MTA, these addresses are rejected from outside, to prevent spammers using them.
I did just find a way to put in a forward to forward everything to root@my.host.name to a virtual box and now the messages have stopped for that
Check out if your MTA handles catch-all aliases or forwards for the whole domain.
- -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUkU0fl3r2wJMiz2NAQKWMQgAoTUyaMW6Zu15Fidi9MrxqRE3yUYWJqRK GXWP9SvXJr/ywieYUZMm3M80kumhU7OMqOeS/ahrHRautHz/3q9RRuZsDTejlYPV 8IbrVbsjKpFJ2Uxvm4n/hHur5qeV3vq+NN9N4MJG2/DQf/nYJvDgLPGbaKDQUdnw 6gpS2NIx9de8QAejc+1gqhgrl9SdJI1I8mk5KuXVoQ5REfBLGvnhTzdlawcx3CQp XKIv0xciRxWeSuykf/EWUGeX8etOYwiVBCPkTp0vf+WczPIoR6cgiZGLax2rk7sb Hyop59COwPd2NWwP0O3I4crNR8201GdkSNHVaJlOp9tOo1L3XWDLkQ== =b5qI -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 27 Sep 2013, Mike Edwards wrote:
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?
Correct depends on many things - and I do not use Postfix.
https://ixquick.com/do/search?query=postfix+catch-all http://wiki2.dovecot.org/LDA/Postfix
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUkU4d13r2wJMiz2NAQIdiAf+Kvp+9p/UIf6IzUqBF3lCgyo3F4mi6e+s p6LhI74TCyVHlIdMfo88TmPgsAdqXz8zHzdmkJKu3+vZpOaXyhQyUr/FF9Dviyf/ 2YaayM6j/spOo19hladsng4p8nG5S4GIDe+OlWpF1yzO1+sBVEqYxrDTde3yEiqv 3hJ2GymfquoNKxA1xHFQJZ1JrA6kFfpJzOczAgWzhq8gQIdG6c/MbNytU3CBh4W0 Y0nqvmrnSzZWHaaMBNP7y3Pjn4Hs0bl7i2cyY5ZdsSGUtLJ7oSQ3pSbVSGgp0+Gb Mz3f8XTMaEb+RolbF8l4sve4K017SMkR2CsFbgS19AbJkWENyXicMw== =wl1i -----END PGP SIGNATURE-----
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... ;-)
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. 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".
So, you could for example define an alias:
vmail: yourself@your.virtual.domainsince you're potentially more interested than user vmail in the messages emitted by the cron job.
Or add such a line to your crontab:
MAIL=yourself@your.virtual.domainso as to override the default recipient, ie the user the job runs as.
HTH, Axel
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?
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. 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.
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.
http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
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
On Mon, Sep 30, 2013 at 10:27:19AM +0200, Axel Luttgens wrote:
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. ;-)
In Linux land, Slackware uses the simpler Dillon's cron which lacks some of the features of the more popular Vixie cron. I bet a lot of commercial Unix flavors are also using simpler cron implementations than Vixie's.
http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
participants (4)
-
/dev/rob0
-
Axel Luttgens
-
Mike Edwards
-
Steffen Kaiser