Subject: [EAI] I-D ACTION:draft-ietf-eai-utf8headers-03.txt

From: [email-masked]
Date: Thu, 01 Mar 2007 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Email Address Internationalization Working Group of the IETF.

	Title		: Internationalized Email Headers
	Author(s)	: J. Yeh
	Filename	: draft-ietf-eai-utf8headers-03.txt
	Pages		: 14
	Date		: 2007-3-1
	
Full internationalization of electronic mail requires not only the
   capability to transmit non-ASCII content, to encode selected
   information in specific header fields, and to use non-ASCII
   characters in envelope addresses.  It also requires being able to
   express those addresses and information based on them in mail header
   fields.  This document specifies the use of Unicode encoded in UTF-8,
   rather than ASCII, as the base form for Internet email header field
   bodies.  This form is permitted in transmission only if authorized by
   an SMTP extension, as specified in an associated specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-eai-utf8headers-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-eai-utf8headers-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: "abel" <[email-masked]>
Date: Thu, 8 Mar 2007 14:49:23 +0800

Do we discuss those more ?

1. As I know in SPF
    SPF TXT record listed where  my email come from list in this domain ,

    A example in downgrading :
>>ehlo twnic.net.tw
>>mail from: <[email-masked]>  ALT-ADDRESS=[email-masked]  # EAI-aware
>>rcpt to:<[email-masked]>     # non-EAI-aware

when the downgraded mail transmits , if other.domain run SPF check, we can
pass in SPF helo check ,but fail in SPF  sender check ([email-masked]) if
gmail.com SPF records with -all unless gmail.com adds SPF for us,
but it seems impossilbe to do that.
Fujiwara's downgrade-03 draft said 'more detailed consideration is required'
in Section 5, But I think that SPF sender check will break ALT-ADDRESS
without
restriction.

2. DKIM
    Header change (downgraded / drop ) maybe break the signatures,

a downgraded mail keeps the original header can follow DKIM, but DKIM
should know how to verify and reduction.

2.1 Downgrading after DKIM, some header value has changed by downgrading
   procedue when transmits, DKIM verifier should restores 'Downgraded:'
   header to verify, and all 'Downgraded:' headers are above
'DomainKey-Signature'
   header.
2.2 Downgrading before DKIM, DKIM signs the downgraded headers, it's
possible
   to include 'h=Downgraded:' in 'DomainKey-Signature', all 'Downgraded:'
   headers are under DomainKey-Signature header, DKIM verifier should verify
   all 'Downgraded:' headers if there are 'Downgraded' in tags 'h='

   And we still need to more consideration about the downgrading impact  in
   DomainKey-Signature  tags 'd=' (domain) 'i=' (sender) 'z=' (header name
   and header values in quoted-printable) or more.

If we drops header values (such as uFor or others ) and the headers are
signed in
'DomainKey-Signature' will cause Domain Key verifier  treats as a bad
signature
if they do not appear ,especially in trace field, that's fine in trace filed
rule
and DKIM siner/verifier issue.

---

From: Kari Hurtta <[email-masked]>
Date: 08 Mar 2007 09:33:39 +0200

> Do we discuss those more ?

I think that we should.

> but it seems impossilbe to do that.

Yes, but that do not much differ from  
     ehlo twnic.net.tw
     mail from:<[email-masked]>

I think that there is no new restrictions.

On general if you have
     ehlo twnic.net.tw
     mail from: <[email-masked]>  ALT-ADDRESS=[email-masked]

if gateway.example ia providing forwarding service, it practically 
can not provide SPF records --  not providing SPF records is part
of service. 

>     Header change (downgraded / drop ) maybe break the signatures,

Also header change ( conversion to UTF-8 by IMAP/POP server) may 
break signatures. This also need to be discussed.

>    header to verify, and all 'Downgraded:' headers are above

A)

That requires that Donwgrading -undo algorithm ('upgrade')
in draft-ietf-eai-downgrade really returns original header fields.
Currently there is:

     *  If each mail header has [RFC2047] encoded part and which
         encoding is "UTF-8", it is a downgraded header, so decode it.

This does NOT fill these requirements.  

Currently 'downgrade' part of algorihm even do not preserve
original header fields (except address header fields) to
'Downgraded:' -header fields.

