3

Our marketing department is contracting with a service that will send email to prospective customers on our behalf. From what I'm gathering from their documentation, it sounds like they do so via the Sender header (i.e. the From header contains an address in our domain, and the Sender header contains one from their domain). This places a "via" or "on behalf of" tag in the display of some mail clients.

They give us the option of installing a DKIM record in our domain and having them send emails directly from our domain with their servers. (Presumably we'd also have to add them to our SPF, though they didn't mention that.)

I understand the general implications of all this, but one claim they make in trying to push the direct-send option is that the "via" or "on behalf of" messages are more likely to be marked as spam. Is this actually true in practice?

In other words, are messages with a Sender header different from the From header more likely to be marked as spam than one sent with only a From header (assuming SPF records don't get in the way)?

0

The Sender is a standard originator field specified in the Internet Message Format (RFC 5322, 3.6.2) and, therefore, should not be considered as an error. Sometimes it's even mandatory.

The originator fields of a message consist of the from field, the sender field (when applicable), and optionally the reply-to field. The from field consists of the field name From and a comma- separated list of one or more mailbox specifications. If the from field contains more than one mailbox specification in the mailbox- list, then the sender field, containing the field name Sender and a single mailbox specification, MUST appear in the message. In either case, an optional reply-to field MAY also be included, which contains the field name Reply-To and a comma-separated list of one or more addresses.

The originator fields indicate the mailbox(es) of the source of the message. The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The Sender: field specifies the mailbox of the agent responsible for the actual transmission of the message.

I can't be completely sure if some spam detection gives score to the existence of the Sender header alone, but we can start by investigating SpamAssassin Rule QA as an example. The rule for __HAS_SENDER isn't currently active i.e. it doesn't give any score to the message.

If signed, DKIM tests From: field against the signature and the signature against the public key provided in DNS for that domain and selector. The DKIM signature must match the From field whether the Sender is present or not. These two doesn't exclude each other, but this day and age it's recommended to have DKIM signatures – and enforce DKIM with DMARC. I'd recommend having separate selector (and signing keys) for every 3rd party service provider.

SPF on the other hand doesn't check anything against email headers at all. It checks if the domain used in envelope sender (i.e. the address used in SMTP MAIL FROM: command) lists this MTA as a permitted sender. While RFC 6854 allows having multiple addresses in the From field, MAIL FROM has always only one address and it always starts a new mail transaction, clearing all recipients and mail data (RFC 5321, 3.3).

Therefore, the sending server may use an own domain in envelope sender, and ideally it would match with the Sender header, while From matches DKIM. Then, the final destination server records the envelope sender by inserting a third header Return-Path, as a trace information (RFC 5321, 4.4). As this information currently only saved in the final destination might change during the transmission, SpamAssassin has a proposal for storing this information on every Received header. It's not widely accepted, but SpamAssassin has supported it since version 3.0.3.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.