that's larger than Alice accepts, I don't believe he's going to like
not being told Alice didn't get it because he also sent a copy to
Charlie. Especially when it didn't work that way last quarter.
But if Alice was silently dropping the message last quarter.
Bob is no worse off.
That violates my supposition that
"it didn't work that way last quarter".
I suppose one could claim that that's an unreasonable supposition,
but I don't believe that's what you were trying to do.
No it doesn't. I posit the case where it didn't work "last quarter".
Your objection stands, given your preconditions.
Yes, sometimes it's the same as before, but sometimes it's not.
I'm not concerned about the times when it's the same as before.
You should be - these are also valid cases.
In fact, since this behaviour is (from the start of this quarter)
standardized, Bob now knows that if he needs the QOS he was *assuming*
to be in place, he can ask for it. Alice can give him an appropriate
negative response after DATA. No changes needed to the syntax or
sequencing
(or number)
of commands.
I guess I'm not understanding the proposal.
If it's documenting that "The sender shouldn't depend on getting
notified if the email isn't delivered, especially if sent it to
more than one recipient" then ok.
I'd also add that it would probably be a good idea to add
"MTAs SHOULD NOT combine identical messages to a single domain
when they are queued separately since it's possible that the sender
was attempting to get a higher quality of service."
You may be right, and if anyone ever formally proposes such a thing, they'd
probably be wise to include something along these lines.
If it's documenting the practice of not sending a DSN when there's
more than one recipient, and claiming that as MAY or even worse SHOULD,
then not ok.
Oooh, no, I didn't suggest any such thing (please see below).
If you change the probability of receiving a DSN based on
number of recipients, then even a party who chooses
not to implement it will be forced to change their behavior
if they want the best chance of it working the old way.
I.e. instead of sending messages in batches,
they now must send each message separately.
Yes. If they want to explicitly request the QOS that they were assuming.
Thus this would increase the number of senders who send
a separate message to each recipient. I get penalized every time
one of those users sends two of my users the same message,
But you've failed to consider any possible advantages.
Senders of bulk-mail (those who ask for the high QOS) are
penalised to the same extent. Overall costs in the MTS *may* increase
or may not - it's not clear. Some study (or modeling) might be useful.
Such a change might allow you to provide per-user filtering at the MTA (a
selling proposition) without impacting the overall reliability
of the MTS. It's not easy to say (even if you're a net receiver of mail)
that the costs outweigh the benefits. Costs at the boundary
are not the only costs. It's not clear that you are (on balance)
penalized.
even if I think "the proposal is new and therefore, bad.".
I don't see any way to not consent to the change.
Changing the meaning of a response effects everyone
who /doesn't/ upgrade.
No, not in practice. If I get all positive responses and no DSN
I still don't know that my message actually gets to the mailbox.
What does a 250 after data *mean* to the sender now?
Well if I'm the sender, it means I expect the receiver to behave as
RFC 2821 specifies, to wit:
No, that's your expectation. This is a string emitted by the receiver. It
does not *mean* that the receiver is behaving in strict accordance with RFC
2821.
6.1 Reliable Delivery and Replies by Email
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
message in response to DATA), it is accepting responsibility for
delivering or relaying the message. It must take this responsibility
seriously. It MUST NOT lose the message for frivolous reasons, such
as because the host later crashes or because of a predictable
resource shortage.
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message.
And that's the problem, not that 2821 says "MUST" regarding DATA,
but that it says MUST regarding the notification. I've always thought it
strange that the protocol spec. relies on (what is effectively) OOB
communication. Also, it's kindof a moot point whether blackholing (say)
based on policy *is* a "delivery failure".
My point is that MUST DSN (in all cases) may be too strong.
Maybe what I suggested might be better called "clarification"
Another curiosity in 2821 is "Rejection of messages (for excessive
recipients) with fewer than 100 RCPT commands is a violation of this
specification. ". I guess this was intended as some kind of optimization.
And we all know about premature optimization. This
is another area where many systems cheerfully fail to comply.
I personally don't expect the receiver to always succeed,
but if 2821 says MUST, I expect a best effort attempt.
I don't see an exception like "... unless two recipients
are specified and one thinks you're a spammer,
in which case you can skip the notification message when you
don't deliver to that one."
If the receiver doesn't try and send a DSN, then I'm likely to refer
to their mail system as "non-compliant" in public, and something
less polite in private.
So you'd expect a DSN if a recipient deletes a message without reading it?
No, of course not. What if the MTA is behaving as the
users agent?
Of course, it's unlikely the receiver will do anything other
than what they damn well please, but even if most people don't
bother with DSNs currently, it does not follow that not sending
them is BCP. Nor does it follow that because notification of
delivery failure is not guaranteed, it's ok to recommend
second best effort to deliver said notification.
No, such a proposal "merely" (thanks V.S.) documents the current reality.
Things change, you may not like it, but it's true.
Conservative positions are valuable, without them we wouldn't have the
required stability. I respect your position, but I urge you to consider
possible benefits of change.
All change is not bad, even if it's associated with costs.
--
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg