Subject: [EAI] draft-ietf-eai-simpledowngrade-00

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 2 Mar 2012 16:55:13 +0100

Hi,

I cleaned up the protodraft I posted and Josepth just approved it, so
you should see a new WG draft in your next-door mirror very soon. Just
what you needed to start the weekend: The shortest, simplest draft
you've seen in weeks.

There's one open issue: How to explain the relationship between this
document and the two other alternatives.

One alternative is Fujiwara's draft. His draft is complex and provides a
high-fidelity rendering of EAI messages, at the cost of requiring much
implementation and testing. Mine is much simpler, requires little
testing, and provides only the most important information. Choosing
between those is really a matter of preference.

The other alternative is no downgrade at all, and this is where I have
problems.

I believe that no downgrading is harmful for two reasons. One is that
without downgrade, nervous admins might not want to enable EAI until
they know all clients work, and IMP and POP don't make gathering that
information simple. The other, and more important, reason is that once
an IMAP server has revealed the existence of a message, it cannot really
deny the user access to that message. So either it has to downgrade by
creating a monster (e.g. just-send-utf8 addresses, which hopefully will
not cause the MUA to misdirect an reply) or go to some effort to never
reveal the EAI messages, or deal with the possible infinite loops if it
suppresses the content of revealed messages.

All of those three need code in servers. IMO it's quite likely that a
cheap downgrade can be simpler to implement than those three, and that
cheap downgrade is what my document aims for. The best that can be done
at near-zero implementation cost.

Somehow I can't wrangle the previous two paragraphs into RFC shape. I
tried, but the result was either much too short or a wretched
digression, or even both.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Fri, 02 Mar 2012 11:28:34 -0500

--On Friday, March 02, 2012 16:55 +0100 Arnt Gulbrandsen
<[email-masked]> wrote:

> Hi,
> 
> I cleaned up the protodraft I posted and Josepth just approved
> it, so you should see a new WG draft in your next-door mirror
> very soon. Just what you needed to start the weekend: The
> shortest, simplest draft you've seen in weeks.
> 
> There's one open issue: How to explain the relationship
> between this document and the two other alternatives.

Note that some discussion of this went into the most recent
version of draft-ietf-eai-popimap-downgrade.  I'm guilty of
supplying most of that text (if you don't like it, definitely
blame me and not Kazunori), but the decision about what to do
about it, and whether more or less should be said, belongs to
the WG.

> One alternative is Fujiwara's draft. His draft is complex and
> provides a high-fidelity rendering of EAI messages, at the
> cost of requiring much implementation and testing. Mine is
> much simpler, requires little testing, and provides only the
> most important information. Choosing between those is really a
> matter of preference.

> The other alternative is no downgrade at all, and this is
> where I have problems.
> 
> I believe that no downgrading is harmful for two reasons. One
> is that without downgrade, nervous admins might not want to
> enable EAI until they know all clients work, and IMP and POP
> don't make gathering that information simple. The other, and
> more important, reason is that once an IMAP server has
> revealed the existence of a message, it cannot really deny the
> user access to that message. So either it has to downgrade by
> creating a monster (e.g. just-send-utf8 addresses, which
> hopefully will not cause the MUA to misdirect an reply) or go
> to some effort to never reveal the EAI messages, or deal with
> the possible infinite loops if it suppresses the content of
> revealed messages.

Different perspective --speaking strictly as an individual
participant:  There are going to be situations in which it is
possible to convert/upgrade all POP, IMAP (and other) clients
before turning on SMTPUTF8 in the delivery server.  The most
obvious case is one in which a central IT department controls
all of the desktop and other client machines and can force-push
changes onto them, but there are others.  There is no issue of
the POP or IMAP server having to discover penetration of
upgrades because that is handled in another way.  For that case,
a "no downgrades and we are not going to spend time worrying
about it" strategy is no more risky that hundreds of other types
of operational failures.  Presumably, if a user's IMAP or POP
client fails to advertise the needed capabilities, either that
machine gets immediately and forcefully upgraded or the user is
instructed to report for a spanking.  From our point of view,
those are administrative issues, not technical ones -- no
IMAP/POP server code required.

