Re: [mailop] Effeciveness (or not) of SPF

[Brandon Long via mailop]

On Wed, Dec 9, 2020 at 11:29 PM Thomas Walter via mailop 
wrote:

> Hey Brandon,
>
> On 09.12.20 00:55, Brandon Long via mailop wrote:
> >
> > On Tue, Dec 8, 2020 at 1:31 AM Paul Smith via mailop  > > wrote:
> > If you're forwarding to your own company's mail server, then it
> should
> > be easy to have that forwarding work with SPF, and if you're
> forwarding
> > to someone like gmail, then, to be honest, it should be relatively
> > trivial for them to *USE* SPF to allow forwarding to them. I could
> tell
> > Google to allow a specific domain to forward to me (the domain of the
> > forwarder), and they use the SPF record for that domain to validate
> the
> > IP addresses that can then forward and override other SPF checks.
> >
> >
> > That feature was on my backlog at Gmail for a long time, but never high
> > enough priority
> > to get off it... now it would probably use ARC instead unless that
> > becomes a pipe dream,
> > at least theoretically with ARC we could just learn it and not worry
> > about the user interface
> > and confusing users.
> Interested question: Your systems could learn something like that too?
>
> If a number of emails come in to the same recipient with "failing" SPF
> from the same host(s)/domains it is probably a forwarder to that recipient?
>

We have some things that we use for trying to learn forwards, but they are
far from
perfect.  ARC would be a much cleaner signal and one we'd likely put more
effort into
due to it's need for DMARC and mailing lists. With ARC, we wouldn't need to
learn
of the forwarding, but we would need to determine whether we want to trust
a given forward.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Brandon Long via mailop]

On Thu, Dec 10, 2020 at 1:27 PM Liam Fisher via mailop 
wrote:

>
> SPF plays havoc with forwards unless the sender is rewriting their
> envelope from addresses to a domain with SPF friendly to their
> source.
>

Unless you do a good job of not forwarding your spam mail, we don't
recommend rewriting
the envelope sender when forwarding to Gmail especially to match SPF.
That's a good way
to have all of the spam you forward attributed to your own domain and hurt
it's reputation in
our system.  That applies to using SRS too.

If you don't forward spam, or don't rewrite things you think are spam,
rewriting is less harmful.

I realize that Gmail auto-forwarding does indeed rewrite the mail from, but
I'm going to go with
we do a good enough job of spam blocking, and also our forwards are not a
high percentage
of the gmail.com mail, so it does actually meet the suggestions.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Liam Fisher via mailop]

-Original Message-
>From: Thomas Walter via mailop 
>Sent: Dec 10, 2020 2:26 AM
>To: mailop@mailop.org
>Subject: Re: [mailop] Effeciveness (or not) of SPF
>
>Hey Brandon,
>
>On 09.12.20 00:55, Brandon Long via mailop wrote:
>> 
>> On Tue, Dec 8, 2020 at 1:31 AM Paul Smith via mailop > <mailto:mailop@mailop.org>> wrote:
>> If you're forwarding to your own company's mail server, then it should
>> be easy to have that forwarding work with SPF, and if you're forwarding
>> to someone like gmail, then, to be honest, it should be relatively
>> trivial for them to *USE* SPF to allow forwarding to them. I could tell
>> Google to allow a specific domain to forward to me (the domain of the
>> forwarder), and they use the SPF record for that domain to validate the
>> IP addresses that can then forward and override other SPF checks.
>> 
>> 
>> That feature was on my backlog at Gmail for a long time, but never high
>> enough priority
>> to get off it... now it would probably use ARC instead unless that
>> becomes a pipe dream,
>> at least theoretically with ARC we could just learn it and not worry
>> about the user interface
>> and confusing users.
>Interested question: Your systems could learn something like that too?
>
>If a number of emails come in to the same recipient with "failing" SPF
>from the same host(s)/domains it is probably a forwarder to that recipient?
>
>Regards,
>Thomas Walter
>
>-- 
>Thomas Walter
>Datenverarbeitungszentrale
>
>FH Münster
>- University of Applied Sciences -
>Corrensstr. 25, Raum B 112
>48149 Münster
>
>Tel: +49 251 83 64 908
>Fax: +49 251 83 64 910
>www.fh-muenster.de/dvz/
>


SPF plays havoc with forwards unless the sender is rewriting their 
envelope from addresses to a domain with SPF friendly to their 
source.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Thomas Walter via mailop]

Hey Brandon,

On 09.12.20 00:55, Brandon Long via mailop wrote:
> 
> On Tue, Dec 8, 2020 at 1:31 AM Paul Smith via mailop  > wrote:
> If you're forwarding to your own company's mail server, then it should
> be easy to have that forwarding work with SPF, and if you're forwarding
> to someone like gmail, then, to be honest, it should be relatively
> trivial for them to *USE* SPF to allow forwarding to them. I could tell
> Google to allow a specific domain to forward to me (the domain of the
> forwarder), and they use the SPF record for that domain to validate the
> IP addresses that can then forward and override other SPF checks.
> 
> 
> That feature was on my backlog at Gmail for a long time, but never high
> enough priority
> to get off it... now it would probably use ARC instead unless that
> becomes a pipe dream,
> at least theoretically with ARC we could just learn it and not worry
> about the user interface
> and confusing users.
Interested question: Your systems could learn something like that too?

If a number of emails come in to the same recipient with "failing" SPF
from the same host(s)/domains it is probably a forwarder to that recipient?

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Brandon Long via mailop]

On Tue, Dec 8, 2020 at 1:31 AM Paul Smith via mailop 
wrote:

> On 07/12/2020 21:47, John Levine via mailop wrote:
> >
> >> 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).
> > Uh, no. I have lots of users with role accounts who read their mail at
> > gmail.  Forwarding is as useful as it ever was, even though it is ever
> > harder to to do successfully.
> >
> > The fact that SPF can't handle forwarded mail is a failure of SPF, not
> > a bug in forwarding.
>
> We have to be careful not to prescribe that the old way of doing things
> is sacrosanct. The world changes.
>
> I remember when I could have emailed you by sending a message to
> johnl%taugh.com%microsoft@ibm.com and it would have got to you. No
> one (I hope) nowadays would say that is an acceptable way of doing things.
>
> Forwarding is still useful nowadays, but 'willy nilly' forwarding
> shouldn't be. Nowadays, there needs to be a way to limit forwarding to
> the forwarding you actually want to happen. The risk of spoofed mail can
> be catastrophic for a company, and because forwarded mail looks very
> similar to spoofed mail, there needs to be a way to differentiate them.
>
> If you're forwarding to your own company's mail server, then it should
> be easy to have that forwarding work with SPF, and if you're forwarding
> to someone like gmail, then, to be honest, it should be relatively
> trivial for them to *USE* SPF to allow forwarding to them. I could tell
> Google to allow a specific domain to forward to me (the domain of the
> forwarder), and they use the SPF record for that domain to validate the
> IP addresses that can then forward and override other SPF checks.
>

That feature was on my backlog at Gmail for a long time, but never high
enough priority
to get off it... now it would probably use ARC instead unless that becomes
a pipe dream,
at least theoretically with ARC we could just learn it and not worry about
the user interface
and confusing users.


> Or forwarders could add a digital signature to a header, and the user
> somehow tells the forwarding target the public key to validate that
> signature for forwarders they want to allow that would then bypass SPF
> checks. (This would be better than the IP checking way, but would
> require a new standard)
>

that's basically ARC.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Brandon Long via mailop]

On Tue, Dec 8, 2020 at 2:44 AM Rich Kulawiec via mailop 
wrote:

> SPF is just about entirely useless, which should surprise nobody.
> This was obvious on inspection when it was announced.
>
> - It's no help with spam: almost without exception, every message that
> hits my spamtraps passes SPF.
>
> - It's no help with phishing: thanks to ICANN, registrars, and
> the proliferation of TLDs, phishers have their choice of hundreds of
> millions of typographically similar domains.  Or they can just use
> freemail providers and rely on the gullibility of recipients.
>
> - It's no help with forgery for the same reason, and for another:
> mass compromises of email accounts are commonplace (see: Yahoo).
>
> It's never worked.  It's not working.  It's not going to work.
>

I'll disagree, SPF is extremely useful for antispam, and even for
antiphishing.  It's not useful as "did it pass or not" type of
obvious flag, sure.

It's mostly useful in terms of "pass", less useful in terms of "fail"
though not entirely.  The utility comes from identifying a "who".

Do spam filters still use IPs as a strong signal?  Yes.  Why?  Because it's
an identity that (mostly[1]) can't be spoofed and ties past behavior
to.

SPF and DKIM both do the same thing, they attach a strong identity signal,
and should be used in much the same way... note that
DKIM explicitly says that failures should be ignored.  SPF's policy signal
was always weak, and should be ignored by modern receivers
which have a diverse set of mailboxes and want to support their users doing
what users do.  If you instead want to play BOFH in your
domain, of course that's your purview.

Yes, spammers and phishers can create as many new domains and SPF records
for them as they want, but those things can't match
those they are trying to pretend to be.  This makes it easier to separate
the good from the bad.  I'd even say that it makes it easier
to programmatically compare look-alike domains to know what is good and
what is bad.

It's also helpful to senders who don't want to be tied to their existing
IPs, SPF & DKIM allow them to add IPs or move IPs with fewer
issues, since their reputations move with their domains instead of being
tied to IPs.

There are cases where the differential between DKIM and SPF can be useful.
The DKIM replay spam attacks a couple years back
come to mind, where the fact that most messages aren't forwarded and
DKIM/SPF is the same, means differentiating made it easier
to spot the replays and learn they were bad.

One should also be wary of potentially bad SPF records.  Unless you're
Apple whitelisting your entire class A, most broad records should be looked
at skeptically, unless you want spammers to find them and exploit them.

And yes, SPF & DKIM and the usage of that for antispam/anitphishing does
increase the desire of spammers/etc to compromise accounts.  I
don't think that's a reason to abandon SPF.  Obviously you want to work to
secure your users' accounts for a variety of reasons.

Looking at any of these things as the solution to spam is of course
incorrect, but they are part of the tools we have, and together those
tools can do a pretty decent job.

I don't really have "statistics" on the utility of SPF, but nearly every
rule we create relies on it at some level.  It's a pretty fundamental part
of our
system.  Can you make an equally strong system without it?  Maybe.

Brandon

[1] One should also be wary of incorrectly written broad SPF records.
Unless you're Apple whitelisting your entire class A, most broad records
should be looked
at skeptically, unless you want spammers to find them and exploit them.
See also DNS hijacking or BGP spoofing as well.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[John Levine via mailop]

In article <8487930e-ef45-9354-e451-1e77ecccf...@fh-muenster.de> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>
>
>On 07.12.20 22:47, John Levine via mailop wrote:
>> People do use them as part of a scoring spam filter.  But no sensible person
>> uses SPF alone to do mail filtering.
>
>I also thought that no sensible person would discard messages even
>though the SPF entry owner asks them to do a softfail, but I guess I was
>wrong.
>> Uh, no. I have lots of users with role accounts who read their mail at
>> gmail.  Forwarding is as useful as it ever was, even though it is ever
>> harder to to do successfully.
>
>I fully agree, but gmail is a bad example, because they actually support
>importing remote mailboxes with pop3 which does not require forwarding.
>We never tried that, but it is an option:

Yes, it works, I've encouraged my users to set that up since it is
less likely to lose mail at the cost of some polling delay.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Graeme Fowler via mailop]

On 8 Dec 2020, at 10:38, Graeme Fowler via mailop  wrote:
> Grant said, paraphrased

> If you decide otherwise, Rafa

Apologies for the mixed use of forename and surname; that was absolutely not 
intentional. Thanks to those who pointed that out privately.

Graeme (who needs to sleep for a long, long time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Jesse Thompson via mailop]

