+91 9619904949

06-Email Email standards Base on RFC

by | Apr 7, 2021 | Linux | 0 comments

Email structure

These RFCs define the way emails themselves are structured.

  • RFC 5322 — Internet Message Format (basic format of an email message), previously RFC 822 and RFC 2822.
  • RFC 2045 — Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. This is an extension to the email message format to support attachments and non-ASCII data in emails.
  • RFC 2046 — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types.
  • RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text.
  • RFC 2231 — MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations.

Email protocols

These RFCs define how emails are transported between computers, both for sending (SMTP) and receiving (IMAP/POP).

  • RFC 5321 — Simple Mail Transfer Protocol. This is a protocol used to send emails between computers. This was previously RFC 821 and RFC 2821.
  • RFC 3501 — INTERNET MESSAGE ACCESS PROTOCOL — VERSION 4rev1. This is the IMAP protocol, used to read emails.
  • RFC 4551 — IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization. This is an IMAP extension that adds MODSEQ as a way to quickly find changes to a mailbox.
  • RFC 1939 — Post Office Protocol, Version 3. This is the older POP protocol, used to read emails.
  • RFC 8620 — The JSON Meta Application Protocol (JMAP). This is a new protocol for fetching, organizing, and sending messages, to replace older IMAP and SMTP protocols.

Email security

These RFCs define some security standards for email protocols and formats.

  • RFC 2595 — Using TLS with IMAP, POP3 and ACAP. This is a protocol used to upgrade a plaintext IMAP/POP connection to an SSL/TLS encrypted one.
  • RFC 3207 — SMTP Service Extension for Secure SMTP over Transport Layer Security. This is a protocol used to upgrade a plaintext SMTP connection to an SSL/TLS encrypted one.
  • RFC 5246 — The Transport Layer Security (TLS) Protocol Version 1.2. This is a protocol used to encrypt a connection.
  • RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures. This allows emails to be signed by a particular domain to ensure they haven’t been tampered with and to say that that domain claims responsibility for the message.
  • RFC 8617 — Authenticated Received Chain (ARC). This is a protocol to provide an authenticated chain of custody for messages that have passed through intermediate mail servers, such as through forwarding.

Service discovery

Email software, including clients like Outlook and Mac Mail, need to know which mail server to contact in order to download the user’s messages. This used to be manually configured by the user but nowadays is often done by putting the user’s email address through a service discovery process.

  • Thunderbird/Autoconfiguration — This is Mozilla’s custom approach that Thunderbird uses to auto-discover servers.
  • RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services.

Some software vendors maintain their own database of links between email domains and server name definitions to support automatic configuration in their email clients. These seem to be custom databases maintained by each software vendor separately.