If algorithm is modified and original header fields are preserved
on Downgraded: -header field, on Donwgrading -undo algorithm there
is little problem -- it needs to know which one header fields must
discard -- it must discard correspond downgraded header field, 
when restoring data from Downgraded: -header field -- otherwise
more header fields with same name is generated than on original message.

B)

DKIM signature verify may accur on agent which do not know about
UTF8SMTP protocol -- therefore it will not know how to upgrade header fields.

That also causes that DKIM signature verify fails.

To prevent that downgrading need to move DomainKey- -header fields
to Downgraded: -header fields and destroy original header fields.

... problem there is that downgrade procedure needs know every signing
    protocol ...

( You may want compare how I proecess exatcly this same promlem
  on my draft-hurtta-eai-encapsulation-00.txt  draft. )

> and DKIM siner/verifier issue.

/ Kari Hurtta

---

From: "abel" <[email-masked]>
Date: Thu, 8 Mar 2007 16:26:44 +0800

Thanks for Kari comments,
These remind us to pay attention to more details in SPF and DKIM

> can not provide SPF records --  not providing SPF records is part
Yes, but users/clients dont know whether their provider has SPF record in
their ALT-ADDRESS,
If there are SPF in thoes domain include '-all' , that maybe cause their
mail to be rejected.
Mail adminstrator is hard to explains those issue to their clients.

> break signatures. This also need to be discussed.
Agree!  we miss.

> 'Downgraded:' -header fields.
I 'm not sure what headers information we lose, but 'change' is a issue in
DKIM

> more header fields with same name is generated than on original message.
yes, agree!

>   on my draft-hurtta-eai-encapsulation-00.txt  draft. )
yes, DKIM dose not know how to -undo header fields in 'Downgraded',
and our Drafts does not memtion those more details.

Abel

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 08 Mar 2007 12:21:46 -0000

> should know how to verify and reduction.

There are no simple answers to the question of EAI and DKIM, but there are  
some possibilities that might be worth exploring.

But first some general points. The first requirement is that DKIM  
verifiers should be able to recognise when they are being asked to verify  
a downgraded message (what they do then is less certain, but without that  
information they are totally stuck).

And the second is that you should include as few headers in the signature  
as will suffice to achieve the desired level of security. The more headers  
that are included in the signature, the less likely that any verification  
will be possible.
>    header to verify, and all 'Downgraded:' headers are above

Yes, that is one possible approach. In principle the changes specified in  
our 'downgrade' document should be reversible. In practice, it is not so  
sure how well that would work. It might be easier if DKIM included an even  
more relaxed canonicalization algorithm. And it is more likely to work the  
fewer headers covered by the signature (but, unfortunately, including the  
 From header is a MUST).

>    and header values in quoted-printable) or more.

Again, if the downgrade process is suffficiently well defined that all  
downgraders will produce exactly the same dongraded message, then signing  
that (even if what you send is the original utf8 form) would suffice. Even  
better, include two signatures, one for the original utf8 version (which  
should verify without problem at site that receive it in that form) and  
one for the downgraded version.
> and DKIM siner/verifier issue.

Generally speaking, signing trace fields is a Bad Thing.

It is doubtful whether this WG should be looking into this issue in too  
much detail at this stage, but it is nevertheless useful to have some idea  
of what the problems and possibilities might be, since the matter will  
have to be settled at some stage.

-- 
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: John C Klensin <[email-masked]>
Date: Thu, 08 Mar 2007 10:59:28 -0500

> These remind us to pay attention to more details in SPF and

Sorry, but let me suggest a different view, one that I think is
important if anyone actually wants to finish this stage of the
work.  Please remember that we are many, many months behind our
original schedule which was to have Experimental documents
approved and in the publication queue before the end of last
calendar year.

The charter calls for us to worry about compatibility issues
with the base email infrastructure.   We originally thought
about that in terms of what is covered by 2821 and 2822.  It has
been expanded to include DSNs, POP, IMAP, and consideration of
mailing lists (the latter are covered in 2821 although very
superficially).  

It does not specify compatibility with SPF, or DKIM, or any of
several dozen activities and proposals for dealing with email or
using it in unusual ways.

