[Rspamd-Users] Handling of InterPlanetary File System (IPFS) abuse

[G.W. Haywood]

Hi there,

On Sun, 7 Aug 2022, Tobias Westerhever via Users wrote:

> if I may (ab)use this list to solicit a sentiment ...

It doesn't worry me. :)

> Blocking IPFS gateway FQDNs ... regular expressions that aim at IPFS
> CIDs ... patterns like "ipfs" in a URL ...
> ...
> ... don't have sufficiently diverse test corpse at hand

s/corpse/corpus/;  (At least I hope so... :)

> How do you handle this? By simply blocking IPFS gateway FQDNs, and
> maybe some abused open redirectors such as googleweblight[.]com?

All of the above, plus...

> ... something more mature ...

1. We use over a dozen DNSBLs and concoct a 'BS' value.  It's a simple
weighted total which eliminates the vast majority of troublesome mail.
Anything with any score is at least greylisted, anything with a modest
score is TEMPFAILed indefinitely, and anything with a high score is not
only TEMPFAILed but also handed to our automated reporting system.  In
effect this creates a positive feedback loop. :)

2. We have a large number of spamtrap addresses which we have built up
over many years.  Even a very modest greylisting interval will usually
ensure that spamtrap addresses are hit before similar spam to genuine
addresses is considered for delivery.  Fortunately one fairly reliable
characteristic of spammers is that they don't seem to take any trouble
at all to clean their lists.  Obviously when a spammer sends mail to a
spamtrap address, we don't tell them that they've done that. :)

3. Messages are fingerprinted[*].  Fingerprints of unwanted messages,
such as to spamtrap addresses, score highly.  Messages sent to genuine
addresses but having highly-scored fingerprints are treated as suspect.
Although this is only needed for the few percent of messages which are
not effectively handled by earlier processing, and this is very much a
work in progress here at the moment, the results are very encouraging;
no phishing message has yet managed to sneak past these defences.  The
processing can use quite a lot of resources but the volume of (wanted)
mail here is small.  We make something of the order a hundred thousand
automated malicious and spam message reports per year.  The interface
between the manager and the reporting system is browser-based, and two
browser bugs have resulted in a total of three false reports this year
(which personally I find irrationally irritating), but apart from that
there have been no other false reports since the system went live just
over eighteen months ago.

[*] A somewhat modified https://github.com/ssdeep-project/ssdeep

-- 

73,
Ged.