On 12/8/20 1:02 AM, Hans-Martin Mosner via mailop wrote:
> Am 07.12.20 um 23:51 schrieb Thomas Walter via mailop:
>>
>> I fully agree, but gmail is a bad example, because they actually support
>> importing remote mailboxes with pop3 which does not require forwarding.
>> We never tried that, but it is an option:
> 
> Well if giving The Goog all kinds of information via search history and gmail 
> account isn't enough, we hand them the
> passwords to our accounts at other providers on a silver platter. Yup.

OAuth 2.0 is the answer to that, since it's an integration that can be 
permission-scoped appropriately, revoked without changing the users' passwords, 
etc.  

Gmailify supports it for some mailbox providers.  

Jesse
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Grant Taylor via mailop]

On 12/8/20 2:10 AM, Thomas Walter via mailop wrote:
So in that case you are against servers supporting SRS since it breaks 
your idea of how email should work?

As a sender?  Yes.

As an email server operator that supports forwarding?  No.  -  Yes, I 
have SRS configured and functional.  Though I only apply it to outgoing 
messages that the SMTP from is not a domain that the servers are 
authoritative for.


Aside:  I think someone questioned the venerable .forward functionality 
in relation to SRS.  --  Perhaps I misunderstood the comment.  --  Yes 
.forward (or alias local address to remote address works perfectly fine 
with SRS.


This discussion really reminds me why I never liked this broken 
by design concept and never will. Yet I am forced to support it, 
because the big fishes decided otherwise.


We obviously disagree.

Can someone point me to statistics about how effective SPF is compared 
to other antispam measures?


I stated the disagreement above because "antispam" can mean a lot of 
different things to different people.  I say this because some people 
consider spoofed email to be spam while others consider spoofed email to 
be something other than spam.  This is germane because SPF can be one of 
these and not the other.


SPF can be quite effective against spoofing actual email addresses from 
companies that have a strong hand in how their email works including 
publishing proper SPF records.  --  That particular task is completely 
independent of filtering out recreational drugs or stock pump and dump spam.


I consider SPF to be one of many tools in the email hygiene toolbox, 
each used to combat slightly different problems.  Collectively, they can 
do quite a good job cleaning email flow.


Spammers using phished/hacked accounts don't care. Spammers with 
their own domains just add SPF records and can easily include (hacked) 
third party systems?


Which is why SPF is not a good anti-spam technique.

I consider SPF to be an acceptable way to know if an email came from an 
authorized source or not.  Specifically in a federated like manner.


Phishers just use mail0p.org with correct SPF records to foil targets 
or just use 'From: "Example " ' 
since modern MUAs decided it's a good idea to not show mail addresses 
anymore...


That tells me that SPF has been effective to protect mailop.org.  As 
such, I can be more confident in trusting email from mailop.org than i 
can in trusting mail0p.org.


Different tools protect against different things.

Would you argue that keeping matches out of kids reach is useless when 
they can find a hammer and crush their thumb?



Perhaps I should just start looking into botany.


I'm confident that there are things in botany that will annoy you too.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Rich Kulawiec via mailop]

On Tue, Dec 08, 2020 at 10:58:22AM +, Paul Smith via mailop wrote:
> "Typographically similar" is not "identical". Yes, many people will be
> fooled by "typographically similar", but not everyone. SPF (and DKIM) allow
> you to verify to some level of certainty that the sender is who they say
> they are if you want to try. Without them, you have no chance.

First, "similar" is more than enough to fool almost everyone.  Presume
that example.com is, let's say, a financial institution.  If example.TLD
(where TLD is any of the myriad new ones) isn't available because example.com
decided to get there first, then example.com.TLD or example.comm.TLD will
probably suffice.  (I know, because I've run the experiments while doing
penetration tests.  BTW, this works a lot of the time even when the targets
are people who work for example.com and should ostensibly know better.
Guess what?  They don't.)

Second, suppose that you can verify the sender.  So what?  Even if this
verification is completely reliable -- and it's not -- it doesn't tell
you what their intentions are.  Or will be tomorrow. [1]

Third, neither SPF nor DMARC nor anything else can be relied on if the
email account or email host is compromised -- and we see instances of
that constantly.  In other words, if financialoffi...@example.com has
been compromised then the new owner of that email account can send
anything they want and it will be dutifully "verified" by anyone
naive and foolish enough to believe SPF et.al. provide verification.

(Should I remind everyone that *every* Yahoo account was compromised
and that *every* message those accounts sent was "verified"?  And this is
hardly an isolated case.)

SPF et.al. are failed attempts to wallpaper over a massive underlying
security problem that has gotten steadily worse for most of two decades.
They pretend to provide "verification" in an environment with hundreds
of millions of bots [2], mass compromises of individual email accounts,
and a steady stream of security breaches of mail servers of all
shapes and sizes.

It's a pretend game.  It doesn't actually address the root cause(s).
And that's because fooling around with SPF et.al. is much easier, much
simpler, much cheaper than actually tackling the underlying problems.

---rsk


[1] Everyone should know by now that even if a network/host/mail server/
email account is benign today, that in no way ensures that it will be
benign tomorrow.

[2] Probably more like a billion by now, but let's gloss over that and
note that anyone who controls a bot controls all email accounts used/stored
by the bot's previous owner.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Peter Nicolai Mathias Hansteen via mailop]

> 6. des. 2020 kl. 14:12 skrev Hans-Martin Mosner via mailop 
> :
> 
> 
> In addition, manual checks against spam mails from hosts on spam-supporting 
> or indifferent network IP ranges shows that
> spammers provide SPF records for their domains, of course, so properly 
> applied SPF is bound to have a significant
> percentage of false negatives.
> 
> So, there are much more false positives and false negatives than I'm willing 
> to accept. But obviously others have
> different experiences, otherwise they would not publish SPF records and check 
> them on mail reception.
> 
> 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, using SPF fail or otherwise as the only or strongly weighted 
criterion for reject or accept is not a good idea. In my own configs it is one 
of several factors considered mainly (but not exclusively, see the last one 
below) after passing greylisting (which I have found more useful) along with 
Spamassassin’s content and header checks.

A few notes from the field that involve various potential and quite real 
pitfalls with SPF and friends:

https://bsdly.blogspot.com/2016/10/is-spf-simply-too-hard-for-application.html 

 (they trusted SPF so much their application could not handle mail from 
correctly setup domains)

https://bsdly.blogspot.com/2018/02/a-life-lesson-in-mishandling-smtp.html 
 
(they should have known better than to run the checks *there*)

https://bsdly.blogspot.com/2018/11/goodness-enumerated-by-robots-or.html 
 (how 
I implemented sort-of trusting the thing)

Hopefully useful or possibly good for a few laughs.

All the best,
Peter


—
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.






signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Thomas Walter via mailop]

On 08.12.20 11:58, Paul Smith via mailop wrote:
> Verifying the sender is who they say they are is valuable, even if some
> people are fooled by messages from "b...@micr0soft.com".

For that it would help _a lot_ if mail clients didn't stop displaying
the actual address of the sender.

Yes, I am looking at you, Outlook et al.

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Tim Bray via mailop]

