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: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Barry Leiba
Sent: Saturday, October 02, 2010 10:24 AM
To: ietf-dkim(_at_)mipassoc(_dot_)org
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 <johnl(_at_)iecc(_dot_)com>
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