Subject: Re: [Asrg] ACK4

From: Scott Nelson <[email-masked]>
Date: Thu, 22 May 2003 00:17:39 -0700

At 10:30 PM 5/21/03 +0100, Jon Kyme wrote:
>>>> If you're going to change SMTP,
>>>> I think it's better to create a new commands rather than modify old
>>ones.
>>>
>>>No, I don't believe so. A change such as I suggested is backward
>>compatible
>>>
>>
>>
>>It's only compatable if you think changing the QoS on a multi rcpt
>>message is compatible.  I can see the point of view, but I don't share it.
>>
>>Don't get me wrong, I like the idea of dropping bounces - they are
>>the bane of my mail systems existance and many if not most are
>>ignored anyway.  But if the Bob is delivering a share holders report
>>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.
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.

>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."

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.

> 
>
>>I grant that it's a large objection, but it applies to almost any 
>>change proposed.  It's nothing more or less than a large cost.
>>The cost may or may not exceed the benefit.  
>
>
>Your ACK4 needs wide deployment - and that takes years.
>

I expect many people would never adopt it.
Some would always think it's new and therefore, bad.
But when two parties connect and both have implemented it,
they gain the benefit of having done so.  
In the case where only one has, there is no difference.
In other words, ACK4 describes a way in which consent for it's 
use is implicit in the very act of using it.

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.
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, 
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:

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.

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.

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.

Scott Nelson <[email-masked]>
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 22 May 2003 11:00:08 +0100

> 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.

> I'm not concerned about the times when it's the same as before.

You should be - these are also valid cases.

> 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.

> more than one recipient, and claiming that as MAY or even worse SHOULD, 

Oooh, no, I didn't suggest any such thing (please see below).

> they now must send each message separately.

Yes. If they want to explicitly request the QOS that they were assuming.

> 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.

> 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.

>    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.
 
> to their mail system as "non-compliant" in public, and something 

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?

> 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.

--