dovecot - Apr 2008 - 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
at example.org"
and "bob at example.org". 

But today I received spam mail (which was correctly identified as such by 
amavisd-new) for "info at example.org" and "sales at
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 at exmaple.org): unknown user
dovecot: auth(default): passwd-file(info at mexample.org): unknown user
dovecot: auth(default): static(info at example.org): passdb doesn't support 
lookups, can't verify user's existence

postfix/pipe[25328]: C7EA18BC0B5: to=<info at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20080417/1c6d52b7/attachment-0002.bin>

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 at example.org"
> and "bob at example.org". 
>
> But today I received spam mail (which was correctly identified as such by 
> amavisd-new) for "info at example.org" and "sales at
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 at exmaple.org): unknown user
> dovecot: auth(default): passwd-file(info at mexample.org): unknown user
> dovecot: auth(default): static(info at example.org): passdb doesn't
support
> lookups, can't verify user's existence
>
> postfix/pipe[25328]: C7EA18BC0B5: to=<info at 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
>