On Wed, 19 Jan 2005, Ryan Tracey wrote:
> Thanks for clearing that one up. So it is better to warn initially
> and later use the X-Broken-Reverse-DNS header -- if you don't want
> someone elses broken DNS to cause their emails to be indefinitely
> temporarily rejected (considering that they are probably going to
> take a long time to fix their DNS.)
Keep in mind that if you accept mail "from" a persistently unreachable
address, your recipient isn't going to be able to reply to it anyway.
Much of that junk is abusive anyway (spam/malware); as for the
minority that is bona fide, it seems to me that a well-intentioned
sender would like to be informed as soon as possible that their
address is (or has become) persistently unreachable. Since, in this
kind of situation, one cannot email them to tell them the bad news,
there's one sure way to let them know - to refuse mail from them, with
a hint that if they can't get the problem fixed at their end, they
should contact our postmaster address (which is, by and large,
unfiltered, in accordance with RFC guidelines). We can then consider
whitelisting or whatever other measures might be appropriate.
In short: domains which are persistently tempfailing at the "verify =
sender" (and/or "verify = header_sender") check get put into our local
unreachable_domains list, and we then permfail mails from those
domains, except to postmaster/abuse.
> Is there any way to detect broken DNS (someone elses) and generate a
> defer with wording specific to that problem.
Ours says something like this[1] -
deny [...]
message = We are currently unable to accept mail from \
$sender_address_domain\n\
because that mail domain is persistently unreachable or not\n\
responding properly, for reasons that are outside our control.\n\
We do not know if/when the problem will be resolved: \n\
if the matter is urgent, contact postmaster@???
in the RCPT ACL. There's an analogous clause in the DATA ACL:
message = We are currently unable to accept mail from \
$h_from: \n\
because [...]
With us, that local unreach_domains list is maintained manually. I.e
entries added by hand - occasionally verified by running a script,
and, where appropriate, deleted by hand. In a larger operation, I'm
sure we'd have a log-watching script looking for persistent tempfails
and taking appropriate action. YMMV.
[1] Yes, with the benefit of hindsight we know that verbose multi-line
responses cause problems to some MTAs. Ho hum.