On 08/12/2020 09:22, Paul Smith via mailop wrote:
Forwarding is still useful nowadays, but 'willy nilly' forwarding 
shouldn't be. Nowadays, there needs to be a way to limit forwarding to 
the forwarding you actually want to happen. The risk of spoofed mail 
can be catastrophic for a company, and because forwarded mail looks 
very similar to spoofed mail, there needs to be a way to differentiate 
them.



I see a lot of forwarding between different divisions of the same 
company.   The UK office runs gsuite and uses example.co.uk.   The USA 
head office runs on office 365 and uses example.com.


The were checking both accounts, and they just set up a mail forward to 
the other one.


Corporate policy says `you must only publish b...@example.com`. So you 
see the crazy thing of an email from b...@example.co.uk with 
b...@example.com as their email address in the signature.


I'm not saying whether it is right or wrong, but it's a common use case.

On the spoofed bit.  Scams are real.   I'm pro SPF.  But the benefit of 
SPF is dimished because you can still send an email like  From: A 
trusted name  And the user doesn't see the 
domain.


Or forwarders could add a digital signature to a header, and the user 
somehow tells the forwarding target the public key to validate that 
signature for forwarders they want to allow that would then bypass SPF 
checks. (This would be better than the IP checking way, but would 
require a new standard) 


You mean a bit like a second DKIM signature?    Is that possible?  Is 
that useful?  Mailinglists do this ?    Could somebody who understands 
this a bit better please say what they think ?



--
Tim Bray
Huddersfield, GB
t...@kooky.org

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Laura Atkins via mailop]

> On 8 Dec 2020, at 10:58, Paul Smith via mailop  wrote:
> 
> On 08/12/2020 10:27, Rich Kulawiec via mailop wrote:
>> - It's no help with phishing: thanks to ICANN, registrars, and
>> the proliferation of TLDs, phishers have their choice of hundreds of
>> millions of typographically similar domains.  Or they can just use
>> freemail providers and rely on the gullibility of recipients.
> 
> "Typographically similar" is not "identical". Yes, many people will be fooled 
> by "typographically similar", but not everyone. SPF (and DKIM) allow you to 
> verify to some level of certainty that the sender is who they say they are if 
> you want to try. Without them, you have no chance.
> 
> Similarly, if you use a CRM or similar, then "typographically similar" won't 
> fool them, but a spoofed sender will.
> 
> Verifying the sender is who they say they are is valuable, even if some 
> people are fooled by messages from "b...@micr0soft.com".

SPF doesn’t verify the 5322.from.

> I've had to deal with customers who have lost large amounts of money because 
> of spoofed emails, even though they checked that the sender's email address 
> was valid. If the sender had used SPF or DMARC, it wouldn't have happened. 
> Yes, in hindsight they should have checked bank details offline, but lots of 
> people don't realise that email addresses can be forged so easily; anything 
> that makes it harder is a good thing.

I can trivially send mail from b...@micr0soft.com  
and have it pass SPF. 

With a little bit of work and spending some mone I can send mail from 
b...@micr0soft.com  and have it pass DMARC, too. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Paul Smith via mailop]

On 08/12/2020 10:27, Rich Kulawiec via mailop wrote:

- It's no help with phishing: thanks to ICANN, registrars, and
the proliferation of TLDs, phishers have their choice of hundreds of
millions of typographically similar domains.  Or they can just use
freemail providers and rely on the gullibility of recipients.


"Typographically similar" is not "identical". Yes, many people will be 
fooled by "typographically similar", but not everyone. SPF (and DKIM) 
allow you to verify to some level of certainty that the sender is who 
they say they are if you want to try. Without them, you have no chance.


Similarly, if you use a CRM or similar, then "typographically similar" 
won't fool them, but a spoofed sender will.


Verifying the sender is who they say they are is valuable, even if some 
people are fooled by messages from "b...@micr0soft.com".


I've had to deal with customers who have lost large amounts of money 
because of spoofed emails, even though they checked that the sender's 
email address was valid. If the sender had used SPF or DMARC, it 
wouldn't have happened. Yes, in hindsight they should have checked bank 
details offline, but lots of people don't realise that email addresses 
can be forged so easily; anything that makes it harder is a good thing.


--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Jaroslaw Rafa via mailop]

Dnia  8.12.2020 o godz. 10:38:04 Graeme Fowler via mailop pisze:
> The domain "owner" has stated something via a lookup system that
> practically anyone in the world can query.  What we as receivers can't
> intuit is whether the "-all" was intentional, whether they knew what it
> meant, whether is was accidental or someone's playing a joke on the domain
> owner; we can only go off what it states.  If it says "reject email from
> everywhere (except here)", then why wouldn't you?

I have already explained that in one of my previous emails. I wouldn't,
because the I would reject forwarded messages, if any.

Rich Kulawiec stated it perfectly in another email in this thread:
forwarding worked perfectly for years until it has been broken by SPF, which
does NOT work - ie. technically it does work, but it does not fulfill it's
purported goal, so it's useless and gives us virtually no benefit at all.

