Re: [Asrg] Some data on the validity of MAIL FROM addresses

>>> Can you show instances in which they say yes to messages they cannot
>deliver?
>
>
>VS> I was skeptical of the report that Yahoo defers no-such-user responses
>VS> until the DATA command, and so I made the obvious `telnet ... 25`
>test.
>VS> I tried a perfectly valid message to an address that was very unlikely
>VS> to exist.  The Rcpt_To command was answered with at 250 response.  It
>VS> was not until the end of the DATA command that I got a 5yz.
>
>
>Folks, the email operations world has increasingly moved away from
>real-time processing of SMTP data.
>
>Processing causes delays and SMTP client daemons are impatient. The
>very, very wide range of network delays has compunded the effect of
>these processing delays, constantly causing problematic timeouts.
>
>So the tendency, these days, is to just say 'yes' in the protocol, take
>the addresses and content, store them in a queue, and do any real work
>after the connection closes.
>

The tendency may have been to move away from "real-time processing of SMTP
data", however with the increasing spam burden I wouldn't be surprised to
see the pendulum swing back. Only by making checks at the border can
traffic be rejected as near source as possible.
It's interesting that some MTAs nowadays offer hooks for highly
configurable checking during SMTP transaction (I'm thinking of the
local_scan interface in exim 4). The economics of handling spam
(and spam bounces) can make this very attractive even for high traffic
operations.

It seems sensible that a system should not accept messages that won't be
deliverable. The whole "accept anything / bounce it later" model is not
IMHO the wave of the future, rather expending CPU at the boundary MTA (and
providing the infrastructure to make checks) conserves resources later on.

Of course there are issues with implementation - I seem to remember hotmail
having problems with distributing their user database to their outward
facing MTAs in the past. However, we're all familiar with the sight of
systems failing under the demands of handling *bounces* (to non-existent
senders?) following massive spam runs (dictionary attacks) against them.

--
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg