I can provide one example (case) of an implementation breaking signing. In the case where a transmitted message does not specify a mime type, Ironport appliances will do the DKIM signing and afterwards add the mime type header ASCII.
This is a bit of an edge case but is illustrative of a way in which a signature might be broken. I identified this issue (and submitted to Ironport) back in late 2007 or early 2008 (I would have to do some digging to nail it down exactly). The problem was created when the "dot stuffing" issue in their implementation was fixed). RFC1521 (and subsequent) indicate (wording varies slightly over time/RFC): Default RFC 822 messages are typed by this protocol as plain text in the US-ASCII character set, which can be explicitly specified as "Content-type: text/plain; charset=us-ascii". If no Content-Type is specified, this default is assumed. In the presence of a MIME- Version header field, a receiving User Agent can also assume that plain US-ASCII text was the sender's intent. In the absence of a MIME-Version specification, plain US-ASCII text must still be assumed, but the sender's intent might have been otherwise. So there isn't really a need to "fix" this because the RFC indicates US-ASCII is assumed if not specified - but if it were to be "fixed" by a helpful MTA, it should be done before DKIM signing rather than after. The only reason I found this issue is that I do testing for various things using manual SMTP sessions and lazy person that I am, I do not type in the extra characters to specify content type. I haven't posted this publicly before because it seemed (as an implementation issue) something that was somewhat esoteric. Mike > -----Original Message----- > From: [email protected] [mailto:ietf-dkim- > [email protected]] On Behalf Of Barry Leiba > Sent: Saturday, October 02, 2010 10:24 AM > To: [email protected] > Subject: Re: [ietf-dkim] Updated implementation report > > I'd like to rein in discussion a bit, here. Or, perhaps more > accurately, separate the threads. It's fine if folks want to talk > about the relative value of some kinds of signatures relative to > others, and so on -- that sort of thing actually is on our charter. > But it's a separate item from getting an implementation and > interoperability report done. > > To that end, let's make sure we keep the threads separate. John's > comment, to which I'm replying here (see below), is the sort of > comment that will help finish the implementation report. Let's take > comments about what we think the report tells us about the efficacy of > DKIM... to separate threads. Thanks. > > Barry, as chair > > > On Fri, Oct 1, 2010 at 11:04 PM, John R. Levine <[email protected]> wrote: > >>> If this is the #1 reason that verifications fail, would there be room > >>> for a new canonicalization scheme, to improve verification rates? > > > > Seems to me it would be more appropriate to add a note saying something > > like be sure your headers are all RFC 5322 compliant before signing, > > including arcana such as quoting rules in address fields, to avoid > > signature failures due to helpful relay MTAs fixing the quoting errors > on > > the way through. > > > > As far as figuring out who's doing what, it's hard to think of anything > > better than running a bunch of deliberately marginal messages through a > > variety of MTAs and see what happens. A couple of years ago I set up a > > forwarding project, in which I asked people to set up different MTAs to > > forward mail back to me, just so we could find out about this kind of > > stuff. The code has suffered severe bit rot but if people really wanted > > to use it, I could probably resuscitate it. > > > > R's, > > John > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
