Re: homework, not an experiment, draft-crocker-email-deliveredto
Richard Clayton <[email protected]> Sat, 7 Aug 2021 19:51:09 +0100
| Newsgroups | gmane.ietf.smtp |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <[email protected]>, Dave Crocker <[email protected]> writes > Ideally that would include details about concerns with the text. > Extra points for suggesting specific improvements. I have read -05 It suggests a header which will added, perhaps many times, to a message which shows how it has traversed various delivery systems. The document provides only one justification for this One use can be for detecting a delivery sequence loop. Delivering the same message more than once to the same address is almost certainly not an intended activity. The first sentence makes sense to me. The second sentence is poorly drafted, I often get two copies of a message to the same address and welcome it because it shows two rather distinct paths through some complex mail systems are both working. They aren't strictly the same message (lots of header fields differ). So the second sentence might usefully say something more generic such as without loop detection messages may be in transit indefinitely or appear at the final destination more than once. Since loop detection is an explicit aim then mentioning other loop detection mechanisms (such as counting Received header fields) might be useful -- if only to indicate how these go wrong, or do not kick in fast enough (or indeed once the message is no longer using SMTP may not be generated at all). I did a lot of work 20 years ago developing software to detect loops (mail systems have all sorts of exotic ways of preventing standard mechanisms from kicking in) ... and for an ISP user base of 200K or so would find one or two a day. I have no newer data than that -- I expect that far more people now use proper MTA software than back then, so the incidence will be much lower. However, for loop detection an opaque value would do just as well and would avoid a lot of discussion about privacy. We know how to produce "globally unique" values (because we do it for MIME separators) and this may avoid issues when two systems think that mailboxes are fred@local. Because of the privacy issues I think the document needs to explicitly set out other uses of the header if human readable values are to be used Finally, there seems little value (and much unnecessary annoyance) in overloading an existing header that is in fairly widespread use... perhaps using "Been-There" (so that the this mailing list can retire an X-Header) would be sensible. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBYQ7WHd2nQQHFxEViEQLl3wCgx6rAYg6ul2UEn7aBrA/KQP7y4Z0AnAn6 Q/Xt6/KkUw/9l5OEUOYOksdX =/0HF -----END PGP SIGNATURE-----