Συντάκτης: Pat Lashley Ημερομηνία: Προς: Exim Users Mailing List, Alan J. Flavell Αντικείμενο: Re: [Exim] OT: Problem sending mail to verizon.net
--On Thursday, November 06, 2003 15:17:53 -0500 "Greg A. Woods"
<woods@???> wrote:
> [ On Thursday, November 6, 2003 at 00:04:53 (+0000), Alan J. Flavell
> wrote: ]
> SMTP _IS_ a store and forward protocol, BY DESIGN. PERIOD.
Although SMTP strongly supports store-and-forward, there is nothing
in the RFC that mandates, or even indicates a preference for that
paradigm over direct immediate delivery.
> Glomming on active SMTP-based sender address verification is not a
> design change -- it's a very bad and stupid hack that violates these
> fundamental design limits in the SMTP protocol. It causes serious and
> now well documented interoperability problems on several levels.
Bullshit! When implemented correctly, it is a perfectly good
technique to get a first-order approximation of what will happen
if you accept a message and then attempt to bounce it. Note
that the only results it can produce are "Nope, we won't accept
it", and "Maybe we will accept it".
Any store-and-forward aspect of SMTP has nothing to do with the
validitity of the check. You aren't checking the final result,
only the MTA to which you would be handing off the bounce.
Of course, bad implementations can cause problems. But that's
true of the rest of SMTP; and everything else for that matter.
I missed part of this thread; so perhaps there's some problem
of which I'm unaware. But the only problems I've seen are when
some idiot thinks that (s)he has a good reason to send a (non-
bounce) message which can't be bounced. Since there is -NO-
legitimate excuse for doing that; I don't see the problem.
(I'm generally a strong supporter of the 'Be liberal in what
you accept; conservative in what you send' philosophy. But
the abuses by spammers and viri have caused me to take a much
stronger standards-compliance line with e-mail. Unfortunately,
legitimate operators of non-compliant MTAs generally ignore
external requests to fix their configurations. So the only
way to get them to listen is if enough other sites refuse to
communicate with them that their own customers start raising
a ruckus. I would still not advocate doing that if it were
not for the fact that tightening compliance checks also makes
it much harder for spammers to hide the true origins of their
messages.)