The exact answer to your question (handling the bounce-xxx@example.com
address) depends on how your server is configured to receive mail. If example.com
is the virtual domain the best you can do is collect the messages in the bounce@example.com
mailbox (assuming recipient_delimiter = -
).
If example.com
is the locally delivered domain for the server (mail is delivered to actual system accounts) then you can add a .forward
file to the home directory of the bounce
user, which delivers to a program that parses the bounce information and records it in a database or file. See man local
for more info on the .forward
format and how to deliver to a program.
What we do, since we send messages for a large number of domains, is use bounces.example.com
as our VERP domain. This domain needs to be added to relay_domains
. Create /etc/postfix/transport_maps
with this content:
bounces.example.com bulkbounce:
Then append a line similar to this to /etc/postfix/master.cf
:
bulkbounce unix - n n - - pipe
user=nobody argv=/usr/local/bin/bounce_handler.py ${recipient}
The bounce_handler.py
script accepts the VERP address as its command line option, parses it and makes the necessary database updates to record the bounce.
The status value itself isn't as valuable as the data in parenthesis that directly follows it, which gives a better description of what's going on.
"Message queued for delivery"
- This means the transaction between your server and the target server has yet to transpire for that particular message, this usually means something just sent the message, and your SMTP server is acknowledging it's existence
"Message Accepted"
- This means the destiantion server acknowledges that the message has been received on it's end. (It doesn't indicate read)
"Bounced"
- This typically means that something went wrong - either the email was rejected from the target email server because the email address didn't exist, OR it could be rejected due to being on an RBL. This also means the email will NOT be delivered, nor handled anymore by the server. AKA: The message is dead in the water.
"Deferred"
- This means that something temporary has happened to cause the message to not be delivered, but the server (yours) hasn't given up and will try again later. This is also common to see when the target SMTP server uses an anti-spam technique known as 'greylisting'.
Other things, here's an example of a log line from my mail.log:
postfix/qmgr[32131]: 3858792A80: from=<foo@domain.com>, size=757, nrcpt=1 (queue active)
postfix/smtp[32135]: 3858792A80: to=<foo@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.91.27]:25], delay=8, delays=8/0.01/0.4/1.5, dsn=2.0.0, status=sent (250 2.0.0 OK
1307169606 6si4629303qcd.120)
relay=gmail-smtp-in.l.google.com[74.125.91.27]:25]
= Target SMTP server for the 'to' email address
delays=0.08/0.01/0.4/1.5 =
- 0.08s = time from message arrival to last active queue entry
- 0.01s = time from last active queue entry to connection setup
- 0.4s = time to negotiate connection (EHLO, etc)
- 1.5s = time spent transferring entire message
A good way to learn is to simply tail your mail log and send emails in various ways - watch what happens when you send to bad accounts; or to a server that uses greylisting.
block the outbound port and send one.
Best Answer
Out-Of-Office replies do usually get sent via return-path, yes.
It's correct to the RFC specs, too. More info here: https://www.rfc-editor.org/rfc/rfc3834