The other "no downgrade" cases are, as you note, harder, but I
continue to think that it ought to be plausible to generate
something that looks a lot like a DSN whose content is "there is
this message that you can't get until you either upgrade your
client, access it through an upgraded client, or figure out
another way to get at it".   One of many options would be for
the notification message to contain a URI that points to the
UTF-8 form of the message as a text file or equivalent (hmm...
an application for message/external-body?  :-) ).  That is very
different from "deny the user access to the message", especially
in the very common case environments in which one might imagine,
e.g., web access capability to complement the POP or IMAP
capability.  I suppose we might explicitly advise anyone going
down that path to be sure that there is some alternate mechanism
for letting the user of legacy clients to get to those messages.

What I don't know is whether the WG needs (or wants) to try
exploring and writing up that "DSN and warnings about support
structure" option or whether we would be ok just mentioning the
possibility (which the text in draft-ietf-eai-popimap-downgrade
sort of does although improvements are probably needed).

> All of those three need code in servers. IMO it's quite likely
> that a cheap downgrade can be simpler to implement than those
> three, and that cheap downgrade is what my document aims for.
> The best that can be done at near-zero implementation cost.

Whether that is true relative to some "tell the user she doesn't
get the message until..." strategy depends on what variant of
that strategy is decided upon and how whatever structure is
needed to support the strategy is counted.   Certainly just
generating a pseudo-DSN wouldn't take much code.  Fortunately,
I think our job is to identify the alternatives; we don't need
to answer that question.

> Somehow I can't wrangle the previous two paragraphs into RFC
> shape. I tried, but the result was either much too short or a
> wretched digression, or even both.

See if any of the above helps.  I'm trying really hard to resist
the feeling that we are going to need some sort of separate
"downgrading tradeoffs and issues" document so that we could
leave the other specifications to deal with the relevant
protocol issues alone but, as long as we can get it written and
reviewed, it would not be the worst possible outcome.  Having
all of the information, but having it split in fairly arbitrary
ways across two or three different protocol specs might well be
worse.

best,
    john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 2 Mar 2012 17:33:12 +0100

On 03/02/2012 05:28 PM, John C Klensin wrote:
> 'm trying really hard to resist
> "downgrading tradeoffs and issues" document

RFC 1925, 6a

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 2 Mar 2012 17:51:21 +0100

There has been a little offlist discussion of what "no downgrade" might
mean in concrete terms. Here's one way which should work fairly well in
real life, except that the ALERT response code is frequently rerouted to
/dev/null by today's clients.

Personally I don't like this very much. It holds people's mail hostage.

Arnt

2. IMAP

When an IMAP server is required to send an EAI-specific response, it
sends nil in the relevant part of the response. For example

  C: a UID FETCH 42 ENVELOPE
  S: * 1 FETCH (UID 42 ENVELOPE NIL)

The IMAP server MUST send the ALERT response code along with the
command's tagged response. Continuing the previous example:

  S: a OK [ALERT] One or more messages requires internationalisation and
cannot be displayed

IMAP clients commonly request partial information about a message, so a
client may well ask for only ASCII information in an EAI message. The
server MAY send null responses even if this is the case for a particular
command.

An IMAP server MUST NOT set the \deleted flag or expunge an EAI message
when instructed to by a non-EAI client.

3. POP

When a POP server is required to send an EAI-specific response, it sends
an empty message. A POP server MUST NOT mark such a message as deleted,
no matter what the client does.

---

From: Chris Newman <[email-masked]>
Date: Fri, 02 Mar 2012 14:27:25 -0800

