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

[Grant Taylor via mailop]

On 12/8/20 11:04 AM, Jesse Thompson via mailop wrote:
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.


Dislike of one thing (showing the friendly from) is not support for 
another thing (munging / removing the friendly from).


I am almost always against having an MTA modify a message, save for 
adding headers.


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.


I can't agree with that.  I feel like adding an "[EXTERNAL]" or 
"[Mailing list]" tag serves a different purpose than altering / hiding 
the friendly from.


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.


I agree that stripping the friendly from can be subtle.  But it still 
breaks some things like client side DKIM.  I feel like it's bad form.




--
Grant. . . .
unix || die



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

Re: [mailop] [FEEDBACK] Azure Spammer Activity

[John Levine via mailop]

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

That is a real list.  I looked at its archives and see that it is active and
not full of spam so in this case it's a red herring.

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

Re: [mailop] scam prevention

[Tim Bray via mailop]

On 08/12/2020 21:35, Ángel via mailop wrote:

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.


pretty much like Jason said.

email `please give me your mobile number, its urgent`.    Message via 
whatsapp, also with the senders name set.


And then email a list of the voucher codes back.

I'm on a conference call, too busy, please can you go to Tescos 
(supermaket) and buy some vouchers.


They used their own money.

If they had even told their co-worker they were going out of the office, 
then they would have stopped it. 2 people fell for the same scam, 
they sit in the same office about 4m away from each other with nobody in 
between.   If they had even mentioned to each other ..


As a company, we never ask anybody to spend personal money, so bizarre 
they fell for it.


One of the reasons they said thought it was genuine was because our 
actual real bank keeps blocking company debit cards for fraud checks on 
genuine transactions.  So once every 2 weeks somebody will ask somebody 
else to use their company card to buy something for them.  These staff 
too junior to have their own cards.



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

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