Re: [EAI] How to prevent up-conversion (Re: Respawn "Messages on original form" (Re: I-D ACTION:draft-ietf-eai-imap-utf8-01.txt))

["Charles Lindsey" <chl at clerew.man.ac.uk>]

On Tue, 27 Mar 2007 02:58:12 +0100, John C Klensin <klensin at jck.com> wrote:

> (combined answer)
>
> --On Monday, 26 March, 2007 16:50 +0100 Charles Lindsey
> <chl at clerew.man.ac.uk> wrote:
>
> > > Charles Lindsey wrote:
> > > > Generally speaking I just regard it as a fundamental
> > > > requirement of any   internet protocol to be able to examine
> > > > what was actually on the wire,   before other agents started
> > > > to "improve" it.
> > > If taken to mean what the words mean in their dictionary
> > > definitions,   what you are asking for is packet trace.
> > > The most reasonable tools for that are called "tcpdump" and
> > > "ethereal"   (provided that your "wire" is an Ethernet, of
> > > course).
> >
> > Yes, I am not concerned about the inner structure of TCP
> > packets. But what I DO want to see is that anyone who receives
> > an email in his MUA (whether via an IMAP storage server of
> > otherwise) can have access to the original RFC 2822 object as
> > it arrived on the wire at the final MTA. The ability to
> > provide that service constrains somewhat what IMAP
> > implementations can do internally.
>
> I do not believe this is a requirement for IMAP implementations
> today (for all-ASCII messages).   Retrieving the various pieces
> as pieces and reassembling them doesn't count, since that may or
> may not exactly restore the original, received-by-MTA, version.
> If it is not, I suggest that it is out of scope for this WG
> until and unless IMAPext gets around to making the change for
> the base specification.

I think it is more a question of what current IMAP implementations  
actually DO, rather than what they are required to do.

Let us take an example. A message body was in Q-P on the wire. Is the IMAP  
implementation entitled to store it in only its decoded (8bit) form?  
Suppose the message was in fact signed by DKIM or PGP-mime (both of which  
are supposed to sign the Q-P form - a bad design decision, but there it  
is). The recipient (or his MUA) finds that the signature is broken. So the  
recipient requests to see the original form of the message so that he can  
check for himself exactly why the signature did not work (maybe some  
trailing empty line had got lost, and by manually restoring it he can make  
the signature work).

Now, if all that is required to work in current IMAP (or in practice does  
work), then I want corresponding scenarios in UTF8SMTP to work as well.

The corresponding situation in UTF8SMTP is where the message arrived at  
the final MTA in downgraded form. Is the IMAP implementation allowed to  
upgrade it, and store only the upgraded form (thus depriving the recipient  
of any possibility of seeing the downgraded form and thus possibly being  
able to debug some obscure side effect of the upgrading process)?

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 ;                      
   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      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

_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima