Didn't you check or am I missing something?
These are the current options users have to choose from in how spam is handled, as spam is defined by their user preferences:
1. Inbox it
2. Redirect to catch-all
3. Send to spam folder
4. Delete the spam
Where as the functionality me and
@flips are looking to see implemented would be more on par with how cPanel handles things that are absolutely defined as spam by the user preferences. I'll go over it a bit:
My cPanel account on ghost.mxroute.com has just added
[email protected] to user_prefs as a blacklisted item. The actual item written to the user_prefs file by the control panel is this:
Now I'm going to telnet to ghost.mxroute.com and attempt to deliver an email to
[email protected] while claiming to be sending from
[email protected]. While this violates SPF, that won't be relevant, the filter in the user_prefs is what will cause this event:
Code:
[root@gateway] ~ # telnet ghost.mxroute.com 25
Trying 138.201.205.224...
Connected to ghost.mxroute.com.
Escape character is '^]'.
220-ghost.mxroute.com ESMTP Exim 4.92 #2 Thu, 06 Feb 2020 19:11:21 +0000
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
HELO gateway.mxroute.com
250 ghost.mxroute.com Hello gateway.mxroute.com [104.251.123.3]
MAIL FROM: [email protected]
250 OK
RCPT TO: [email protected]
250 Accepted
data
354 Enter message, ending with "." on a line by itself
Subject: What's up?
Disregard this
.
550 "The mail server detected your message as spam and has prevented delivery."
quit
221 ghost.mxroute.com closing connection
Notice that ghost.mxroute.com did not deliver a bounce message to
[email protected] nor did it deliver or delete it after accepting it, but it directly rejected it at SMTP time sending a failure code to the sending server after it processed the entire content through SpamAssassin's rules, including the local user's individual rules. This is something I would like DirectAdmin to be able to do, but is not currently set up for such a scenario. DirectAdmin will take that blacklisted email and inbox it, redirect it to catch-all, deliver to the spam folder, or accept it and delete it. However, all of these options involve spammers counting the email account among those that work and accept their emails.
For many users this results in exponentially increased spam over time, for which all but the last option DA offers result in increased inode usage if not regularly cleaned, which becomes an increasingly difficult job due to the exponential increase over time. With the growth of DA users after the cPanel pricing fiasco, you'll see the increased inode usage creep up on all of the shared hosting providers with high tenancy per server in 3-5 years where they were able to curb it previously by stating a global SpamAssassin reject score in WHM and users were able to reject more email outright. Couple this with a significant number of catchall accounts on each server and the timeline may be even sooner.