I'm working on updating contrib/doublebounce.pl in the sendmail
distribution. If you have specific questions about my work there
please e-mail me off list, but I do have one on-list topic I'd like
to discuss.
A quick summary, a "double bounce" is when an e-mail bounces, and
then the bounce notification also bounces. This is a common
occurrence for people like me, I run www.tmbg.org which offers your
choice of aliases @tmbg.org. These are in fact just forward rules
to a users real e-mail (think also pobox.com). Generally speaking,
the box doing the relaying must accept the mail, discover that the
actual recipient is unavailable, and then finds itself unable to
deliver the failure message.
I'm sure it will come as no surprise that many of these are spam.
This is my motivation to do two things, first get it out of my in
box and second notify someone who might be able to do something
about it.
Anyway, sendmail (and probably other MTA's) allows these messages
to go to a special place. In my case, a perl script inspired by
contrib/doublebounce.pl. The idea is to automatically figure out
which postmaster to notify of the problem, and send them a notice.
That is the crux of my question. Who should be notified? That
information must come from the header of the original message,
so the options are fairly limited. I don't know of any RFC that
covers this specific case (but if there is one I would love to
know), so I'd like to find some community consensus.
Basically, there are two schools of thought:
1 - Notify postmaster@ for the domains in the normal fields
you would use to reply to a message (Sender, Reply-To,
From, Errors-To).
2 - Notify postmaster@ for the domains in the Received headers,
starting with the first one the mail passed through and
working forward until notification succeeds.
When looking at each case, you can also then apply a depth first
(eg, try foo.bar.com, then bar.com, then foo.baz.com, then baz.com)
for bredth first (foo.bar.com, foo.baz.com, bar.com, baz.com)
method.
There are drawbacks to both. Addresses in #1 are often forged,
causing postmaster@ the forged domain to get all sorts of unwanted
notices about people using his domains. Method #2 would seem to fix it,
but often the first postmaster@ is owned by the spammer, and is in
fact a black hole.
So, if I'm going to rewrite the script what logic should I use?
If there are any RFC's that pertain to this problem I would love
to know what they are so I can follow them, but I suspect there
are not any. I might even be able to live with two choices of
how the script should work, if that seems like the right thing
for people to do.
Thank you for your input.
--
Leo Bicknell - bicknell(_at_)ufp(_dot_)org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request(_at_)tmbg(_dot_)org, www.tmbg.org
pgpwMDzcq0qjj.pgp
Description: PGP signature