the reason I bring this up.
Even though we may not fix SMTP MDN issues etc in a long time, if we
build protocol support for notifying a client about things relating to
delivery etc, then we can
a) implement it initially with server-side heuristics if at all (e.g.
recognise and strip bounce messages, or deliver them to a special folder
and notify)
b) move to a deterministic model once it becomes available
So it affects what we do now with whatever client-server stuff we do now.
Adrien
On 21/02/2012 9:23 a.m., Adrien de Croy wrote:
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
