Subject: [EAI] #1481 HDR=UTF8 argument - status, and request for input

From: Harald Alvestrand <[email-masked]>
Date: Mon, 26 Mar 2007 19:25:43 +0200

Hello,

as I see the current status with HDR=UTF8, we have:

- The WG meeting in Prague discussed it, and found no particular 
advantage in using it, for the same reason as with the header marker: 
The recipient, in order to be certain about the format of a message, has 
to parse the message anyway, so the flag will at best be a warning, and 
at worst it can generate silly states when it is wrong.

- After the WG meeting, the argument was raised (or, at least, I did not 
understand it until after the meeting) that IF an MTA does NOT implement 
downconversion, BUT handles mail for some recipients that are able to 
receive UTF8SMTP mail, AND some recipients that are not so capable, the 
HDR=UTF8 flag will give the MTA the ability to reject the recipients for 
which it cannot handle the message, and accept the recipients for which 
it assumes that UTF8SMTP delivery will succeed.

There are two other alternatives:
- Say that an MTA MUST implement either conversion or return of an error 
message, after delivery
- Say that an MTA can return a 5xx reply to the DATA command, rejecting 
the message for all recipients.

So far, we have heard from Kari, Charles and Frank on this issue.

I would like the other participants in the WG to weigh in with opinions; 
I have created #1481 to make it easy to keep track of this one separate 
from other issues.

                   Harald

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 26 Mar 2007 21:35:27 -0400

--On Monday, 26 March, 2007 19:25 +0200 Harald Alvestrand
<[email-masked]> wrote:

> - The WG meeting in Prague discussed it, and found no
> particular advantage in using it, for the same reason as with
> the header marker: The recipient, in order to be certain about
> the format of a message, has to parse the message anyway, so
> the flag will at best be a warning, and at worst it can
> generate silly states when it is wrong.
> 
> - After the WG meeting, the argument was raised (or, at least,
> I did not understand it until after the meeting) that IF an
> MTA does NOT implement downconversion, BUT handles mail for
> some recipients that are able to receive UTF8SMTP mail, AND
> some recipients that are not so capable, the HDR=UTF8 flag
> will give the MTA the ability to reject the recipients for
> which it cannot handle the message, and accept the recipients
> for which it assumes that UTF8SMTP delivery will succeed.
> 
> - Say that an MTA MUST implement either conversion or return
> of an error message, after delivery
> - Say that an MTA can return a 5xx reply to the DATA command,
> rejecting the message for all recipients.
> 
> I would like the other participants in the WG to weigh in with
> opinions; I have created #1481 to make it easy to keep track
> of this one separate from other issues.

Harald, 

It seems to me that part of the question here depends on whether
we are, as a WG, as concerned about bouncing ("returning")
messages as some of us clearly are.   If we are, then your first
new alternative above ("conversion or return") is a non-starter.
If not, it is entirely consistent with 2821 and the language in
"framework".

The second of your new alternatives is, I believe, equivalent to
the "deliver to all or to none" option that has been requested
for email several times but never, IMO, written up.
Experience in implementations that behave that way has been, I
think, that they generally make both senders and receivers
unhappy.  

Now, since (i) I don't go non-linear every time someone thinks
about returning a message to an unauthenticated sender and (ii)
I believe in adding as little extra complexity that will become
unneeded when everyone is able to accept i18n formats as
possible, that leads me to favor "no extra argument", even with
the above additional concern.   

My view about that is reinforced by being able to see several
cases in which a late discovery of the need to downgrade in
relay environments will result in message return regardless of
what we try to do to restrict it, so I think it is more
important to concentrate on acceptable levels of sender
authentication or authorization (which are not on this WG's task
list) than to try to make a few extra cases in which bounce
messages can be avoided.

Just my opinion.

     john

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 27 Mar 2007 08:54:22 +0200

John C Klensin wrote:
> what we try to do to restrict it,
>   
Yes - I forgot to note that the only time at which the differential 
ability actually helps is when the MTA is configured so as to be able to 
make the determination on whether or not the recipient supports UTF8SMTP 
at RCPT TO time.

In all other cases, it makes no difference.

Harald

---

From: Yangwoo Ko <[email-masked]>
Date: Tue, 27 Mar 2007 16:33:40 +0900

> make the determination on whether or not the recipient supports UTF8SMTP 

I think that it is rougher than that. Additional condition that should 
be met is that such a determination has been kept correct until no 
further access to the message is needed any more.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 27 Mar 2007 10:08:09 +0200

Yangwoo Ko wrote:
>> ability actually helps is when the MTA is configured so as to be able 
>> to make the determination on whether or not the recipient supports 
>> UTF8SMTP at RCPT TO time.
>
My unclear grammar.

What I meant is that it only matters if the MTA can decide, at the time 
it gets the RCPT TO, that it will have to bounce the message because the 
recipient doesn't support UTF8SMTP, AND the MTA is unable or unwilling 
to downconvert.

Such may be the case when the MTA discovers that the user is behind a 
delivery channel that does not support UTF8SMTP, or when the MTA 
discovers that the user's mail will be relayed to another system that 
does not have UTF8SMTP support.

The issue of how to deal with messages stored in a message store that 
supports UTF8SMTP is entirely orthogonal to this one.

                        Harald