[Rspamd-Users] Rejecting TLDs

[Achim Lammerts]

I have a completely different experience, but this is also due to the 
fact that all users of the system I maintain, for example, do not expect 
e-mails from Russia.
For a while my server was bombarded with the same email (phishing) 
almost every minute to all available addresses until I blocked it via 
smtpd_client_restrictions even before rspamd. All these emails came from 
hosts with a .ru domain or another TLD, which was just cheap to book – 
either used for FROM or hostname. And what was *always* 
spam/phishing/malware what came from there. Mostly with large images in 
the mail, which put extra strain on the bandwidth and produced a lot of 
traffic. Not a single one of these mails was wanted.

Another example of bulk:
A user books a newsletter, but ends up with his address in dozens of 
other mailing lists and is permanently bombarded with new advertising 
that he has not booked at all. This also all comes from one address 
range (e.g. ASN 12676) and is already blocked before rspamd.

At least 99% of unsolicited emails on my MTA have no SPF record and at 
best a DMARC record with "p=none; sp=none;". The remaining 1% come from 
hijacked MTAs or outdated webmailers.

I have had very good experience with reducing the score (and 
whitelisting for known senders/hosts) for validatable SPF/DKIM/DMARC 
records; there are no false positives in this respect. And very less 
false negatives that passes rspamd.

Regards
Achim


Am 04.05.23 um 09:08 schrieb Daniel, Sebastian:
> Please distinguish between spam and bulk.
> 
> 60% of our spam messages get stuck at certain "helo" restrictions.
> The remaining 35% of spam clients only try to relay or don't even make it past our first spam trap which only checks for blacklists @spamhaus. The remaining 5% then actually visit rspamd and get stuck there at "factory settings".
> 
> The thing that causes trouble and also keeps rspamd and the admin busy are bulk emails.
> In most cases the users have subscribed to these themselves (unknowingly) and are then annoyed by the advertising. Instead of pressing the "unsubscribe" button, the mail admin is threatened with trouble.
> The admin then goes along and simply blocks everything to have his own peace.
> That this leads to the fact that valid emails hang and at the end perhaps important orders are lost (only because the client has @domain.net as TLD). But that doesn't matter, because the SPAM statistics are finally "green".
> 
> In the end, persistent clients and own users will switch to a freemail address to be able to communicate with each other.
> Very good work, mail admin! *irony
> 
> Correct would be to sensitize the users to unsubscribe bulk emails and even as admin to rather go by the principle "better one bulk email too many than to be unreachable for valid communication".
> 
>> This view seems wildly optimistic to me.
>>
>> We run a pretty small operation here, handling only our own mail.
>>
>> We log pretty much everything.  Just now I ran a query against our database
>> asking for messages in the past year which were detected as spam but which
>> were flagged as passing our (strict) SPF checks.
>>
>> Just over 50,000 passed, of 130,000 total spam, so about 40 percent of the
>> spam we saw in the past year passed our strict SPF tests.
>>
>> SPF is about forgery, not about spam.  Yes a lot of spam is forged, but - at
>> least of the spam we see here - almost half of it isn't.
>