HTTP/2 302 date: Mon, 14 Jul 2025 09:11:54 GMT content-type: text/html content-length: 143 location: https://get.ietf.org/implementation-report/report-rfc2822.txt cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0 expires: Thu, 01 Jan 1970 00:00:01 GMT vary: Accept-Encoding server: cloudflare cf-ray: 95efe537aac2cb77-BLR alt-svc: h3=":443"; ma=86400 HTTP/2 200 date: Mon, 14 Jul 2025 09:11:55 GMT content-type: text/plain etag: W/"ef510b50ee9a04cb82df96cd25296803" vary: Accept-Encoding server: cloudflare cf-ray: 95efe537df96c467-BLR content-encoding: gzip alt-svc: h3=":443"; ma=86400 Summary This implementation report is in support of moving RFC2822 to Draft Standard. RFC2822 -- the Internet Message Format used in email -- is very, very widely deployed and very, very widely interoperable. This report focuses on identifying possible problems or exceptions to what is otherwise interoperably implemented. Methodology A questionnaire was distributed to implementors. Four implementors (with independent implementations) responded, and their full responses are in the Appendix. There were no common interoperability problems not addressed in the update of RFC2822 that is proposed for Draft Standard. Exceptions to general interoperability Note that 2822 includes "obsolete syntax" described in ABNF -- syntax that implementations must not generate, but may parse. It seems that parsing obsolete syntax is not always fully implemented but if that works in practice then this is not a threat to interoperability. Appendix ================ 01 ================ 0. Contact and Description Organization Name: Implementation (Software or Service) Name: Oryx Mail Systems GmbH. Archiveopteryx. 1. Have you implemented RFC2822? Yes, and we wrote units tests and blah, too. 2. For how long it has been deployed? Three or four years, I'd have to look it up. 3. What features have NOT been implemented from RFC2822? There are some things for which our implementation must be considered, ah, partial. The only ones which are in 2822 itself are nonempty address groups, some obs-* syntax and something John told me was a bug in the 2822 grammar so I shouldn't care. 4. What features of RFC2822 are problematic for your implementation? Resent-*. From fields containing more than one address. The (lack of) case sensitivity rules for localparts. The threading rules for in-reply-to, which describe threads as DAGs rather than trees. Some little-used syntax bits where I'm not sure our handling conforms to user expectations. Most are odd and little-used parts of the document, which is partly why they're problematic for us. 5. Please add any other comments you wish to share: 2822 is where we have the least problems. For example, while 2822 allows some characters in some header fields that I don't think are advisable, that's not a problems compared with all the deployed code that chokes on "+" in addresses. I'm happy with 2822. ================ 02 ================ 0. Contact and Description Organization Name: Implementation (Software or Service) Name: As before, I'm a private individual who built my own SMTP server. I haven't given it a name; I call it smtpd, which is sufficiently generic that I have trouble really considering it an implementation name. 1. Have you implemented RFC2822? Only sort of. My SMTP server is mostly blind to the (SMTP) body of the message, which is 2822's bailiwick. I do inspect message bodies for blocking reasons, and have implemented pieces of 2822 as necessary for that. My SMTP server needs to be backeded by something else for deliver, aliasing, outgoing queueing, etc; in my case, that is done by fairly stock sendmail. (Fairly old stock sendmail, but still.) 2. For how long it has been deployed? Some years now? The current paradigm was in place sometime in 2001, and, while I've been evolving the tests, the changes have been evolutionary rather than revolutionary. 3. What features have NOT been implemented from RFC2822? Speaking strictly about the stuff done by my own code (which is pretty much entirely about "bad mail" defenses): Any obs- syntax that looked inconvenient to implement. For example, obs-char includes NULs (and backslashes quote NULs); I decided that supporting NULs was more trouble than it was worth and used stock C calls for my string manipulation. Anything I haven't felt any need to implement (for example, I've seen no need to look at Cc: headers, so I haven't implemented even recognizing them, much less handling them). 4. What features of RFC2822 are problematic for your implementation? Except for NUL issues such as those mentioned above, nothing comes immediately to mind. 5. Please add any other comments you wish to share: Most of the 2822-related problems I have are not really problems with 2822 but problems with others' implementations of not-quite-2822. My Date: syntax checks, for example, stop a depressing amount of ham; apparently some implementors can't be bothered to read the spec and instead just guess based on looking at examples or some such. ================ 03 ================ 0. Contact and Description Organization Name: Isode Limited Implementation (Software or Service) Name: M-Switch (MTA [RFC2822 parser + reformatter + generator]) and M-Box (IMAP server [RFC2822 parser] and LMTP server [RFC 2822 generator (in Sieve)]) - parsers/generators written using two different codebases. 1. Have you implemented RFC2822? Yes. 2. For how long it has been deployed? M-Switch - since at least 1997, M-Box was implemented in 2004, but its parsing code is from Cyrus Imapd, so it dates in mid 90s. 3. What features have NOT been implemented from RFC2822? Multiple "for" clauses were not implemented in Received header field (never generated). Obsolete syntax (as defined in section 4) is probably not parsed correctly or not accepted in some cases (I haven't tested that). In particular bare LFs or CRs in message headers are likely to be discarded/rejected. But note that obsolete (non numeric) timezones and obsolete addressing (with route) are supported. 4. What features of RFC2822 are problematic for your implementation? See above. 5. Please add any other comments you wish to share: ================ 04 ================ 0. Contact and Description Organization Name: Implementation (Software or Service) Name: AT&T Labs Maillennium MTA and webmail 1. Have you implemented RFC2822? Yes, along with unit tests, etc. 2. For how long it has been deployed? well over a decade 3. What features have NOT been implemented from RFC2822? We parse, but do not generate . We parse, but do not generate addr-spec without the "<>". We parse, but do not generate the obs-*. We allow other header fields to be trace header fields. We do not generate the optional resent-* header fields. 4. What features of RFC2822 are problematic for your implementation? none 5. Please add any other comments you wish to share: 2822 and 2822upd are very solid