Folks, please tone down the rhetoric, read the specs, try to
understand the comments Dave Crocker and I made, and at least be
clear about the difference between your taste and what SMTP
requires and allows. There actually are reasons for most or all
of SMTP. If you think those specifications are incorrect, I
look forward to seeing the well-reasoned I-D, one that starts
from the Internet email environment as it actually exists
outside the giant providers (and as several people, notably
including John Levine) keep trying to explain).
Some particular comments below.
--On Wednesday, October 28, 2015 19:27 +0000 Viktor Dukhovni
<ietf-dane@xxxxxxxxxxxx> wrote:
> On Wed, Oct 28, 2015 at 02:40:57PM -0400, Ted Lemon wrote:
>
>> > 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.
> You're clearly sending mail to poorly operated systems, likely
> to systems where the attachments are rejected somewhere other
> than at the edge MX host. Such systems should not be
> rejecting the attachments, it is too late for that, once it
> crossed the line from "outbound" to "inbound". The systems in
> question need to apply their attachment policy closer to the
> "edge", i.e. at the first inbound hop.
If you are describing what you consider good practice, then
fine. But SMTP requires no such thing and there are perfectly
reasonable configurations that make it impossible without
rejecting messages that should not be rejected (see John
Levine's comments about complaints about why mail was not
delivered, but that is only part of the issue).
And please don't talk about "edge MX host" when you probably
mean "final delivery MTA" or equivalent. They are different and
the spec very deliberately allows some cases that "edge MX host"
probably doesn't cover.
>> 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.
No, in order to _reject_ a message as part of the SMTP dialog,
you clearly need to evaluate it before that dialog is complete.
Depending on how the delivery SMTP server is configured, that
may or may not be possible and it is, in general, neither a
violation of the standard nor of good sense to configure it that
way (optimality for that case involves a lot of factors even
though operational conditions these days, especially
"backscatter" risks, usually favor rejection over bouncing. You
can _bounce_ a message at any point prior to delivery into a
mail store (and maybe after that).
A "250 Message Accepted response" does not mean the message must
be delivered. It means that the MTA has taken responsibility
for it and, barring very unusual circumstances (e.g.,
"operational necessity") will either deliver it as intended or
generate a bounce message (aka NDN).
> The SMTP reply code and DSN code SHOULD be correct, but are not
> especially critical. Any 5XX 5.N.M code will have the effect
> of synchronously rejecting the message.
Yep. SMTP is very clear about that and has been since RFC 821
-- especially if there is any doubt, only the first digit of the
reply is actionable.
> Postfix has header/body checks that reject based on content,
> and supports milters and proxy filter that can do the job out
> of process. The reply for bad content in Postfix defaults to
> "550 5.7.1 message content rejected".
Good for Postfix. The last I heard, it was not the standard.
>> 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,
>
> Well it is being done, and Postfix users are strongly
> encouraged to do so whenever backscatter is discussed on the
> users list.
>
> Systems where content inspection happens after mail is queued,
> and unwanted content triggers bounces are misconfigured.
Thank you for your opinion. While I also generally prefer to
have them configured some other way when that is feasible,
"misconfigured" goes too far. As a particular example, it is
often desirable to configure one or more lower-preference MTA to
collect mail traffic when the preferred delivery server is not
available. It is also common, but not an SMTP requirement, that
the lower-preference MTAs have enough information about the
delivery environment to be able to reject messages for some
reasons, e.g., "no such mailbox" conditions as well as, or
instead of, message header or content conditions. However, such
arrangements can easily lead to race conditions such that, if
the lower-preference servers are configured _really_ carefully,
they should not return "5yz no such mailbox" code unless they
know that from, e.g., syntax rather than by absence from a list
of mailboxes but should probably return a 4yz code or accept the
message and then let the final delivery server make the
deliverability determination and generate an NDN if needed
(because, other than just discarding the message, that it the
only thing it usefully can do).
>> 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.
>
> I await patches for Postfix and your favourite MUA that solve
> this "entirely solvable" problem.
>
> MUAs are a very different issue. The MSA should generally
> accept and bounce back to the authenticated user, this is
> fine, because the MSA authenticates the client. MUAs are
> often not able to deal with rejection at submission time,
> especially rejection for a subset of the recipients. Nor is
> it possible for the MSA to synchronously report remote rejects
> from (some subset of) the receiving domains.
Some of that may be an argument for MUA using proprietary and/or
out-of-band means, rather than slightly modified SMTP, to
communicate with the submission server. But that has been
allowed since the beginning of SMTP and was normal practice for
many years. But expecting such rejections to always be
detected and reported in real time requires that the submission
server attempt mail delivery when the MUA connection to it is
still open _and_ that it be able to make a direct connection to
the final delivery MTA and do on its first attempt. See Dave
Crocker's notes about those assumptions.
best,
john