We are using postfix 2.7 and custom SMTPD (based on qpsmtpd) in highly customized configuration for spam filtering. We have a new requirement to filter postfix-generated bounces through our custom qpsmtpd process (not so much for content filtering, but to process these bounces accordingly).

Our current configuration looks (in part) like this:

main.cf (only customizations shown):

2526      inet  n       -       -       -       0       cleanup
pickup    fifo  n       -       -       60      1       pickup
  -o content_filter=smtp:

Our smtpd injects messages to postfix on port 2526, by speaking directly to the cleanup daemon. And the custom pickup command instructs postfix to hand off all locally-generated mail (from cron, nagios, or other custom scripts) to our custom smtpd.

The problem is that this configuration does not affect postfix generated bounce messages, since they do not go through the pickup daemon.

I have tried adding the same content_filter option to the bounce daemon commands, but it does not seem to have any effect:

bounce    unix  -       -       -       -       0       bounce
-o content_filter=smtp:
defer     unix  -       -       -       -       0       bounce
-o content_filter=smtp:
trace     unix  -       -       -       -       0       bounce
-o content_filter=smtp:

For reference, here is my main.cf file, as well:

biff = no
# TLS parameters
smtpd_tls_loglevel = 0
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtp_tls_security_level = may

mydestination = $myhostname
alias_maps = proxy:pgsql:/etc/postfix/dc-aliases.cf
transport_maps = proxy:pgsql:/etc/postfix/dc-transport.cf

# This is enforced on incoming mail by QPSMTPD, so this is simply
# the upper possible bound (also enforced in defaults.pl)
message_size_limit = 262144000
mailbox_size_limit = 0

# We do our own message expiration, but if we set this to 0, then postfix
# will try each mail delivery only once, so instead we set it to 100 days
# (which is the max postfix seems to support)
maximal_queue_lifetime = 100d

hash_queue_depth = 1
hash_queue_names = deferred, defer, hold

I also tried adding the internal_mail_filter_classes option to main.cf, but also tono affect:

internal_mail_filter_classes = bounce,notify

I am open to any suggestions, including handling our current content-filtering-loop in a different way.

If it's not clear what I'm asking, please let me know, and I can try to clarify.

  • No for me it is not clear what you are asking. Do you want all bounces created by external servers go into one mailbox (or instead of a mailbox through a content filter or a script)? Or do you want all bounces created by Postfix go into a mailbox/filter/script? – mailq Sep 8 '11 at 8:41
  • The latter, I want all bounces created by postfix to go through our custom smtpd. – Flimzy Sep 8 '11 at 16:10

In this case you do it too complicated. This is the easy way.

You need to have this (additional) in your main.cf:

notify_classes = resource, software, bounce, 2bounce
bounce_notice_recipient = random.bounce@example.com
2bounce_notice_recipient = random.bounce@example.com
transport_maps = hash:/etc/postfix/transport_maps   #or another file. See below.

in the /etc/postfix/transport_maps put

random.bounce@example.com    smtp:

then postmap /etc/postfix/transport_maps. Afterwards postfix reload or restart Postfix.

This will notify the random.bounce@example.com user of all bounces and as this user is said to be transported through you get all these mails through that server. Replace the addresses/IP/port according to your environment.

  • This has potential, but isn't ideal, as it means the original recipient address doesn't remain in tact. Is there some other way to preserve that? Maybe in a mail header? Our custom filter can easily grab that data from wherever it is... – Flimzy Sep 8 '11 at 20:07
  • The original recipient of the bounce would be postmaster. But this is also not that what you want. You need the sender of the original (bounced) mail and this is only in the body of the bounce but not in the header of the bounce. – mailq Sep 8 '11 at 20:14
  • I see, so in this case, the original bounce is still sent as it normally would... with an additional notification of the bounce being sent to postmaster (or in our example, to random.bounce@example.com). Am I understanding this correctly? – Flimzy Sep 8 '11 at 20:36
  • That's right. This is how it must be done according to RFC 5321 section 3.6.3 paragraph 3. – mailq Sep 8 '11 at 20:40

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.