Recently noticed a huge number of messages in mail queue for a sitework domain with an email alias as the recipient; i.e. forwards to a 3rd party email address.
Looking at the message contents I see that all of the messages are SA subject line rewritten [SPAM], but this shouldn’t happen, messages above X score in sitework (3.0) are set to delete.
Obviously an email alias has no IMAP folder so I really need for the siteworx delete setting to actually delete the message and not rewrite the subject line, thus forwarding hundreds of messages with [SPAM] subject line to the 3rd party email target of the alias. Really we’re doing the spammer’s job by spamming the recipient, ridiculous.
Should note that I have SMTP level scanning enabled system wide (5.0 drop), not sure if the double scanning is causing an issue. At any rate something is broken.
Could you post a full view of one these emails, or at the very least the full header detail
It sounds likely given your other post, you maybe running an open mail relay perhaps, but this based on gut feeling until you post details which could help
Yeah, not running an open relay, might have been a single compromised email account (see my other thread) – changed password on affected account, we’ll see what affect that has.
As for the issue here, this is different, SA is not deleting messages above X score when the target is an email alias (i.e. not a “real” vpopmail account). Since posting this topic there’s a fresh batch of 100+ messages waiting in the queue that SA should have deleted (since all of the messages were flagged above 3.0 threshold).
Many thanks, and I’ll digest your other post later
One thought though, your alias is an open relay be definition ie alias do not require credentials to be accepted, and would immediately send out to third party server.
I understand what your saying over alias and SA though, so I’ll have to test it on one of our test servers
Have you lowered the correct setting, MTA score I think
Authentication isn’t required to send email to a nonaliased address either. SA filters in both cases, the only difference is that SA does not delete messages above X score (despite setting the delete threshold in siteworx for the affected domain), and is pointlessly sending boatloads of [SPAM] rewritten subject lined messages to the alias’ target.
Sorry, it is and I realise what your saying, but most alias are not on forwarder to another third party server, hence why it is your server been blacklisted, as it is your server sending the email to its final destination
Also, SA would not class the email as spam as your posted header shows it is not been detected as spam
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on OurMailServer
X-Spam-Level: *
X-Spam-Status: No, score=1.2 required=2.3
I hope that helps and I will test myself on our test server when I have chance
All of the messages in the mail queue pertaining to alias@domain.com have been flagged by SA as [SPAM]; that’s what this thread is about. An open relay is allowing users to authenticate and send unfiltered mail through a remote server. Simply sending mail (via your ISP for example) to alias@domain.com and non-alias@domain.com is not an open relay, particularly when the messages go through a spam filter en route – I believe that’s just called sending a message to a remote server
The header sample in the other thread is in regard to a potentially compromised non-alias account (i.e. a non-forwarding vpopmail account). Basically a different issue. We’ll see what affect changing the password has. I’m still not sure if that was a bouncing/backscatter issue, or if some spammer in fact gained access to the vpopmail account in question.
I bow down to your definition it must be old age catching up with me
SA is actually working, ie it is classifying the mail as spam
SA does not itself delete emails, it just classifies the mail
Qmail should delete the email I believe
Now, as this is a forwarder, it would be interesting to know if the forwarder were reset to an actual email account, does it delete the spam mail - I suspect it would
If my theory is correct, it means qmail is not acting on alias the same way as an actual mail account, which I’m thinking is correct, as email incoming would bypass the domain and sent straight out.
Now if this is correct, then I see 2 ways to overcome this logic as follows
Set a system wide config for qmail to delete mails marked as spam (not a good idea at all)
Set the forwarder as an actual email account, then set a copy to to forward the email (this should allow the email to be acted normally upon by qmail and be deleted)
I could be entirely wrong though, so I apologise in advance
Sorry, there is one more which has just come to mind
Your SA is set to class email with a score higher then 3, which then needs to be deleted.
What is the value you have set for /nodeworx, system services, mail server, spam filtering, SMTP spam score threshold
If higher then 3, then it is reliant upon the siteworx account SA spam score to lower, and hence why the post above may not work on forwarders perhaps.
Unfortunately, setting this particular value to low, could cause loss of email and not a very good idea, but just thought I’d mention it
Nodework level SMTP score is 5.0; siteworx delete score for affected account is 3.0. The messages should be deleted rather than having the subject line rewritten.
And yes, the setting is quite aggressive, but then again SA is easily fooled these days, so much spam gets through while valid emails wind up in the user’s IMAP spam folder o_O
Sigh, maybe give up and go with Google apps or similar extortion service. I remember when email used to cost next to nothing. $5/email/month is the norm these days, incredible.
Turns out that Interworx does not delete spam messages for email alias targets. In this sense email aliases are spam relays since spam is impossible to delete; at best you get the subject line rewritten to “[Spam] …”, which doesn’t buy you much credibility with 3rd party ISPs ;-(
Could set the threshold to 0.1, wouldn’t matter, the bash script only looks for vpopmail accounts, and drops according to spam score for these “real” accounts.
On my CentOS system the script is located at: /home/interworx/lib/maildrop/spamfilter
it must be old age catching up with me