So it seems a reasonable decision just to ignore SPF (which is useless)
to make forwarding (which is useful) still work as expected.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Graeme Fowler via mailop]

On 8 Dec 2020, at 10:27, Jaroslaw Rafa via mailop  wrote:
> Dnia  7.12.2020 o godz. 18:02:08 Grant Taylor via mailop pisze:
>> you send me email from an unapproved IP and you have asked me to
>> reject unapproved emails via -all, them I'm going to reject your
>> email flat out.  After all, that's what /you/ as the domain owner /
>> administrator /asked/ me to do.
>> 
>> My personal option is that being soft and not rejecting on -all is
>> nothing short of coddling people that seemingly don't know how to
>> administer their email infrastructure.
> 
> The SPF RFC explicitly says:
> 
> "A "fail" result is an explicit statement that the client is not
> authorized to use the domain in the given identity. Disposition of
> SPF fail messages is a matter of local policy."
> 
> So no, it's not the sender who has the authoritative voice on what should be
> done with messages that fail SPF check, it's the recipient. Of course, *you*
> may decide what you say above, ie. that you reject such messages. But it's
> *your local policy*. Do not claim that it's a sender decision, because that
> claim is simply false. The RFC puts the responsibility *on you*.

You are both in violent agreement.

Grant said, paraphrased, that "the domain owner has asked me to do this" and is 
therefore _making a policy decision_ based on that guidance which is coming 
from the SPF record.

If you decide otherwise, Rafa, that's also your policy decision but you're 
going against the explicit guidance of the domain whose SPF record you've 
looked up.

The domain "owner" has stated something via a lookup system that practically 
anyone in the world can query. What we as receivers can't intuit is whether the 
"-all" was intentional, whether they knew what it meant, whether is was 
accidental or someone's playing a joke on the domain owner; we can only go off 
what it states. If it says "reject email from everywhere (except here)", then 
why wouldn't you?

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Rich Kulawiec via mailop]

SPF is just about entirely useless, which should surprise nobody.
This was obvious on inspection when it was announced.

- It's no help with spam: almost without exception, every message that
hits my spamtraps passes SPF.

- It's no help with phishing: thanks to ICANN, registrars, and
the proliferation of TLDs, phishers have their choice of hundreds of
millions of typographically similar domains.  Or they can just use
freemail providers and rely on the gullibility of recipients.

- It's no help with forgery for the same reason, and for another:
mass compromises of email accounts are commonplace (see: Yahoo).

It's never worked.  It's not working.  It's not going to work.


And about this:

On Sun, Dec 06, 2020 at 02:12:25PM +0100, Hans-Martin Mosner via mailop wrote:
> (I know mail users should not simply forward their mail

It worked perfectly well for decades until it was broken...for nothing.

---rsk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Jaroslaw Rafa via mailop]

Dnia  7.12.2020 o godz. 18:02:08 Grant Taylor via mailop pisze:
> you send me email from an unapproved IP and you have asked me to
> reject unapproved emails via -all, them I'm going to reject your
> email flat out.  After all, that's what /you/ as the domain owner /
> administrator /asked/ me to do.
> 
> My personal option is that being soft and not rejecting on -all is
> nothing short of coddling people that seemingly don't know how to
> administer their email infrastructure.

The SPF RFC explicitly says:

"A "fail" result is an explicit statement that the client is not
authorized to use the domain in the given identity. Disposition of
SPF fail messages is a matter of local policy."

So no, it's not the sender who has the authoritative voice on what should be
done with messages that fail SPF check, it's the recipient. Of course, *you*
may decide what you say above, ie. that you reject such messages. But it's
*your local policy*. Do not claim that it's a sender decision, because that
claim is simply false. The RFC puts the responsibility *on you*.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Paul Smith via mailop]

On 07/12/2020 21:47, John Levine via mailop wrote:



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).

Uh, no. I have lots of users with role accounts who read their mail at
gmail.  Forwarding is as useful as it ever was, even though it is ever
harder to to do successfully.

The fact that SPF can't handle forwarded mail is a failure of SPF, not
a bug in forwarding.


We have to be careful not to prescribe that the old way of doing things 
is sacrosanct. The world changes.


I remember when I could have emailed you by sending a message to 
johnl%taugh.com%microsoft@ibm.com and it would have got to you. No 
one (I hope) nowadays would say that is an acceptable way of doing things.


Forwarding is still useful nowadays, but 'willy nilly' forwarding 
shouldn't be. Nowadays, there needs to be a way to limit forwarding to 
the forwarding you actually want to happen. The risk of spoofed mail can 
be catastrophic for a company, and because forwarded mail looks very 
similar to spoofed mail, there needs to be a way to differentiate them.


If you're forwarding to your own company's mail server, then it should 
be easy to have that forwarding work with SPF, and if you're forwarding 
to someone like gmail, then, to be honest, it should be relatively 
trivial for them to *USE* SPF to allow forwarding to them. I could tell 
Google to allow a specific domain to forward to me (the domain of the 
forwarder), and they use the SPF record for that domain to validate the 
IP addresses that can then forward and override other SPF checks.


Or forwarders could add a digital signature to a header, and the user 
somehow tells the forwarding target the public key to validate that 
signature for forwarders they want to allow that would then bypass SPF 
checks. (This would be better than the IP checking way, but would 
require a new standard)


--

Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Thomas Walter via mailop]

On 08.12.20 02:02, Grant Taylor via mailop wrote:
> Obviously I disagree.  Thankfully SPF w/ -all allows second order
> receivers to know that I have not authorized the first order receiver to
> re-send email on behalf of my domain name.

So in that case you are against servers supporting SRS since it breaks
your idea of how email should work?


This discussion really reminds me why I never liked this broken by
design concept and never will. Yet I am forced to support it, because
the big fishes decided otherwise.

Can someone point me to statistics about how effective SPF is compared
to other antispam measures?

Spammers using phished/hacked accounts don't care. Spammers with their
own domains just add SPF records and can easily include (hacked) third
party systems?

