What do we mean when we refer to the 'sender' of an email?

  • [アーティクル]

There's a lot of ambiguity about the term "sender" when talking about the sender of an email. What do we mean?

The term is overloaded because there are so many possible "senders" of a message. Here's the most commonly used terms and how they show up in various email clients:

1. The From: address in the message headers
.This is the email address you see in your email client, and it's the one that DMARC protects. It's also the one that Office 365's antispoofing works on, too (see https://aka.ms/AntispoofingInOffice365). When you hit "Reply" in your email client, this is who the recipient will be with the exception described in #4.
..

2. The SMTP MAIL FROM
. This is the Return-Path, and it's where SMTP bounces are sent when the recipient mail server cannot deliver the email (e.g., mailbox is full, mailbox does not exist, etc.). This is is the email address that SPF protects. You won't see this email address anywhere in the email client, it only appears in the headers, typically in the Return-Path and in the Authentication-Results header in the smtp.mailfrom=<...>.The one exception where this does show up in the email client is in Gmail, where they sometimes show you the SMTP MAIL FROM in the via tag..
.3. 

3. The Sender: address in the message headers
. Some emails have a "Sender" header. RFC 5322 gives some guidance about this header, but I don't think it's clear:

The "Sender:" field specifies the  mailbox of the agent responsible for the actual transmission of the message.  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 Sender: field is the one that has the least consistent implementation.

Where is it typically used?
.
(a) When someone sends on behalf of another within an organization
. The place where I see it the most is internally here at work where an admin sends on behalf of an executive, usually when sending a a meeting invitation, or calendar invitation. Because it shows up so often when an admin sends on behalf of an executive, Outlook and Outlook Web Access (not sure about the mobile client or Outlook for Mac) renders the message differently in the mail client:.

<Sender> on behalf of <From>.

So, something like this:

admin@example.com on behalf of executive@example.com

That's useful to me, because I can see it's not the executive who is communicating with me, but their admin who is forwarding a message to me.

That rendering only shows up in the message view in Outlook and OWA. The list view displays only the From: address.

(b) On mailing lists

The place where I personally see this the most for my own email (as opposed to everyone else's as in point [a]) is on mailing lists. Some mailing lists will put the mailing list's email address into the Sender: and the original poster into the From:, like this:

Birdwatcher's List <birdwatchers@example.org> on behalf of Terry Zink <someone@noreply.com>

This is helpful when viewing which mailing list sent the message, but I think that there are better workarounds (e.g., A tip for mailing list operators to interoperate with DMARC to avoid failures). As far as I can tell, mailing lists doing this doesn't help the original poster pass DMARC without the mailing list implementing some workaround.

(c) In bulk email

Some bulk emailers add a Sender: header into their messages. I'm not sure why they do this, but it may be because they want the message to render differently in Outlook (but as far as I know, only Microsoft email clients render it differently; larger receivers like Gmail and Yahoo do not). Or, it may be because they want the message to pass SenderID which sometimes uses the domain in the Sender: header instead of From: upon which to do an SPF check.

Personally, I don't think adding the Sender: header to bulk email is necessary.

There isn't a standard authentication technique that protects the Sender: header (other than SenderID, which isn't used by any major email receiving organization, it's only used by some on-prem Exchange servers). I suspect that's because most email clients don't render it, and therefore any phisher or spammer trying to spoof it doesn't gain much because the average user won't even see it.

4. The Reply-To
. The Reply-To header is added when the originator of the message wants any replies to the message to go to that particular email address rather than the one in the From: address. This usually shows up as a separate field in the email client. There is no technique (SPF, DKIM, DMARC, or any other technology) that protects the Reply-To header.

Some email filters try to compare the Reply-To with the From: address and do something when they are different, but in my experience this generates a lot of false positives.

For the most part, when people say "sender" they are referring to the From: address. Most of the message traces in Office 365 and Outlook.com are referring to that. It's also the one that email clients are most concerned about protecting. But sometimes we are also referring to the SMTP MAIL FROM.

Hopefully this clears things up a bit.

Comments

  • Anonymous
    June 25, 2017
    Well, thanks, here's an article I wouldn't have to write myself :D
    • Anonymous
      June 27, 2017
      This topic comes up often enough that I felt compelled to write one.
  • Anonymous
    August 31, 2017
    Terry,regarding the Sender: header in bulk email my view is that it is all about authentication. Even if the "Sender Id" times are long gone and there is no longer a practical need for using the Sender: header, you now best, that the fundamentals are always the same and rise awareness about authentication is a must.If someone sends using an ESP and a from: domain that is not aligned with the signing DKIM domain, then the ESP makes very clear, adding the sender: header, that the email is signed using the ESP domain on behalf of the original sender.If the original sender bothers to configure DKIM accordingly then the message will be signed with their own domain and there is no need of any additional sender: header.The fact that the message renders differently in some clients is a chance to educate customers regarding authentication, and it should not be missed :)