A few days ago our IT teams got a support ticket from an employee, who sent an email and it bounced. The explanation for the reject states: “This message has been blocked because it is from a FortiGuard – AntiSpam black IP address”. Naturally it was quite a surprise for us.
A quick check with mxtoolbox showed that we are listed in a SPAM blacklist called “The Spam and Open Relay Blocking System” or SORBS. SORBS provides lists of IP addresses that are known for (or suspected as) disseminating all kind of bad stuff. SORBS has several lists, one of them is a SPAM list where we appeared. Fortunately SORBS allows to open an account with them to see information about the listing. A report on our IP address showed that it was blocked due to 1 message that was considered SPAM.
When explaining how one gets listed, SORBS states “If you are listed in the ‘spammers’ database, it is because you […] sent unsolicited bulk […] email to one of the administrators of SORBS or any of the spam traps SORBS operates.”. It seems that inclusion in the list is automatic and uses spamtraps. Initially it seemed somebody in the company sent an unsolicited email to an email address that was monitored. We went on to speculate who that might be. I used the data that is provided in the SORBS account to identify the email message that caused this. SORBS provides you some parts of the MessageId and that allowed our IT team to find the email. To my surprise it was an “Undeliverable” email from our postmaster to some random looking email address (e*n@*x.se).
Some pondering about what happened brings me to this conclusion: the spamtrap address emailed us a spam email message to an invalid company mailbox. Our company server tried to help and responded with an “Undeliverable” email message. The spamtrap operator then flagged our server IP as a spammer. Of course, we are quite certain that the original spam sender was not really the legitimate user of the email address (SORBS operator). It is quite common for spammers to use random spoofed addresses as the “from” field of SPAM messages. In fact, this seems like a very smart thing to do if you consider the difficulty it imposes on SPAM blacklist operators.
What I don’t understand is why no anti-spoof measures were used by the spamtrap operator. SPF and DKIM are two long-existing methods used to protect a domain from malicious senders, who want to spoof organizations’ addresses. Interestingly, the domain used in this case (*x.se) didn’t have an SPF record and it is not possible to verify whether the original senders (IPs in the far east) were legitimate senders authorized by the domain owner.
I am not sure what we should do given what was discovered. Penalties that SORBS impose increase exponentially every time such an event occurs. This was the first time for us, so getting unlisted was quick, however, how should we go about preventing such cases from repeating? For now we decided to cancel “Non-delivery reports” in our mail server. However, this can happen with auto-responders as well. First, I think there is room for blacklist operators, such as SORBS, to provide better differentiation between real SPAM and false positives. Second, there needs to be more use of anti-spoofing measures. And finally, list operators who allow paid removal need to be taken out of circulation as it creates a conflict of interest in the world of SPAM detection. If you have other suggestions, please send them in the comments.