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.
In SORBS blacklist
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.
Spamtrap fail
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.
Interesting.
I wonder how corporations handle such behaviors.
I had a similar issue with SORBS. I wasn’t able to put 2 and 2 together but I see now that the sender faking the From email will cause this.
Not sure how it could be setup, but maybe your auto-responder can validate the SPF before sending a reply to the From email account.
Many of these anti-spam groups get it right a lot of times but when it catches the innocent, it can be some time before we realize why customers are not getting their emailed receipts and other transnational emails from us.
IMO, you can block (at your firewall or sendmail server) the mail hosted ip of the domain *x.se of Sorbs will completely block sending mails to them.
Even you could notify you/admin personally will help identify further mail sending domains and usability to such sorbs network.
Hope this help you to retain your functionalities without breakage.
Meanwhile could you please share the complete domain or mail hosted domain or IP of this Trap domain, for my study reference.
Hi Gopi, based on my understanding Sorbs has hundreds if not thousands of domains and addresses, with people “contributing” email addresses on their domains for the project. With that in mind it makes no sense to block any specific addresses or domains that are identified as a SPAM traps. With regards to sharing the original address, I have not published or kept the details so not to hurt the anti-SPAM efforts. Sorry.
Hi Arik, I can understand it is difficult to block the entire network of SORBS. But what is the solution for such manual mistakes ?
Could you please clarify your statement //people “contributing” email addresses on their domains for the project//
People are contributing their DOMAIN or EMAIL addresses of their own ? If they are Email Address(es), how does SORBS fetching and taking necessary steps/measures to treat the mails as SPAM ?
I believe, every SPAM-TRAP addresses/domain through errors if they reached connections from the source at first.
Could you please through some lights on this ?
Hi Gopi,
Unfortunately there is no easy solution. It is up to the different lists to generate their lists properly. In the end you can send a request to get delisted and it is some relief.
Regarding my note about people contributing traps. What some anti-spam services are doing (and I don’t remember if SORBS are doing exactly that) is they accept email redirects from people who want to help fight spam. So, for example I will setup a secret email address called xyzyam@yavilevich.com and redirect it to some email that a block list provider will give me. I might feature this email address on some non public webpage to let spammers collect it. Then any spam generated will reach the block list without them having to register domains and while using legitimate domains. It is just more robust. The block list on the other hand, should take measures to cross validate any reports that come from external sources like this. So, for example, if several separate sources report an IP as problematic it will be considered bad with higher priority.
It is complex, but any simple solution would be easier to circumvent, for example by creating a counter-list.
Hi Arik,
Then definitely this is the nice move. None of them can find the source of SPAM TRAP, if email addresses of valid organisation used to relay/report the spam to the concern antispam system. Just curious, how do you approach SORBS to know the email towhom you would forward the spam mail ? Any references or link, do you have for this ?
Hope you meant that the mentioned domain *x.se also followed the same approach on this ? that is, the email address (not the entire domain *x.se) alone used as SPAM TRAP?
But i heard that some out-dated email addresses of major ESPs are harvested/used for this by SORBS. Not sure.
However creating a counter-list with the email address instead IP/DOMAIN, will be more complicated. Practically it is beyond the imagination.
Hi Gopi,
Unfortunately I am not sure if I have seen this method used with SORBS or some other provider. I don’t have additional information about that. I recall that the email address that was relevant in my case looked totally random, but as I have mentioned, I didn’t keep the full value to say for sure.
>Our company server tried to help and responded with an “Undeliverable” email message.
There’s the problem. Your server was entirely at fault here. You should be checking for valid users at the SMTP level and refuse to accept it if it is invalid. Once you have accepted the email you should never send back email errors. Look up “backscatter” for a full explanation.
Hey,
You are absolutely correct. Thanks for referring me to the term for this, “backscatter”. As I have originally cited, the sender’s domain had no SPF record. In such a scenario, you can’t score the email for SPF, so it passed. As Mike mentioned previously in the comments, it is preferable if your mail server can be configured to only send NDRs to 100% confirmed senders. In our case (back in 2014), our mail software didn’t offer such an option, so we have decided to disable NDRs completely. Perhaps today different options are available.
sorbs is extorion and mxtoolbox is a enabler.
i just started putting in random made up ip addrsses
and every one comes up as blacklisted by SORBS and Spamhaus zen.
DH, there’s a reason for that. Your ‘random’ IP addresses will probably have not PTR records and belong to address spaces that are already listed on the policy block list because no email should be coming from them.
Most email professionals have limited toleration for SORBS and their wacky listing policies. They come from a time when previous owner Micheal (now Michelle) Sullivan had some very odd ideas about extorting money from companies for delisitings. I think his/her goals were always to sell the list and Trend Micro bought it meaning it appears by default in some of their gateway products.
It’s a rubbish blocklist. However, Spamhaus are on the money. If an IP comes back listed, it’s listed for a good reason.
According to Wiki, the current owner of SORBS is Proofpoint, Inc. in CA. They cause my ISP to block my POP ports, so I can’t access them through an email client. ISP is Spectrum and their customer support is outsourced and useless. No way to get somebody in charge and educated on the phone, in order to make them drop this BS list. I can’t even get an new dyn IP on demand.
Only temporary way to get out of this mess is by changing the Mac address in my router and restarting the modem. This finally pulls a new IP from the ISP.
Maybe its time for a lawsuit since this is hindering me in running my own company. And authorities need to look into the extortion claim in AU.