Visual RFC.
ALL RFCs / RFC 3848
Read the RFC ↗
RFC 3848 / MAIL TRANSMISSION TRACE

Use traces for diagnosis, not automatic trust

05

Mail can carry several Received fields written by different systems. A readable ESMTPSA token is only a claim about a hop; the header itself does not authenticate the claim.

DIAGRAMRead RFC section 3 ↗
RFC 3848 · § 3EXAMPLE
3 / 3
Use traces for diagnosis, not automatic trustThree trust-boundary states. Earlier sender-to-relay ESMTPSA claim and later relay-to-next ESMTP claim are independent. A malicious supplied or modified older trace claimsESMTPSA and a decision based only on text stops at trust gate. Finally operator correlates a claimed handling event with corresponding MTA logs as more reliable diagnostic evidence, without declaring a verified author or safe message. Keywords can be modified, omit mechanism specifics, and should not determine filtering or relaying except in very controlled environments.A trace claim is not a security decisioncompare claimed event with relay logsTrace claim + corresponding MTA logs→ more reliable diagnostic evidenceStill not proof of the message authorNo TLS mechanism details in the suffix
03
Correlate with operational evidence.

An operator compares the claimed relay and event with that relay’s logs. This can improve diagnosis; the keyword alone still reveals neither TLS specifics nor a verified message author.

Source for this drawing: RFC 3848 · Read RFC section 3 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 5321 SMTP RFC 5322 Email message format RFC 3207 SMTP STARTTLS

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Correlate trace claims with the relevant mail-server logs.

  • RFC 3848 §3 says these keywords are not normally protected in transport and can be modified by an active attacker. They reveal no security-mechanism specifics and provide no real-world security assurance.
  • The text advises against using the keywords for filtering or relaying decisions except in very controlled environments. This is source guidance, not an invented uppercase MUST/SHOULD requirement.
  • Higher reliability comes from correlating Received headers with the logs of the mail transfer agents that handled the message. A diagrammed correlation is supporting evidence, not a cryptographic proof.
  • Preserve useful traces for later diagnosis. RFC 5321 §7.6 also cautions that trace names and optional FOR information can disclose details; this guide does not change logging, retention or privacy policy.
DETAILS

A suffix does not verify the message author, certify every relay, or make a message safe.

Read the RFC section ↗

All chapters in RFC 3848

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