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

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



(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.



--On Thursday, 22 March, 2007 18:46 +0200 Kari Hurtta
<hurtta+gmane at siilo.fmi.fi> wrote:

>> (I can see a couple of possible reasons why you would want
>> this. But I can't tell from your messages which ones you are
>> thinking of.)
>> 
>>                 Harald
> 
> Well, I have needed these kind functionality at least
> 
>          - For debugging   
>               (as postmaster I usually require to see original
> message                -- some time I answer -- sorry, that
> was not original                message as received -- before
> I can help, I want original                message -- not
> forwarded text or reformatted message. 
> 
>                This is usually related to junk filtering)

For debugging, you need a direct interface to the message store.
You may even need to specify what your delivery MTA puts in the
message store, or that it do a write-aside on messages as well
as logging them and you need to access that.  But you don't need
to impose extra requirements on either EAI formats or IMAP.
Such requirements might make your life easier, but they come at
the price of more complexity for everyone.
 
>          - For learn junk filters

Maybe, but, as you suggest above, this may be more similar to
debugging and may need special interfaces for other reasons.

> Also I can see that MUAs needs to see messages on original form
> when checking signatures of messages. Most of signature
> algotihms sign messages on form where no further encoding is
> not needed. That means that all signed data is encoded to
> 7-bit.

That is a reason to not up-convert before getting to the final
MUA (or user portion thereof).  If I put a signature on a
message as an integrity check, I really don't want an
intermediate system to turn the message inside out, or even
convert it to something else, and then have another intermediate
system try to restore it sufficiently to make the signature
work.  That is really scary to me.  

We shall see what happens in practice, but I think we will see
pressure from user/ consumers of mail systems to be able to
configure "no downgrade with signed messages", "no downgrade
with DKIM headers", "strip signatures and/or dkim headers on
downgrade" and probably some similar options.

    john








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




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.