Re: 451 See http://pobox.com/~djb/docs/smtplf.html.
Following up on my own message... Aaron Nabil writes... >D. J. Bernstein writes... >>Aaron Nabil writes: >>> The message in question had a "bare LF" in it, perfectly legal, >> >>Bare LFs are now categorically prohibited by 822bis. They were never >>handled correctly by sendmail. The client's behavior is inexcusable. > >I guess not having access to 822bis, I'll have to ask for clarification. > >Are bare LF's themselves prohibited? Or is it the treating of bare >LF's as line terminators that is prohibited? I found draft-ietf-drums-msg-fmt, which seems to be the 822bis-in-progress. 2.3. Body The body of a message is simply lines of US-ASCII characters. The only two limitations on the body are as follows: - CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body. which would seem to address the question of 822bis messages. But my question about MIME messages still remains, the draft goes on to read... - Lines of characters in the body MUST be limited to 998 characters, and SHOULD be limited to 78 characters, excluding the CRLF. Note: As was stated earlier, there are other standards documents, specifically the MIME documents [RFC-2045, RFC-2046, RFC-2048, RFC-2049] that extend this standard to allow for different sorts of message bodies. Again, these mechanisms are beyond the scope of this document. My question about 8BITMIME messages remains. Would a bare LF be legal? I'm not suggesting that a bare LF be treated a line terminator. In any case, I'm not sure where 822bis sits on the standards track, but wouldn't it be reasonable to require an MTA to interopertate with MTAs that are following real, published, approved RFCs like RFC-822 and RFC-1652? Thanks, -- Aaron Nabil
Re: 451 See http://pobox.com/~djb/docs/smtplf.html.
D. J. Bernstein writes... >Aaron Nabil writes: >> The message in question had a "bare LF" in it, perfectly legal, > >Bare LFs are now categorically prohibited by 822bis. They were never >handled correctly by sendmail. The client's behavior is inexcusable. I guess not having access to 822bis, I'll have to ask for clarification. Are bare LF's themselves prohibited? Or is it the treating of bare LF's as line terminators that is prohibited? What about in 8BITMIME messages? No bare LF's allowed at all? -- Aaron Nabil
Re: 451 See http://pobox.com/~djb/docs/smtplf.html.
Aaron Nabil writes: > The message in question had a "bare LF" in it, perfectly legal, Bare LFs are now categorically prohibited by 822bis. They were never handled correctly by sendmail. The client's behavior is inexcusable. ---Dan
Re: 451 See http://pobox.com/~djb/docs/smtplf.html.
Russell Nelson writes... > > But I'm not sure I see where this is going. Qmail would never deliver > > such a message, it would barf. The case you are also stating in specifically > > one of delivery, where local newline standards come into play. What about > > the case of transport? > >Qmail does not distinguish between delivery and transport, therefore >it can store the messages in a file which use newlines for a line >terminator. Well, sort of. It doesn't distinguish between delivery and transport in the sense that it coerces all tranported message into a local delivery format. Is this supposed to be a qmail feature? >Thus, qmail cannot accept bare newlines, since such a >message cannot be reconstructed once it's been in a queue or mailbox >file. Cannot be reconstructed? You have entirely lost me. Is that exactly the question you posed me, reconstructing a message with embedded bare LF's? Was something wrong with my answer? It also sounds like you are saying that qmail must refuse to transport messages that it doesn't have the local ability to reconstruct. That seems awfully presumptuous of qmail, denying transport say, to sendmail, simply on the basis of some potential ambiguity in qmail's local delivery environment and projecting that ambiguity onto the target delivery enviroment. It's entirely possible the the recipient MTA at the end of the transport has no such ambiguity, why in the world would qmail try to enforce such a silly restriction? Qmail is saying, "I AM QMAIL, IF THIS MAIL WAS DESTINED FOR LOCAL DELIVERY I WOULDN'T KNOW WHAT TO DO WITH IT, THEREFORE I WILL REFUSE TO TRANSPORT IT TO ANOTHER MTA THAT MIGHT POSSIBLY BE ABLE TO DELIVER IT WITH NO AMBIGUITY." Pretty damn cheeky. -- Aaron Nabil
Re: 451 See http://pobox.com/~djb/docs/smtplf.html.
Aaron Nabil writes: > I guess if this is really important, we could try feeding such a message > to sendmail with 8BITMIME and see what it does. sendmail is not an example implementation. > But I'm not sure I see where this is going. Qmail would never deliver > such a message, it would barf. The case you are also stating in specifically > one of delivery, where local newline standards come into play. What about > the case of transport? Qmail does not distinguish between delivery and transport, therefore it can store the messages in a file which use newlines for a line terminator. Thus, qmail cannot accept bare newlines, since such a message cannot be reconstructed once it's been in a queue or mailbox file. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: 451 See http://pobox.com/~djb/docs/smtplf.html.
Russell Nelson writes... >Aaron Nabil writes: > > Robin Bowes writes... > > >I'm seeing the above error message in the log for my MS Mail gateway > > >(MailBeamer), but only for 1 particular message. > > > > > > . . . > > >I've looked at Dan's explanation of the problem and I am aware of the > > >SMTP LF issue. My problem is why should this error occur just for 1 > > >message? I mean, if *every* message had the same problem, I could > > >understand it and would put it down to a broken program, but for just 1 > > >message to cause the error? Seems strange to me... > > > > The problem is Qmail. > > > > The message in question had a "bare LF" in it, perfectly legal, but > > qmail barfs on them. I just posted a message describing the > > phenomena in more detail. > >Aaron, how would you store the following one-line message sequence of >characters received by a DATA command into a Unix mailbox without >losing information? Nevermind which MTA is doing it -- just tell me >what you think the Unix mailbox would look like at the end of the process. > >"beginning of line 1more of line 1". I love puzzles! But I'm not sure what you mean by "one line", other than you typed it on one line. So just to make sure we are talking about the same thing... DATA beginning of line 1more of line 1 . right? Well, the easy one first. If the message was sent as a normal RFC-822 only message, I'd expect the unix mailbox to contain... \n beginning of line 1\n more of line 1\n since RFC-822 anticipates local newline conversions. whereas if it were a MIME message sent with 8BITMIME, I'd expect something like... \r\n beginning of line 1\n more of line 1\r\n I guess if this is really important, we could try feeding such a message to sendmail with 8BITMIME and see what it does. But I'm not sure I see where this is going. Qmail would never deliver such a message, it would barf. The case you are also stating in specifically one of delivery, where local newline standards come into play. What about the case of transport? -- Aaron Nabil
Re: 451 See http://pobox.com/~djb/docs/smtplf.html.
Aaron Nabil writes: > Robin Bowes writes... > >I'm seeing the above error message in the log for my MS Mail gateway > >(MailBeamer), but only for 1 particular message. > > > > . . . > >I've looked at Dan's explanation of the problem and I am aware of the > >SMTP LF issue. My problem is why should this error occur just for 1 > >message? I mean, if *every* message had the same problem, I could > >understand it and would put it down to a broken program, but for just 1 > >message to cause the error? Seems strange to me... > > The problem is Qmail. > > The message in question had a "bare LF" in it, perfectly legal, but > qmail barfs on them. I just posted a message describing the > phenomena in more detail. Aaron, how would you store the following one-line message sequence of characters received by a DATA command into a Unix mailbox without losing information? Nevermind which MTA is doing it -- just tell me what you think the Unix mailbox would look like at the end of the process. "beginning of line 1more of line 1". -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr sells support for free software | PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
Re: 451 See http://pobox.com/~djb/docs/smtplf.html.
Robin Bowes writes... >I'm seeing the above error message in the log for my MS Mail gateway >(MailBeamer), but only for 1 particular message. > > . . . >I've looked at Dan's explanation of the problem and I am aware of the >SMTP LF issue. My problem is why should this error occur just for 1 >message? I mean, if *every* message had the same problem, I could >understand it and would put it down to a broken program, but for just 1 >message to cause the error? Seems strange to me... The problem is Qmail. The message in question had a "bare LF" in it, perfectly legal, but qmail barfs on them. I just posted a message describing the phenomena in more detail. -- Aaron Nabil
