[Dovecot] How to deal with mail to unknown virtual recipients?
Hello list,
I am not quite sure whether this is a questions for Dovecot or Postfix. I have set up, virtual hosting for one domain (for test purposes) using a passwd-file as passdb and a static userdb (see dovecot -n at the end) along with Postfix in a manner described in [1], i.e. a non-Postfix mail store. Other than that I also do hosting for the canonical domain which is for users with a regular Unix account on the system (looked up via PAM)
The virtual domain shall be "example.org", with two users "alice@example.org" and "bob@example.org".
But today I received spam mail (which was correctly identified as such by amavisd-new) for "info@example.org" and "sales@example.org", two recipient addresses that do not exist. According to [1] "it's left up to the non-Postfix delivery agent to reject non-existent recipients from local submission or from local alias expansion."
How to deal with such a situation?
The sender address was clearly forged so returning a failed delivery message is pointless. The messages are now hanging around in the queue with a status of "deferred: temporary failure".
The logs show:
dovecot: auth(default): passwd(info@exmaple.org): unknown user dovecot: auth(default): passwd-file(info@mexample.org): unknown user dovecot: auth(default): static(info@example.org): passdb doesn't support lookups, can't verify user's existence
postfix/pipe[25328]: C7EA18BC0B5: to=info@exmaple.org, relay=dovecot, delay=1.4, delays=0.07/0.02/0/1.3, dsn=4.3.0, status=deferred (temporary failure)
The dovecot relay is defined in /etc/postfix/master.cf:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f ${sender} -d ${recipient}
The question, once again, is: what to do in such a situation? A catch-all address could be set up, but to what end? It would just catch a lot of spam over time. What is the correct way to deal with this?
More importantly: is there even anything Dovecot could (or should) do?
Thanks in advance,
Andreas
[1] http://www.postfix.org/VIRTUAL_README.html#in_virtual_other
# 1.0.10: /usr/local/etc/dovecot.conf base_dir: /var/run/dovecot/ protocols: imap imaps pop3 pop3s managesieve listen(default): * listen(imap): * listen(pop3): * listen(managesieve): *:2000 ssl_cert_file: /path/to/ssl_cert ssl_key_file: /path/to/private_key login_dir: /var/run/dovecot//login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login mail_extra_groups: mail mail_location: maildir:~/Maildir maildir_copy_with_hardlinks: yes mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 mail_plugin_dir(managesieve): /usr/local/lib/dovecot/managesieve imap_client_workarounds(default): outlook-idle delay-newmail tb-extra-mailbox-sep imap_client_workarounds(imap): outlook-idle delay-newmail tb-extra-mailbox-sep imap_client_workarounds(pop3): outlook-idle imap_client_workarounds(managesieve): outlook-idle pop3_uidl_format(default): pop3_uidl_format(imap): pop3_uidl_format(pop3): %08Xu%08Xv pop3_uidl_format(managesieve): sieve_storage(default): sieve_storage(imap): sieve_storage(pop3): sieve_storage(managesieve): ~/sieve sieve(default): sieve(imap): sieve(pop3): sieve(managesieve): ~/.dovecot.sieve namespace: type: public separator: / prefix: Public/ location: maildir:/var/mail/public:CONTROL=~/Maildir/control/public:INDEX=~/Maildir/index/public namespace: type: private separator: / inbox: yes auth default: mechanisms: plain login verbose: yes passdb: driver: passwd-file args: /etc/dovecot/passwd passdb: driver: pam userdb: driver: passwd userdb: driver: static args: uid=vmail gid=vmail home=/home/vmail/%d/%u socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 432 user: vmail group: vmail
Andreas "daff" Ntaflos Vienna, Austria
GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4
Andreas Ntaflos wrote:
Hello list,
I am not quite sure whether this is a questions for Dovecot or Postfix. I have set up, virtual hosting for one domain (for test purposes) using a passwd-file as passdb and a static userdb (see dovecot -n at the end) along with Postfix in a manner described in [1], i.e. a non-Postfix mail store. Other than that I also do hosting for the canonical domain which is for users with a regular Unix account on the system (looked up via PAM)
The virtual domain shall be "example.org", with two users "alice@example.org" and "bob@example.org".
But today I received spam mail (which was correctly identified as such by amavisd-new) for "info@example.org" and "sales@example.org", two recipient addresses that do not exist. According to [1] "it's left up to the non-Postfix delivery agent to reject non-existent recipients from local submission or from local alias expansion."
note that this is about local submission and local alias expansion. it is not about mail received from outside.
How to deal with such a situation?
this is postfix issue. postfix will reject mail to invalid local and virtual users unless you rebak recipient validation. a common error is to use wildcard virtual aliases or wildcard canonical mapping.
Followup on the postfix list, but do show enough informations:
- output of 'postconf -n'
- logs of the transaction (from reception until error)
- do you have a wildcard alias or canonical.
The sender address was clearly forged so returning a failed delivery message is pointless. The messages are now hanging around in the queue with a status of "deferred: temporary failure".
The logs show:
dovecot: auth(default): passwd(info@exmaple.org): unknown user dovecot: auth(default): passwd-file(info@mexample.org): unknown user dovecot: auth(default): static(info@example.org): passdb doesn't support lookups, can't verify user's existence
postfix/pipe[25328]: C7EA18BC0B5: to=info@exmaple.org, relay=dovecot, delay=1.4, delays=0.07/0.02/0/1.3, dsn=4.3.0, status=deferred (temporary failure)
The dovecot relay is defined in /etc/postfix/master.cf:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f ${sender} -d ${recipient}
The question, once again, is: what to do in such a situation? A catch-all address could be set up, but to what end? It would just catch a lot of spam over time. What is the correct way to deal with this?
More importantly: is there even anything Dovecot could (or should) do?
Thanks in advance,
Andreas
[1] http://www.postfix.org/VIRTUAL_README.html#in_virtual_other
# 1.0.10: /usr/local/etc/dovecot.conf base_dir: /var/run/dovecot/ protocols: imap imaps pop3 pop3s managesieve listen(default): * listen(imap): * listen(pop3): * listen(managesieve): *:2000 ssl_cert_file: /path/to/ssl_cert ssl_key_file: /path/to/private_key login_dir: /var/run/dovecot//login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login mail_extra_groups: mail mail_location: maildir:~/Maildir maildir_copy_with_hardlinks: yes mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 mail_plugin_dir(managesieve): /usr/local/lib/dovecot/managesieve imap_client_workarounds(default): outlook-idle delay-newmail tb-extra-mailbox-sep imap_client_workarounds(imap): outlook-idle delay-newmail tb-extra-mailbox-sep imap_client_workarounds(pop3): outlook-idle imap_client_workarounds(managesieve): outlook-idle pop3_uidl_format(default): pop3_uidl_format(imap): pop3_uidl_format(pop3): %08Xu%08Xv pop3_uidl_format(managesieve): sieve_storage(default): sieve_storage(imap): sieve_storage(pop3): sieve_storage(managesieve): ~/sieve sieve(default): sieve(imap): sieve(pop3): sieve(managesieve): ~/.dovecot.sieve namespace: type: public separator: / prefix: Public/ location: maildir:/var/mail/public:CONTROL=~/Maildir/control/public:INDEX=~/Maildir/index/public namespace: type: private separator: / inbox: yes auth default: mechanisms: plain login verbose: yes passdb: driver: passwd-file args: /etc/dovecot/passwd passdb: driver: pam userdb: driver: passwd userdb: driver: static args: uid=vmail gid=vmail home=/home/vmail/%d/%u socket: type: listen client: path: /var/spool/postfix/private/auth mode: 432 user: postfix group: postfix master: path: /var/run/dovecot/auth-master mode: 432 user: vmail group: vmail
On Thursday 17 April 2008 23:50:40 mouss wrote:
But today I received spam mail (which was correctly identified as such by amavisd-new) for "info@example.org" and "sales@example.org", two recipient addresses that do not exist. According to [1] "it's left up to the non-Postfix delivery agent to reject non-existent recipients from local submission or from local alias expansion."
note that this is about local submission and local alias expansion. it is not about mail received from outside.
How to deal with such a situation?
this is postfix issue. postfix will reject mail to invalid local and virtual users unless you rebak recipient validation. a common error is to use wildcard virtual aliases or wildcard canonical mapping.
Thank you for your reply! Reading through it and re-reading the Postfix documentation gave me the clue I needed.
Unfortunately I forgot to mention that I didn't have a virtual_mailbox_maps directive defined in Postfix's main.cf, so Postfix couldn't know anything about which virtual recipients were valid and which weren't. Since that particular map was optional and everything worked fine during my tests (which didn't include sending mail to an invalid virtual recipient, shame on me) I quickly forgot about it.
Naturally that was the root of problem I was facing.
Defining a virtual_mailbox_maps file with all valid virtual users solves the problem in principle, however now I need to maintain two files with valid virtual users for valid virtual domains: the passwd-file for Dovecot (/etc/dovecot/passwd) plus the vmailbox file for Postfix (hash:/etc/postfix/vmailbox).
I suppose this is unavoidable when using flat files and would be better solved using a real database backend, but it makes me wonder if there really isn't anything Dovecot could do about this?
Seeing as Dovecot recognises when a virtual recipient is invalid, couldn't it somehow put the to-be-rejected mail back to Postfix (or whichever MTA)? Or should it just drop it? I don't know what the SMTP (whichevery protocol is to be followed here) says about this, so I pose the question again:
Is there anything Dovecot itself can do to reject or handle mail to invalid virtual users? Or does this situation *have* to be dealt with earlier, by the MTA?
Andreas
Andreas "daff" Ntaflos Vienna, Austria
GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4
Seeing as Dovecot recognises when a virtual recipient is invalid, couldn't it somehow put the to-be-rejected mail back to Postfix (or whichever MTA)? Or should it just drop it? I don't know what the SMTP (whichevery protocol is to be followed here) says about this, so I pose the question again:
Once you have accepted the mail *YOU* are responsible for dealing with it and generating bounced back to the original sender as per all the RFCs. If you accept obvious forged mail then this is going to get you sending bounced back to poor innocent forged recipients and listed as a spam sender when you hit spam traps...
Just don't accept mail into postfix that you don't want to have to deal with later... Kill it right at the front door and reject it and then it becomes the upstream server's problem to deal with...
Good luck
Ed W
On 4/18/2008, Andreas Ntaflos (daff@pseudoterminal.org) wrote:
Is there anything Dovecot itself can do to reject or handle mail to invalid virtual users?
Not directly - the solution, as you surmised, earlier, is to use the same db backend for your users.
Or does this situation *have* to be dealt with earlier, by the MTA?
Yes, it *must* be done at the MTA, otherwise you accept-then-bounce, which makes you a backscatter source, and will quickly get you blacklisted...
--
Best regards,
Charles
On Friday 18 April 2008 18:56:08 Charles Marcus wrote:
On 4/18/2008, Andreas Ntaflos (daff@pseudoterminal.org) wrote:
Is there anything Dovecot itself can do to reject or handle mail to invalid virtual users?
Not directly - the solution, as you surmised, earlier, is to use the same db backend for your users.
Or does this situation *have* to be dealt with earlier, by the MTA?
Yes, it *must* be done at the MTA, otherwise you accept-then-bounce, which makes you a backscatter source, and will quickly get you blacklisted...
Charles, Ed,
thank you very much for your insightful replies.
Andreas
Andreas "daff" Ntaflos Vienna, Austria
GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4
Andreas Ntaflos wrote:
Thank you for your reply! Reading through it and re-reading the Postfix documentation gave me the clue I needed.
Unfortunately I forgot to mention that I didn't have a virtual_mailbox_maps directive defined in Postfix's main.cf, so Postfix couldn't know anything about which virtual recipients were valid and which weren't. Since that particular map was optional and everything worked fine during my tests (which didn't include sending mail to an invalid virtual recipient, shame on me) I quickly forgot about it.
Naturally that was the root of problem I was facing.
Defining a virtual_mailbox_maps file with all valid virtual users solves the problem in principle, however now I need to maintain two files with valid virtual users for valid virtual domains: the passwd-file for Dovecot (/etc/dovecot/passwd) plus the vmailbox file for Postfix (hash:/etc/postfix/vmailbox).
use a script to generate the virtual mailbox maps files from a single source file. you can use a Makefile to rebuild only when the source file changed.
I suppose this is unavoidable when using flat files and would be better solved using a real database backend, but it makes me wonder if there really isn't anything Dovecot could do about this?
Seeing as Dovecot recognises when a virtual recipient is invalid, couldn't it somehow put the to-be-rejected mail back to Postfix (or whichever MTA)?
as already said, you should reject invalid recipient during the smtp transaction. there's already too much backscatter out there, and the borked sites are listed in backscatterer.org.
Or should it just drop it?
No, because people sometimes mistype addresses and you don't want to blackhole such mail. if I send mail to daf@yourdomain, and you discard that mail, I'll assume that you received it. now suppose this mail is important ("Hi Andreas, there is a problem at foo bar, tell me if I should handle it...").
I don't know what the SMTP (whichevery protocol is to be followed here) says about this, so I pose the question again:
if you accept the message during the smtp transaction, you take responsibility and you should not lose it "frivoulously". This requirement is what makes email as reliable as it is, at the expense of disk IO overhead (before saying "ok", the MTA must sync the file to permanent storage, so that it survives server crashes... etc).
of course, servers should never bounce spam and viruses. as a result, it is important to reject as much junk during the smtp transaction and to minimize failures after a message was accepted. In particular, it is no more acceptable to bounce mail because the recipient is invalid. quota bounces and exceptional server errors are still acceptable because they don't occur too often.
Note that this also applies to auto-responders (vacation, ...). auto-responders must follow the recommendations of rfc3834 as well as other best practices.
Is there anything Dovecot itself can do to reject or handle mail to invalid virtual users? Or does this situation *have* to be dealt with earlier, by the MTA?
yes. see www.backscatterer.org for an incentive ;-p
participants (5)
-
Andreas Ntaflos
-
Andreas Ntaflos
-
Charles Marcus
-
Ed W
-
mouss