Re: [mailop] [EXTERNAL] Re: scam prevention

[Michael Wise via mailop]

SPF checks IPs against the From: domain … which may fail for good reasons or 
bad, and in both ways.
If the criteria is too lax, bad actors can take advantage.

DKIM can also fail, since Bad Actors love to set up their domains with valid 
DKIM info.

DMARC puts it all together.

But ultimately, with the flagrant abuse of what we call the, “Friendly From” … 
ripping it out entirely does have a certain appeal, especially as it’s almost 
impossible on devices such as smartphones, to get at that actual information 
for validation in the first place.

The phone number metaphor is a better fit.
I set up this phone number in my contacts as belonging to my friend, “Joe 
Smith”, and presupposing the number isn’t forged, they get to ring my phone, 
and I know who it is just by looking at the caller-ID.

Friendly From is a False Friend.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Open a ticket for Hotmail ?

From: mailop  On Behalf Of Scott Mutter via mailop
Sent: Tuesday, December 8, 2020 9:27 AM
To: mailop@mailop.org
Subject: [EXTERNAL] Re: [mailop] scam prevention

Good idea or not, that's a debate.

But if it did happen - be ready for the chorus of... "But it used to show the 
person's name, why did it change?  Can you change it back?"

People don't respond well to change.  Even if it's for the betterment of 
humankind, that's not really comprehensible.

On Tue, Dec 8, 2020 at 6:13 AM Tim Bray via mailop 
mailto:mailop@mailop.org>> wrote:
Hi,

I'm wondering if it might be a good idea to strip all sender names from
emails coming into our corporate email system.   To avoid a false name
being used by a scammer.

So rewrite a header like

`From: Bob Smith mailto:b...@example.org>>` to  `From: 
b...@example.org`

Because the domain part is checked by SPF and DKIM.  The but name (Bob
Smith) is not.

Background:

Some people at work fell for a scam email  where the From line was

From: =?UTF-8?Q?Darren_Smith=C2=A0?= 
mailto:mablecri...@gmail.com>>

That's a  Darren_Smith with a non breaking space on the end.
mablecri...@gmail.com is the real scammer address.

Darren Smith  (not his real name) is the Managing director of their
employer.  And they just trusted the name, and didn't check the
domain.   To the more experienced members of staff it was so blatantly a
scam they just deleted it.  To the junior members, they rushed to the
shops for amazon and google vouchers thinking they were on a special
mission for the big boss. £1300 lost, some maybe recovered.

If I stripped the name, they would have seen 
mablecri...@gmail.com and
hopefully noticed sooner.

Thoughts or ideas?


--
Tim Bray
Huddersfield, GB

___
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] [FEEDBACK] Azure Spammer Activity

[Hans-Martin Mosner via mailop]

Yesterday and the day before we received such a massive wave from them that I 
had to temporarily block several Microsoft
IPv4 ranges...

Today we got a response to our abuse reports requesting that we report these to 
j...@office365.microsoft.com - I
would've thought that within one corporation, forwarding of abuse tickets 
should work somehow.

The spam mails had a header line of "List-Id: OAUTH WG " which 
may either be completely fake or an
indication of a mailing list hack.

Cheers,
Hans-Martin


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

Re: [mailop] scam prevention

[Jason Grant via mailop]

At the small company I work at we see this sort of attack frequently. 
Especially this time of year when the crooks dust off the ol’ “Busy 
boss here. Need’ya to buy me gift cards as client gifts” scam. Over 
the years, at least one employee has fallen for this, and another came 
close. During non-holiday periods we get occasional waves of 
“employees” mailing one another “invoices”, as though this would 
be a common practice(?)


Anyway, I just set up a list of key/long-tenured/frequently spoofed 
employee names along with common variants and quarantine anything 
purporting to come from them which originates from outside our 
organization. This takes a bit of white listing for those wayward 
employees who email themselves pictures and whatnot from personal 
accounts as a means of transferring files, but otherwise it’s not much 
work and reasonably effective.

___
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] scam prevention

[Ángel via mailop]

On 2020-12-08 at 12:13 +, Tim Bray wrote:
> If I stripped the name, they would have seen mablecri...@gmail.com
> and hopefully noticed sooner.
> 
> Thoughts or ideas?

You would still have most of them falling when, next time, they email
you from darrensm...@bossmail.com though. :-/

I would recommend directly filtering display names matching the names
from C-level management that don't come from inside the organization.
If they wanted to use their personal well, they shouldn't. And their
employees shouldn't trust commands coming from an email outside the
org, either.


That said, I am firmly in the camp of "MUA showing only the friendly
from considered harmful".


By the way, how did the "buy amazon and google vouchers" work? That is
a new one for me. I am used to CEO fraud wanting to transfer a big
amount from the company account, not having the employees buying (with
their own money?) amazon vouchers.


___
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] scam prevention

[Bill Cole via mailop]

On 8 Dec 2020, at 7:13, Tim Bray via mailop wrote:

Because the domain part is checked by SPF and DKIM.  The but name 
(Bob Smith) is not.


You're thinking too much of DMARC, which applies a concept of DKIM 
signature "alignment" between the From header domain and the d= element 
in a DKIM signature. Alignment relates to domains only, but the DKIM 
signature almost always include the full From header, verbatim (with 
strict canonicalization) or almost verbatim (with relaxed 
canonicalization.) For some inexplicable reason, the "relaxed" 
canonicalization was defined without doing the obviously correct thing 
for resiliency: reduce address list headers to a comma-delimited list of 
case-squashed email addresses without "display name" or "comment" 
elements of any sort.  As a result, stripping out those elements will 
break a DKIM signature.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] scam prevention

[Jesse Thompson via mailop]

On 12/8/20 11:26 AM, mailop@mailop.org wrote:
> But if it did happen - be ready for the chorus of... "But it used to show the 
> person's name, why did it change?  Can you change it back?"

That what I assumed too.  However, the complaints are extremely low for us (we 
do employ a nuanced approach to minimize the effect on more trustworthy mail 
flows).  We get more complaints about mailing list munging.

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

Re: [mailop] scam prevention

[Jesse Thompson via mailop]

On 12/8/20 10:41 AM, mailop@mailop.org wrote:
> On 12/8/20 5:13 AM, Tim Bray via mailop wrote:
> I *REALLY* dislike the idea.  I think it is fundamentally flawed, in a mostly 
> non-technical way.
...

> This one of the reasons why I hate the idea of not showing the full email 
> address in email clients.

I think your later statement suggests that you *almost* like the idea ;-) but 
would prefer the implementation to occur at the MUA level instead of 
manipulation by MTAs.

Most organizations are now hosted by providers who don't give that level of 
control over the MUA behavior and/or their users may be using alternative MUAs, 
but many still have upstream MTAs that can do the transformation (even if the 
mailbox provider doesn't directly support that type of transformation).


> *IF* I were to do something like this, I would purposely alter the name to be 
> something decidedly atypical in the headers and then rely on a company wide 
> address book to show the trusted name.  E.g. "Darren Smith" becomes "EXTERNAL 
> - Do NOT Trust - Darren Smith".  Then known correspondents, e.g. Tim Bray, 
> would have address book entries with display name set to "Tim Bray@".  With 
> the "@" (or some other indicator) used to make things look nicer in the email 
> client.  But even this has non-trivial drawbacks and can break a lot of 
> things.

Anecdotally (I don't have hard numbers), I think that conditionally 
stripping/munging the Friendly From is an effective alternative to doing things 
like adding [EXTERNAL] tags to Subjects and bodies - which are common 
strategies employed by enterprises.

Plus, simply stripping the Friendly From is so subtle that users hardly even 
notice - partially because it's mitigated by address book resolution.  The only 
team in our organization who bothered to inquire was from our CRM team who was 
using Friendly From to soft match on contacts.

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

Re: [mailop] scam prevention

[Bill Cole via mailop]

On 8 Dec 2020, at 7:32, Mary via mailop wrote:

A solid idea, but you would have to avoid modifications to DKIM signed 
emails that sign the From header field via the h= tag as specified by 
RFC6376 secton 5.4 and 5.4.1.


Or validate the signature and re-sign the message including that 
validation before doing modifications.


I recognize the issues with that. They also exist with the increasingly 
widespread addition of "[EXTERNAL]" tags in Subject headers. They also 
exist with default and/or widely-used Sendmail behaviors with both From 
and To headers. DKIM is inherently fragile.



On Tue, 8 Dec 2020 12:13:57 + Tim Bray via mailop 
 wrote:



Hi,

I'm wondering if it might be a good idea to strip all sender names 
from
emails coming into our corporate email system.   To avoid a false 
name

being used by a scammer.

So rewrite a header like

`From: Bob Smith ` to  `From: b...@example.org`

Because the domain part is checked by SPF and DKIM.  The but name 
(Bob

Smith) is not.

Background:

Some people at work fell for a scam email  where the From line was

From: =?UTF-8?Q?Darren_Smith=C2=A0?= 

That's a  Darren_Smith with a non breaking space on the end.
mablecri...@gmail.com is the real scammer address.

Darren Smith  (not his real name) is the Managing director of their
employer.  And they just trusted the name, and didn't check the
domain.   To the more experienced members of staff it was so 
blatantly a
scam they just deleted it.  To the junior members, they rushed to 
the

shops for amazon and google vouchers thinking they were on a special
mission for the big boss. £1300 lost, some maybe recovered.

If I stripped the name, they would have seen mablecri...@gmail.com 
and

hopefully noticed sooner.

Thoughts or ideas?



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] scam prevention

[Mary via mailop]

Here we go:

if !/^DKIM-Signature:/
/^From:.*<(.*)>/ REPLACE From: <${1}>
/^From:\s?(.*)(\s+\(.*)/ REPLACE From: <${1}>
endif


If its not a DKIM signed email, replace From addresses that match these formats:

From: Mr Fake 
From: em...@address.tld (Mr Fake)


I just run a quick test with postfix, header_checks runs quite early, so the 
modification happens before all milters/scanners/spamassassin/etc. I don't know 
if that is the right thing, maybe an alternative is to run it as 
milter_header_checks, I'm not sure.



On Tue, 8 Dec 2020 11:28:46 -0500 Phil Pennock via mailop  
wrote:

> On 2020-12-08 at 16:13 +0200, Mary via mailop wrote:
> > So in postfix you'd do something like this? (under header_checks)
> > 
> > /^From:.*<(.*)>/ REPLACE From: $1
> > 
> > I wrote that in my email client, so I don't expect my regex to work. I 
> > guess it would be fun to see how much damage I can do with something like 
> > that...  
> 
> Don't forget the "obsolete" form:
> 
>   From: f...@example.org (Foo Smith)
> 
> (because the spammers won't forget)
> -Phil
> ___
> 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

[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] scam prevention

[Scott Mutter via mailop]

Good idea or not, that's a debate.

But if it did happen - be ready for the chorus of... "But it used to show
the person's name, why did it change?  Can you change it back?"

People don't respond well to change.  Even if it's for the betterment of
humankind, that's not really comprehensible.

On Tue, Dec 8, 2020 at 6:13 AM Tim Bray via mailop 
wrote:

> Hi,
>
> I'm wondering if it might be a good idea to strip all sender names from
> emails coming into our corporate email system.   To avoid a false name
> being used by a scammer.
>
> So rewrite a header like
>
> `From: Bob Smith ` to  `From: b...@example.org`
>
> Because the domain part is checked by SPF and DKIM.  The but name (Bob
> Smith) is not.
>
> Background:
>
> Some people at work fell for a scam email  where the From line was
>
> From: =?UTF-8?Q?Darren_Smith=C2=A0?= 
>
> That's a  Darren_Smith with a non breaking space on the end.
> mablecri...@gmail.com is the real scammer address.
>
> Darren Smith  (not his real name) is the Managing director of their
> employer.  And they just trusted the name, and didn't check the
> domain.   To the more experienced members of staff it was so blatantly a
> scam they just deleted it.  To the junior members, they rushed to the
> shops for amazon and google vouchers thinking they were on a special
> mission for the big boss. £1300 lost, some maybe recovered.
>
> If I stripped the name, they would have seen mablecri...@gmail.com and
> hopefully noticed sooner.
>
> Thoughts or ideas?
>
>
> --
> Tim Bray
> Huddersfield, GB
>
> ___
> 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] scam prevention

[Anne P. Mitchell, Esq. via mailop]

> Background:
> 
> Some people at work fell for a scam email  where the From line was
> 
> From: =?UTF-8?Q?Darren_Smith=C2=A0?= 

We have been beating this drum for ages, most recently here:

https://www.theinternetpatrol.com/warning-having-email-display-senders-contact-image-and-info-helps-scammers-get-in-through-the-cracks/

..which implores businesses to get rid of the so-called 'friendly' name (the 
same thing you are talking about) and includes an example where a company was 
scammed out of $4million dollars with exactly this method - hopefully your 
company's losses were much less. :-(

Anne
--
Anne P. Mitchell,  Attorney at Law
CEO, SuretyMail Email Reputation Certification
Dean of Cyberlaw & Cybersecurity, Lincoln Law School
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Board of Directors, Denver Internet Exchange
Chair Emeritus, Asilomar Microcomputer Workshop
Former Counsel: Mail Abuse Prevention System (MAPS)

___
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] scam prevention

[Phil Pennock via mailop]

On 2020-12-08 at 16:13 +0200, Mary via mailop wrote:
> So in postfix you'd do something like this? (under header_checks)
> 
> /^From:.*<(.*)>/ REPLACE From: $1
> 
> I wrote that in my email client, so I don't expect my regex to work. I guess 
> it would be fun to see how much damage I can do with something like that...

Don't forget the "obsolete" form:

  From: f...@example.org (Foo Smith)

(because the spammers won't forget)
-Phil
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] scam prevention

[Grant Taylor via mailop]

On 12/8/20 5:13 AM, Tim Bray via mailop wrote:

Hi,


Hi,

I'm wondering if it might be a good idea to strip all sender names from 
emails coming into our corporate email system.   To avoid a false name 
being used by a scammer.


So rewrite a header like

`From: Bob Smith ` to  `From: b...@example.org`

Because the domain part is checked by SPF and DKIM.  The but name (Bob 
Smith) is not.


I *REALLY* dislike the idea.  I think it is fundamentally flawed, in a 
mostly non-technical way.


The idea that there is only one "Tim Bray" or "Grant Taylor" in the 
world seems ... silly to me.  Then there are the even more common names 
like "John Doe" / "Jane Doe".


So the idea that there is only one "Bob Smith" et al. is a flawed 
concept.  As is assigning any security or authenticity to the name.


If I stripped the name, they would have seen mablecri...@gmail.com and 
hopefully noticed sooner.


Thoughts or ideas?


This one of the reasons why I hate the idea of not showing the full 
email address in email clients.


To me, the idea of assigning any value to "Tim Bray" / "Grant Taylor" / 
"Darren Smith" is as ... silly ... as stating that websites that use 
HTTPS as opposed to HTTP are safe to visit.  Because no criminals will 
be named "Grant Taylor" or use HTTPS.


*IF* I were to do something like this, I would purposely alter the name 
to be something decidedly atypical in the headers and then rely on a 
company wide address book to show the trusted name.  E.g. "Darren Smith" 
becomes "EXTERNAL - Do NOT Trust - Darren Smith".  Then known 
correspondents, e.g. Tim Bray, would have address book entries with 
display name set to "Tim Bray@".  With the "@" (or some other indicator) 
used to make things look nicer in the email client.  But even this has 
non-trivial drawbacks and can break a lot of things.




--
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] scam prevention