Phishers just use mail0p.org with correct SPF records to foil targets or
just use 'From: "Example " ' since
modern MUAs decided it's a good idea to not show mail addresses anymore...

Perhaps I should just start looking into botany.

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Paul Waring via mailop]

On Mon, Dec 07, 2020 at 03:21:45PM -0600, Scott Mutter via mailop wrote:
> 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).

There are two cases I come across a lot where forwarding is still used:

1. Small organisations who want to have role-specific aliases (e.g.
secretary@) to advertise on their website etc, but the office holders
want to use their own personal email account because that's what they
check and are familiar with.

2. Some companies refuse to deal with people if they don't have an email
address under the domain of their customers. For example, I have a paul@
alias on one of my client's domains because their suppliers refuse to
allow an account contact to have an email address from a different
domain.

SRS is a bodge, but I do have the ability to make technical fixes
whereas I lack the ability to reconfigure the humans who came up with
the policies behind 1 & 2. :)

-- 
Paul Waring
Freelance PHP developer
https://www.phpdeveloper.org.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Hans-Martin Mosner via mailop]

Am 07.12.20 um 23:51 schrieb Thomas Walter via mailop:
>
> I fully agree, but gmail is a bad example, because they actually support
> importing remote mailboxes with pop3 which does not require forwarding.
> We never tried that, but it is an option:

Well if giving The Goog all kinds of information via search history and gmail 
account isn't enough, we hand them the
passwords to our accounts at other providers on a silver platter. Yup.

Cheers,
Hans-Martin

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Al Iverson via mailop]

On Mon, Dec 7, 2020 at 3:51 PM John Levine via mailop  wrote:
>
> People do use them as part of a scoring spam filter.  But no sensible person
> uses SPF alone to do mail filtering.

Nobody should, but some do. Whether or not it's sensible, it's
something that some people deal with.

> The fact that SPF can't handle forwarded mail is a failure of SPF, not
> a bug in forwarding.

It doesn't matter if it's a failure of SPF or not. SPF is something
one has to deal with if one wants to get as much of the mail delivered
as possible.

> Uh, no. I have lots of users with role accounts who read their mail at
> gmail.  Forwarding is as useful as it ever was, even though it is ever
> harder to to do successfully.

ITYM "harder to do it the old way successfully." Pull instead of push,
or use SRS or other header rewriting and don't try to stretch a
domain's SPF accountability beyond the IPs they publish, and it
actually isn't that hard. Heck, I SMTP auth relay my role account mail
into Gmail to bypass all of that and it works just fine.

Email forwarding itself isn't bad, we agree. External old school
dot-forwarding is outdated and too prone to failure. Tilt at that
windmill all you want, but that doesn't really change anything.

Cheers,
Al Iverson



-- 
Al Iverson // Wombatmail // Chicago
Song a day! https://www.wombatmail.com
Deliverability! https://spamresource.com
And DNS Tools too! https://xnnd.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Grant Taylor via mailop]

On 12/7/20 2:47 PM, John Levine via mailop wrote:
People do use them as part of a scoring spam filter.  But no sensible 
person uses SPF alone to do mail filtering.


Well ... maybe I'm not a sensible person then.  In the spirit of truth 
and kickings -- thank you Taylor Mali for "What Teachers Make"[1] -- if 
you ask for it, I'm obliged to give it to you.  So if you send me email 
from an unapproved IP and you have asked me to reject unapproved emails 
via -all, them I'm going to reject your email flat out.  After all, 
that's what /you/ as the domain owner / administrator /asked/ me to do.


My personal option is that being soft and not rejecting on -all is 
nothing short of coddling people that seemingly don't know how to 
administer their email infrastructure.


Uh, no. I have lots of users with role accounts who read their mail 
at gmail.  Forwarding is as useful as it ever was, even though it is 
ever harder to to do successfully.


Forwarding may be useful, but is it proper?

Consider the policy standpoint of from the sender's point of view.  I, 
as a domain owner / administrator / operator, provided you information 
on the servers that *I* authorize to send email claiming to be from my 
domain -and- asked you to /reject/ anything that is not from the 
server(s) that /I/ authorized to send email on my behalf.


To me, that very simple /policy/ (who's allowed to send and what to do 
with the riffraff) does indeed conflict with forwarding.  But here's the 
kicker, /forwarding/ in general /conflicts/ with my /published/ desire. 
So, I'm /happy/ that SPF -- when implemented properly by receivers -- 
supports my stated / published goal.


The fact that SPF can't handle forwarded mail is a failure of SPF, 
not a bug in forwarding.


Obviously I disagree.  Thankfully SPF w/ -all allows second order 
receivers to know that I have not authorized the first order receiver to 
re-send email on behalf of my domain name.


I can't prevent people from forwarding emails from my domain.  But I 
sure can make it more difficult for them to do so.


[1] http://www.taylormali.com/poems-online/what-teachers-make/



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Jaroslaw Rafa via mailop]

Dnia  7.12.2020 o godz. 15:21:45 Scott Mutter via mailop pisze:
> 
> 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?

Just because having one main mail account and forward mail from auxilliary
accounts to it is more natural (you only have to look at one account) than
having a mail client configured for multiple accounts. I would rather call a
multi-account configuration a poor workaround for e-mail accounts incapable
of forwarding ;).

> 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?

That proves that SPF has no point at all. Exactly because of forwarding.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Thomas Walter via mailop]

On 07.12.20 22:47, John Levine via mailop wrote:
> People do use them as part of a scoring spam filter.  But no sensible person
> uses SPF alone to do mail filtering.

I also thought that no sensible person would discard messages even
though the SPF entry owner asks them to do a softfail, but I guess I was
wrong.
> Uh, no. I have lots of users with role accounts who read their mail at
> gmail.  Forwarding is as useful as it ever was, even though it is ever
> harder to to do successfully.

I fully agree, but gmail is a bad example, because they actually support
importing remote mailboxes with pop3 which does not require forwarding.
We never tried that, but it is an option:

https://support.google.com/mail/answer/21289

