RFC 7103: Advice for Safe Handling of Malformed Messages
In plain English — editorial summary, not part of the RFC
Although Internet message formats have been precisely defined since the 1970s, authoring and handling software often shows only mild conformance to the specifications. The malformed messages that result are non-standard. Nonetheless, decades of experience have shown that using some tolerance in the handling of the malformations that result is often an acceptable approach and is better than rejecting the messages outright as nonconformant. This document includes a collection of the best advice available regarding a variety of common malformed mail situations; it is to be used as implementation guidance.
Document record
- Document ID
- RFC7103
- Published
- January 2014
- Authors
- M. Kucherawy; G. Shapiro; N. Freed
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- art
- Pages
- 24
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 5617DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)Updated
August 2009
- RFC 7960Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email FlowsCurrent
September 2016
- RFC 6710Simple Mail Transfer Protocol Extension for Message Transfer PrioritiesCurrent
August 2012
- RFC 7672SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)Current
October 2015
- RFC 6531SMTP Extension for Internationalized EmailCurrent
February 2012
- RFC 6530Overview and Framework for Internationalized EmailCurrent
February 2012
- RFC 7817Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related ProtocolsCurrent
March 2016
- RFC 6186Use of SRV Records for Locating Email Submission/Access ServicesUpdated
March 2011
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?