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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg