On 01/24/2018 01:01 PM, Vincent Fox wrote:
SPF is designed for whitelisting, not blacklist.
Not true. We are supposed to reject email that doesn't pass SPF checks if the domain has told us to with "-all". That is a form of blacklisting controlled by the domain itself to protect it's own brand/reputation from spoofing. If you don't know what you are doing and create an SPF record with "-all", then that's your own fault. Google has started putting many of these emails with SPF_FAIL in their Spam folder which puts more importance to get your SPF record correct and complete.
Remember when "shields" appeared in mail clients, and how fast that feature disappeared? Far too many people clicking on phish that seemed "authentic". With the explosion of cheap domains and registrars, there's really no snowshoe Black Hat operation that can't comply. Compliance is 99.9999% in every phish I've investigated last year, the outlier I can recall was a simple typo in 1 server in the sender's network.
SPF is authorization not authentication. There is a difference and complete security requires both. You use SPF to tell the Internet authorized mail servers for your domain. That doesn't have a direct tie to spam but it does allow a level of whitelisting (I like to call it safelisting) for senders you trust.
SPF is a zombie legacy that someone should shoot in the head. Maybe then we could design something that is useful for what we all desire, which is properly authenticating senders.
If keep in mind that SPF is authorization and DKIM is authentication, you really need both. When a sender with DMARC p=reject aligns perfectly in both SPF and DKIM then all you know is that email is legit and not spoofed. It doesn't say anything about spam or ham in the content. If you whitelist trusted senders then you segment them out of the way which allows fine tuning on the rest of the mail flow.
------------------------------------------------------------------------ *From:* David Jones <djo...@ena.com> *Sent:* Wednesday, January 24, 2018 6:12:19 AM *To:* 'users@spamassassin.apache.org' *Subject:* Penalty for no/bad SPF Google Chrome and other browsers have been slowly penalizing sites not using encryption to the point that soon they will be alerting users of plain HTTP sites. This along with letsencrypt.org has been moving the HTTPS bar forward to improve web security and privacy. I think it's time for the SA community to help move the bar forward with SPF. The problem is many sysadmins that don't understand SPF have been implementing SPF incorrectly (thank you Microsoft Office 365) and incompletely without understanding they are shooting themselves in the foot. I decided about a month ago to start sending feedback emails to senders with SPF PERMERR and SPF FAIL in an attempt to help them help themselves improve _their_ mail delivery. If you setup your SPF record like Microsoft recommends with a "-all" and it's not completely covering all legit sources of email, it's completely useless for any MTAs and mail filters to take SPF_FAIL hits seriously. We should have rejected the email per that sending domain's own wishes but we all know they didn't intend for us to really block it so what good is it? What does everyone think about slowly increasing the score for SPF_NONE and SPF_FAIL over time in the SA rulesets to force the awareness and importance of proper SPF? This may need to have an official announcement of what the plans/timelines would be so we could get the word out. These days with DMARC reporting, it's not impossible to figure out a good SPF record like it was 10 years ago. The real problem with SMTP in general is there is no reliable way to get feedback to mail admins without sending confusing technical emails to regular users. -- David Jones
-- David Jones
