Reject mail at SMTP level, address blocklist
-
I use email tagging (myemail+xyzfuturehackedwebsite@mydomain.com) and would like to be able to use the address blocklist feature to completely reject (all emails) to designated addresses at SMTP level, as opposed to having Cloudron flag them as spam and put them in the respective folder.
Years ago I used Mail-in-a-Box and this feature was built in and configurable via the command line. Used to make abandoning tagged addresses a breeze. They would be permanently banished from my mind.
I can't help but be honest that it triggers me when spam constantly shows up in my spam folder without my ability to nuke their attempts at even hitting my email server.
What do ya'll say? Can this be implemented easily in a future update please?
The only reference I found to the same was in this thread.
-
-
@xarp SpamAssassin doesn't reject email, it simply tags it with a weighting on how confident it is that it's spam instead of ham. So I don't believe SpamAssassin will do what you're wanting to achieve.
To reject email at the SMTP level, you need to use a DNSBL which is documented here (it essentially runs before SpamAssassin even sees the message but doesn't allow you to control which addresses are involved, only if it's a "true" then reject and if it's "false" then continue processing): https://docs.cloudron.io/email/#dnsbl
-
@d19dotca said in Reject mail at SMTP level, address blocklist:
To reject email at the SMTP level, you need to use a DNSBL which is documented here (it essentially runs before SpamAssassin even sees the message but doesn't allow you to control which addresses are involved, only if it's a "true" then reject and if it's "false" then continue processing): https://docs.cloudron.io/email/#dnsbl
Thanks for the reminder. I've added two extra blacklists to the default.
The primary feature request still stands though.Surely it can't be difficult to implement SMTP reject when the devs are able to get around to it.
-
@xarp What is the feature request you're needing though?
I interpreted it as you wanting to say "hey, deliver no spam to only this email address but allow some spam to other addresses (i.e. don't be so aggressive for some addresses but be more aggressive for others)", is that accurate though? The DNSBL rejects mail but system-wide, not at an address-specific level.
May need to clarify specifically what you want to achieve or how you expect your use-case to be implemented so it can be better addressed though.
-
@d19dotca To make it really simple:
I blacklist me+website@myemail.com
All email arriving that matches receiver address me+website@myemail.com is SMTP rejected.This is great for when websites or mailing lists get compromised and there is just an endless spam campaign on that address. I can ban the address at server level and now that address is forever blackholed.
I can go to the website in question, if I choose, and simply update my email address with a new tag, thus effectively generating a new non-spammed contact for which they hopefully won't get compromised again. If so, rinse repeat.
On Mail-in-a-Box, you'd just run a command on console with the block address parameter and address to block. Very easy. Forever SMTP rejected until removed again.
-
@xarp Ah okay, I see. Makes sense.
FYI - That's technically possible as a workaround currently but just not technically at the SMTP level itself, it will still need to make it in to the user's mailbox but you can essentially setup a rule to delete the message immediately so from a users perspective it's never seen / dropped. Here's an example filter/rule set I created for you as an example in case you wanted it:
# rule:[Drop email sent to plus address] if allof (header :contains "to" "user+plusaddress@example.com") { discard; }But yes, that could be a nice-to-have to control that inside of the Cloudron UI so that it can be controlled more from an admin perspective.
-
@d19dotca Since this hasn't received any traction, would you mind assisting with your SpamAssassin discard rule in context that would be acceptable via Cloudron? It seems the syntax isn't allowed.
Is there any way discard can be achieved using the single line approach that cloudron docs/examples illustrate? Thank you!
The workable examples given are:
header SUBJECT_HAS_DISCOUNT Subject =~ /\bdiscount\b/i score SUBJECT_HAS_DISCOUNT 100 describe SUBJECT_HAS_DISCOUNT I hate email discountsIf not, I can try going in and editing the config file directly, if it even exists. Thought I'd try here first given editing stuff directly isn't always the best idea with Cloudron. If it even manages to persist.
-
@xarp ah so what I provided earlier was to be added in a filter in Roundcube for example. The interface for server-side rules with regards to filters is done via webmail. What you did was try the code in the SpamAssassin rules but that isn’t the right spot.
You can do this in SpamAssassin too but it doesn’t reject it, it simply guarantees that it is thrown into the junk folder. The filter method from earlier would be the way to do it in a way that it doesn’t even get to junk mail folder either.
With SpamAssassin method though to always throw a message from someone into the junk folder in a way that is essentially guaranteed would look like this:
blacklist_from userIDontWantEmailFrom@example.com
-
@girish any input possible? Doesn't seem it would be too difficult to implement.
In addition to server rejecting "To" domains (e.g. me+taggedwebsite@mycloudron.com), same with "From" (e.g. spammerphisher@fakedomain.com) -
+1
I would very much like to see this implemented as well. There should be an option to disgard emails on the blocklist as if they match certain criteria and are therefore always considered SPAM, there would appear to be no reason why these should not be removed before they reach a user's mailbox. In my experience filtering at the mailbox level is unreliable as the mail will already have been processed by Spamassassin and placed in the SPAM folder, overriding the filter. -
@girish or @nebulon , any chance this will be implemented?
This is definitely needed since marking messages as spam is not sufficient when an address isn't in use anymore.
There are even reports of hosters suspending or blocking your account when receiving floods of spam (here for example)
