[Top] [All Lists]

Re: [ietf-822] Question about line folding and maximum line length

2021-05-06 12:54:59
On 6 May 2021, at 9:33, Paul Smith wrote:

On 06/05/2021 14:52, Bryan Frimin wrote:
1. The maximum line length.
RFC 5322 section 2.1.1[2] describes two possible line length limits. The historical one, 78 characters, and the new one, 998 characters. Is the
historical limit still relevant for an email client in 2021, or can I
just use the new one?

998 is a MUST (to avoid possibly breaking something, although it's unlikely nowadays)

78 is a SHOULD (to make it easier for users to read).

The 78 character limit is not 'historical'; it's a recommendation, not a requirement.

Well, to be clear, a "SHOULD" according to RFC 2119 is basically "MUST unless you know what you're doing". But otherwise, Paul is exactly right. As 2.1.1 says:

   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.

So, you really ought to accommodate arbitrarily receiving long lines, but 998 at a minimum, and on sending limit yourself to 78 if you can, but 998 at maximum.

In fact in RFC 822, there are no line length limits defined at all, just a suggestion not to make them too long. The limits were first introduced in RFC 2822 as far as I can see, and that uses the same wording as RFC 5322

Yep. When 2822 was being written, there were implementations that downright blew up on anything over 998. I imagine there still are.

When reading RFCs it's very important to know the difference between MUST and SHOULD (in capitals) as they have a strict meaning.

So, you should try to make lines no longer than 78 characters, but if they're longer (but no longer than 998) it's not going to break anything.


2. The long line folding mechanism.
RFC 5322 section 2.2.3[3] defines a folding mechanism for long header
fields. But it does define whether it is possible to fold a header field
name longer than the limit (yes it is an edge case, but it could

Header field names definitely can't be folded. We probably should have put an explicit limit of 77 (to leave space for the colon), but we didn't. See In the cleanup we're currently working on, we added in a comment in the ABNF in section 3.6.8:

   field-name      =   1*ftext            ; Limit to 77 characters to
                                          ;  stay within 78 char-per-
                                          ;  line recommendation

We haven't seen any actual header field names in the wild that are greater than 77 in length, so decided that changing the ABNF to "1*77ftext" wasn't worth possibly screwing something else up, given that we're trying to advance this to full Standard, and that the comment in the ABNF would be sufficient.

(If you'd like to follow along with the current cleanup effort, please see

And folding can only be done if a lexical token or a space is
present. So what about values without any separator ?

Don't fold them if you can't. I don't think you'd fold a header field name (we don't) - as you say it's an edge-case, and I've never come across it.

It is very possible to have header lines where the data does not contain any spaces and is longer than 78 characters. That's exactly why the 78 character line-length limit is a SHOULD and not a MUST.

Obviously if you've got a header field name longer than 998 characters that you would HAVE to fold but you can't, then you've got a problem - in more ways than one.

Yeah, you also have a similar problem if you have a header field value (or a line in the body of a message for that matter) with an unbroken chain of greater than 998 characters. There are ways in MIME to solve that problem (RFC 2047 for header field values, RFC 2045 for bodies). If you can't use one of those, best answer is for your MUA or MSA to tell the user "Sorry, can't do that". (At the SMTP -- i.e., MTA -- level, you shouldn't be trying to check syntax and re-fold lines; if you can't handle the mess you were sent, bounce the message. If you send it to the next one down the line and it bounces, so be it.)


Pete Resnick
All connections to the world are tenuous at best
ietf-822 mailing list