Tony Hansen wrote:
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. Of course, the likelihood of both that *AND* the MTA adding an
extra CRLF during transmission does seem to me to be rather low.
So, do we worry about this potential case or not?
So not knowing anything about BDAT, isn't an MTA that added CRLF's to
binary data that it claims to understand (via ESMTP) be somewhat... broken?
Mike
Tony
Michael Thomas wrote:
I must be missing something. The 821 input string of:
a b</body></html>CRLF
.
CRLF
already contains the final CRLF of the body, so there wouldn't be a
situation where you'd ever see an input string of the form: a
b</body></html> (no crlf), right? Or are you saying that's the case
for DATA, but maybe not BDAT?
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html