The WG signed off on "framework".  It discusses "systems or
mechanisms that are dependent on digital signatures or similar
integrity protection for mail headers" and mentions the need for
DKIM and this work to _eventually_ consider each other" but
explicitly indicates that this work will not "address or solve
the issues" in Section 9 on Security Considerations.  There is
also a discussion of signed body parts and downgrading in
Section 6.4 on "Encoded words, signed messages and downgrading"
that concludes 
"...downgrading must be performed with extreme care if at all."

I believe that, if we make smooth working of DKIM, SPF, etc.,
especially in systems that have not been upgraded to work with
UTF8SMTP mail, a requirement for an acceptable downgrading
solution that we will never find an acceptable downgrading
solution.   

We actually know how to make systems like that work today
(assuming they are upgraded to recognize our addresses) and that
is to reject or bounce any message that contains their headers
and would otherwise need to be downgraded.  My instinct is that
we are better off ignoring them, downgrading, and letting the
final delivery system sort things out.   Perhaps it would be
wise to remove the SPF or DKIM headers entirely on downgrade
instead, but advice on that option should come from those WGs
--we should not be guessing here about what would cause the
least damage in their various scenarios.

But the bottom line, IMO, is that, if we are sincerely
interested in getting this work done we ignore anything that is
not in the Charter or critical to completing chartered work, at
least until we get the Experimental documents finished.  I
believe that anyone considering bringing these issues up again
on the mailing list should first ask him or herself whether the
probable outcome of delaying, or even killing, this work is
worth it... and whether he or she wants to take responsibility
for that.

     john

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 08 Mar 2007 19:38:17 +0100

> Do we discuss those more ?

For SPF I consider a separate draft.

> but it seems impossilbe to do that.

Downgrading is actually the simple case.  Of course using different policies
for the UTF-8 address and the ALTADDRESS would be unwise (putting it mildly).

A simple way to guarantee no nonsense is to use the same domain resulting
in the same policy, e.g.

MAIL FROM:<[email-masked]> ALT-ADDRESS=[email-masked]

It starts to get more interesting without downgrading if the local part
uses UTF-8, and the result has to be reported in a Received-SPF header
field.  And of course no SPF implementation already supports the IDNA
magic to deal with internationalized domains, but in theory that's a
solved problem (okay, I lurk on the IDNAbis list, s/theory/THEORY/ :-)

Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 09 Mar 2007 08:44:36 +0100

> Mail adminstrator is hard to explains those issue to their clients.
I think the brutal answer is "don't do that".
If you use an email address in an ALT-ADDRESS, that needs to be an email 
address controlled and managed by someone who's actively supporting 
UTF8SMTP - including mangling the SPF records (if any) to allow the 
gateways to send the messages as needed.

                    Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 09 Mar 2007 08:46:03 +0100

> For SPF I consider a separate draft.
I think a separate draft is a Good Idea.
As John said, consideration of such a draft isn't on the WG's agenda 
until the core specs are shipped for Experimental.

              Harald

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Mar 2007 11:36:26 -0500

--On Friday, 09 March, 2007 08:44 +0100 Harald Alvestrand
<[email-masked]> wrote:

>> Yes, but users/clients dont know whether their provider has
>> SPF record in their ALT-ADDRESS,
>> If there are SPF in thoes domain include '-all' , that maybe
>> cause their mail to be rejected.
> If you use an email address in an ALT-ADDRESS, that needs to
> be an email address controlled and managed by someone who's
> actively supporting UTF8SMTP - including mangling the SPF
> records (if any) to allow the gateways to send the messages as
> needed.

I may be wrong, but I think that, in the overwhelming number of
cases in which downgrade is actually plausible, Abel's analysis
is going to turn out to be equivalent to "for a
backward-pointing address, either 

(1) Use SPF without ALT-ADDRESS, thereby guaranteeing message
rejection if a downgrade situation arises.

(2) Use ALT-ADDRESS without SPF, thereby losing whatever
benefits SPF is expected to convey but without the risk of an
apparently-clear SPF rejection.

(3) Use them together and just hope that, if downgrading occurs,
it occurs with a domain context that is sufficiently permissive.

And, again, if someone wants to put that, or other comments,
into a separate document that is not on the WG's plate (or
discussed on its mailing list), at least in the near term, I
think that would be great.  In particular it is a set of issues
that such a document might usefully bring to the attention of
the SPF community.

     john