SpamAssassin Rule for some Catch-all users in my domain

[girish]

@dsp76 Just going to debug this but I think I know the problem. catch all addresses (like aliases) are not real mailboxes and thus are not processed by Spam Assassin. The address is translated before being sent for SA processing. see comment below

[fbartels]

I also like using catch-all addresses to direct the incoming flow of emails and have some addresses that get a good amount of spam (because they were in a data leak). The workaround I found for myself is the following:

• create a mailbox dev-null@my-domain.com
• through curl I have set a mailbox quota of 1kb (through the ui the smallest size is 500mb)
• when I want one address to no longer be received I am assigning this as an alias to my dev-null mailbox

Now whenever something is sent to one of these aliases the sender gets a "permanent delivery error". The only downside is that for the bounce message the "real address" of the mailbox is shown and not the alias that was used for sending.

[girish]

@dsp76 So, for me, your rule works just fine. I created a catch all. And then added rule below for sales@ and support@ . We send the To address as-is to SpamAssassin and in fact it's that way in the end email as well.

It ends up in junk as expected:

[girish]

@fbartels would a discard rule work better for your set up? In sieve, you can just drop that email altogether and sender also gets no bounce. The screenshot below is from roundcube.

You can also "Discard with message" but this exposes the translated email address though.

[girish]

@fbartels said in Custom SpamAssassin Rule for some Catch-all users in my domain:

The only downside is that for the bounce message the "real address" of the mailbox is shown and not the alias that was used for sending.

Right... mmm.. The mail comes from dovecot and dovecot has no idea about aliases. This information gets lost in the email delivery flow

[fbartels]

@girish said in Custom SpamAssassin Rule for some Catch-all users in my domain:

would a discard rule work better for your set up?

Yes, that was what I have been using before. But that still makes the mta first accept the mail, my goal was to produce a bounce message for the sender in the hope that at some point they realise it does not exist anymore.

If you want to claim to have never received something it is better to reject than to silently delete.

[dsp76]

@girish looks like the rule is now for me working too. May have to do with a restart of the server / service? Also probably missed one user name or two initially

[dsp76]

Having said that, a bit later it stopped working, @girish - could it be, that with maybe regularly rebuilding the spam rules, the custom ones get forgotten? I still have the rule set up, checked its syntax several times (also with help of KI ;)) ... but it's not adding that custom rule right now.

(I can still verify it was working yesterday afternoon, as the type of spam had the correct rule added to X-SPAM-STATUS - while later not anymore.)

Solution in the initial post.

[dsp76]

I added the solution in my initial post. Turns out, that with the custom rule, one would need to consider the many different ways of how an email address is build up, as it takes the whole string and applies your rules. So that why it worked sometimes (like when it was written as "user@example.com", but had no match with ""user example" user@example.com").

[necrevistonnezr]

Depending on your use case it might be worthwhile checking if just a simple "wildcard alias" (instead of catch-all) is sufficient (as described in the docs).
See an example here: https://forum.cloudron.io/post/74184

[dsp76]

Hi @necrevistonnezr ... right, that is also a good approach. I just didn't want to setup the alias before I start using it. I deactivate reactively now. Seems to work pretty good right now.

[necrevistonnezr]

Sorry, I forgot in my last Reply: i’ve seen many companies checking for catch-all addresses, possibly flagging you as spam or of low reputation.
https://forum.cloudron.io/post/74173

[dsp76]

Thanks - that sounds interesting. Didn't know that - but this is a reason to rethink my approach.