I'm trying to make sense of rfc5322 Line Length Limits
. Is the line limit 78 chars or 998 chars? Is one for the body and the other for the headers? I can't find anything to specify that.
Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.
It's saying that preferably, lines should ideally be no longer than 78 characters but lines must never be longer than 998 characters.
In other words, 998 is a hard limit while 78 is a soft limit.
I'm using Mailgun for sending emails. The mail has a short subject (11 characters), a text body which its maximum line length 115 characters and a PDF attached.
I'm getting some errors from Mailgun (on very few emails) with message: "550 Maximum line length exceeded (see RFC 5322 2.1.1)."
RFC 5322, 2.1.1 says that the maximum line length is 998 characters excluding the CRLF.
As my email's longest line is way shorter than that, is it possible that this issue is being caused by a header, CSS rule or the attachment?
The attachment should not be a problem. If you have css, then I suspect you have html body as well. I would check out the line lengths there and in the text body. Maybe a line break is missing somewhere.
I ran into the same error and I wanted to make a more definite answer: CSS is counted in the line length limit, so if you have a lot of CSS with no line breaks, it will cause this error.
The server will only allow so many (550 or 980) characters per line. When there are no line breaks, all the HTML is counted as a single line.
So the simple solution is to add a few line breaks in the email body.
That is put a few \r\n in the body of the message.
I ran into this problem when an attachment I had included in my raw email (encoded in base64) was longer than 998 characters. As the error suggests, this is due to RFC5322 section 2.1.1.
I resolved it by chunking the base64 up into lines of 1000 characters each (which is 998 + \r\n). PHP has a function for this called chunk_split, and a similar thing can be done in JavaScript with a regex implementation of chunk_split
My website sends out an email with a link in it. Lately we've been getting a lot of errors that indicate that the URL in the email that we send out is being somehow garbled. Unfortunately we dont' have any logs that indicate what the url they tried to access was exactly. I've ruled out a number of possibilities (bad data, bad url encoding, etc) The only thing I haven't ruled out is that perhaps the url is being truncated by our users email clients. The URL is slightly different for each user, but generally the url will be 210 - 220 characters in length.
My question: As a rule of thumb, what is the maximum url length that can be be safely sent in an email client, to ensure consistent behavior?
UPDATE
I know that there are a number of questions on SO related to the maximum URL length, but my question is specific to a hyperlink in an email client, and I can't seem to find that.
Good style recommendation [URL length <= recommended line length]
URL should fit into a single line, single email line should be 78 chars (minus at least two chars for quoting in reply).
https://www.rfc-editor.org/rfc/rfc5322.txt
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
RFC Standard says the max email size is 320 (actually 256 according to http://www.dominicsayers.com/isemail/). Is there any conceivable scenario where email addresses could end up being bigger than this?
Read this: http://www.eph.co.uk/resources/email-address-length-faq/
The upshot of it is that you should use 254 characters to store email addresses, because that is the maximum allowed in an SMTP transaction. This is specified in RFC5321 (your article says so, and is actually quoted in mine), which is authoritative.
To be honest, even if someone had a valid email address beyond 256/320 chars it would be a major pain to use.
Anyone using an email address that is even half as big as that (128 chars) needs to trim back!
although on the plus side, they likely get no spam!
For example both of these would be unusable:
//long domain
joe.shmoe#someveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylogdomain.com
//long username
someveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylonguser#aregularlengthdomain.com
This guy managed to have a 345 character-long email address and make it work:
The World’s Longest Active Email Address
Admittedly, such a long email address is completely pointless.
How many characters are allowed to be in the subject line of Internet email?
I had a scan of The RFC for email but could not see specifically how long it was allowed to be.
I have a colleague that wants to programmatically validate for it.
If there is no formal limit, what is a good length in practice to suggest?
See RFC 2822, section 2.1.1 to start.
There are two limits that this
standard 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.
As the RFC states later, you can work around this limit (not that you should) by folding the subject over multiple lines.
Each header field is logically a
single line of characters comprising
the field name, the colon, and the
field body. For convenience however,
and to deal with the 998/78 character
limitations per line, the field body
portion of a header field can be split
into a multiple line representation;
this is called "folding". The general
rule is that wherever this standard
allows for folding white space (not
simply WSP characters), a CRLF may be
inserted before any WSP. For
example, the header field:
Subject: This is a test
can be represented as:
Subject: This
is a test
The recommendation for no more than 78 characters in the subject header sounds reasonable. No one wants to scroll to see the entire subject line, and something important might get cut off on the right.
RFC2322 states that the subject header "has no length restriction"
but to produce long headers but you need to split it across multiple lines, a process called "folding".
subject is defined as "unstructured" in RFC 5322
here's some quotes ([...] indicate stuff i omitted)
3.6.5. Informational Fields
The informational fields are all optional. The "Subject:" and
"Comments:" fields are unstructured fields as defined in section
2.2.1, [...]
2.2.1. Unstructured Header Field Bodies
Some field bodies in this specification are defined simply as
"unstructured" (which is specified in section 3.2.5 as any printable
US-ASCII characters plus white space characters) with no further
restrictions. These are referred to as unstructured field bodies.
Semantically, unstructured field bodies are simply to be treated as a
single line of characters with no further processing (except for
"folding" and "unfolding" as described in section 2.2.3).
2.2.3 [...] An unfolded header field has no length restriction and
therefore may be indeterminately long.
after some test: If you send an email to an outlook client, and the subject is >77 chars, and it needs to use "=?ISO" inside the subject (in my case because of accents) then OutLook will "cut" the subject in the middle of it and mesh it all that comes after, including body text, attaches, etc... all a mesh!
I have several examples like this one:
Subject: =?ISO-8859-1?Q?Actas de la obra N=BA.20100154 (Expediente N=BA.20100182) "NUEVA RED FERROVIARIA.=
TRAMO=20BEASAIN=20OESTE(Pedido=20PC10/00123-125),=20BEASAIN".?=
To:
As you see, in the subject line it cutted on char 78 with a "=" followed by 2 or 3 line feeds, then continued with the rest of the subject baddly.
It was reported to me from several customers who all where using OutLook, other email clients deal with those subjects ok.
If you have no ISO on it, it doesn't hurt, but if you add it to your subject to be nice to RFC, then you get this surprise from OutLook. Bit if you don't add the ISOs, then iPhone email will not understand it(and attach files with names using such characters will not work on iPhones).
Limits in the context of Unicode multi-byte character capabilities
While RFC5322 defines a limit of 1000 (998 + CRLF) characters, it does so in the context of headers limited to ASCII characters only.
RFC 6532 explains how to handle multi-byte Unicode characters.
Section 3.4 ( Effects on Line Length Limits ) states:
Section 2.1.1 of [RFC5322] limits lines to 998 characters and
recommends that the lines be restricted to only 78 characters. This
specification changes the former limit to 998 octets. (Note that, in
ASCII, octets and characters are effectively the same, but this is
not true in UTF-8.) The 78-character limit remains defined in terms
of characters, not octets, since it is intended to address display
width issues, not line-length issues.
So for example, because you are limited to 998 octets, you can't have 998 smiley faces in your subject line as each emoji of this type is 4 octets.
Using PHP to demonstrate:
Run php -a for an interactive terminal.
// Multi-byte string length:
var_export(mb_strlen("\u{0001F602}",'UTF-8'));
// 1
// ASCII string length:
var_export(strlen("\u{0001F602}"));
// 4
// ASCII substring of four octet character:
var_export(substr("\u{0001F602}",0,4));
// '😂'
// ASCI substring of four octet character truncated to 3 octets, mutating character:
var_export(substr("\u{0001F602}",0,3));
// '▒'
I don't believe that there is a formal limit here, and I'm pretty sure there isn't any hard limit specified in the RFC either, as you found.
I think that some pretty common limitations for subject lines in general (not just e-mail) are:
80 Characters
128 Characters
256 Characters
Obviously, you want to come up with something that is reasonable. If you're writing an e-mail client, you may want to go with something like 256 characters, and obviously test thoroughly against big commercial servers out there to make sure they serve your mail correctly.
Hope this helps!
What's important is which mechanism you are using the send the email. Most modern libraries (i.e. System.Net.Mail) will hide the folding from you. You just put a very long email subject line in without (CR,LF,HTAB). If you start trying to do your own folding all bets are off. It will start reporting errors. So if you are having this issue just filter out the CR,LF,HTAB and let the library do the work for you. You can usually also set the encoding text type as a separate field. No need for iso encoding in the subject line.