On Oct 28, 2015, at 2:34 PM, Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org> wrote:
On Wed, Oct 28, 2015 at 02:14:23PM -0400, Ted Lemon wrote:
And this is because the SMTP store-and-forward model requires that error
messages be delivered asynchronously, which is another architectural
problem with SMTP.
1. There is no requirement to always send asynchronous bounces,
most properly operated mail systems strive to reject
synchronously rather than accept and then bounce. Avoidable
backscatter is frowned upon.
2. It is not possible to *guarantee* delivery of all mail accepted
for onward relaying. *Some* asynchronous errors are unavoidable.
If error messages could be delivered at the moment of transmission rather
than later, at least most of the time, this wouldn't be an issue.
Most of the time, on properly configured receiving systems, errors
are already synchronous.
This is almost never the case.
Actually, in the SMTP world, it's almost always the case. The majority of email
systems go to *tremendous* lengths to perform all SMTP rejections at the point
of ingress to the administrative domain, because doing anything else
unavoidably creates large amounts of blowback spam. And that's not acceptable
for a bunch of different reasons.
In the very rare cases where a check ended up having to be done somewhere past
the ingress MTA at a site that uses our software, a bug filing was always the
immediate result. And I can assure you we accord such bugs the highest possible
priority, because we're well aware of how serious their effect can be on a
site's reputation.
Sure, if you send mail to a RCPT TO: that fails, then you can get immediate
notification, but rejection of attachments generally happens after the mail
has
been accepted and queued.
Interestingly, you're wrong on both counts. SUBMIT-time recipient address
validation is generally only achievable for addresses within an administative
domain. The minute you send to someone outside your ADMD, such validation gets
to be much more difficult for a variety of reasons.
And the same rules apply regardless of your rejection criteria. Intra-ADMD
Messages are rejected based on content analysis at submission time all the
time. Messages destined for other ADMDs are not, because the rejection criteria
are implemented by the other ADMD's servers and are not available to the SUBMIT
server. But in such cases the rejection does happen at the ADMD ingress point.
To put this another way, is it's not the nature of the check, it's who is
performing the check, that determines whether or not it can be done immediately
from the MUA's perspective.
In order to _bounce_ a message based on content,
you need to evaluate it before sending the "250 Message Accepted response."
Yep, and that's exactly what is done. Routinely and at enormous scale.
There is a valid code for that, which I don’t remember off the top of my
head, but I don’t know of any MTAs that use it.
For better or worse, the code for the MTAs handling the majority of the world's
email is no longer something you can inspect. But even looking at the open
source world, there are a number of milters with this capability, and there's a
selection of MTAs that support milter.
The point is that it is possible following the current specs to deliver an
immediate response in the majority of cases, but that isn’t being done, and
furthermore MUAs aren’t expecting it, and so probably won’t give the user a
message that explains to them why the message was rejected. This is an
entirely solvable problem, but it is not a solved problem.
Your problem is you're confusing and conflating message submission (SUBMIT) and
relay (SMTP). We now talk about these as separate protocols for a reason.
And as far as MUA handling of various sorts of errors, it really depends on the
mail client. Some clients handle immediate errors well, others do it poorly,
and some are abysmal. By the same token some clients handle nondelivery report
messages well and some do not.
MUAs aren't really my thing, so I can't really talk about what's common
and what isn't in that space.
In any case, the bottom line is you're jumping to conclusions about a vast
infrastructure that's currently handling in excess of a trillion messages a day
based on what appears to be little more than your personal experience. And I
must say if your experience is what you say it is, it's more than a little
atypical.
Ned