Peter van Dijk <peterat_private> wrote: <<snip>> > > ... but is not the real problem here that > > SMTP servers accept non-compliant messages in the first place **and > > pass them on thus**? > > Not at all. SMTP servers are concerned with RFC821 (SMTP), not RFC822 > (message format). The only place where SMTP and RFC822 touch is in the > adding of Received headers. Everything else is purely between the > original sender and the final recipient. Well, that is a generous reading of RFC821 -- generous if you are an SMTP server author. RFC821 does not make much sense "on its own" -- what is the use of such a constrained file transfer protocol? Careful reading of RFC821 shows it was designed expressly (albeit poorly) for the transfer of RFC822 format messages in a relatively network independent way. For example, just one of many oddities is that it is the the *transport protocol* (RFC821) that defines the maximum line length a mail message can have, whereas RFC822 says lines can be of infinite length. How do we *know* RFC821 wwas written with RFC822 "expressly" in mind? Read RFC821. Note how many times when it talks about the "data transmission" part of the protocol it uses the term "mail data" to refer to what is being transferred. Now look up "mail data" entry in RFC821's Glossary section: mail data A sequence of ASCII characters of arbitrary length, which conforms to the standard set in the Standard for the Format of ARPA Internet Text Messages (RFC 822 [2]). > Lots of MTA's, however, try to enforce RFC821 compliance on > SMTP-received and -transferred messages. All of them fail miserably, > mutilating messages in the process and basically harming > interoperability and message integrity. Well, I guess the blame for that partly falls on the architects of these mutually conflicting, yet interwoven, RFCs. You see, despite your claim that such "mutilating" should not be done, RFC821 disagrees with you: 4.5.3. SIZES There are several objects that have required minimum maximum sizes. That is, every implementation must be able to receive objects of at least these sizes, but must not send objects larger than these sizes. **************************************************** * * * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * * OF THESE OBJECTS SHOULD BE USED. * * * **************************************************** Ignoring the not entirely mixed-messages just from that small section of RFC821 alone, recall that RFC822 says nothing about limits on line sizes (and, in fact, explicitly defines a line as of potentially infinite length), but a few lines below the preceding, after describing some of the minimum maxima for header lines and the like, we read in RFC821: text line The maximum total length of a text line including the <CRLF> is 1000 characters (but not counting the leading dot duplicated for transparency). This clearly imposes an upper limit on the allowable line length of the "mail data" part of an RFC821 (i.e. SMTP) message transmission, yet RFC822, in defining the format of the messages RFC821's protocol was expressly intended to transfer says nothing about line length maxima (in fact, it defines them as infinite). Now, what is an SMTP server following the absolute requirement of the RFC821 dictate "must not send object longer than these sizes" to do when the "mail data" (aka an RFC822 compliant text message) contains a line longer than 1000 characters? Hard to say. The RFC says the server *must not* send it but it provides **no** directions on what to do should the circumstance arise (not even weaker forms of guidance in the forms of "shoulds" or "mays"...). At least one popular SMTP server chops such lines at 1000 chars (or perhaps at the nearest whitespace preceding the 1000 char position?) and adds an "X-" header warning to the message that it contained overlong lines that were truncated. As far as I'm conerned, that is perfectly valid according to RFC821, but tough luck to users of Email clients whose authors only ever read RFC822 and create "compatible" messages with a "line break" at the end of each paragraph only (or don't apply quoted-printable encoding to their abominable HTML Email) if their messages have to traverse a relay running such *standards compliant* SMTP server software... > Programs should not crash or allow security violations when > presented with unexpected input. So while the SMTP servers probably > shouldn't be passing along these messages, nor should the email > clients be crashing. I agree the clients shouldn't crash when processing "out of bounds" input, but the point would be all but moot if the servers were doing what they should. Regards, Nick FitzGerald
This archive was generated by hypermail 2b30 : Wed Apr 25 2001 - 17:18:20 PDT