Choose the return path, not reply-all
03For ordinary Personal and Group responses, the transport return address is the recommended destination, rather than the fields used for human conversation.
Before delivery, use the SMTP reverse-path as the recommended destination. The depicted valid non-null address is still not authentication.
Source for this drawing: RFC 3834 · Read RFC section 4 ↗
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
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
After delivery, automatic responses SHOULD use Return-Path. Before delivery, they SHOULD use the SMTP MAIL FROM reverse-path (the transport return address). Never generate a response to a null destination.
- After delivery, automatic responses SHOULD use Return-Path. Before delivery, they SHOULD use the SMTP MAIL FROM reverse-path (the transport return address). Never generate a response to a null destination.
- A Personal or Group Responder SHOULD NOT fall back to From, Reply-To or Sender, including when Return-Path is missing. Missing Return-Path after delivery indicates a delivery-system error; fix that error instead of guessing.
- Generally there SHOULD be one recipient per automatic response. A Service Responder MAY use From or an address in the request only when its service specification precisely defines that behavior; it SHOULD NOT use Reply-To. Return-Path is not proof of a trusted identity.
Fictional example.org addresses. Independent examples are labelled; this is guidance for responders, not a full mail parser or an authentication mechanism.
Read the RFC section ↗