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 <scott(_at_)spamwolf(_dot_)com>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg