>So... do I conform to standards or make my my recipients unhappy? In passing >I note that almost all the Email I get, not from [email protected], has >very long lines.
Let's look at the standard. Specifically, the latest update to RFC 822, RFC 5322. It says: 2.1.1. Line Length Limits There are two limits that this specification places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. So as long as you're keeping it under 998, you're keeping it within the hard limits of RFC 5322 (that limit really applies to SMTP). Note that nmh will happily send a message with >998 characters per line; whatever is in the draft file just gets blasted to the SMTP server. That's a violation of the next paragraph of RFC 5322: The 998 character limit is due to limitations in many implementations that send, receive, or store IMF messages which simply cannot handle more than 998 characters on a line. Receiving implementations would do well to handle an arbitrarily large number of characters in a line for robustness sake. However, there are so many implementations that (in compliance with the transport requirements of [RFC5321]) do not accept messages containing more than 1000 characters including the CR and LF per line, it is important for implementations not to create such messages. But I was (rather cheekily, I admit) talking about the next paragraph in particular: The more conservative 78 character recommendation is to accommodate the many implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line, in spite of the fact that such implementations are non-conformant to the intent of this specification (and that of [RFC5321] if they actually cause information to be lost). Again, even though this limitation is put on messages, it is incumbent upon implementations that display messages to handle an arbitrarily large number of characters in a line (certainly at least up to the 998 character limit) for the sake of robustness. We can display stuff with lines >78; they just line wrap poorly. Fixing this is ... well, hard. Take a look at mhl and you'll see what I mean. I generally restrict my email to 78 columns or less, and I've never heard from anyone that my emails look "jagged". Maybe it looks jagged to everyone and they're not saying anything; hard to tell. But I have a question for you; does the emal you get that has really long lines come in as text/plain with a 7bit encoding? Or does it come in as quoted-printable? In my limited experience the former is rare; the latter is common. The reason I noticed is that replyfilter assumes that text/plain with a 7bit (or 8bit) encoding is exactly how the sender wanted it to be displayed and thus it will not run the message through "par" for formatting. I did this because I was replying to a lot of messages with code in them and par really chewed that text up. In my experience people with long lines generally used q-p or base64 or some other encoding. So, what to do? We'll, I'm not sure; with the current tools you're going to make someone unhappy. We don't right now have a good way to compose things like format=flowed, and it's not clear to me how that would work without some editor smarts. I'm open to suggestions (code would be better). --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
