Home / Blogs

IGF Meeting Blacklisted

Patrick Vande Walle

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
Follow CircleID on
SHARE THIS POST

If you are pressed for time ...

... this is for you. More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Vinton Cerf, Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Share your comments

One should not send outbound SMTP directly jeroen  –  Sep 18, 2008 7:00 AM PST

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 are the e-mail headers Patrick Vande Walle  –  Sep 18, 2008 10:36 AM PST

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 jeroen  –  Sep 19, 2008 12:50 AM PST

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.

Lets not generalize shall we? Suresh Ramasubramanian  –  Sep 19, 2008 12:55 AM PST

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 jeroen  –  Sep 19, 2008 1:01 AM PST

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…

Bad spam software Patrik Fältström  –  Sep 21, 2008 7:17 AM PST

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 Patrick Vande Walle  –  Sep 21, 2008 9:23 AM PST

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.

Well, I do not really agree with you here... Patrik Fältström  –  Sep 21, 2008 9:55 AM PST

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):

<NNNNNN.MMMMMMM@pts.se>: host mail2.pts.se[192.121.211.220] said: 550
  5.7.1 This system has been configured to reject your mail. An IP address
  (217.169.133.248) found in the message's 'Received:' headers is listed by
  the lookup site 'sbl-xbl.spamhaus.org.'.  (in reply to end of DATA command)

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 jeroen  –  Sep 22, 2008 12:07 AM PST

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 ;)

IPv6 won't save you The Famous Brett Watson  –  Sep 18, 2008 2:33 PM PST

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 jeroen  –  Sep 19, 2008 12:51 AM PST

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 ;)

CBL is meant to be used on the connecting IP (that actually connects to you) Suresh Ramasubramanian  –  Sep 18, 2008 10:23 PM PST

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..

To post comments, please login or create an account.

Related

Topics

Whois

Sponsored byWhoisXML API

New TLDs

Sponsored byAfilias

Cybercrime

Sponsored byThreat Intelligence Platform

Domain Names

Sponsored byVerisign

Cybersecurity

Sponsored byVerisign

DNS Security

Sponsored byAfilias

IP Addressing

Sponsored byAvenue4 LLC

Brand Protection

Sponsored byAppDetex