Subject: Re: Header-Type, Mime-Version (Re: [EAI] Status of utf8header draft)

From: Randall Gellens <[email-masked]>
Date: Fri, 2 Feb 2007 00:47:30 -0800

At 6:38 AM +0200 1/26/07, Kari Hurtta wrote:

>  Precense of ALT-ADDRESS does not indicate that headers are UTF-8.
>
>  So I disagreed with "isn't needed in that case" part with you.

What do you gain from the additional extension?  It seems to me that 
you only get the ability to specify that a client is using non-ASCII 
addresses but all-ASCII headers.  Yet, the recipient server can't 
trust this, so what is the benefit?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Never write software that patronizes the user.

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

---

From: Kari Hurtta <[email-masked]>
Date: Fri, 2 Feb 2007 16:03:43 +0200 (EET)

> trust this, so what is the benefit?

[ If I remember correctly wo which thread that was refering.
  It may be that I remember context incorrectly. ]

Also on opposite.    Missing precense of ALT-ADDRESS  do not
specify that headers are all-ASCII.

That means that ALT-ADDRESS ESMTP option does not function as indicator.

If some option claims incorrect information, it is garbage in 
garbage out. "Can not trust" is not reason for scanning (for
me at least.)

Additional extension was giving same that Header-Type header field.
Avoid scanning of headers and mime structure to decide when to
do downgrade.

But it turned out that scanning all MIME headers on whole mail
makes sense after all. (For example sendmail sendmail already
parses mime structure every time when using default configuration.
So scanning all headers do not add complication. )

/ Kari Hurtta

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 05 Feb 2007 19:11:43 -0000

On Fri, 02 Feb 2007 08:47:30 -0000, Randall Gellens <[email-masked]>  
wrote:

> What do you gain from the additional extension?  It seems to me that you  
> only get the ability to specify that a client is using non-ASCII  
> addresses but all-ASCII headers.  Yet, the recipient server can't trust  
> this, so what is the benefit?

Kari's proposed HDR=UTF8 was an alternative to the "Header-Type" header  
(which is now officially dead, though it remains to be seen whether it  
will lie down :-) ).

The alternatives to both of those are scanning the whole message looking  
for headers which might need to be downgraded (which is indeed robust in  
the face of headers which you do not trust). However, it is not yet clear  
how to do such a scan, or whether it is even possible in the face of  
various strange message/* types. So we just have to hope that the ongoing  
discussions will find some agreed way to do it.

But, for sure, please can we avoid any mention of the ALT-ADDRESS  
parameters in the envelope as being related to whether the actual message  
contains utf8headers or not. That would just confuse the issue, because  
there is no connection there whatsoever.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Randall Gellens <[email-masked]>
Date: Thu, 8 Feb 2007 00:22:11 -0800

At 5:52 PM -0500 1/26/07, John C Klensin wrote:

>  Either they will get sorted out
>  at the right times, or the presence of DKIM signatures will be
>  taken in practice to encourage message rejection rather than
>  downgrading, or users (and MSAs) will end up with a choice
>  between internationalized email and DKIM.

Given the presumption that delivery paths between I18n mail users 
will tend to be upgraded to be UTF8SMTP compatible, the choice 
between I18n and DKIM is likely to be a temporary one.  Taking the 
presence of DKIM signatures to be an indication that, when needed, 
messages should be rejected rather than downgraded is perhaps another 
argument in favor of the requeue-and-retry-later technique when the 
next hop doesn't support UTF8SMTP.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Spotted on the back of a t-shirt worn by LAPD Bomb Squad:
"If you see me running, try to keep up."

/1.0) with ESMTP id
	l188Nc9O007700
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 8 Feb 2007 00:23:38 -0800
Date: Thu, 8 Feb 2007 00:22:11 -0800
To: John C Klensin <[email-masked]>, Charles Lindsey <[email-masked]>, 
	IMA <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Headers that define other headers and non-SMTP 
	environments (was:	Re: [EAI] The Header-Type header (was: Re: 	Status
	of utf8header	draft))
Cc: 

At 5:52 PM -0500 1/26/07, John C Klensin wrote:

>  Either they will get sorted out
>  at the right times, or the presence of DKIM signatures will be
>  taken in practice to encourage message rejection rather than
>  downgrading, or users (and MSAs) will end up with a choice
>  between internationalized email and DKIM.

Given the presumption that delivery paths between I18n mail users 
will tend to be upgraded to be UTF8SMTP compatible, the choice 
between I18n and DKIM is likely to be a temporary one.  Taking the 
presence of DKIM signatures to be an indication that, when needed, 
messages should be rejected rather than downgraded is perhaps another 
argument in favor of the requeue-and-retry-later technique when the 
next hop doesn't support UTF8SMTP.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Spotted on the back of a t-shirt worn by LAPD Bomb Squad:
"If you see me running, try to keep up."

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Feb 2007 07:10:33 -0500

--On Thursday, 08 February, 2007 00:22 -0800 Randall Gellens
<[email-masked]> wrote:

>>  at the right times, or the presence of DKIM signatures will
>>  be taken in practice to encourage message rejection rather
>>  than downgrading, or users (and MSAs) will end up with a
>>  choice between internationalized email and DKIM.
> 
> Given the presumption that delivery paths between I18n mail
> users will tend to be upgraded to be UTF8SMTP compatible, the
> choice between I18n and DKIM is likely to be a temporary one.
> Taking the presence of DKIM signatures to be an indication
> that, when needed, messages should be rejected rather than
> downgraded is perhaps another argument in favor of the
> requeue-and-retry-later technique when the next hop doesn't
> support UTF8SMTP.

Agreed.
    john