"After we've composed our email and hit send it has to be packaged up and sent over the wires to the recipient. That low level protocol to actually transmit the mail from A to B is specified in RFC 5321, but at a high level we can mostly ignore the requirements in that RFC. Mostly. One thing we can't ignore is that RFC 5321 has a limit on the length of each line in the payload of a message."
"The mention of "SMTP Service Extensions" might make you think that this is just a historical limitation and of course we have service extensions to remove the limitation on the modern Internet. Sadly, no. Service extensions that allow more flexibility in payload structure either have to be supported by every single mailserver involved in delivering a message, or intermediate mailservers need to rewrite a message they're relaying to support the requirements of the server they're sending the message on to."
DKIM signatures can fail when email payloads are badly structured, particularly when individual lines exceed protocol length limits. RFC 5321 sets a maximum total length of a text line including <CRLF> at 1000 octets, effectively requiring each payload line to be no longer than 998 bytes. SMTP service extensions can relax limits but must be supported by every mailserver in the delivery path or require intermediaries to rewrite messages. Message rewriting often breaks DKIM signatures, causing DMARC to mark mail as spam or reject it. MIME encoding and packaging provide methods to meet line-length requirements for bodies and attachments.
Read at Wordtothewise
Unable to calculate read time
Collection
[
|
...
]