Score:0

Are SMTP servers generally obliged to copy MAIL FROM from client-server session?

br flag

Are SMTP servers during (STMP) server-to-(SMTP) server communication generally obliged to copy MAIL FROM from client-server session? I've explicitly checked that servers of some mail providers actually exhibit this behaviour, but it doesn't seem to be a requirement enforced by https://datatracker.ietf.org/doc/html/rfc5321 . Also, I don't know how popular this practice is (if it is not a standard).

Update to be more specific: I'm primarily interested in case of a very usual e-mail message, person - to - person, domains on two different servers.

Rowan Hawkins avatar
us flag
It would be good, since at least on of the answers seem to answer your question, for you to mark that as an answer and it can become a reference for others.
Tom Johnson avatar
br flag
There are two answers that (almost) directly answer my question, both are equally good (IMO), is it OK to choose one of them randomly and mark it as accepted?
Score:1
jp flag

The RFC 5321, 3.3 tells what the MAIL FROM:<reverse-path> is for:

The <reverse-path> portion of the first or only argument contains the source mailbox (between "<" and ">" brackets), which can be used to report errors (see Section 4.2 for a discussion of error reporting).

The originator fields in the Internet Message Format headers (RFC 5322, 3.6.2) have more specific purposes to distinguish the author (From:) from the agent responsible for the actual transmission of the message (Sender):

For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field.

The RFC 5321 envelope sender has merely a technical purpose. It is typical in mail forwarding and mailing list scenarios to rewrite the MAIL FROM to match the forwarding domain/server or the mailing list operator. This has two benefits:

  • The error reports will get back to the mailing list operator who should take care of removing erroneous addresses from the list.
  • Rewriting the envelope sender does not break the SPF policy of the original domain (Shevek (2004): The Sender Rewriting Scheme).

On the other hand, such practices are slightly against RFC 5321, 3.7.5:

3.7.5. Envelopes in Gatewaying

Similarly, when forwarding a message from another environment into the Internet, the gateway SHOULD set the envelope return path in accordance with an error message return address, if supplied by the foreign environment. If the foreign environment has no equivalent concept, the gateway must select and use a best approximation, with the message originator's address as the default of last resort.

I do not see this as a problem, because the SMTP protocol has not been updated (except for the SMTP 521 and 556 Reply Codes, RFC 7504) since 2008, but the practices including email forgery prevention have evolved since.

Tom Johnson avatar
br flag
I'm aware of this, but thank you for information. But my question is slightly different - an SMTP client gives his "MAIL FROM: ... " during MUA - MTA communication. Do servers generally copy this "MAIL FROM: ..." during MTA - MTA communication for this message? From what I've figured out so far the outgoing SMTP server is basically free (as per RFC5321) to construct "MAIL FROM: ..." in his own way, it can be taken from "From: ", "Sender: ", "MAIL FROM: ..." or even set to some completely non-standard value (although normally it wouldn't make much sense when transferring a usual message).
Tom Johnson avatar
br flag
But do perhaps SMTP servers behave in some specific way being just a de facto, not the official standard?
Tom Johnson avatar
br flag
Well, in fact your response answered my original question for cases of mail forwarding and mailing lists. But actually I'm more interested how it looks in the case of a usual message, I updated my original message a bit to reflect that.
jp flag
In a simple scenario the mail goes directly from the senders mail server to the recipients mail server and, therefore, there's no place to rewrite anything before the next-hop server. If the receiving infrastructure is more complex than that, it can do whatever is appropriate for its own purposes. The standard doesn't limit that in any way.
Tom Johnson avatar
br flag
Thx. Although the direct SMTP server - to - SMTP server communication is rare, usually there is MTA sitting in the very front of everything. OK, so I think that it can be reasonably accepted that when a usual mail is transmitted and it goes through a usual outgoing SMTP server to a usual inbound SMTP server, one can expect that "Return-Path" will be taken either from original "MAIL FROM:" or from "Sender:" or from "From:" header although one cannot say in advance which of this header a given SMTP server uses and there's even no guarantee that any.
Tom Johnson avatar
br flag
"there is MTA sitting in the very front of everything" - I meant MUA.
jp flag
I have added a reference to a chapter in the RFC 5321 that advices not to modify the envelope sender but rationalized how this has become outdated – although it is in the current protocol specification.
Tom Johnson avatar
br flag
After some more reading of the RFC 5321 I'm not sure if you're quite right saying that "such practices are slightly against RFC 5321, 3.7.5", because the fragment you quoted deals with mail gateways and it seems that gateways and mailing list exploders are generally recognized as two different things. I quote from the very same RFC: "When a message is delivered or forwarded to each address of an expanded list form, the return address in the envelope ("MAIL FROM:") MUST be changed to be the address of a person or other entity who administers the list."
Score:1
us flag

The servers are obliged to keep the return path open, the easiest way to do this is to copy the original MAIL FROM: address and re-use it in the outgoing SMTP transmission, but this is not the only way to satisfy that requirement.

Generally they do do that, but some servers take other actions such as deploying BATV, SRS or some other form of VERP.

As such it is safe to expect an email addressed to the purported sender to reach the entity responsible for creating the message, but possibly via one or more intermediaries who restore the previous SMTP sender address

Tom Johnson avatar
br flag
Thx for your answer. "The servers are obliged to keep the return path open" - it certainly makes sense, but is it a formal requirement or just a practice? If it's formal, could you give a link to specification saying so?
us flag
SMTP (RFC5321) discusses the rerurn path and its importance for smooth operation of the email system. my claim is mostly by implication from that.
Score:0
in flag

MAIL FROM:<reverse-path> as the parameter name hints to, this is used if the server needs to "send back" the email, such as error or other issues, and is not needed to be the same as the sender of the original email.

Many servers validate on this field, and use it for spam, but there is no requirements to this.

Tom Johnson avatar
br flag
Thank you for the response, although I know this, I updated my original question to better reflect what I wanted to know. See also my comment under the Esa Jokinen's answer.
in flag
The answer is very much, they should not, at least not more than put it in a header, or keep it in memory for transfer to "next server". Servers NEVER rewrite the actual RFC822 part, if they did DKIM and friends would break.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.