----- Original Message -----
From: "Eric Allman" <eric+dkim(_at_)sendmail(_dot_)org>
Great! Thanks for the pointer. So it's not a problem with DATA.
Do we want to worry about the BDAT case? My suggestion would work
for that (but break your implementation).
It also occurs to me that there is an assumption in DKIM (and
probably a lot of other specs) that the mail body is text. It
doesn't have to be if you use BODY=BINARYMIME [RFC3030]. Is this
worth considering? It seems like it would either require redefining
simple body canonicalization if you have a BINARYMIME message, or
defining a new canonicalization ("binary"?) that allows absolutely no
changes. Of course, a new canonicalization can be added later.
eric
This canonicalization concept seems to be a big PITA. We need a consistent
and working concept out of the gate. Is it not possible to get a single
straight forward method now?
Sure, new methods can be added in the future, but I don't have to tell you
about legacy and version control issues. Just consider that we already have
few active DKIM participants who are so dependent on alpha-ware designs and
are highly resistance to final design changes. :-)
I just seem to think that if we can't resolve this now, I doubt it will be
resolved later.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html