Having recently migrated to Zoho, I was surprised to see a much greater amount of spam accumulating in my spam folder than at my former e-mail provider. Upon some testing, I realised that Zoho delivers all the spam it detects to the spam folder, while the other provider silently dropped the most obnoxious and obvious part of it. I have two suggestions in connection with it, both having to do with sender analysis (not content analysis).
1. Let’s analyse an incoming SMTP session. Suppose bar.com is hosted at Zoho and is being spammed:
>>> HELO spam.biz
<<< 250 mx.zohomail.com Hello spam.biz (spam.spam.biz (10.9.8.7))
>>> MAIL From: <spammer@spam.biz>
<<< 250 Sender <spammer@spam.biz> OK
>>> RCPT To: <foo@bar.com>
At this point, mx.zohomail.com already knows the spammer’s IP and the destination mailbox. What I suggest to do here is to give the admin of bar.com an option (via control panel, in "Org settings") to abort delivery of messages coming to his mailboxes from known spammer IPs - that is, instead of
return<<< 250 Recipient < foo@bar.com> OK
(same as if the user hadn’t existed), and close the connection. The benefit is twofold: (1) no disk space wasted for spam storage; and (2) at least some spammers are known to delete e-mail addresses appearing to be invalid, so this may help decrease the spam exposure in the long term. This would work for RBL IP analysis. For header analysis, a similar trick can be done later in the session – responding “550 Requested action not taken” instead of “250 Message received” after the spammer has transmitted the message and the filter has identified spam symptoms in its headers. Importantly, as this is done during the SMTP session rather than after it, no backscatter is generated.<<< 550 Requested action not taken: mailbox unavailable
2. I was surprised to see that Zoho MX ignores SPF: even with a hardfail SPF status, the message is delivered. Such messages can also be dropped either unconditionally, or at mailbox owner’s option.