QWeb Ric
Basic Pleskian
TITLE:
Spam filtering stops working when mail forwarding is enabled
PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:Plesk Onyx 17.8.11 Update #24, CentOS 6.10. Postfix + Courier mail servers
PROBLEM DESCRIPTION:One of our clients often requests that we forward his emails to a colleague while he's out of office, and has noticed a pattern in that whenever this forward is enabled, the amount of spam mail he receives increases considerably.
His account remains a physical inbox when we enable forwarding, but I'm wondering whether the forwarding itself is somehow voiding the incoming mail filter settings. We only use incoming filtering, not outgoing, so perhaps the forward tricks something into thinking the mail is outgoing and then no checks occur, despite it still being dropped into a physical inbox?
STEPS TO REPRODUCE:His account remains a physical inbox when we enable forwarding, but I'm wondering whether the forwarding itself is somehow voiding the incoming mail filter settings. We only use incoming filtering, not outgoing, so perhaps the forward tricks something into thinking the mail is outgoing and then no checks occur, despite it still being dropped into a physical inbox?
I'm not completely certain which steps are needed to reproduce, but this is our own configuration:
- Enable server-wide SMTP authentication
- Enable server-wide Plesk Antivirus
- Enable server-wide DKIM authentication on incoming mail
- Enable server-wide SPF protection on incoming mail
- Enable server-wide DNS blackhole protection ( we're using b.barracudacentral.org )
- We also have a server-wide blacklist of currently close to 3,000 domains
- Create two inboxes within the same domain.
- Enable incoming spam filtering on both. For this particular client we have this set to delete all spam, with a sensitivity of 4 (very sensitive I know!)
- Enable incoming antivirus protection on both.
- We also have some custom SpamAssassin rules in place, though presumably not relevant.
- Then enable forwarding on one of these inboxes, setting the destination to be the second inbox address
ACTUAL RESULT:- Enable server-wide SMTP authentication
- Enable server-wide Plesk Antivirus
- Enable server-wide DKIM authentication on incoming mail
- Enable server-wide SPF protection on incoming mail
- Enable server-wide DNS blackhole protection ( we're using b.barracudacentral.org )
- We also have a server-wide blacklist of currently close to 3,000 domains
- Create two inboxes within the same domain.
- Enable incoming spam filtering on both. For this particular client we have this set to delete all spam, with a sensitivity of 4 (very sensitive I know!)
- Enable incoming antivirus protection on both.
- We also have some custom SpamAssassin rules in place, though presumably not relevant.
- Then enable forwarding on one of these inboxes, setting the destination to be the second inbox address
As far as we can tell, without enabling forwarding, most junk mail is filtered out and deleted by inbox A. But with forwarding enabled on inbox A, lots of junk mail makes it into inbox A despite being properly filtered by inbox B after the forward.
EXPECTED RESULT:Junk filtering on inbox A should still occur when inbox A is forwarding email to inbox B.
ANY ADDITIONAL INFORMATION:This is really difficult to test properly given it's a client that's reported this to us, our servers are production stage, and incoming junk is unpredictable, but they've always received significant amounts of spam hence the low sensitivity on their inboxes, and I absolutely trust that if they're seeing more spam while forwarding is enabled this isn't just a paranoid claim. We enable forwarding on this account probably once a week on average so I don't feel that the pattern is coincidental.
Also - I'm setting my expectation to "confirm bug" as I'd mostly just like to know that this is a real issue, but any help in resolving if it isn't would be much appreciated.
YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:Also - I'm setting my expectation to "confirm bug" as I'd mostly just like to know that this is a real issue, but any help in resolving if it isn't would be much appreciated.
Confirm bug