[Emailcore] EMAILCORE ticket #55: G.14. The FOR Clause in Received header field and draft-klensin-email-for-clause-00

John C Klensin <klensin@jck.com> Mon, 25 July 2022 03:07 UTC

Date: Sun, 24 Jul 2022 23:07:04 -0400
From: John C Klensin <klensin@jck.com>
To: emailcore@ietf.org
cc: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <2134F9F7A2003D9C264267F8@PSB>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/1EY_ssSq3sT6q02MhhZaSzf_6kg>
Subject: [Emailcore] EMAILCORE ticket #55: G.14. The FOR Clause in Received header field and draft-klensin-email-for-clause-00
Precedence: list

Hi.

In trying to work on this ticket in the last twelve hours or so,
I ended up back at the point of feeling that we have a rather
considerable mess on our hands, one that goes back to at least
RFC 821 and that has more implications and more odd cases than
the test in RFC 5321 or the revisions in the current version of
5321bis account for.  So I have tried to do a fairly
comprehensive for the "for" clause, when and where it can be
safely used.  I've also tried to think through the various
options of how me might proceed.

In part because no one would read a ten page email message (I
did say "comprehensive"), I've posted an I-D,
draft-klensin-email-for-clause-00, containing that analysis.   I
have deliberately not tried to tie it to EMAILCORE: depending on
WG decisions, if it is useful for anything past Tuesday, parts
of it could be fodder for 5321bis, for the A/S, for an update to
RFC 6409.  Or it may just disappear.

Extremely abbreviated synopsis:

While we didn't get very sensitive to it until we started
worrying about privacy, the real problem with the "for" clause
goes back to the omission in 821 of any sort of explanation of
which address to choose or when the clause should be used.  821
basically stops with syntax and, while we've done some tuning in
2821 and 5321, the underlying problem remains.  The document
reviews that situation and the relevant history, reviews some of
the cases that make a clear, handwaving-free, solution
difficult, and then identifies four sets of options, one of
which is to deprecate the clause entirely.

Warning: Ten hours ago, this document was not even an idea.  It
was consequently written very hastily.  If there are rough edges
or mistakes, that should be no surprise.  On the other hand, I
hope it will give us something to discuss in that part of
Tuesday's agenda. 

best,
   john


---------- Forwarded Message ----------
Date: Sunday, July 24, 2022 19:38 -0700
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-klensin-email-for-clause-00.txt


A New Internet-Draft is available from the on-line
Internet-Drafts directories.


        Title           : Issues with the SMTP/IMF 'for' Clause
and Remedies         Author          : John C Klensin
  Filename        : draft-klensin-email-for-clause-00.txt
  Pages           : 10
  Date            : 2022-07-24

[...]

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-klensin-email-for-clause/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-klensin-email-for-clause-0
0.html

Internet-Drafts are also available by rsync at
rsync.ietf.org::internet-drafts

---------- End Forwarded Message ----------

[Emailcore] EMAILCORE ticket #55: G.14. The FOR C… John C Klensin