|
Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto)
2021-08-17 10:04:37
--On Friday, August 6, 2021 04:29 -0400 Valdis Klētnieks
<valdis(_dot_)kletnieks(_at_)vt(_dot_)edu> wrote:
On 05 Aug 2021 22:45:58 -0400, "John Levine" said:
It appears that Dave Crocker <dcrocker(_at_)bbiw(_dot_)net> said:
that's one less thing to make this more complicated...
If we have a mail corpus it'd be interesting to see how many
Received headers have "for" clauses and if they match up at
all with Delivered-To.
Probably not, the "for" clause was never very popular.
Don't bet on that. :)
For the very old corpus, there were a total of 214,585
Received: lines, of which 65,273 had a ' for ' clause.
By comparison, out of some 31,000 emails I received during
June of this year, there are 270,893 Received: lines, of which
23,253 have a ' for ' clause. A quick eyeball indicates that
Postfix, Exim, and Google all do it for single-recipient
deliveries (several representative examples):
...
Let me try to generalize a little bit from experience, although
I think the data given are consistent with what I'm about to
suggest. What follows is mostly historical; those who don't
care can safely stop reading or skip to the last paragraph about
the footnotes.
Once upon a time, "for" was very heavily used, not just in
single-recipient messages but to trace address transformations.
Especially in the days before "List-*" header fields, knowing
whether a message that was received originated from a mailing
list and which one (and is) was very useful. Often the
traditional "To:" or "Cc:" header fields provided that
information but not always (and not always reliably)[0]. That
information is related to the presumed target address close to
the injection of a message into the system and hence very
different from "Delivered-to:" but, if "for" is relevant to this
discussion, we cannot dismiss it. And, especially for
debugging and tracing, it was also important in situations where
messages moved between transport environments with possible
destination address translation at the boundaries [1].
It was, however, never very popular for multi-recipient
messages. I believe that was partially because the specs were
never clear about what was supposed to be done with them [2].
That was mostly at a time when we didn't pay much attention to
privacy of envelope information and, more generally, the
question of which parties were sending or receiving mail as long
as content could be protected [3]. As sensitivity to privacy of
that information increased, the use of "for" decreased. The
reduced percentage of "Received:" lines in Valdis's data seem
consistent with that [4].
Coming back to the document after that long digression, if we
think that confusion between the intended use of "for" and the
intended use of "Delivered-to:" is important, it might be useful
to include somewhat more text than is now present to explain the
difference between the intent and application of the two. I'll
leave to others whether that is worth the trouble in a
to-be-Experimental text that has been kicking around this long.
best,
john
[0] Consider the position of a recipient looking at a message in
which their address does not appear in either field although one
or more individual recipients to and, perhaps, so do two or more
addresses of mailing lists. Now, was the message transferred
through one of those list? The other? or is a a "blind" (sic)
copy? The answer can usually be deduced by working through all
of the "Received:" fields and other available information, but
doing so involved heuristics well beyond the skills of typical
email users.
[1] If anyone has far too much time on their hands, it would be
interesting to
try to reconstruct the reasons why MIXER (RFC 2156) does not
mention "for".
[2] We probably should have spotted that during the discussions
leading to RFC 1123 or during the DRUMS effort and said
something in 1123 or 2821. We didn't. At least partially mea
culpa. Sorry.
[3] Analogies to the postal system and, at least in the US and
the environments in which I was working, "pen registers" in the
PSTN are obvious and were frequently cited.
[4] A caution: my general impression, one that is, I think,
important to the believe that SMTP over TLS (or equivalent) are
Good Things, is that we are doing far less relaying than was the
case decades ago. Unless the increased number of Received lines
is simply due to significantly increased message load something
is adding a lot of those lines rather than seeing them reduced.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
| <Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), (continued)
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), Tim Wicinski
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), Sam Varshavchik
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), Dave Crocker
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), tjw ietf
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), Dave Crocker
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), John Levine
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), Jeremy Harris
- Re: [ietf-smtp] "for" clause, Claus Assmann
- Re: [ietf-smtp] "for" clause, Viktor Dukhovni
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), Valdis Klētnieks
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto),
John C Klensin <=
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), Viktor Dukhovni
- [ietf-smtp] "for" and Deliever-to: (draft-crocker-email-deliveredto)), John C Klensin
- Re: [ietf-smtp] "for" and Deliever-to: (draft-crocker-email-deliveredto)), Ned Freed
- Re: [ietf-smtp] "for" and Deliever-to: (draft-crocker-email-deliveredto)), John C Klensin
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), Murray S. Kucherawy
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), John C Klensin
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), Viktor Dukhovni
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), John C Klensin
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), Murray S. Kucherawy
- Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), John C Klensin
|
| Previous by Date: |
Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), Viktor Dukhovni |
| Next by Date: |
Re: [ietf-smtp] New Version Notification for draft-crocker-email-deliveredto-05.txt, Viktor Dukhovni |
| Previous by Thread: |
Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), Valdis Klētnieks |
| Next by Thread: |
Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draft-crocker-email-deliveredto), Viktor Dukhovni |
| Indexes: |
[Date]
[Thread]
[Top]
[All Lists] |
|
|