Downgrading Mechanism for Email Address Internationalization
RFC 5504

[Ballot discuss]
I have reviewed draft-ietf-eai-downgrade-11. Overall, the document
looks good, but I have the following concerns that I'd like to discuss
before recommending approval of the document:

Section 3 says "an internationalized client might use the information
in the "Downgraded-" header fields when processing a downgraded
message, for example, such as displaying or composing a reply.".

I think the security considerations section should probably explicitly
warn about how not to do it. For example, just showing the value
of "Downgraded-From:" instead of "From:" (if the message has
Downgraded-From) header would probably not be a good idea, at least
if the client does not verify that the value of "From:" is actually a
downgraded version of the original value.

For example, some organizations mark emails coming from outside the
organization. When a message with "From: Ms. CEO "
arrives at example.com boundary MTAs from the outside, it might get
changed to "From: ext Ms. CEO " or something.  If the
MUAs get updated to EAI-capable faster than the other elements, and
they just blindly displayed Downgraded-From instead of From, this
marking could be bypassed just by adding "Downgraded-From: Ms. CEO
" header (and some totally unrelated From: value).

Even for other headers, it probably would be very confusing if the
value in "Subject:" was totally unrelated to the value in
"Downgraded-Subject:" (that would not be the result of legitimate
downgrading according to this spec, but someone deliberately trying to
get different parts of the mail system to interpret the same message
differently).

There's probably no perfect fix for this situation... but at least
a warning that even a MUA should not attempt to "upgrade" the message
by displaying just the Downgraded-* values would probably be in order.

[Ballot comment]
The second and final bullets in the security considerations could be strengthened a bit, imho.

Specifically, in bullet 2 the authors might wish to say what implementations that attempt to
detect spoofing should do.  Do they rely on the Downgraded-* fields and ignore the rewritten
headers, or is some comparison between these fields in order?

The last bullet closes with the sentence "Such gateways violate [RFC2979] and can be upgraded
to correct the problem."  Unless there is a downside to this upgrade, the authors should
consider strengthening this to say the upgrade is recommended.

[Ballot comment]
I was wondering why this was experimental - then I read Klensin's note from Jan 7. If that reflects general state of this document, it seems like it would be a good idea to add an IESG Note that adds a bit caution and highlights why this is experimental.

[Ballot comment]
The Gen-ART Review by Vijay Gurbani posted on 2-Jan-2009
  includes two comments:

  1) The last statement in S3.3 ("Applying this procedure to
  "Received" header field is prohibited.") ought to be moved
  elsewhere.  I think this is a fairly important statement
  and appearing as it does in a section for "unknown" header
  fields, I believe adequate attention may not be paid to it.

  A couple of places where it could be moved would be S1 or
  S5, when "RECEIVED downgrading" is discussed.

  2) In S5, under "RECEIVED downgrading", does it make sense
  to say "will not contain non-ASCII values" or "should not
  contain non-ASCII values" instead of "don't contain non-
  ASCII values."

IANA has questions about draft-ietf-eai-downgrade-10.txt:

- In section 5.1 you indirectly reference Downgraded-Resent-Reply-To and
Downgraded-Disposition-Notification-To but you don't register them
in the registry. Is this an oversight?

- Later in Section 5.1 you indirectly reference a Downgraded-List-*
but do not register it. Is this an oversight too?

Upon approval of this document, IANA will make the following
assignments in the "Permanent Message Header Field Names" registry at
http://www.iana.org/assignments/message-headers/perm-headers.html

Header Field Name Protocol Status Reference
----------------- ---------- ------ ---------
Downgraded-Mail-From mail experimental [RFC-eai-downgrade-10]
Downgraded-Rcpt-To mail experimental [RFC-eai-downgrade-10]
Downgraded-From mail experimental [RFC-eai-downgrade-10]
Downgraded-Sender mail experimental [RFC-eai-downgrade-10]
Downgraded-To mail experimental [RFC-eai-downgrade-10]
Downgraded-Cc mail experimental [RFC-eai-downgrade-10]
Downgraded-Reply-To mail experimental [RFC-eai-downgrade-10]
Downgraded-Bcc mail experimental [RFC-eai-downgrade-10]
Downgraded-Resent-From mail experimental [RFC-eai-downgrade-10]
Downgraded-Resent-To mail experimental [RFC-eai-downgrade-10]
Downgraded-Resent-Cc mail experimental [RFC-eai-downgrade-10]
Downgraded-Resent-Sender mail experimental [RFC-eai-downgrade-10]
Downgraded-Return-Path mail experimental [RFC-eai-downgrade-10]

Disallow any registration for unknown header fields:
Downgraded-* N/A [RFC-eai-downgrade-10]

We understand the above to be the only IANA Actions for this document.

(February 1, 2007 template)

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

  Harald Alvestrand. Yes.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

  Yes. No.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

  No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

  No.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

  Solid.
  There is some worry about the handling of header fields
  containing URIs if someone introduces IRIs in them, but the
  WG decided that it was not appropriate to try to solve this
  problem at this time.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

  No.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

  Yes.
  The draft refers to RFC 2821 and 2822, which were obsoleted
  a few days ago; this can be fixed at the RFC Editor stage, we
  do not know of any problem with referring to the newer RFCs.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

  Yes.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

  Yes.
  The document contains experimental entries for the header
  registry (RFC 3864), which does not have a review procedure.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

  Yes. Section 5 contains some parts that look like ABNF, but
  should be considered as pseudocode; otherwise, the specification
  is believed to be in valid ABNF.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
    This document specifies a downgrading procedure for
    messages that are extended according to the EAI UTF8SMTP
    extension, when these are being sent to a recipient MTA
    that does not support the UTF8SMTP extension.

          Working Group Summary
    The WG came to consensus on this document.

          Document Quality
    The document has been reviewed in the WG.