But yes, please do not bash forwarding, just because someone invented a
mechanism that ignored the basics of email traffic.

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Michael Peddemors via mailop]

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 > 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 
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 

Re: [mailop] Effeciveness (or not) of SPF

[John Levine via mailop]

In article  
you write:
>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!

People do use them as part of a scoring spam filter.  But no sensible person
uses SPF alone to do mail filtering.

>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).

Uh, no. I have lots of users with role accounts who read their mail at
gmail.  Forwarding is as useful as it ever was, even though it is ever
harder to to do successfully.

The fact that SPF can't handle forwarded mail is a failure of SPF, not
a bug in forwarding.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Scott Mutter via mailop]

> 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 
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
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Paul Smith via mailop]

On 06/12/2020 13:12, 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?


One thing we still encounter occasionally is where a spammer has decided 
to send email from one of our customers' domains (not by hacking their 
mail server, just by forging the return path). In this case, our 
customer get loads of backscatter, and autoresponses, etc.


Adding SPF tends to cut down on the backscatter as, presumably, some of 
the spammers' targets will not send failure messages back if the SPF 
fails, and some reject the junk outright. Also, spammers seem to stop 
using their domain and switch to another one without SPF. (We can 
support BATV as well, but that can break in some situations)


This used to happen a LOT more in the past, but it still happens today 
occasionally.


So, I'd suggest having at least a 'soft fail' SPF record for your own 
domain. If a spammer is in the habit of trying to piggy-back off other 
companies' domain reputations, then it seems to encourage them to look 
elsewhere.


For incoming mail: personally, if it was for a personal mail server, or 
I was in charge of a company's mail server, I wouldn't have a problem 
blocking on an SPF hard fail. If the mail system was used for customers, 
then I wouldn't do that, as the support hassle would be too great.


Using SPF as another factor in a more comprehensive spam filtering 
system is reasonable. In my experience, more SPF fails are bad than are 
false positives. But SPF is not an anti-spam mechanism at all, so 'false 
negatives' are actually very rare (those would be where a domain holder 
has an SPF that authorises IP addresses that it shouldn't do and which 
do send forged mails)


--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Matt Harris via mailop]

On Sun, Dec 6, 2020 at 7:20 AM Hans-Martin Mosner via mailop <
mailop@mailop.org> wrote:

> In addition, manual checks against spam mails from hosts on
> spam-supporting or indifferent network IP ranges shows that
> spammers provide SPF records for their domains, of course, so properly
> applied SPF is bound to have a significant
> percentage of false negatives.
>

I wouldn't call these false negatives, because the objective of SPF is not
to prevent spam entirely but simply to authenticate that the sending host
is authorized to send for the given domain. In that regard, it's working
and you're not seeing false negatives. You're simply receiving spam from
spammers using actual spam domains over which they have control or domains
without proper SPF configurations. SPF is helping prevent spammers from
sending email from your domain and my domain and other folks' domains,
however, when you and other mail server operators configure things
correctly.

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Mary via mailop]

I think the two groups I am monitoring are not interested in horizontal 
expansion within their target banks, maybe due to the extreme network security 
of these institutions? Based on my experience, they keep these infected systems 
as sleepers, not using them for long periods of time.

My guess, is that horizontal expansion is more important to organized 
ransomware operations?



On Sun, 6 Dec 2020 20:03:51 +0100 Thomas Walter via mailop  
wrote:

> On 06.12.20 19:27, Mary via mailop wrote:
> > Now, having a large list of real email bodies, they re-use them for 
> > phishing. They re-send a previously legitimate email but with variations, 
> > like replacing attachments.  
> 
> They can also send mail directly from the inside - without any SPF
> checks in place and quite often without any antispam or antivirus
> measures as long as the email stays on the inside? And use the correct
> user's address?
> 
> At least that's what happened here in one incident.
> 
> Regards,
> Thomas Walter
> 
> -- 
> Thomas Walter
> Datenverarbeitungszentrale
> 
> FH Münster
> - University of Applied Sciences -
> Corrensstr. 25, Raum B 112
> 48149 Münster
> 
> Tel: +49 251 83 64 908
> Fax: +49 251 83 64 910
> www.fh-muenster.de/dvz/
> 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Mary via mailop]

To be honest, I am just plain lucky in that respect. Because I have a senior 
position that allows me to enforce a few things like:

1) I teach a representative from the organization, who will go ahead and train 
users, about proper use of email, best practices, so on and so forth.

2) One of those "best practices", is to tell everyone to use a separate 
yahoo/gmail/whatever account for registering to mailing lists and other types 
of non-serious, non-business correspondence.

3) Teach them to use disposable email addresses (like 
https://www.guerrillamail.com/).

So the real business email account stays squeaky clean and I don't have to 
worry about whatever garbage mail was blocked or not.

Sure, postfix has significant logging and monitoring, in case something 
happens, at which point we do damage control and take evasive action by using 
the BOFH excuse board:

http://bofh.bjash.com/ExcuseBoard.html

:D


On 6 Dec 2020 13:42:47 -0500 John Levine via mailop  wrote:

> Don't your users complain about all of the mail they're missing? The
> false positive rate if you block on soft SPF fails is gigantic.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Alan Hodgson via mailop]

On Sun, 2020-12-06 at 14:12 +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?

SPF is most useful as a fallback mechanism for DMARC. DKIM checks fail at
least occasionally for various reasons. You should have an accurate ~all SPF
record to allow the majority of those to pass using SPF. Assuming your ESP
allows you to use an aligned envelope sender domain, of course.

I don't think SPF alone has even been useful for blocking. You can't control
who forwards mail to you or which of your recipients forwards their mail
elsewhere.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Thomas Walter via mailop]

On 06.12.20 19:27, Mary via mailop wrote:
> Now, having a large list of real email bodies, they re-use them for phishing. 
> They re-send a previously legitimate email but with variations, like 
> replacing attachments.

They can also send mail directly from the inside - without any SPF
checks in place and quite often without any antispam or antivirus
measures as long as the email stays on the inside? And use the correct
user's address?

