On Sun, May 26, 2002 at 09:28:19AM -0700, Scott Nelson wrote: | 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.
Right, it obsoletes it. (the copy I have says "Standards Track")
| Also note that RFC does not necessarily equal reality.
Sometimes that is unfortunately true, and other times it is a good
thing :-).
| ...
| >| 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.
Yeah, that's true. You're not supposed to send data with the high bit
in the first place :-) (unless 8BITMIME has been agreed upon).
There was a long discussion on that a while ago on the exim-users
list. A certain demon.nl customer was unhappy that all Norwegian
messages he received from a certain source had the non-ascii
characters mangled beyond recognition. This was the result of some
MTA sending raw 8bit data through demon's MMDF servers. MMDF (at
least the version demon had at the time) only implemented rfc 821 --
it understood neither EHLO nor 8BITMIME and really did provide only a
7bit channel. It took a while before that individual completely
understood the full implications of 8BITMIME and
Content-Transfer-Encoding how having a 7bit channel really isn't a
limitation.
| 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.
Right. exim is one of those. It has an option to advertise 8BITMIME,
but it doesn't not correclty implement that extension (because it
won't convert if relaying through a non-8bit server). I actually set
that option on my installation because I know my server is doing local
delivery only and thus has 8-bit-clean channels all the way.
| >| 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> ...
Yes, but in between those snippets is the description of the special
case you quoted. If the message contents is "null", then that's an
error and violates SMTP, but rfc 2821 allows for that to be less
sever. The particular situation is if the sender sends
DATA<CRLF>
.<CRLF>
(note the missing <CRLF> in front of the '.') The receiver, in this
particular case, is allowed to add a <CRLF>, thus making the message 1
blank line when it previously was "null".
| 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.
I didn't know that history.
| And no, it /shouldn't/.
Agreed.
| ...
| >| 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/.
It says that you are not allowed to transmit a LF or a CR character
under any circumstances, unless
o they are together as a CRLF pair
o they are intended to mark the end of a line
It does say that for local delivery/storage the stream can be
converted, but then it must be converted back to SMTP if the message
will continue to be transmitted over SMTP. The end result is that the
end parties can't determine whether or not such translation occurred
(and gpg, etc, signatures are still correct and base64 attachments
haven't been destroyed).
I actually found a bug in mutt related to this. The problem was that
when saving an attachment it opened the file in the "default" (text)
mode. Of course for a sane OS this doesn't matter, but I was using it
on cygwin, and the .doc files I was sent got corrupted.
| (Hmm... I'd better add that bit of mangling to my mail agent.)
Yes, most MTAs do accept plain LF anyways (AFAIK).
| The RFCs also say that an agent is not allowed to delete email,
| but that is the entire /purpose/ of spam assassin.
Pretty much, but the rfcs do allow the SMTP server to reject messages
for various policy violations. The usual example of a policy
violation is the recipient exceeding their disk quota. I think
inappropriate content also suffices as a policy violation :-). (and
SA is the tool that identifies inappropriate content)
| RFCs are not inflexible rules which everyone is required to follow,
| but rather a set of "best practice" guidelines.
True, but if the RFCs are not held with enough respect then they serve
no purpose at all (not to mention the names of any such developers
...).
| 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:".
Agreed on both points.
| 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.
Ok, no harm done :-).
HAND,
-D
--
One man gives freely, yet gains even more;
another withholds unduly, but comes to poverty.
Proverbs 11:24
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
msg05451/pgp00000.pgp
Description: PGP signature
