the main problem with MDNs, bounce messages etc is that the network
doesn't know what they are.
This is WAY o-t now...
With TCP or UDP etc, if you have a delivery issue (certain types), you
get an ICMP message back.
If there was a distinction between a control message and a data message,
then the network could know things like how to not create loops.
It could also mean we could drop the requirement to allow submission of
mail with NULL return paths, and instead use a non-destructive (in terms
of information) method to notify issues which retained the addressing
information.
It would need to be clearly defined, machine readable etc. It could be
stored and forwarded, and moved over the same transport. It would just
need to be unambiguously identifiable in all cases, which IMO would
require another verb in the mail transport to mark it as a control
message. I don't think message format would cut it.
In terms of privacy etc, if you send a registered letter to someone, you
know when it is received. You're entitled to know this, and you don't
hear complaints about it. So I don't have a problem with the concept of
allowing a sender to know when a message is retrieved. I just turned
off MDNs because the way they are implemented is problematic esp with spam.
Adrien
On 21/02/2012 2:30 a.m., Tony Finch wrote:
Bron Gondwana<[email protected]> wrote:
It almost seems that a SENDMDN command is what is indicated for this
usage. Again, the "client can't screw it up" philosophy.
On the other hand, MDNs are an abusive misfeature that should be shunned.
Tony.
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
