I've tried contacting AirNZ about this to no avail so the rest of you might appreciate knowing: For ages now I've not been able to send email via one particular email provider from the Koru lounge in Wgtn and I finally bothered to find out why. It seems the IP address 162.112.38.5 of koruout.airnz.co.nz has been added to XBL by Spamhaus and one of my email providers uses that to reject connections. It probably got blocked because an infected PC connected to the Koru wireless network and sent out spam to a Spamhaus trap, which of course sees the IP address of the NAT/proxy and so blocks that. It gets worse for AirNZ because the WHOIS record for this IP address gives a non-existent email address in the notify field and so any notification from Spamhaus that they have been blocked will have bounced. *sigh* Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
On 25/06/2010, at 10:03 PM, Jay Daley wrote:
I've tried contacting AirNZ about this to no avail so the rest of you might appreciate knowing:
For ages now I've not been able to send email via one particular email provider from the Koru lounge in Wgtn and I finally bothered to find out why. It seems the IP address 162.112.38.5 of koruout.airnz.co.nz has been added to XBL by Spamhaus and one of my email providers uses that to reject connections.
It probably got blocked because an infected PC connected to the Koru wireless network and sent out spam to a Spamhaus trap, which of course sees the IP address of the NAT/proxy and so blocks that.
It gets worse for AirNZ because the WHOIS record for this IP address gives a non-existent email address in the notify field and so any notification from Spamhaus that they have been blocked will have bounced.
*sigh*
Of course, you should probably not be using port 25 for submission, or if your mail provider has RBLs running on their submission port then something isn't quite right. Also, surely RBLs should be consulted to decide whether to accept mail from an unauthenticated client, as opposed to you, who is presumably an authenticated client. Not saying that AirNZ are doing it right, just saying that your mail provider could likely be doing it better :-) Though, to be honest, I'd be surprised if a more or less public connection like that isn't listed in the XBL, given the number of random hosts that must come through it spewing out garbage. Being able to rely on your end-user Internet connection not being in a popular RBL is a thing of the past I think. -- Nathan Ward
On Fri, 2010-06-25 at 22:47 +1200, Nathan Ward wrote:
Of course, you should probably not be using port 25 for submission, or if your mail provider has RBLs running on their submission port then something isn't quite right. Also, surely RBLs should be consulted to decide whether to accept mail from an unauthenticated client, as opposed to you, who is presumably an authenticated client.
Yes.. if you are authenticated then really they shouldn't be looking at any RBL for rejection. A lot of public access points will block 25 to stop this type of thing happening (Stopping Infected Machines) and still allow port 587 (the smtp submission port which IMHO people should be using with SMTP Authentication).
Not saying that AirNZ are doing it right, just saying that your mail provider could likely be doing it better :-) Though, to be honest, I'd be surprised if a more or less public connection like that isn't listed in the XBL, given the number of random hosts that must come through it spewing out garbage.
I wish more ISP's would list their Entire Dynamic Dialup and Dynamic DSL Ranges on the Spamhaus PBL with non removal and their Static IP Ranges on the PBL with Self Removal) and then alot less spam would come in from these ranges. (not that much target spam comes from NZ IP Addreses, just botted machines) Alot of providers are doing it . for example http://www.spamhaus.org/pbl/query/PBL238719 Which is listed on the PBL with self removal but some of it is dyanmic (looking at the RDNS so i could be wrong) so maybe it could be split into parts to be listed in the PBL still but some able to be removed and some not being able to be removed.
On 25/06/2010, at 12:47 PM, Nathan Ward wrote:
Of course, you should probably not be using port 25 for submission, or if your mail provider has RBLs running on their submission port then something isn't quite right.
In this case it was 587, authenticated over SSL. See below as to why the RBLs.
Also, surely RBLs should be consulted to decide whether to accept mail from an unauthenticated client, as opposed to you, who is presumably an authenticated client.
Not sure I agree. Infected + authorised is a deadly combination if you assume the authorisation always confers legitimacy. That would mean that a compromised host can send with impunity one it authorises. It seems quite sensible for an email provider to protect their systems from being abused by the compromised PCs of customers.
Not saying that AirNZ are doing it right, just saying that your mail provider could likely be doing it better :-) Though, to be honest, I'd be surprised if a more or less public connection like that isn't listed in the XBL, given the number of random hosts that must come through it spewing out garbage. Being able to rely on your end-user Internet connection not being in a popular RBL is a thing of the past I think.
If the public connection is not actively managed, including receiving and responding to notifications then yes I imagine it will quickly be listed. But if someone there is paying attention then they should be able to pick on any listing and sort it out. I've done that many times in the past and it is not complicated. cheers Jay -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
On 2010-06-25, at 08:07, Jay Daley wrote:
On 25/06/2010, at 12:47 PM, Nathan Ward wrote:
Of course, you should probably not be using port 25 for submission, or if your mail provider has RBLs running on their submission port then something isn't quite right.
In this case it was 587, authenticated over SSL. See below as to why the RBLs.
Also, surely RBLs should be consulted to decide whether to accept mail from an unauthenticated client, as opposed to you, who is presumably an authenticated client.
Not sure I agree. Infected + authorised is a deadly combination if you assume the authorisation always confers legitimacy. That would mean that a compromised host can send with impunity one it authorises.
I don't think anybody sane would argue that giving your users free reign to send spam (intentionally or otherwise) is a good idea. At the very least, this is a self-correcting problem since any mail relay that acted that way would soon find it difficult to relay mail to any other system. My impression from those who spend much of their time with this stuff is that the right thing is to authenticate your users and check each outbound message against a useful set of heuristics to avoid spam being relayed by your servers. "The client address is in a blacklist" by itself does not sound like a useful set of heuristics, to me (as you have discovered). Whilst it might be expedient to refuse connections from anonymous people in the Internet based on something as crude as "client address is in a blacklist", in the case of an authenticated user it seems far better to let them connect and deal with any apparent infection they have (drop mail, proactive phone call, whatever fits the budget) than it does to refuse to talk to them. The latter is almost guaranteed to cost you money in your helpdesk budget.
If the public connection is not actively managed, including receiving and responding to notifications then yes I imagine it will quickly be listed. But if someone there is paying attention then they should be able to pick on any listing and sort it out. I've done that many times in the past and it is not complicated.
Cleaning up public hotspots as spam sources sounds very much like whack-a-mole, even more so in a place where it's near guaranteed that the spam sources will have left the country by the time you try to follow up :-) Joe
On 25/06/2010, at 4:05 PM, Joe Abley wrote:
My impression from those who spend much of their time with this stuff is that the right thing is to authenticate your users and check each outbound message against a useful set of heuristics to avoid spam being relayed by your servers. "The client address is in a blacklist" by itself does not sound like a useful set of heuristics, to me (as you have discovered).
Whilst it might be expedient to refuse connections from anonymous people in the Internet based on something as crude as "client address is in a blacklist", in the case of an authenticated user it seems far better to let them connect and deal with any apparent infection they have (drop mail, proactive phone call, whatever fits the budget) than it does to refuse to talk to them. The latter is almost guaranteed to cost you money in your helpdesk budget.
That's the very reason that many people do it - to get the phone call so they can educate the customer, protect their service and reputation and generally make the Internet a better place. Money is not the major motivation for most who take this war seriously.
If the public connection is not actively managed, including receiving and responding to notifications then yes I imagine it will quickly be listed. But if someone there is paying attention then they should be able to pick on any listing and sort it out. I've done that many times in the past and it is not complicated.
Cleaning up public hotspots as spam sources sounds very much like whack-a-mole, even more so in a place where it's near guaranteed that the spam sources will have left the country by the time you try to follow up :-)
It's not the spam sources that you follow up but the RBLs - educate them as to your network and business and they treat you better. Network operators cannot ignore what happens on their network and the effects of that traffic. best Jay PS I'm pretty sure we've spent a week in the same conference centre on the wrong side of the world and I never bumped into you once! -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
On 26/06/2010, at 6:34 AM, Jay Daley wrote:
On 25/06/2010, at 4:05 PM, Joe Abley wrote:
My impression from those who spend much of their time with this stuff is that the right thing is to authenticate your users and check each outbound message against a useful set of heuristics to avoid spam being relayed by your servers. "The client address is in a blacklist" by itself does not sound like a useful set of heuristics, to me (as you have discovered).
Whilst it might be expedient to refuse connections from anonymous people in the Internet based on something as crude as "client address is in a blacklist", in the case of an authenticated user it seems far better to let them connect and deal with any apparent infection they have (drop mail, proactive phone call, whatever fits the budget) than it does to refuse to talk to them. The latter is almost guaranteed to cost you money in your helpdesk budget.
That's the very reason that many people do it - to get the phone call so they can educate the customer, protect their service and reputation and generally make the Internet a better place. Money is not the major motivation for most who take this war seriously.
Educating a customer of any ISP, be it an ADSL provider or a hotspot provider, that their IP address is in the spamhaus XBL likely isn't very helpful, especially when it's a public hotspot (where they can't actually fix the root cause) as opposed to say a home (where they can). Can an end user de-list themselves from the XBL, or does their ISP have to do it for them? -- Nathan Ward
On 26/06/2010, at 3:51 PM, Nathan Ward wrote:
Educating a customer of any ISP, be it an ADSL provider or a hotspot provider, that their IP address is in the spamhaus XBL likely isn't very helpful, especially when it's a public hotspot (where they can't actually fix the root cause) as opposed to say a home (where they can). Can an end user de-list themselves from the XBL, or does their ISP have to do it for them?
This is all getting a bit confused with three separate things being mixed together: - public hotspots nearly all use private address space behind a NAT that aggregates all the clients behind a single IP, so what gets blocked is the NAT device IP and then by extension every hotspot user, but individual users are not getting blocked. In this case the hotspot provider should be paying attention to the RBLs (or at least accepting notifications) so that they can protect the reputation of their NAT device and the service available through the hotspot. If they do not do this then over time their hotspot service will degrade and it will cost them. There is nothing they can realistically do about their users being infected. - the education bit is often done by ISPs who find it easier to use an RBL to block and await the call than to try and contact the user themselves. Obviously not all ISPs see the business sense in this and some do not even care about infected customers. - then there are service providers (now called 'cloud' providers but when I were a lad ...) who are not ISPs, often have peripatetic customers and who wish to protect their infrastructure. For them is makes sense to use an RBL to protect their systems. Again the impact of them not doing this is increasing reputational damage. For example if my email provider that started this thread did not block and I was infected then their mail servers would soon be labelled as a regular source of spam and people would start to refuse connections from them, affecting all their customers. Not that sensible for a 'cloud' email provider. All these things are distinct and all quite rational. cheers Jay
-- Nathan Ward _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
On 25/06/2010, at 10:03 PM, Jay Daley wrote:
I've tried contacting AirNZ about this to no avail so the rest of you might appreciate knowing:
For ages now I've not been able to send email via one particular email provider from the Koru lounge in Wgtn
The best you can hope for at a wireless hotspot is an IP connection to the public Internet that can pass TCP port 80/443 some of the time. If you adjust your expectation to only seeing AirNZ as a hotspot provider rather than an ISP, the problem goes away. Two options to consider, both use your company mta to send mail for you: a) configure your mail server and client to use TLS/SSL b) Use OpenVPN over TCP 443 to a security gateway at your company I use b) and it works just fine for me everywhere. It does not however solve the obstacles that hotspot providers in NZ place in front of us, namely cost and stupid web portals that won't work with standard business tools like a Blackberry browser. regards Peter Mott Swizzle | Managed Private Clouds Tel. +64 21 279 4995 -/-
participants (5)
-
Craig Whitmore -
Jay Daley -
Joe Abley -
Nathan Ward -
Peter Mott