I got an e-mail from someone currently attending the Internet Governance Forum (IGF) meeting in Geneva. The e-mail ended up in my spam folder because the IP address used for the wireless LAN at the meeting is on a spambot/virusbot blacklist, namely cbl.abuseat.org. Apparently some guy there has his computer infected by a spambot or a virusbot. Because the local host uses a NAT, all the computers share the same public IP address. This means that all the attendees to the meeting risk seeing their e-mails blacklisted somewhere.
Funny this comes from the very people who would like to set up strategies to fight cybercrime…
Lesson to be learned:
One: NATs are a nuisance. They are responsible for collateral damage.
Two: In a hostile networking environment, never ever trust the local network and fire up your ssh or IPsec tunnel to a machine you can trust.
Three: give us IPv6 as soon as possible to get rid of NATs
By Patrick Vande Walle, All around Internet governance troublemaker. Visit the blog maintained by Patrick Vande Walle here.
Related topics: Internet Governance, Security, Spam
To post comments, please login or create an account.
Top-Level DomainsSponsored byMinds + Machines | |
DNSSponsored byNeustar UltraDNS | |
IPv6Sponsored byNominum | |
MobileSponsored bydotMobi | |
DNS SecuritySponsored byAfilias | |
SecuritySponsored byVerisign |
One should not send outbound SMTP directly from their host. That is how spam-bots work, not how real people should be doing email. Actually people who are running "Open Wireless" networks and similar systems should be blocking TCP port 25 outbound with a nice "Administrative Reject ICMP".
RFC2476 defines a great mechanism called "Message Submission", this is SMTP, but over port 587, and defines that the SMTP server requires authentication.
As this port is open almost everywhere (at least I never had an issue), one can use that port perfectly fine. As it requires authentication, there is no way (unless the spam bot figures out your user/pass ;) to send mail outbound which is not supposed to go there (it thus is not an open relays). This way you don't have to change your configuration and can use it anywhere you go. The MTA one then uses which provides the Submission service, is generally well-connected, is not blacklisted and might even by whitelisted.
Especially for people participating in standardization and thus who have to travel a lot around the world, this is a great setup to have.
I thus don't see any problem at all that an open access point is in the CBL, that is where it belongs, because it clearly allows people to just send anything outbound.
Configure your MUA correctly and there is no problem at all.
The issue here is not port 587 vs 25. Even through the submission port, the e-mail will have one "Received" header indicating the IP address of the host it is originating from. If there is a NAT it will look like
Received: from [10.18.42.205] (unknown [217.169.133.248])This will trigger the spam filtering software on the receiving end into checking the address on blacklists and assign a score based on that. Hence my suggestion to use a tunnel.
In the meantime, this UN IP address made it to Spamcop, in addition to CBL.
Then that spam filtering software is bogus.
First of all blacklists should only be used for scoring, next to that, those headers should _NEVER_ be trusted.
Lastly, people should use their outbound mailer over submission.
I've never had an issue with any of this btw and I am mailing from all around with the setup $laptop -> $someconnectivity -> $mailbox -> $world which works like a charm.
Blocking outright rather than scoring on carefully chosen blocklists is a good idea
Doing that on other than the connecting IP isnt the brightest of ideas.
I do hope thats what you meant, rather than "use dnsbls only for scoring, never block outright based on them".
No I meant it exactly how I meant it:
- check IP against BL, if it is in there assign it a white-score or a black-score
- do all your other tests, add it to the score
- if score > X then reject the mail
(of course reject during the DATA phase of SMTP so one doesn't have to handle bounces… ;)
That is how every SpamAssassin setup does it afaik. They don't reject a message because it is in one single blacklist. One blacklist might be 'trusted' enough that it scores already more than X though…
Jeroen, I think you are absolutely correct here. Too many installations of anti-spam software do look in all received headers for bad IP addresses. That was what created problems for me at the IGF meeting. I had correctly authenticated with my SMTP server at home, use port 587 and various other correct tricks.
But, because my clients IP address was in some blacklists, it was blocked here and there. Including blocked by the Swedish Regulator, PTS.
Patrik
In this particular case, it was Spamassassin which assigned the bad score, based on the fact that the IGF IP address was originally on 2 blacklists (cbl.abuseat.org and uribl.swinog.ch) and other behaviour patterns. So, it is not just scoring on one blacklist, but actually two plus other factors.
I think it is fair to check all received headers. The receiving MTA has no way to find out if the sending MTA does a correct job in identifying spam or if the original sender was using port 587 in the first place. And even that is absolutely no guarantee the message is not spam. In short, you should not trust any system along the path and do you own checks.
Of course, what is to happen when an IP address (as in this case) end up on a black list is up to the local policy of the receiver. You seem to have it assign "enough" points in spamassassin so that it end up being classified as spam. Other cases completely block the mail (here is an actual example from the week of the IGF):
Note that they are completely blocking the message.
I must admit I do not have any DKIM signature, SPF record or similar on my sender domain. I will add that now and see if that make things better. Because I definitely think that if the message is coming from a reliable source you as a receiver must trust that source of doing the right thing.
But at the end of the day, this is up to you as a receiver.
The solution for this problem, if you are using postfix but other MTA's might have similar functionality:
Have postfix with PCRE support, then add to main.cf something like:
header_checks = pcre:/etc/postfix/headers.pcre
And in the headers.pcre something like that:
/^Received:.*\(192.168.19.*authenticated by MYUSER/ IGNORE
Etc, thus making a PCRE for the lines that you want to have ignored. One can also opt to REPLACE lines. That should do the trick. Nasty effect is that this happens for inbound and outbound mail. Thus one has to be a bit careful when using this.
Best solution around all of that again, to avoid the 'NAT IP' to be visible at all, is to just use a VPN home or to some other trusted network. In my case these tend to be the very sweet AYIYA tunnels which work almost everywhere, lets see how well that works at Internetdagarna ;)
If a recipient is blacklisting that aggressively (on all Received headers, not just the immediate SMTP client IP), don't expect the shift to IPv6 to save you. In fact, there is plenty of scope for things to get worse. There are so many more addresses available under IPv6 that blacklisting individual addresses may become impractical. Even now it's a relatively common practice to blacklist an aggregate range of network addresses when there are several spam sources in the range. Spammers understand that they are blocked on the basis of IP address, and therefore make a point of being as dynamic as possible with their source address — one reason why botnets are so popular for spamming. IPv6 is likely to make this easier for them.
In IPv6 blocking/listing will happen on the /48 level, then /40 and then /32 to get rid of the whole ISP. /48 is the new /24 ;)
If someone is over aggressive enough to scan all headers for cbld IPs and then reject such emails wholesale .. (I might score such email a bit, but wouldnt reject outright) then thats not the cbl's fault. Kids playing with matches comes to mind..