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 3.8.7
As discussed in section 2.4.1, a relay SMTP has no need to inspect or
act upon the headers or body of the message data and MUST NOT do so
except to add its own "Received:" header (section 4.4) and,
optionally, to attempt to detect looping in the mail system (see
section 6.2).
(there is no section 2.4.1 though :-()
| 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. There is the 8BITIMIME
extension, and that requires the encoding from 8bit to 7bit if a
receiver doesn't advertise 8BITMIME. That encoding still isn't
mangling. The difference is the encoding is reversible. Continuing
the post office analogy, it's as if they put your package in a plastic
bag so that it wouldn't be destroyed by the rain.
| change it from ascii to EBCDIC,
If it is doing that then it is a Gateway because EBCDIC isn't used on
the Internet. SMTP only supports the US-ASCII charset.
| 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.
...
I don't think freedom to add blank lines is given when measures to not
add extra lines are taken.
| or do just about anything else it damn well pleases.
RFC821, RFC2821 4.5.2
In some systems it may be necessary to transform the data as it is
received and stored.
...
If such transformations are necessary, they MUST be reversible,
especially if they are applied to mail being relayed.
RFCs 821 and 2821 are careful to take measures to ensure that the
message that arrives to the recipient is the same message that was
sent by the sender. SMTP servers aren't given the freedom to do
whatever they feel like to the data they are supposed to transfer.
| 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.
RFC2821 4.1.1.4
...
The custom of accepting lines ending only in <LF>, as a concession to
non-conforming behavior on the part of some UNIX systems, has proven
to cause more interoperability problems than it solves, and SMTP
server systems MUST NOT do this, even in the name of improved
robustness. In particular, the sequence "<LF>.<LF>" (bare line
feeds, without carriage returns) MUST NOT be treated as equivalent to
<CRLF>.<CRLF> as the end of mail data indication.
...
| But there is a general agreement that no changes to the body
| of an email should be done unless they are required or requested.
| As long as this is a user selectable option, I don't see any
| problem with it, though some might claim the default should be "off".
No *mangling* should be done, but any necessary encapuslation must be
done and must be reversible (see above). Note the semantic
differences between "mangling" and "quoting" and "encoding". Mangling
is an unreversible changing of the data. For example the common
"From " -> ">From " transformation done with mbox folders is mangling.
-D
--
Microsoft DNS service terminates abnormally when it receives a response
to a dns query that was never made.
Fix information: run your DNS service on a different platform.
-- bugtraq
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
msg05444/pgp00000.pgp
Description: PGP signature
