0

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.

2
  • 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. Aug 8, 2021 at 4:05
  • 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? Aug 19, 2021 at 20:35

3 Answers 3

1

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

2
  • 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? Aug 1, 2021 at 11:18
  • SMTP (RFC5321) discusses the rerurn path and its importance for smooth operation of the email system. my claim is mostly by implication from that.
    – Jasen
    Aug 1, 2021 at 12:23
1

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.

8
  • 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). Aug 1, 2021 at 10:33
  • But do perhaps SMTP servers behave in some specific way being just a de facto, not the official standard? Aug 1, 2021 at 10:34
  • 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. Aug 1, 2021 at 10:45
  • 1
    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. Aug 1, 2021 at 10:47
  • 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. Aug 1, 2021 at 10:53
0

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.

2
  • 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. Aug 1, 2021 at 10:47
  • 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.
    – NiKiZe
    Aug 1, 2021 at 14:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .