Fwd: [mailop] SORBS Closing.

2024-06-05 Thread Frido Otten

A little heads-up from the MailOp mailinglist.

So is there anything that needs to be done to prevent false positives 
happening right after the shutdown?




 Doorgestuurd bericht 
Onderwerp:  [mailop] SORBS Closing.
Datum:  Wed, 05 Jun 2024 10:36:58 +1000
Van:Michelle Sullivan via mailop 
Antwoord-naar:  Michelle Sullivan 
Aan:mailop 



For those that haven't heard.  Proofpoint is retiring SORBS effective 
immediately(ish).


Zones will be emptied shortly and within a few weeks the SORBS domain 
will be parked on dedicated "decommissioning" servers.


I am being made redundant as part of the shutdown and my last day will 
be 30th June 2024.  I will be looking for new positions following that.


I would like to thank all the SORBS supporters over the years and 
Proofpoint for keeping it going for the community for the last 13 years.


Best regards,

Michelle Sullivan
SORBS.

--
Michelle Sullivan
http://www.mhix.org/

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



OpenPGP_0xCCDCFB22C59E9DD2.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Re: How to report SPAM?

2024-05-29 Thread Frido Otten
They do if you're offering mail service to a large number of users. They 
login to a phished mailbox, send new phishingmails to that mailbox and 
check the headers if they can see which rules are hit. Then they adapt 
the phishingmail to get a lower score until they are below the spam 
threshold. That's why I am writing my own rules with very generic names 
and description.


Op 27-05-2024 om 23:10 schreef Thomas Barth via users:
What can I do? With these SPAMS, I have the impression that the 
senders know exactly how to trick Spamassassin.


OpenPGP_0xCCDCFB22C59E9DD2.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


FROM header obfuscation

2022-02-08 Thread Frido Otten

Hi All,

Recently we're seeing more spam passing our spamfilters using text 
obfuscating in the FROM header. The problem mainly targets users which 
are using mail clients like iPhone Mail which are only displaying the 
display name of the FROM header and not the actual email address which 
was used, bypassing DKIM measures. For example:


From: =?UTF-8?B?0KBvc3RubC5ubCDQoGFra2V0?= 

This is base64 encoded "Рostnl.nl Рakket" and pretends to come from 
Postnl, a dutch snailmail company. However the hexadecimal 
representation of this base64 decoded text differs from that of normal 
ASCII:


Obfuscated:

$ printf "Рostnl.nl Рakket" | od -A n -t x1
 d0 a0 6f 73 74 6e 6c 2e 6e 6c 20 d0 a0 61 6b 6b
 65 74

Plain ASCII:

$ printf "Postnl.nl Pakket" | od -A n -t x1
 50 6f 73 74 6e 6c 2e 6e 6c 20 50 61 6b 6b 65 74

There is no way to tell the difference with the naked eye. You can 
obfuscate text using this online tool: https://obfuscator.uo1.net/


Is there any way to detect this type of obfuscation with a spamassassin 
rule?


Best regards,
Frido Otten



Rule to detect mailsploit

2017-12-06 Thread Frido Otten
Hi all,

Yesterday I saw this message that a bug in mailclients allow sender
spoofing which bypasses SPF/DKIM/DMARC mechanisms. Maybe you've read
about it. More information about it here: https://www.mailsploit.com/index

I was thinking that there might be a possiblity to detect this in
spamassassin to protect our users against this. Something with the
newline character or null byte in the FROM header, but I'm not that
handy with it. Someone of you maybe already created a rule?

--
Frido



signature.asc
Description: OpenPGP digital signature


Rule to detect mailsploit

2017-12-06 Thread Frido Otten
Hi all,

Yesterday I saw this message that a bug in mailclients allow sender
spoofing which bypasses SPF/DKIM/DMARC mechanisms. Maybe you've read
about it. More information about it here: https://www.mailsploit.com/index

I was thinking that there might be a possiblity to detect this in
spamassassin to protect our users against this. Something with the
newline character or null byte in the FROM header, but I'm not that
handy with it. Someone of you maybe already created a rule?

--
Frido