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. 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. In order to
_bounce_ a message based on content, you need to evaluate it before sending the
"250 Message Accepted response." 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.
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.