For us, we encourage SPF usage in DNS, simply because the 'big guys'
want it or penalize you...
As far as inbound, while SPF can be treated as a marker for various
forgeries, and also sometimes a specific spam vector, we usually ONLY
reject based on SPF if...
* The companies SPF is sane
* The company has a higher risk when the domain is forged (eg banks)
* The company has a history of being the target of malicious forgery
* The email system administrator chooses to for domains hosted on
their own systems
We usually extrapolate the SPF information into a 'Known Sender Forgery
(KSF)' format, for blocking at the SMTP transport layer, as well as
outbound checking (infected/compromised email accounts)
And yes, it is a pain when customers allow forwarding, however more and
more email operators are getting it, and the pain of blocking forwarding
is less than the pain when users exposed to forgeries. Even our own
invoices sometimes hit systems with aggressive SPF filtering, where the
customer has forwarded it another mailbox.. So if you don't get an
invoice, simply stop email forwarding ;)
Often it is a large phishing bot that uses the domain, (eg forgeries of
wetransfer.com at hetzner are better stopped at SMTP layer, and pretty
good evidence that the system should be recommended for inclusion in
spam outbreak RBL's)
On another note.. anyone else seeing a large increase in Azure based
spammers over the weekend?
On 2020-12-07 1:21 p.m., Scott Mutter via mailop wrote:
> 1. You must have an SPF record in order for the big mail providers to
even think about accepting your mail (softfail seems sufficient).
> 2. It's not worth rejecting incoming mail simply because it fails
SPF.There are too many badly configured servers out there
This has been my observation as well. You have to have an SPF record...
but because nobody apparently knows how to configure them accurately and
there's no desire to educate people ... nobody really cares what the SPF
record says. But you've gotta have one!
Forwarders are one of the things that don't respond well to SPF. But
honestly, it's 2020 ... why are we forwarding mail to external
services? SRS might be a bandaid for this, but isn't the easiest
solution to just tell people that forwarding mail to external servers is
bad (mmkay).
For SPF to be effective, if you ask me, the -all modifier has to be
used. If you can't define a list of IP addresses where legitimate mail
from your domain is going to be coming from, then what's the point of
SPF? So a message gets denied because you forgot to add that IP to your
SPF list... now you know to add it.
On Sun, Dec 6, 2020 at 8:03 AM Paul Waring via mailop <mailop@mailop.org
<mailto:mailop@mailop.org>> wrote:
On Sun, Dec 06, 2020 at 02:12:25PM +0100, Hans-Martin Mosner via
mailop wrote:
> In your experience, where does SPF really help? What are the use
cases that I don't see in my spam-blocker tunnel vision?
In my experience:
1. You must have an SPF record in order for the big mail providers to
even think about accepting your mail (softfail seems sufficient).
2. It's not worth rejecting incoming mail simply because it fails SPF.
There are too many badly configured servers out there - one example I
see a lot is where a company has not added their web servers to their
SPF record, but they send out transactional emails such as password
resets. You end up not receiving mail or trying to convince the company
that they should fix their SPF record (to which the response is the same
as broken TLS - "problem must be on your end as it works for us").
3. It does seem to be worthwhile having SpamAssassin take SPF failure
into account, not as an absolute rejection but a factor which indicates
that the mail might be spam.
--
Paul Waring
Freelance PHP developer
https://www.phpdeveloper.org.uk
_______________________________________________
mailop mailing list
mailop@mailop.org <mailto:mailop@mailop.org>
https://list.mailop.org/listinfo/mailop
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