I have reviewed this document and I like this general approach, 
particularly the use of the .invalid TLD. I believe having a 
standards-compliant simple downgrade option like this will increase the 
odds that SMTPUTF8 will deploy successfully.

Some specific comments on this draft:

Section 2.1:

   Irregular email addresses (anything to which one cannot send mail,
   such as "unknown:;") are silently excised.

I suggest changing "are" to "MAY be". It's better usability to leave such 
things in the address list so they should only be excised if it makes the 
implementation simpler.

   The affected header fields are Bcc, Cc, From, ReplyTo, ResentBcc,
   ResentCc, ResentFrom, ResentSender, ResentTo, ReturnPath, Sender and
   To.  Any addresses present in other header fields are not regarded as
   addresses by this specification.

The "-" delimiters disappeared from this list, please fix (e.g. ReplyTo 
should be Reply-To, ReturnPath should be Return-Path, ResentTo should be 
Resent-To, etc). I was going to suggest adding Disposition-Notification-To 
to the list, then I realized it's actually better to omit it from the list.

Section 2.2:

   Any mime field (whether in the message header or a bodypart header)
   which cannot be presented as-is to the client is silently excised
   along with its name.

This isn't clear to me, perhaps because it's not using precise language 
(did you mean MIME parameter?, your example suggests that's the case). It 
also doesn't mention comments although they are mentioned in the section 
title.

Here's one alternative I'd suggest:

  If the Content-Type [RFC2045] or Content-Disposition [RFC2183] MIME 
header fields contain <UTF8-non-ascii> [RFC6532], the following two steps 
are performed on the relevant header field(s):

1. Any RFC 5322 comment containing such characters is excised.
2. Any MIME parameter attribute/value pair containing such characters is 
excised along with the ";" delimiter.

Here's another alternative:

 If either the Content-Type [RFC2045] or Content-Disposition [RFC2183] 
header field contains <UTF8-non-ascii> [RFC6532] then any field content 
following a ";" delimiter is excised.

That's a lot easier to implement, but I worry a bit about the impact of 
dropping charset and boundary parameters so I lean slightly towards the 
more complex algorithm over this one.

Before Section 2.3:

The Received header can't be excised without losing critical diagnostic 
information. The simplest algorithm I can suggest is to replace any 
sequence of characters in a Received header that contains one or more 
<UTF8-non-ascii> characters and ASCII alpha-numeric characters with the 
string "invalid". Next best I can come up with is to excise any 
received-token (as defined in RFC 5322) containing non-ASCII. The former is 
easier to implement, the latter easier to specify. Either is fine with me.

Section 2.3:

There needs to be a prohibition from excising Received header fields here.

Unfortunately, humans tend to encode a lot of useful information in the 
subject header (sometimes it's the only useful information in the entire 
message). So I think this needs to be called out as an important 
quality-of-implementation choice. I suggest adding this sentence:

If the Subject header field contains <UTF8-non-ascii>, it MAY be encoded 
using Message Header Extensions for Non-ASCII Text [RFC2047] instead of 
being excised.

Section 3:

This will require an "updates RFC 3501" in the RFC boilerplate. I like this 
approach.

Section 5 is missing.

		- Chris

--On March 2, 2012 16:55:13 +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima
>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 4 Mar 2012 16:53:54 +0100

Hi,

On 03/02/2012 11:27 PM, Chris Newman wrote:
> I suggest changing "are" to "MAY be".

I deleted the parapgraph. The rule didn't really carry its load.

> The "-" delimiters disappeared from this list,

Oh, search and destroy. Fixed.

> (did you mean MIME parameter?, your example suggests that's the case).

Mind thinks x, fingers type y ;)

> It also doesn't mention comments although they are mentioned in the
> section title.

I wrote the heading and body text, then while searching for a credible
example I decided that comments don't matter enough to warrant special
treatment. So I deleted the body text — and forgot the heading.

Do you have a credible example, perhaps?

> more complex algorithm over this one.

Boundary is IMO vitally necessary, and reason enough to require the
per-parameter rule. I don't like it, but there it is.

> received-token (as defined in RFC 5322) containing non-ASCII. The former
> is easier to implement, the latter easier to specify. Either is fine
> with me.
> 
> Section 2.3:
> 

Really?

Consider: This is about EAI messages. So we're talking about the need to
read Received when either a) EAI mail is sent to someone who can't read
it at all or b) it's sent to someone who can read it, but is at the
moment using an EAI-ignorant MUA.

