Eric Allman wrote:
--On December 15, 2006 7:58:39 AM -0800 Michael Thomas <mike(_at_)mtcc(_dot_)com>
wrote:
The thing that I've seen is that at the very least sendmail will
strip a body with a single CRLF to a null body in its output stage;
I would not be surprised to hear that other MTA's do similar
transformations.
Um... to the best of my knowledge, sendmail will never strip any
data, including trailing CRLFs. It will /add/ a CRLF under certain
circumstances, which include when mailing to a local v7 mailer that
requires a double CRLF between messages.
An update: just proving that none of this stuff can be simple... I
traced between
my home sendmail and cisco's ironports, and you are right: sendmail does
keep
that CRLF in the body. However, something between our DKIM verifier and
one of the inbound Ironport chopped that CRLF off. In reality it looks like:
mtcc.com(sendmail) --> inbound.cisco.com(ironport) --> core
(sun/sendmail) --> dkim (linux/sendmail)
somewhere beyond the first hop, the last CRLF got chopped.
also:
mail.com(sendmail) -> deliver (procmail local)
is chopping off the CRLF as well.
So it may be that local delivery *and* something in Cisco's core is
doing this. Which
kind of points the finger at the Ironportm but who knows. I don't have
access to the core
sendmail configs, but the dkim sendmail configs don't leap out to me
that they might be doing
something odd.
In any case, this weirdness says that regardless of intent the current
canonicalization as
written is actually more robust, and we should keep it that way.
Mike
However, Tony is completely right about the ambiguity, except that
it's actually larger than he says --- it appears the draft doesn't
clearly specify whether you canonicalize then truncate, or truncate
then canonicalize. The only one that actually makes sense from an
interoperability sense is to canonicalize and then truncate. By this
reading, l=0 would not include a trailing CRLF.
Is my logic logical?
eric
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html