Score:1

Rspamd : Blacklists not working consistently

cn flag

RSPAMD 3.5.2

Using the multimap module I am rejecting certain email addresses via a blacklist:

multimap.conf

blacklisted_addresses {
    description = "Blacklisted addresses";
    type = "from";
    prefilter = true;
    filter = "email";
    map = "/${LOCAL_CONFDIR}/local.d/blocked_addresses.map";
    action = "reject";
    symbol = "BLACKLISTED_ADDRESS";
    regexp = "false";
}

In blocked_addresses.map I have a list of email addresses, one per line.

I put my own email address in there to test and this worked without any issue. I can see the blacklist working and I got a rejected email back from the mail server:

Error:

554 5.7.1 Matched map: BLACKLISTED_ADDRESS

However, other email addresses are able to get through. Here is one example where I'm trying to reject marketing emails from Amazon.

[email protected]

Can someone please explain this behaviour? How can I debug this further?

Score:2
in flag

The from map type matches the envelope from and not the From: message Header (when both are present).

Fairly typical is that mailing list messages use uniquely generated SMTP envelope addresses to effectively handle bounces and delivery errors.

Then the "envelope from" probably looks something like from=<[email protected]> rather than the [email protected] address found in the message header.


Just like snail mail letters, SMTP email has two different sets of address information:

  • the envelope headers (like the addresses printed on the outside of an envelope, which is read and used by the Post Office to deliver the message to your mailbox) which are used by the SMTP servers to route and deliver the email. These correspond to the RCPT TO: and MAIL FROM: command words used in the SMTP transaction.

  • the "normal" headers, which are part of the mail message and which are only read and interpreted by the user in his mail client/webmail. These resemble the address attached to a salutation at the start of the physical letter found inside the envelope and similarly have no function in getting the message delivered correctly.
    These come as part of the DATA in the SMTP transaction.

  • the addresses in these two different headers can differ.

Historically there is no one standard on how MTA's store envelope data in messages, if at all. Therefor mail clients only display the normal headers.

Usually you need to take a look at "all headers", the "raw message" , "message source/properties" or similar to see if the MTA records the MAIL FROM: and RCPT TO: in some way.

You may see a Return-Path: <sender-address> Received: ... for <rcpt-address> or X-Original-To: <rcpt-address> or something else entirely. Alternatively the MTA will often store envelope headers used in the delivery log files.


You probably need to test but the "header" map and filtering on the From: header might work better for you:

blacklisted_addresses {
    description = "Blacklisted addresses";
    type = "header";
    header = "From"; 
    filter = "email";
...
Aditya K avatar
cn flag
Thank you that makes a lot of sense, and further testing seems to confirm your answer. Do you think I could use map type "header" instead of "from" and just specify the header as "From"?
HBruijn avatar
in flag
You probably need to test but something like `type = "header";` `header = "From";` and `filter = "email";` or `filter = "email:addr";` might indeed work better for you.
Aditya K avatar
cn flag
Thanks! Worked perfectly!
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.