I feel that in case b), reading Received using a different MUA is
sufficient. It tends to be done for debugging, and debugging is best
done using the original message, not a degraded version. I do not
particularly want to cater to doing debugging badly.

So the argument is about a). Is that something to care about enough to
add a rule?

> using Message Header Extensions for Non-ASCII Text [RFC2047] instead of

You're the second person to point that out, and it's not any more
deniable this time than the first time.

I added that as simple 'is encoded', no MAY about it.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 4 Mar 2012 17:02:56 +0100

I made a -01 after addressing blah. Should be out now.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Sun, 04 Mar 2012 12:57:45 -0500

--On Sunday, March 04, 2012 16:53 +0100 Arnt Gulbrandsen
<[email-masked]> wrote:

>...
> Consider: This is about EAI messages. So we're talking about
> the need to read Received when either a) EAI mail is sent to
> someone who can't read it at all or b) it's sent to someone
> who can read it, but is at the moment using an EAI-ignorant
> MUA.
> 
> I feel that in case b), reading Received using a different MUA
> is sufficient. It tends to be done for debugging, and
> debugging is best done using the original message, not a
> degraded version. I do not particularly want to cater to doing
> debugging badly.
> 
> So the argument is about a). Is that something to care about
> enough to add a rule?

As one of the longer-term advocates of preservation and
accessibility of Received fields, I think I nonetheless have to
agree with Arnt on this.   The very idea of lightweight or
partial downgrading implies that there has to be another MUA or
other mechanism out there somewhere.  Moreover, having messages
in the mail store that require SMTPUPTF8 capability without
having at least a way to inspect them for debugging purposes
would border on "really stupid".   So it seems to me to be
plausible to push off complex Received headers to those
mechanisms.  I would like to see something that says "some
Received header fields discarded because...", but that is a
different matter.

Also, from my point of view, the WG pretty much accepted the
possibility of rrace fields being discarded the moment it
decided that domain names in those fields should be represented
with U-labels rather than A-labels when that choice occurred.

     john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 4 Mar 2012 22:02:06 +0100

On 03/04/2012 06:57 PM, John C Klensin wrote:
> I would like to see something that says "some

I thought about it, but I don't see a simple IMAPish way, and doing it
only for POP isn't worth the bother IMO.

Take a hypothetical header field X-Pseudo-Field-Listing-Downgrades. IMAP
says that message content, once cached, never changes. Since it's common
for for IMAP clients to ask for partial information about messages, IMAP
servers to try to handle that efficiently, and an IMAP server may or may
not have a complete picture of what downgrades should be performed for a
particular message, or even which ones it has performed. Generating that
pseudo thing might not be very simple, and making the client show the
latest version... no idea.

Personally I think clients should upgrade to support EAI and only EAI,
so any solution involving client changes is out of scope.

Arnt

---

From: Bill McQuillan <[email-masked]>
Date: Sun, 4 Mar 2012 18:56:47 -0800

> only for POP isn't worth the bother IMO.

How about the IMAP (or POP) server substituting a single ASCII
character (e.g."?") for each octet outside of the range 0-127?
This would maintain byte counts and could be done on the fly
during the download process. The stored message would not change, 
merely this client's current view of it.

This allows header fields that are for human consumption (most of
them IMO, including Received:) to be interpreted by eyes and
brains. I often scan through the Received fields to see the hops
and notice if there are loops. A partially munged hostname is
quite easy to manage in this sort of human conducted scan.

