is it better to enable Scan From header instead of Return Path for SPF?
Question asked by Richard Frank - 12/7/2021 at 4:35 AM
  • Scan From header instead of Return Path - Enabling this means the check will use the From address for the SPF check as opposed to the message's RETURN-PATH, which is where NDRs (bounce messages) are sent. Many times spammers will spoof messages by changing the From address to make it appear like a message is coming from a legitimate person/organization even though the RETURN-PATH may be for the actual source of the message. While it is possible to spoof a message's RETURN-PATH, spoofing the From address is a much more common method used by spammers.
Customer of mine received a mail showing coming from secretary and to transfer some funds

Return-Path: <melissa@sizemoredesign.com>
Received: from p3plwbeout26-02.prod.phx3.secureserver.net
   (p3plsmtp26-02-2.prod.phx3.secureserver.net []) by
   mail.soko.nl with SMTP    (version=TLS\Tls12    cipher=Aes256 bits=256);   Mon, 6
   Dec 2021 20:37:20 +0100
Received: from p3plgemwbe26-06.prod.phx3.secureserver.net   ([])
    by :WBEOUT: with SMTP    id uJmQmOrGYsdKVuJmQmMUsG; Mon, 06   Dec 2021 12:36:06
X-SECURESERVER-ACCT: melissa@sizemoredesign.com
Received: (qmail 14366 invoked by uid 99); 6 Dec 2021 19:36:06 -0000
User-Agent: Workspace Webmail 6.12.10
Message-ID: <20211206123602.0afaceaf2c0aea7b51b5e246b163acc0.7dd2e2fcb2.wbe@email26.godaddy.com>
From: "  J. Moritz" <correct@address.nl>
X-Sender: melissa@sizemoredesign.com
Reply-To: "  J. Moritz" <alt.h1-59zwnb2@cool.fr.nf>

2 Replies

Reply to Thread
Matt Petty Replied
Employee Post
Should always be Return-Path (Mail From), that's how it is defined in the RFC.
Not too sure why it's configurable, maybe there are some edge cases where checking the other was better, albeit against RFC.
Matt Petty Software Developer SmarterTools Inc. (877) 357-6278 www.smartertools.com
Douglas Foster Replied
The standards are designed for this result:
- SPF validates the invisible SMTP "MAIL FROM" address against the server IP, 
- DMARC validates the user-visible FROM header against the SMTP "MAIL FROM" address. 

People who do not use DMARC can get very frustated with spammers impersonating others, especially their own domain.   So they think checking the FROM header with SPF will solve the problem.   However, most of the world's mail is bulk traffic sent by service providers.   Most bulk traffic uses the service provider's domain for SMTP and the client domain for the message FROM.   If you check SPF against the FROM address, all of that bulk traffic will fail validation.

Both SPF and DMARC will experience validation failures that are not malicious impersonations, but instead are very much wanted.   Therefore, before activating either one, you need a system in place to handle false positives.  This requires: (a) a message log review tool with allows flexible searching and selection, so that you can see potential problems, (b) a way to collect data without disrupting your users, and (c) an exception mechanism which allows you to configure exceptions safely.

A safe exception for SPF should mimic SPF:  When an SMTP domain has a particular value, and the server has a particular identity, then the message is handled as equivalent to SPF PASS.   Because you don't know all IP addresses for a sending organization, matching on IP address does not work well for SPF exceptions.  The better solution is to match on the domain portion of a host name that represents the organization, when that host name is forward-confirmed to the source IP.

Similarly, a safe exception for DMARC should mimic DMARC.  When the message FROM domain and SMTP MAIL FROM domains have specific values, and the SMTP MAIL FROM DOMAIN is validated as SPF PASS or equivalent, then the mesage FROM address is considered equivalent to DMARC PASS.

When a message is confirmed as a malicious or unwanted impersonation, then you want to block the identifiers that are deemed responsible for the attack.   This can be one or more of the submitted identifiers, including: the message FROM user or domain, the SMTP MAIL FROM domain, the HELO domain, the Reverse DNS domain, and/or the server IP address.   Malicious identifiers do not require validation, since impersonation of a malicous sender is reasonably assumed to be malicious.    Consequently, each identifier block can be configured individually as a single-attibute match.

SmarterMail is not well suited to any of this.   SPF weighting can be configured to implemented test-but-dont-block, but DMARC seems only to have a enable-and-block option.   It does not provide a message review tool, and the logs really don't have enough data for you to create your own.   It does not provide three-factor allow rules (independent identifier, validation method, and dependent identifier.)    Consequently, I do not recommend enable either SPF or DMARC blocking in SmarterMail.

I have implemented all of the above using a heavily-customized implementation of Declude.   My DMARC implementation is a poor-man's version which would make the purists gag, but it works for me.    I do not block anything based on validation FAIL.   Instead, I use FAIL to prioritize which messages are reviewed for filtering updates.   Wanted messages are given a 3-attribute allow rule, and unwanted messages are given a single-attribute block rule.   Either way, messages from the source will be handled deterministically thereafter.

I had a great deal of difficulty finding commercial product vendors that could either implement this model, or could explain to me why they had a better one.   If anyone has a commercial product that can meet these requirements, please send a private message with the particulars.

Reply to Thread