Erwin Authried:
> I'm routing messages to a couple of servers with the transport map
> mechanism. I'm using recipient address verification to avoid bounce
> messages. This works fine with mail servers that send a 550 response,
> for example:
> 
> RCPT TO: non-existent-u...@somedomain.com
> 550 5.7.1 Unable to deliver to non-existent-u...@somedomain.com
> 
> There are some mail servers with qmail that do not send an error
> response after RCPT TO:, but later after the "DATA" command:
> 
> RCPT TO: non-existent-u...@somedomain.com
> 250 OK
> DATA
> 554 sorry, invalid mailbox name(s). (#5.1.1)
> 
> In this case, a bounce message is sent to the sender. Is it possible to
> configure the postfix server to reject the message like in the first
> case?

And what if the address exists? Then the end-of-data reply would
be "250 OK", and the recipient would receive a copy of the address
verification test message!  Clearly, not a good idea.

If qmail can't be fixed to reject unknown recipients, then you will
have to configure Postfix relay_recipients_maps to block unknown
recipients instead.

The following example assumes that the qmail machine is responsible
for a domain name that differs from other domains that you handle
mail for.

Unfortunately, this means you also have to add wild-card entries
for the domains that do support recipient verification. otherwise
Postfix would reject their mail.

/etc/postfix/main.cf:
    relay_recipient_maps = cdb:/etc/postfix/relay_rcpts

/etc/postfix/relay_rcpts:
    # Rules for domains that support recipient verification.
    @good-domain1       whatever
    @good-domain2       whatever
        ...
    # Rules for domains without recipient verification.
    user1@qmail-domain  whatever
    user2@qmail-domain  whatever
    user3@qmail-domain  whatever
        ...

Instead of cdb you can use lmdb, or with some care, Berkeley DB:

    # vi relay_rcpts.new
    # postmap relay_rcpts.new && mv relay_rcpts.new.db relay_rcpts.db

This is the "safe Berkeley DB" method in the DATABASE_README
document.

        Wietse

        Wietse

Reply via email to