The issues I see are the possibility of changing an email address
local part to a different, valid local part, and the possibility
of messing up an existing encoded word. The email address local
part could be noticed and converted to *all* "?" chars to make it
a clearly unusable address.

Merely my $0.02.

-- 
Bill McQuillan <[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Mar 2012 10:21:23 -0500

--On Sunday, March 04, 2012 18:56 -0800 Bill McQuillan
<[email-masked]> wrote:

>...
> The issues I see are the possibility of changing an email
> address local part to a different, valid local part, and the
> possibility of messing up an existing encoded word. The email
> address local part could be noticed and converted to *all* "?"
> chars to make it a clearly unusable address.

FWIW, note that "?????@example.com" is a perfectly valid mailbox
name with "?????" as a local-part.   I'd assume that every SMTP
server and web-based submission client that is stupid enough to
claim that "+"-based subaddresses are invalid wouldn't accept it
either, but that doesn't make it invalid.

    john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 5 Mar 2012 16:34:28 +0100

On 03/05/2012 04:21 PM, John C Klensin wrote:
> name with "?????" as a local-part.

The same applies to any number of cases, mime parameters and blah. I'm
decidedly nervous about changing valid syntax into other valid syntax
without even parsing it.

Besides, I think that ????@gulbrandsen.priv.no does not communicate
invalidity clearly. I can pay with a credit card displayed as ???? ????
???? 1234, so why can't I send mail to McQuilWP@?????.com?

Arnt

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Mar 2012 13:51:58 -0500

--On Monday, March 05, 2012 16:34 +0100 Arnt Gulbrandsen
<[email-masked]> wrote:

>> FWIW, note that "?????@example.com" is a perfectly valid
>> mailbox name with "?????" as a local-part.
> 
> The same applies to any number of cases, mime parameters and
> blah. I'm decidedly nervous about changing valid syntax into
> other valid syntax without even parsing it.
> 
> Besides, I think that ????@gulbrandsen.priv.no does not
> communicate invalidity clearly. I can pay with a credit card
> displayed as ???? ???? ???? 1234, so why can't I send mail to
> McQuilWP@?????.com?

Indeed.  I think we are in violent agreement.  Substituting a
standardized syntactically-valid string for another (or for a
UTF-8 form) loses a tremendous amount of information including
the fact that the substitution was made.   Bad idea, IMO.

   john

---

From: Joseph Yee <[email-masked]>
Date: Wed, 14 Mar 2012 02:11:21 -0400

All personal thought below..

I read -01, and think that this approach is tempting because it's simpler.  Its care focus on what's mostly visible (GUI wise).

Using .valid makes the message harder to be actionable, but not completely (ie. bad DNS hacks).  This is where I am more in favor in Fujiwara's draft of empty list.  (Yes, there are still tradeoffs).  

Nits spotted:
Section 2.2
s/atttribute/attribute/

Section 2.4
"the modifications in sections 3.1 and 3.2 is silently excised"
I believed that you mean sections 2.1 and 2.2?

Joseph

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 14 Mar 2012 09:40:55 +0100

> Using .valid makes the message harder to be actionable, but not completely (ie. bad DNS hacks).  This is where I am more in favor in Fujiwara's draft of empty list.  (Yes, there are still tradeoffs…

.invalid is already reserved by RFC 2606. We'd have to reserve .valid
using this document, I'm not sure how much work that would be. I fear
that without a clear and convincing reason it might lead to wearisome
discussion during IETF LC.

> I believed that you mean sections 2.1 and 2.2?

I should learn to type. Fixed.

Arnt

---

From: [email-masked]
Date: Wed, 14 Mar 2012 18:08:25 +0900 (JST)

> From: Arnt Gulbrandsen <[email-masked]>

'Empty list' is WG dicision on the past meetings.

> discussion during IETF LC.

The draft should refer RFC 2606 and some description about
"eai.invalid" helps readers' understanding.

and why don't you refer RFC 6532 ?

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 14 Mar 2012 10:45:00 +0100

> 'Empty list' is WG dicision on the past meetings.

Yes, but that doesn't apply since simpledowngrade does not specify any
format, it just gives some examples. I added two more examples now, and
changed the wording to make it clearer that they are just examples.

Server authors are free to use whichever format generates the lowest
number of support calls. Client authors are unable to write code to
support downgrade (at risk of repeating myself: they should support EAI,
not downgrade).

> "eai.invalid" helps readers' understanding.

OK, done.

> and why don't you refer RFC 6532 ?

No actual sentences need it. There also is no reference to 1939, 5234 or
5322.

I could add a reference for the sake of the reference, but IMO it's
better when the references are inserted out of concrete need.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 14 Mar 2012 11:00:55 +0100

One more thing. I think that I personally am now in favour of publishing
both drafts as RFCs and letting server authors choose according to
inclination.

I have my inclination, of course, but I can see sensible reasons why
people might choose differently, and I don't think we gain very much by
forcing this issue to be resolved before we've gained real
implementation and deployment experience.

Possible wording (in the two downgrade documents or in a reference
paragraph in the popimap spec):

  RFC x describes a very simple downgrade process, while RFC y describes
  a more complex, more accurate process. The WG decided that choosing
  one process based on little implementation experience would be
  premature, so both specifications are published, and servers may
  choose either.

Arnt

---

From: SM <[email-masked]>
Date: Wed, 14 Mar 2012 06:52:50 -0700

Hi Arnt,
>implementation and deployment experience.

The drafts could be Experimental.  The question would be what to do 
once there is real implementation and deployment experience.  It may 
end up as a problem for others to solve.  I am not against what you 
suggested above.

Regards,
-sm

---

From: Joseph Yee <[email-masked]>
Date: Wed, 14 Mar 2012 10:14:32 -0400

> discussion during IETF LC.

My turn to say that I should learn to type, I want to type ".invalid" rather than ".valid"

Joseph

---

From: John C Klensin <[email-masked]>
Date: Wed, 14 Mar 2012 22:39:21 -0400

--On Wednesday, March 14, 2012 06:52 -0700 SM <[email-masked]>
wrote:

>> both drafts as RFCs and letting server authors choose
>> according to inclination.
>> 
>> I have my inclination, of course, but I can see sensible
>> reasons why people might choose differently, and I don't
>> think we gain very much by forcing this issue to be resolved
>> before we've gained real implementation and deployment
>> experience.
> 
> The drafts could be Experimental.  The question would be what
> to do once there is real implementation and deployment
> experience.  It may end up as a problem for others to solve.
> I am not against what you suggested above.

Speaking both personally and as co-chair, I would really like to
avoid producing more Experimental documents that others have to
come back and clean up later.  That is particularly true in this
situation because:

(1) for possibly-further-refined of the two downgrade specs, it
is pretty easy to achieve the Proposed Standard criterion of "no
known defects".  We really do understand POP and IMAP well
enough to know what would or would not cause nasty surprises as
already evidenced by discussion on this list.

(2) I think it is extremely unlikely that implementation and
deployment of these specs will tell us anything we don't know
today, namely that both can be implemented, one is harder to
implement than the other(s), and difference situations and
circumstances will dictate different uses.  We might learn a bit
about the percentages, but knowing that one approach is
applicable to a somewhat larger number of situations than
another is not an appropriate basis for recommending for one and
against the other.

So, unless someone has a really good reason that they are
prepared to share (and "could be Experimental" is not a reason),
I think we should just move ahead.

   thanks,
    john

---

From: "Jiankang YAO" <[email-masked]>
Date: Fri, 16 Mar 2012 09:20:19 +0800

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "SM" <[email-masked]>; "Arnt Gulbrandsen" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 15, 2012 10:39 AM
Subject: Re: [EAI] two downgrade specs, I think

> I think we should just move ahead.

yes,  +1.

Jiankang Yao

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 21 Mar 2012 14:16:00 +0900

I just have read draft-ietf-eai-popimap-downgrade-04 and 
draft-ietf-eai-simpledowngrade-02-proto. I will send some comments on 
each one separately.

[If some of the following has already been discussed at length, pointers 
are appreciated.]

However, my general assumptions for priorities would be, in decreasing 
order:
1) Make sure the user knows what this is not the real thing
2) Make sure the user gets told what the fundamental problem is,
    and how to deal with it (read: please upgrade)