[Mary via mailop]

So in postfix you'd do something like this? (under header_checks)

/^From:.*<(.*)>/ REPLACE From: $1

I wrote that in my email client, so I don't expect my regex to work. I guess it 
would be fun to see how much damage I can do with something like that...



On Tue, 8 Dec 2020 13:09:16 + Tim Bray via mailop  wrote:

> On 08/12/2020 12:32, Mary via mailop wrote:
> > A solid idea, but you would have to avoid modifications to DKIM signed 
> > emails that sign the From header field via the h= tag as specified by 
> > RFC6376 secton 5.4 and 5.4.1.  
> 
> They aren't going to go any further once they will come in.   So I don't 
> think any further DKIM checks will be done.
> 
> I'll DKIM check and then make the change before it drops into the mailbox.
> 
> -- 
> Tim Bray
> Huddersfield, GB
> t...@kooky.org
> 
> ___
> 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] scam prevention

[Stuart Henderson via mailop]

On 2020/12/08 13:09, Tim Bray via mailop wrote:
> On 08/12/2020 12:32, Mary via mailop wrote:
> > A solid idea, but you would have to avoid modifications to DKIM signed 
> > emails that sign the From header field via the h= tag as specified by 
> > RFC6376 secton 5.4 and 5.4.1.
> 
> They aren't going to go any further once they will come in.   So I don't
> think any further DKIM checks will be done.
> 
> I'll DKIM check and then make the change before it drops into the mailbox.
> 
> -- 
> Tim Bray
> Huddersfield, GB
> t...@kooky.org
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop

Not a bad idea at all. I have seen quite a few places that add [EXTERNAL]
or similar to subject lines for this too (you'll see some examples in posts
to this list).

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

Re: [mailop] scam prevention

[Tim Bray via mailop]

On 08/12/2020 12:32, Mary via mailop wrote:

A solid idea, but you would have to avoid modifications to DKIM signed emails 
that sign the From header field via the h= tag as specified by RFC6376 secton 
5.4 and 5.4.1.


They aren't going to go any further once they will come in.   So I don't 
think any further DKIM checks will be done.


I'll DKIM check and then make the change before it drops into the mailbox.

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

[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] scam prevention

[Mary via mailop]

A solid idea, but you would have to avoid modifications to DKIM signed emails 
that sign the From header field via the h= tag as specified by RFC6376 secton 
5.4 and 5.4.1.



On Tue, 8 Dec 2020 12:13:57 + Tim Bray via mailop  wrote:

> Hi,
> 
> I'm wondering if it might be a good idea to strip all sender names from 
> emails coming into our corporate email system.   To avoid a false name 
> being used by a scammer.
> 
> So rewrite a header like
> 
> `From: Bob Smith ` to  `From: b...@example.org`
> 
> Because the domain part is checked by SPF and DKIM.  The but name (Bob 
> Smith) is not.
> 
> Background:
> 
> Some people at work fell for a scam email  where the From line was
> 
> From: =?UTF-8?Q?Darren_Smith=C2=A0?= 
> 
> That's a  Darren_Smith with a non breaking space on the end. 
> mablecri...@gmail.com is the real scammer address.
> 
> Darren Smith  (not his real name) is the Managing director of their 
> employer.  And they just trusted the name, and didn't check the 
> domain.   To the more experienced members of staff it was so blatantly a 
> scam they just deleted it.  To the junior members, they rushed to the 
> shops for amazon and google vouchers thinking they were on a special 
> mission for the big boss. £1300 lost, some maybe recovered.
> 
> If I stripped the name, they would have seen mablecri...@gmail.com and 
> hopefully noticed sooner.
> 
> Thoughts or ideas?
> 
> 
> -- 
> Tim Bray
> Huddersfield, GB
> 
> ___
> 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

[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

[mailop] scam prevention

[Tim Bray via mailop]

Hi,

I'm wondering if it might be a good idea to strip all sender names from 
emails coming into our corporate email system.   To avoid a false name 
being used by a scammer.


So rewrite a header like

`From: Bob Smith ` to  `From: b...@example.org`

Because the domain part is checked by SPF and DKIM.  The but name (Bob 
Smith) is not.


Background:

Some people at work fell for a scam email  where the From line was

From: =?UTF-8?Q?Darren_Smith=C2=A0?= 

That's a  Darren_Smith with a non breaking space on the end. 
mablecri...@gmail.com is the real scammer address.


Darren Smith  (not his real name) is the Managing director of their 
employer.  And they just trusted the name, and didn't check the 
domain.   To the more experienced members of staff it was so blatantly a 
scam they just deleted it.  To the junior members, they rushed to the 
shops for amazon and google vouchers thinking they were on a special 
mission for the big boss. £1300 lost, some maybe recovered.


If I stripped the name, they would have seen mablecri...@gmail.com and 
hopefully noticed sooner.


Thoughts or ideas?


--
Tim Bray
Huddersfield, GB

___
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] [FEEDBACK] Azure Spammer Activity

[Philip Paeps via mailop]

On 2020-12-08 09:33:48 (+0800), Michael Peddemors via mailop wrote:
I know, I know.. most already are looking at Azure sourced email with 
suspicion, but kind of wanted to wait until others chimed in on this 
one..


[...]

Hundreds of Azure IP(s) used in this one.. MS, you need to spend a 
little more money on threats from 'within' your networks..


Interesting ... I thought Azure blocked outbound SMTP connections?  Has 
that changed?


Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises
___
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