> On 14 Apr 2023, at 12:26, Cyril - ImprovMX via mailop <mailop@mailop.org>
> wrote:
>
> Hi!
>
> What is the best approach when you receive an email that doesn't respect the
> SPF (with a hard fail)?
>
> I'm asking because we've been running ImprovMX for a few years now and the
> decision we took was that if you send us an email with a SPF that is failing
> ("-a"), we immediately refuse the email.
>
> For me, the reason was pretty straight forward ; you set your SPF in a way
> that you ask for it to fail, so it makes sense that we refuse it if ... it
> fails.
>
> But I just discovered that, among others, Google Workspace and Namecheap
> breaks the SPF when they forward an email!
Unless they’re rewriting the envelope, yes. This is part and parcel of how SPF
works. I’m somewhat surprised that those services are not rewriting the
envelope, though. Unfortunately, I don’t have the Google access /
infrastructure to test this and see what they’re doing.
> If you set up a forwarding for your email, say "supp...@domain.com
> <mailto:supp...@domain.com>" that redirects to al...@destination.com
> <mailto:al...@destination.com> and send an email from b...@example.com
> <mailto:b...@example.com> to supp...@domain.com <mailto:supp...@domain.com>,
> the server @destination.com <http://destination.com/> will see an email
> coming from b...@example.com <mailto:b...@example.com>, but with the IPs of
> Google (or Namecheap).
>
> Since b...@example.com <mailto:b...@example.com> hasn't put the Google (or
> Namecheap) IPs in their SPF because they don't use it, their email will break
> SPF at @destination.com domain. <>
Google is using ARC which gives the recipient server the ability to see the
authentication as it was when the message was received by Google.
> So, since Google Workspace and Namecheap are doing this, it means that others
> are certainly also doing this.
Many forwarders rewrite the Envelope From so that the SPF record is theirs.
There’s even a standard documenting how to do this (SRS).
> What would be the best behavior here? Should we rely on both the SPF AND DKIM
> to refuse an email (compared to just the SPF), even if no DMARC are set?
> Should we allow all emails, even those who fail SPF?
> Should we only block when DMARC is set and fails?
>
> What is the best approach here?
The best approach really depends on what your goal is here. Refusing to deliver
mail that fails authentication checks will always result in legitimate and
wanted mail. It’s just the nature of the beast. These are really internal and
business decisions and while we all have opinions about how to handle
authentication failures and deliver mail, I don’t think we can tell you how to
manage your business.
> I personally don't want to accept emails that fails SPF with no further
> checks, otherwise it will be hell on the amount of emails we'll handle.
That is a valid business choice. But given the type of service you run, it is
going to result in a lot of lost mail and possibly unhappy customers.
When clients come to me with questions like this, we go through a discussion
designed to get them to identify what are their business priorities, what are
your business and technical constraints and how do you want your customers to
see you. Typically those discussions lead to clarity and then the business can
make the decision that’s best for them.
Overall, I think it’s generally a bad idea to block mail for SPF failures and,
quite honestly, most of the industry doesn’t do that.
laura
--
The Delivery Experts
Laura Atkins
Word to the Wise
la...@wordtothewise.com
Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