3) Allow the user to get all the information in the message, if
    necessary manually

What I'd personally try to do if I had, in a POP or IMAP implementation, 
would be to convert a minimum of the header fields that are usually used 
for display in MUAs in some obvious and helpful way.

For the subject, I'd of course use RFC 2047, but prepend some indicative 
label (e.g., "INVALID" or so).

For the typical mail address headers fields (From, To, Cc,...), if a 
display name is present I'd use only the display name, and remove or 
reduce the address to something like <> (if that's permitted by the 
syntax) or <invalid> or so.

Then what I'd do is to wrap the original message (in message/global or 
even just in text/plain;charset=utf-8) and prepend some text that 
explains the situation and what might be done about it.

I'm really wondering why what I have written in the last paragraph 
(include an original verbatim) isn't proposed in either of the downgrade 
specs. It would make sure that no info is lost, although the information 
isn't very actionable directly.

> implementation and deployment experience.

I'm fine with that. As explained above, I'd personally go for your 
approach, with some tweaks, if I had to implement something or if I had 
to choose an approach as an administrator.

At the current point in time, I really don't see the point of all the 
Downgrade- headers. If we want a faithful reproduction of the original 
headers, it's much easier to just include that as a message part. If 
anybody wants to automatically move back to the original (in my opinion, 
MUA writers should focus on upgrading their clients, not on being able 
to handle Downgrade- headers,...), having the original headers included 
in some way is much easier to convert back than some complicated header 
mangling.

