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

[Tobias Westerhever]

Hi,

thanks for your mail, and apologies for my belated response.

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

True, indeed. No living being was harmed in any way. :-)

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

Lowering the greylisting threshold (currently at 2.0, down from default 4.0)
does appear to have a noticeable positive effect over here indeed.

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

Also true, but I continue to struggle to get rspamd properly recognizing that
certain addresses are actually spamtraps, and should accept any messages.
Although my spamtrap module configuration is pretty straightforward (

enabled = true;
map = "file:///etc/rspamd/local.d/maps/spamtrap.map";
score = 4.0;
learn_spam = true;
learn_fuzzy = true;
fuzzy_flag = 12;

), that never seemed to work reliably, but did not fail reproducible either.

As soon as there is some more time (you know its August when half of your
team is on vacation, and the other half is on sick leave with COVID-19 :-/ ),
I will try to dig more deeply into this, and also submit a patch for some
IPFS URL heuristics. Perhaps that provides some benefit to the broader rspamd
userbase.

Best,
Tobias


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