On Oct 28, 2015, at 2:34 PM, Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> 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.