But as I said above, I'm not against keeping both documents.

Regards,    Martin.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 21 Mar 2012 21:58:22 +0100

> label (e.g., "INVALID" or so).

I hate the mere thought, but perhaps that's just me. If more people
agree with you and Alexey I'll hold my nose and a sentence such as "the
server may add a prefix or suffix to the subject to inform the user that
the message has been downgraded", without specifying what the
prefix/suffix should be. IMO that's too language-dependent to be
specified in an RFC anyway.

> syntax) or <invalid> or so.

Neither is syntactically permitted by the RFC. Well, <invalid> is
permitted by much code, but it quite often points to something.
Remember, there are a gmail accounts, so a billion people's misaddressed
replies would pile up in the inbox of [email-masked].

The four examples in the document, or varieties along the same lines,
are the closest safe ones, I think. Your preference is probably #2
(original display-name plus <[email-masked]>).

There's also qmail's approach, <""@[]>. I've always felt bad about that,
so I didn't include it as an example.

> isn't very actionable directly.

In my case, I don't specify that precisely because it isn't very
actionable, and because message/global is an unusual content type.
Absent good reason I want to stay away from unusual syntax or features.

I believe that internationalized mail will generally be sent to people
who can read and write that. Send mail to people who can't reply, and
nothing more happens. Send mail to people who can, and before you know
it it's late at night and you have 116 more messages to read.

It follows that downgrade occurs mostly when a user has an
internationalized client, but is (also) using a conventional MUA (think
of the built-in client on your smartphone). In that scenario, the
optimal strategy is to deliver enough of the message to get the point
across, without adding any unusual syntax that might make the client
stumble, and expect the user to switch to the internationalized client
if necessary. God what awfully long sentences. I hope I'm not rambling
too much. I should finish off and go to bed.

Arnt