ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] [EAI] IETF Last Call comment on downgrade

2009-01-12 06:25:24
On Fri, 09 Jan 2009 15:31:57 -0000, John C Klensin <klensin(_at_)jck(_dot_)com> 
wrote:

Now, if what you are really asking about is my personal
opinion... At this point, I believe we would be better off

      * without Downgrade as specified
      * pushing for rapid implementation and deployment of an
        internationalized email solution that is free of
        in-transit downgrading and the associated syntax,
        header, digital signature, etc., issues
      * concentrating our efforts on address downgrading
        procedures that could be applied at the endpoints --
     the sending MUA or submission MTA and after SMTP final
        delivery, rather than figuring out how to make
        in-transit work
      * getting more specific about the cases in which
        in-transit downgrading might be needed and how they can
        best be avoided by careful configuration.

Yes, that is a situation we can hope to arrive at eventually, but perhaps  
not so soon as you seem to imply. For sure, there would have been huge  
outcries if we had tried to introduce it with no downgrading right from  
the start, so we had to do it that way. What happens next will depend on  
how successful and how widely adopted implementation turns out to be. and  
we shall not know that for a few years yet. But it would probably be  
useful to mention in some document somewhere that there is an intention  
that downgrading can eventually be phased out.

MIME got itself into a mess when it invented 8BITMIME, by saying that  
implementations offering it MUST downgrade to 7bit if the next hop does  
not advertise that extension. BUT, in practice, you would be hard pressed  
nowadays to find a working server that was NOT 8-bit clean, at least for  
bodies (and even 8bit cleanliness in headers is becoming near-universal).  
But, of those 8-bit-body-clean implementations, some do not offer the  
downgrqde service and, of those, some still advertise 8BITMIME rergardless  
(e.g. qmail), whereas others (e.g. EXIM) refrain from advertising it  
(though EXIM does allow individual admins to override that restraint).

The result of all that, as it turns out, is that 8bit stuff propagates  
just fine, even via qmail, except that much unnecessary downgrading to  
7bit takes place on account of implementations like EXIM which do it but  
don't advertise it. And this unnecessary downgrading brings its own  
problems, such as failure of s-MIME and DKIM signatures. Indeed, there is  
just too much Q-P and base64 stuff flowng around these days, most of it  
not really necessary.

So we need some sort of "sunset" clause that indicates that this state  
will not last for ever. But at least, with IMA, we have quite properly  
arranged that bouncing is an acceptable alternative to downgrading, and  
this may well lead to the development of large cimmunities within which  
downgrading is not provided, and I have no problem with that.

-- 
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(_dot_)man(_dot_)ac(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [ietf-dkim] [EAI] IETF Last Call comment on downgrade, Charles Lindsey <=