Filtering

  • RFC 5228 — Sieve: An Email Filtering Language. Sieve is a language used to file, filter, and forward emails, and is what our Rules system generates on the server. For more information, please see the documentation of Sieve and Sieve extensions. Our server doesn’t support all the extensions for Sieve.
    RFC Title / Topic Purpose Key Technical Concepts Relevance to Email Deliverability
    RFC 5321 SMTP (Simple Mail Transfer Protocol) Governs how email is transmitted between Mail Transfer Agents (MTAs). – Core commands: HELO, EHLO, MAIL FROM, RCPT TO, DATA – Specifies retry logic and transient vs permanent failure codes – Connection sequencing and session management Fundamental for compliant message relay, bounce handling, and delivery retry mechanisms. Misconfigured MTAs can lead to failed delivery or rate limiting by recipient servers.
    RFC 5322 Internet Message Format Defines the syntax for email message headers and body content. – Required headers: From, To, Date, Subject, Message-ID – Format for plain text and multipart messages – Proper encoding standards (e.g., Base64, quoted-printable) Proper formatting ensures messages are parsed correctly by receiving MTAs and user agents. Malformed headers are a common reason for rejections or spam filtering.
    RFC 6376 DKIM (DomainKeys Identified Mail) Enables email authentication via digital signatures linked to domain identity. – Uses public/private key encryption – Signatures added in the DKIM-Signature header – Domain alignment validated using the d= tag Core to sender reputation and trust. A valid DKIM signature proves the email was not tampered with in transit, improving inbox placement and compliance with DMARC.
    RFC 7208 SPF (Sender Policy Framework) Allows domain owners to specify authorized sending IPs via DNS. – DNS TXT record with mechanisms (a, mx, ip4, include) – Policy qualifiers: +, -, ~, ? – Lookup limits and processing rules Helps prevent spoofing and phishing. An enforced SPF record enhances sender credibility. Misconfigured or overly permissive records reduce deliverability and expose to abuse.
    RFC 7489 DMARC (Domain-based Message Authentication, Reporting, and Conformance) Aligns SPF and DKIM with the “From” domain; enables policy enforcement and reporting. – DMARC policy tags: p=, adkim=, aspf=, rua=, ruf= – Aggregate and forensic reporting – Enforces alignment of DKIM/SPF with the visible “From” domain Vital for protection against domain spoofing. Provides visibility into authentication performance. DMARC policies are often required by major mailbox providers to ensure trust.
    RFC 6531 SMTPUTF8 Extends SMTP to support internationalized email addresses and non-ASCII content. – Enables UTF-8 in mailbox names and domain labels – Permits non-English characters in addresses and headers – Requires SMTPUTF8 keyword in server support Expands reach to global audiences, especially in markets using non-Latin scripts. Ensures accessibility and compliance with modern internationalization standards.
    RFC 3463 Enhanced Mail System Status Codes Introduces detailed, standardized SMTP response codes for delivery diagnostics. – Code format: X.Y.Z (e.g., 5.1.1 = invalid recipient) – Categorization by subject and severity – Distinguishes between soft and hard bounces Improves bounce classification and resolution. Helps ESPs and postmasters understand failure causes accurately, which enhances feedback loops and deliverability analysis.
    RFC 8617 ARC (Authenticated Received Chain) Preserves authentication results across multiple hops, especially forwarding scenarios. – Adds ARC-Authentication-Results, ARC-Seal, and ARC-Message-Signature headers – Ensures DKIM/SPF results are not lost in transit – Chain validation mechanisms Critical when using mailing lists or forwarders. Maintains trust signals, ensuring downstream MTAs do not flag otherwise legitimate messages as unauthenticated.
    RFC 3834 Automatic Email Responses Provides standards for handling auto-responses like out-of-office replies. – Auto-Submitted: header controls loop prevention – Avoids unintended back-and-forth messaging – Differentiates manual from automated responses Helps prevent mail loops that can degrade sender reputation. Ensures automated responses do not impact metrics like open/click rates or get misclassified as spam.
    RFC 2045–2049 MIME (Multipurpose Internet Mail Extensions) Defines mechanisms to send multimedia and multipart content via email. – Headers like Content-Type, Content-Disposition, and Content-Transfer-Encoding – Enables attachments, HTML formatting, inline images, and alternate views Essential for modern email design and functionality. Incorrect MIME handling may cause rendering issues, poor user experience, or trigger spam detection heuristics.
    RFC 4409 Message Submission (via Port 587) Differentiates message submission from relay; defines how MUAs submit email to MTAs. – Emphasizes use of port 587 for submission, not port 25 – Requires client authentication – Enables better abuse detection and message origination control Promotes secure and authenticated email origination. Helps in separating legitimate user traffic from bulk or unauthenticated sources, enhancing trust and reducing blocklisting.
    RFC 8058 List-Unsubscribe Standardizes how mailing list subscribers can opt-out seamlessly. – Adds List-Unsubscribe: header with mailto: and HTTP URLs – Enables one-click unsubscribe mechanisms supported by clients like Gmail and Outlook Key to reducing spam complaints and promoting a user-centric experience. Non-compliance or poor UX during unsubscription can lead to domain blacklisting.
    RFC 8314 Email Submission Over TLS Recommends encryption for SMTP connections to protect user data. – Encourages STARTTLS usage – Moves away from plaintext email transmission – Enhances confidentiality and prevents tampering or eavesdropping Strong encryption practices are essential for privacy compliance (e.g., GDPR). Securing the message pipeline improves sender reputation and ISP trustworthiness.
anil jalela