At 09:08 AM 5/26/02 -0500, dman wrote: >On Sat, May 25, 2002 at 06:53:08PM -0700, Scott Nelson wrote: >| At 11:01 AM 5/25/02 -0500, dman wrote: >| > >| >That sounds bad to me. I clearly recall a section of RFC821 stating >| >that an MTA MUST not mangle a message in any way. >| >| Nope, that's completely wrong. > >I went back to the RFC, and it's not completely wrong. > >RFC2821
Uh, rfc2821 does not equal rfc821. Also note that RFC does not necessarily equal reality. ... > >| Technically, you can't even guarantee that the mailer won't >| change mail from 8bit to 7bit by some foul method, > >SMTP only allows 7-bit data transfer... > You misunderstand me. If you've opened an 8 bit channel (and most do) and then send data with the high bit set, then all bets are off. RFC2821 handles this much better than RFC821, in that it specifies the exact mangling that is allowed; (RFC2821:2.4 a.k.a. 2.4.1) ... If such messages are transmitted in violation of this rule, receiving SMTP servers MAY clear the high-order bit or reject the message as invalid. The reality is that the vast majority of mail receivers accept 8 bit data without argument, and do not modify it, but this is not a behavior one can count on. >| add blank lines, > >RFC2821 4.1.1.4 > ... > An extra <CRLF> MUST NOT be added, as that would cause an empty > line to be added to the message. > ... > And if you go a little further in the same paragraph; ... in that case, the originating SMTP system MUST either reject the message as invalid or add <CRLF> ... In reality to fix a bug (that is now ancient history) many mailers added a blank line to completely empty messages. (for the curious, that's the origin of the .signature) The bug has long since vanished, but the fix remains on some systems. And no, it /shouldn't/. ... >| For example, most mail recivers will accept LF, or CRLF as >| the end of line character, and convert it to the appropriate >| character(s) for the local system. On transmit, they convert to CRLF. > >That's not allowed : > >RFC2821 2.3.7 > In addition, the appearance of "bare" "CR" or "LF" characters in text > (i.e., either without the other) has a long history of causing > problems in mail implementations and applications that use the mail > system as a tool. SMTP client implementations MUST NOT transmit > these characters except when they are intended as line terminators > and then MUST, as indicated above, transmit them only as a <CRLF> > sequence. > If I read that correctly it says that not only is what I claimed allowed, it's /required/. (Hmm... I'd better add that bit of mangling to my mail agent.) The RFCs also say that an agent is not allowed to delete email, but that is the entire /purpose/ of spam assassin. RFCs are not inflexible rules which everyone is required to follow, but rather a set of "best practice" guidelines. I think we agree on these guiding principles; "Change the message as little as possible." and "If you make changes, make them reversible if at all possible." No matter how you slice it, I can't see any justification for removing a complete line of text from the body of a message, even if it does start with "Bcc:". I just started ranting (instead of thinking) because I twigged on the "body of message isn't to be changed" part of what you said without reading the context of it. Scott Nelson <[EMAIL PROTECTED]> _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
