Re: [ietf-smtp] homework, not an experiment, draft-crocker-email-deliver

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In message <169a9cbd-6dd3-7daa-f380-067f286aba75(_at_)dcrocker(_dot_)net>, Dave
Crocker <dhc(_at_)dcrocker(_dot_)net> 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-----

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp