Subject: [EAI] Messages on original form (Re: I-D ACTION:draft-ietf-eai-imap-utf8-00.txt)

From: Kari Hurtta <[email-masked]>
Date: 06 Feb 2007 21:29:49 +0200

Question about imap draft.

Is there possible to retrieve mail messages on original from ?

I think that I missed to something, but it looked like IMAP server
do all messages up conversion or down conversion depending of selected
access method.

What I have looked for is:
        1) UTF8SMTP messages are returned UTF8SMTP form

        2) Downgraded UTF8SMTP messages are returned UTF8SMTP form
           (ie. selective up conversion)

        3) Non-UTF8SMTP messages are returned on RFC (2)822 from
           (ie. no up conversion)

That is import for signed messages, I think.

/ Kari Hurtta

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

---

From: Chris Newman <[email-masked]>
Date: Thu, 15 Feb 2007 15:33:10 -0800

If I put my IMAP/POP server implementer hat on, I have no concept what 
"original form" means.  There's typically only one message form available, 
which is the form of the message that's in the mail store.  More often than 
not, the IMAP/POP server has no idea how the message got into the mail store or 
what it looked like before it was delivered.

Attempting to make signatures survive message transformation is unnecessary 
complexity.  End-to-end signatures can be embedded in a multipart/signed which 
already forbids any transformation of the embedded content (the downgrade 
document should reiterate this restriction, IMHO).

                - Chris

---

From: Kari Hurtta <[email-masked]>
Date: 16 Feb 2007 16:44:19 +0200

Chris Newman <[email-masked]> writes in  gmane.ietf.ima:

> "original form" means.  There's typically only one message form
> available, which is the form of the message that's in the mail store.
> More often than not, the IMAP/POP server has no idea how the message
> got into the mail store or what it looked like before it was delivered.
> 
> Attempting to make signatures survive message transformation is
> unnecessary complexity.  End-to-end signatures can be embedded in a
> multipart/signed which already forbids any transformation of the
> embedded content (the downgrade document should reiterate this
> restriction, IMHO).
> 
>                 - Chris

Well, I have seen servers which combine at least final delivery,
mailstore and imap to one product.

Well, I still do not like that if
 
      mailstore, imap combination  helpfully "upgrades" messages
      which do not have sent as UTF8SMTP on first place. At least
      UTF8SMTP capable IMAP clients should have way to avoid that.

/ Kari Hurtta

---

From: Chris Newman <[email-masked]>
Date: Fri, 16 Feb 2007 19:27:47 -0800

>       UTF8SMTP capable IMAP clients should have way to avoid that.

The WG has not had a consensus discussion on the "upgrade" behavior in the 
IMAP/POP specifications so I consider that point an open issue.

However, my goal in writing the specifications the way I did was to begin the 
process of deprecating RFC 2047/2231 in favor of native UTF-8.  If the WG 
decides not to pursue that goal, then the specifications will have to be 
modified accordingly.

                - Chris

---

From: Kari Hurtta <[email-masked]>
Date: 22 Feb 2007 16:45:09 +0200

> embedded content (the downgrade document should reiterate this

Multipart/signed does not help for DKIM.  It also requires that
message is converted to 7-bit form before signing. 

So for header fields which are part of signature that then means that 
EAI/UTF8SMTP is not used, but instead MNIME encoding is used.

If these header fields are 'upgraded' then MUA, which check signature, 
will see broken message.

Better to not go to full conflict with that working group.

/ Kari Hurtta

  http://www.ietf.org/internet-drafts/draft-ietf-dkim-base-10.txt

( The IESG has approved 'DomainKeys Identified Mail (DKIM) Signatures'
   <draft-ietf-dkim-base-10.txt> as a Proposed Standard. )

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 22 Feb 2007 18:13:05 -0000

> message is converted to 7-bit form before signing.

Indeed, the fact that both multipart/signed and DKIM insist on signing the  
C-T-encoded form on the wire (which may vary as it passes through various  
agents), instead of signing the original, unencoded form of the message  
(which is presumably what the signer actually cares about) is one of the  
major stupidities of both those schemes.

> Better to not go to full conflict with that working group.

I have already been there and done that. And it is accepted that the only  
way out is to define a new 8bit-clean canonicalization that signs the  
unencoded form. I intend to do that, but want to wait until I understand  
message/* types better (which just happens to be an active topic on this  
group).

-- 
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: Harald Alvestrand <[email-masked]>
Date: Fri, 23 Feb 2007 09:22:04 +0100

Charles Lindsey wrote:
> Indeed, the fact that both multipart/signed and DKIM insist on signing 
> the C-T-encoded form on the wire (which may vary as it passes through 
> various agents), instead of signing the original, unencoded form of 
> the message (which is presumably what the signer actually cares about) 
> is one of the major stupidities of both those schemes. 
Charles, the consensus of all the WGs that have been over this field was 
that it was impossible to preserve signatures if one signed the 
unencoded format.

It's possible that you are a genius and everyone else who's worked on it 
is an idiot.
But it's also possible that you haven't understood the problem.

                        Harald

---

From: Kari Hurtta <[email-masked]>
Date: 23 Feb 2007 11:31:26 +0200

Harald Alvestrand <[email-masked]> writes in gmane.ietf.ima:

> > Indeed, the fact that both multipart/signed and DKIM insist on
> > signing the C-T-encoded form on the wire (which may vary as it
> > passes through various agents), instead of signing the original,
> > unencoded form of the message (which is presumably what the signer
> > actually cares about) is one of the major stupidities of both those
> > schemes.
> Charles, the consensus of all the WGs that have been over this field
> was that it was impossible to preserve signatures if one signed the
> unencoded format.
> 
> It's possible that you are a genius and everyone else who's worked on
> it is an idiot.

For leaf body parts on MIME structure similar than Content-MD5
can be used ( RFC  1864 ).   That calculates hash from unencoded format.

But I do not believe that something like that works with header fields.

Also that kind signature is difficult extend to mime structure
(and not just to MIME leaf parts.)

/ Kari Hurtta

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 23 Feb 2007 13:16:02 -0000

>> various agents), instead of signing the original, unencoded form of the  
>> message (which is presumably what the signer actually cares about) is  
>> one of the major stupidities of both those schemes.

It is certainly impossible using the tools as defined in RFC 1847 and RFC  
3156. The question is whether they could have written things differently.  
Both Q-P and Base64 and fully reversible encodings (if implemented  
correctly), so there is no fundamental problem that I can see, and  
Content-MD5 was defined successfully on the basis that the unencoded text  
would be signed.

If the object to be signed is a multipart or message type, it is not clear  
how RFC 3156 is supooosed to work (it instructs you to encode something  
that MIME does not permit you to encode). RFC 1847 does seem to indicate  
how to deal with that case.

It is also interesting to note that RFC 3156 contains the words

       Implementor's note: It cannot be stressed enough that applications
       using this standard follow MIME's suggestion that you "be
       conservative in what you generate, and liberal in what you
       accept."  In this particular case it means it would be wise for an
       implementation to accept messages with any content-transfer-
       encoding, but restrict generation to the 7-bit format required by
       this memo.  This will allow future compatibility in the event the
       Internet SMTP framework becomes 8-bit friendly.

Since our present task is to bring about that state where "the Internet  
SMTP framework becomes 8-bit friendly", it may yet one day become possible  
to take full advantage of that liberality.
> But it's also possible that you haven't understood the problem.

Evidently so. Perhaps you could explain it.

As far as DKIM is concerned, see  
http://www.cs.man.ac.uk/~chl/uncode/uncode.html for a Perl script to do  
what is required (it is not quite correct in the case of some message  
types as it stands, but that shold be fixable).