I'd like to separate the concern of fragmenting a share conversation from the concern that the user might be confused about the From: header not being set to the sharing user's email address. If I understand correctly, by impersonating the user via From: we're running the risk of being identified as spam. E.g. if the domain of the user's email address publishes a DMARC record, and the configured mail server is e.g. either not in the SPF or does not add the DKIM signature, we're getting identified as potential spam, and depending on that record we might get rejected. However, even if we set the Sender: header, the From: is still suspect to SPF, see
We're completely circumventing that problem by setting the Reply-To:, and in fact we're doing exactly what the best practices recommend:

MAIL FROM: info@evite.com
...
From: "Mary Dinkleplotz" <info@evite.com>
Reply-To: "Mary Dinkleplotz" <mdinkleplotz@hotmail.com>
Subject: Mary Dinkleplotz has sent you an invite! evite.com does it this way:
Choose a general address in your domain (info@evite.com).
Change the "MAIL FROM" to that address.
Change the "From" header to that address.
Add a "Reply-To" header that contains your user's e-mail address.

By allowing the admin to configure an email for the From: header we're giving him the power to either opt-in verification mechanisms by choosing an email address which is not in a domain for which a DMARC record is published. As soon as we're setting the From: to a user's email address, we're taking away that (direct) control from him and he has to ensure that his mail server complies with all of those mails. If there's an SPF record for that domain, and the mail server is not in it, the mail will be identified as spam.

Also we're setting the personal name part of the From: already to the user's name, e.g. From: "Fabian Kraemer (Confluence)" <admin@noreply.com>, which is set on the mail server configuration

${fullname} (Confluence)

, that should lower the confusion.

I'm going to close this issue as "Not a bug" due to the above findings, if you want us to reconsider it, please raise a feature request.

The issue here seems to be an inconsistency in the From, Reply-To and X-Original-Sender information in the header of the information. The following illustrates how these values are currently set:

From: "User Name (Confluence)" <server_from_address@atlassian.com>
Reply-To: user_email@atlassian.com
X-Original-Sender: server_from_address@atlassian.com

I'd suggest that the From address and Reply-To should be the same.

The 'reply' does not go back to the user email address. - It goes to the 'no_not_reploy@nasa.gov' black hole.