> 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.
Are there many user interfaces that can't handle more than 78 characters anymore? Even terminal windows wrap now. I'm inclined to believe that the 78 character recommendation really isn't that important anymore.
That said, I'm curious if the 998 restriction really is important too. That comes from here:
> 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.
Are there many such implementations hanging around that can't handle more than 998 characters?
I don’t have hard information but I believe so. If you have a line with more than 998 characters you’re taking a risk that your email will be rejected. But I’m pretty sure there is never any problem with lines <= 998 characters, and it works far better on more devices than trying to break lines to fit some imaginary screen, which always ends up in a mess.
