0

Is it possible to exempt "MAILER DAEMON" messages from alias expansion or relaying?

Context: Let's illustrate the problem is on this trivial forward-all setup:

/etc/aliases
root: monitoring@domain.com

/etc/postfix/generic_maps
@host.local linuxmail@domain.com

/etc/postfix/main.cf
relayhost = [smtp.domain.com]:submission

When the relay breaks

  • regular cronjob tries to send e-mail From:root@host.local
  • it gets rewritten by aliases and encounters relaying failure
  • "MAILER DAEMON" sends warning e-mail To:root@host.local
  • it gets rewritten by aliases and encounters relaying failure
  • the errors uselessly clutter the queue

I'd like them delivered to local inbox, alerting administrators who log in.
How do I exempt the error mail from alias expansion and/or relaying?

0

1 Sane solution

/etc/postfix/main.cf
   bounce_queue_lifetime = 0
   notify_classes = bounce
   bounce_notice_recipient = bounces@<yourdomain.tld>
  • You may be tempted to disable bounce(8) service, but I expect that disables postmaster bounces.

For more details see the Drop undelivered MAILER-DAEMON and collect bounces in postfix

How it works:

  1. Undeliverable bounce messages are deleted
  2. A copy of all bounce messages is sent to bounces@<yourdomain.tld>

Drawbacks: 1) bounces@<yourdomain.tld> must be a non-redirected local inbox. 2) original bounce messages are deleted after the server attempts their useless delivery over the failed relay

2 Slightly Insane solution (untested)

/etc/postfix/main.cf
   sender_dependent_default_transport_maps = hash:sender_dependent_default_transport_maps
   virtual_mailbox_base = /var/spool/mail
   virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_maps
   virtual_uid_maps = hash:/etc/postfix/virtual_uid_maps
   virtual_gid_maps = static:<GID_of_/var/spool/mail>
   #virtual_mailbox_domains = <yourdomain.tld> #MAYBE
sender_dependent_default_transport_maps
   MAILER-DAEMON@<yourdomain.tld> virtual:
/etc/postfix/virtual_uid_maps
   alice@<yourdomain.tld>   1000
   bob@<yourdomain.tld>     1002
   charlie@<yourdomain.tld> 1001
/etc/postfix/virtual_mailbox_maps
   alice@<yourdomain.tld>    alice/
   bob@<yourdomain.tld>      bob
   charlie@<yourdomain.tld>  charlie
  • Don't forget to $postmap all *_maps files after every change.

For more details see the virtual delivery agent manpage and collect bounces in postfix

How it works:

  1. sender_dependent_default_transport_maps forces bounce delivery by virtual: delivery agent ...
  2. ... which delivers the message to mailbox/maildir configured in virtual_*_maps

Drawbacks: 1) Untested. 2) Will never deliver to UID below virtual_minimum_uid. 3) virtual_*_maps must be manually kept in sync with existing user accounts

3 fully Insane solution

/etc/postfix/main.cf
   virtual_mailbox_base = /var/spool/mail
   virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox_maps
   virtual_uid_maps = hash:/etc/postfix/virtual_uid_maps
   virtual_gid_maps = static:<GID_of_/var/spool/mail>
   virtual_mailbox_domains = bounces.<yourdomain.tld>
   smtp_generic_maps = regexp:/etc/postfix/generic_maps
   sender_canonical_maps = regexp:/etc/postfix/canonical_sender_maps
/etc/postfix/virtual_uid_maps
   alice@bounces.<yourdomain.tld>   1000
   bob@bounces.<yourdomain.tld>     1002
   charlie@bounces.<yourdomain.tld> 1001
/etc/postfix/virtual_mailbox_maps
   alice@bounces.<yourdomain.tld>    alice/
   bob@bounces.<yourdomain.tld>      bob
   charlie@bounces.<yourdomain.tld>  charlie
/etc/postfix/generic_maps
   /@bounces./ @
/etc/postfix/canonical_sender_maps
   /^([^@]*)$/ $(1)@bounces.<yourdomain.tld>
   /^([^@]*)@/ $(1)@bounces.
  • Don't forget to $postmap all *_maps files after every change.

How it works:

  1. canonical_sender_maps adds "bounces." to senders of all locally queued mail
  2. If a message goes out by SMTP, smtp_generic_maps undoes the change
  3. If a message bounces, smtp_generic_maps does not apply ...
  4. ... and notification is delivered to virtual domain @bounces.<yourdomain.tld>...
  5. ... which delivers the message to mailbox/maildir configured in virtual_*_maps

For more details see the address rewriting overview

Drawbacks: 1) Insane. 2) Will never deliver to UID below virtual_minimum_uid 3) virtual_*_maps must be manually kept in sync with existing user accounts

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.