At least that's what happened here in one incident.

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[John Levine via mailop]

In article  you write:
>On Sun 06/Dec/2020 16:32:13 +0100 Mary via mailop wrote:
>> (but I don't agree with point 2. by Paul, I aggressively block SPF fails, 
>> even soft errors. If a company doesn't fix their SPF records
>then I reject all their mail)

Don't your users complain about all of the mail they're missing? The
false positive rate if you block on soft SPF fails is gigantic.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Mary via mailop]

(long read, take a coffee with you...)

I've been monitoring two very sophisticated groups that mostly target banks 
around Europe. Their operation starts by finding real people working at the 
targeted banks, next step is to give them a call and ask for their business 
email address. Their goal, is to eventually take over their PC and get access 
to their email client (via some kind of PDF infected with javascript, or other 
type of email attachment that exploits some kind of vulnerability).

Apparently they are quite adept at getting information from people via social 
engineering, they will tell them various excuses that they sent emails that 
didn't go through and ask information about the employee's email client (they 
need this kind of information to prepare their injection exploit).

Once they manage to run a remote access tool of some kind, they use that system 
to download entire bodies of email (not just addresses). Usually, they avoid 
reusing that system and keep it for future use.

Now, having a large list of real email bodies, they re-use them for phishing. 
They re-send a previously legitimate email but with variations, like replacing 
attachments.

Without SPF, the From address makes the fake email pretty legitimate, no matter 
what the body is all about. With SPF, these phishing groups, got a serious dent 
in their operations (well, except when some admins don't use SPF, maybe they 
also don't use masks during a COVID pandemic...)

Anyway, at this point these phishing groups had to improvise, they started 
using hacked accounts with modifications to the From name, for example:

"John Surname at SecureBank p...@securebank.com" 

The idea above, is to make the "name" part (between the double quotes) as long 
as possible, so that the real domain name (hacked.domain.cc) scrolls to the end 
and "disappears" by the email client, because there is not enough screen space 
to display the whole thing. A normal person will fall for that technique.

SPF isn't perfect, of course it does not help block spam. The large amounts of 
spam I see from gmail.com can't be blocked by SPF...

I'd appreciate your comments and your experience with similar incidents.



On Sun, 6 Dec 2020 09:18:37 -0800 Dave Crocker via mailop  
wrote:

> On 12/6/2020 7:32 AM, Mary via mailop wrote:
> > 5. SPF provides a serious block to phishing attacks.  
> 
> Given the nature of phishing and, especially, its reliance on the 
> message body, rather than on header fields in the message -- nevermind 
> the SMTP return address -- it would be interesting to hear the basis for 
> you assessment.
> 
> d/
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Alessandro Vesely via mailop]

On Sun 06/Dec/2020 16:32:13 +0100 Mary via mailop wrote:

(but I don't agree with point 2. by Paul, I aggressively block SPF fails, even 
soft errors. If a company doesn't fix their SPF records then I reject all their 
mail)



Me too, except if the forwarder is in DNSWL.


Best
Ale
--









___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Dave Crocker via mailop]

On 12/6/2020 7:32 AM, Mary via mailop wrote:

5. SPF provides a serious block to phishing attacks.


Given the nature of phishing and, especially, its reliance on the 
message body, rather than on header fields in the message -- nevermind 
the SMTP return address -- it would be interesting to hear the basis for 
you assessment.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Jaroslaw Rafa via mailop]

Dnia  6.12.2020 o godz. 14:12:25 Hans-Martin Mosner via mailop pisze:
> night, what I've found is not a single spam mail was held due to SPF fail or 
> softfail results, but I learnt of several
> forwarding hosts in use by our users that I was unaware of before, probably 
> because they do good inbound spam rejection
> themselves.

Because if you look at the very idea of SPF, it is not to protect from spam.
It is not possible to protect from spam by indicating which IPs are allowed
to send mail for a given domain, as spam is about the *contents* of the
message, and not about where it is sent from.
SPF is to protect from *impersonation*, ie. someone sending mail from a fake
address belonging to another domain. In times when it was quite difficult to
register a domain, the spammers actually often used fake sender addresses,
thus a side effect of SPF could be some protection from spam. But in no way
can SPF protect from spammers who register their own domains, which can be
done now in easy and automated way.

Of course SPF breaks forwarding and therefore is a bad idea, but I don't
want now to go further on this topic.

> So, there are much more false positives and false negatives than I'm
> willing to accept. But obviously others have different experiences,
> otherwise they would not publish SPF records and check them on mail
> reception.

In my opinion they publish SPF records mostly because Google (and other
"big guys") require them to. You can have trouble with your mail being
properly delivered to Gmail if you don't publish a SPF record. That's the
reason why for example I published a SPF record for my domain after many,
many years of staying away from SPF. But I don't SPF check *incoming* mail
nor plan to (well, actually, SpamAssassin - which I use - does some SPF
checks by default, so I can say that in fact *to some extent* I do SPF
checks on incoming mails - but only to increase a little their spam score
and not reject them outright).

> 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 opinion the only SPF record you should care about is a record that
contains "-all" as the *only* item, ie. it indicates that this domain will
never send any mail. Thus you can safely reject all mails claiming to be
from this domain. There are *some* domains that publish such SPF records,
but there is a small number of them, so I personally don't bother.

For all other SPF records, I would say: just ignore them and use whatever
criteria you used already for spam filtering. SPF won't improve the quality
of your spam filtering.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Mary via mailop]

4. The more widespread SPF becomes, the more work spammers need to do. Small 
spam operations tend to go out of business rather quickly. The very 
"professional" ones all use proper SPF records.

5. SPF provides a serious block to phishing attacks.


(but I don't agree with point 2. by Paul, I aggressively block SPF fails, even 
soft errors. If a company doesn't fix their SPF records then I reject all their 
mail)


On Sun, 6 Dec 2020 14:03:44 + Paul Waring via mailop  
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?  
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Paul Waring via mailop]

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
https://list.mailop.org/listinfo/mailop