Re: [Asrg] ACK4

[Scott Nelson <[e-mail]>]

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 <[e-mail]>
_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg