[conspire] (forw) [sorbs.net #212641] [Webform] SORBS registration systems sends RFC-ignorant mail

[Rick Moen]

Hi, Ruben.  Apologies if I was brusque.  Your question caught me at a
bad moment, and I didn't have time to elaborate.

Quoting Ruben Safir (ruben at mrbrklyn.com):

> How are you going to check the user if you can't reach the machine?

So, to elaborate:  ;-> 

My MTA does not aspire, and doesn't need to aspire, to ensure that the
claimed sender of any arriving mail has a UID on his/her local machine.
That's just not relevant to the situation at all.  For purposes of
RFC-compliance -- and I'm actually, truth to tell, at this moment at a
small loss to tell you where exactly the RFCs state this requirement --
it suffices for my MTA to investigate whether the claimed sender e-mail
address is deliverable for return mail at the domain's advertised mail
exchangers (MXes).  I.e., if your address originates mail, the RFCs
require that the sending mailbox be a valid destination for return mail.

That would be one of several things that can be checked during SMTP time
(during a pending attempt by some remote SMTP host to deliver mail, but
before one's own MTA accepts or declines the mail) as what is termed a
"callout" aka "callback" check.  Essentially, _while_ the inbound SMTP 
attempt is still ongoing, a separate fork of your MTA initiates a return
SMTP connection to one of the claimed sender domain's publicly
advertised MXes, and announces that it wishes to drop off a mail for the
claimed sender.  If the remote MTA says "250" to indicate that the
recipient will accept the return mail, then my own MTA cancels the
partial delivery.  My own MTA _also_ caches the successful callout, 
so as _not_ to be guilty of the network abuse that the SORBS guy
unreasonably claims is inherent in any use of callouts.

The other common callout items are the existence of a deliverable
"postmaster" and "abuse" mailbox at the claimed sending domain.  For
those, I _can_ cite if you need them exactly where the RFCs mandate them
for any domain that sends SMTP.

The point is not to be an RFC zealot, but rather to suss out mail that's
highly likely to be spam/malware -- because spammers/malware authors
typically cannot be bothered to make their ratware deliver mail in an
RFC-compliant manner.  Thus, RFC-non-compliance tends to correlate
strongly with spamicity, and makes an excellent antispam heuristic.

And, as I was saying, because reverse DNS is _not_ RFC-mandated, that is
a really _poor_ idea as an antispam heuristic.  Yes, I know there are
people who do that, but they're deluded.