ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Possible problem with "simple" body canonicalization -- trailing CRLFs

2006-07-19 14:43:54
Exactly. If you're using something other than SMTP DATA, such as SMTP
BDAT, it is conceivable that the body could wind up without an ending
CRLF....

BDAT is part of the CHUNKING extension defined in experimental RFC
1830 in 1995.

Your information is out of date. RFC 1830 was superceded by RFC 3030 in
December 2000. RFC 3030 is a proposed standard and I believe there has been
talk about advancing it to draft. I'm pretty sure there are enough
implementations.

It's been 11 years.  Does anyone use it?

There's some use, but there are also incompliant implementations out there that
make unrestricted use of BDAT somewhat problematic. I currently have it enabled
on my home system after having added some workarounds for some compliance
issues, but a couple of folks are reporting having trouble sending me mail now
that i have it on. The problem appears to be BDAT-related so I'm probably going
to have to disable it. Given the limited traffic on my system this is not a
good sign.

Has anyone even proposed making it standards track?

The question is, of course, moot, but FWIW the move to standards track was done
at the behest of the VPIM WG. I believe the LEMONADE profile calls for support
for both CHUNKING and BINARYMIME. (Although to be fair, I have yet to see a
single tangible result arise from any email service profile document other than
RFC 1123.)

I don't ever recall running into it,

CHUNKING is definitely deployed to some extent. However, there are actually two
extensions: CHUNKING and BINARYMIME, and from what I've seen there's a lot less
support out there for BINARYMIME than for CHUNKING. Without BINARYMIME all you
have is a somewhat more efficient data transfer mechanism - you're still
dealing with 7bit or 8bit material. Stuff like the final line not being
terminated with CRLF is only supposed to be possible when BINARYMIME is used.

so I don't see any point in worrying about it.

Well, one thing I do worry about is the assumption some folks keep making that
the transport infrastructure doesn't, or isn't supposed to, mess around with 
message content. Like it or not, operations like encoding downgrading (or
upgrading) are an explicit part of the email architecture and have been ever
since MIME came out. Getting this particular genie back in the bottle is
effectively impossible at this point, and the issues it may cause if we don't
get the applicability of DKIM right will make problems relating to bare CRs and
LFs pale in comparison.

This is why I keep pushing back on client use of DKIM. I think DKIM can be made
to work across boundaries between administrative domains, but any more than
that is asking for trouble.

                                Ned
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>