Re: [Exim] OT: Problem sending mail to verizon.net

On Wed, 5 Nov 2003, Greg A. Woods wrote:

> There's no real point to doing any "active/real-time" sender address
> verification by way of SMTP connections to the sender's MX, and worse
> ends up causing all these problems you're complaining about.

It's a point of view; but if done *selectively*, our experience is
that it can keep out a deal of spam, so I wouldn't reject it out of
hand.

OTOH, if done *globally* it would doubtless result in some loss of
bona fide mails (from misguided MTAs, maybe, but the users were bona
fide); one would be entitled to say it wasn't our fault - we were only
applying well-established interworking rules, and if they or their
vendor chose to disregard those rules, too bad for them. But the
users would likely not understand that anyway, so we don't drive it
that far.

> SMTP is not a "real-time" protocol -- it's a store and forward protocol.

It may have been intended that way, back when all the participating
sites could be deemed well-intentioned - and quite ready to hang any
offending users of theirs from the flagpole. Those times are long
gone, and if you accept spam or other garbage for storing and
forwarding, only to find that the destination site won't accept it and
the purported sending site won't accept the non-delivery notification,
then you have yourself to blame, basically.

> Attempting to implement sender address verification by way of testing
> SMTP connections to the sender's MX breaks the store & forward model in
> a fundamental way.

Indeed it does, but that only helps to confirm that the store and
forward model, in its most general form, is now dead. One stores and
forwards for one's own accredited intermittently-connected users, but
one would be well advised not to store and forward (relay) for
untrusted other MTAs out there. But I really don't need to remind you
of that!