Personally, I think the easiest solution to this problem is to modify
the
semantics of 250 after DATA such that in the case of a message with
multiple RCPT TO we shouldn't *require* that a notification be generated
for a "delivery failure" if this "failure" is an action requested by a
mailbox "owner".
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
and works right away. I think. I'm not particularly attached to the idea.
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.
In this case, I'd suggest two new commands.
Some disadvantages;
Only useful if both sender and receiver have implemented it.
Till then it's just dead code/wasted text in the specification.
You've raised the killer objection to your own idea.
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. Since I'm a bit
unclear what the benefit to any of the three proposals is,
the killerness of the objection is also unclear to me.
I'm not trying to imply that implementing ACK4 would make SMTP
better in general, just better than the multi-line ack to
data previously suggested.
If no one accepts ACK4, then it doesn't hurt anything
(well, beyond the 6 extra bytes in a EHLO)
Changing the meaning of a response effects everyone
who /doesn't/ upgrade.
Scott Nelson <scott(_at_)spamwolf(_dot_)com>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg