if anyone from cox.net is reading... ----- The following addresses had permanent fatal errors ----- <abuse@cox.net> (reason: 552 5.2.0 F77u1Y00B2ccxfT0000000 Message Refused. A URL in the content of your message was found on...uribl.com. For resolution do not contact Cox Communications, contact the block list administrators.) This seems a rather unwise policy on behalf of cox.net -- their customers can originate scam emails, but cox.net abuse desk apparently does not care to hear about it.
On Tue, 20 Nov 2007 11:21:19 PST, goemon@anime.net said:
This seems a rather unwise policy on behalf of cox.net -- their customers can originate scam emails, but cox.net abuse desk apparently does not care to hear about it.
Seems to be perfectly wise if you're a business and care more about making money than getting all tangled up in pesky things like morals and ethics. It's great when you can help the balance sheet by converting "ongoing support costs" and "loss of paying customers" into what economists call "externalities" (in other words, they make the decisions, but somebody else gets to actually pay for the choices made).
Or it was a minor oversight and you're all pissing and moaning over nothing? That's a thought too. Valdis.Kletnieks@vt.edu wroteth on 11/20/2007 11:42 AM:
On Tue, 20 Nov 2007 11:21:19 PST, goemon@anime.net said:
This seems a rather unwise policy on behalf of cox.net -- their customers can originate scam emails, but cox.net abuse desk apparently does not care to hear about it.
Seems to be perfectly wise if you're a business and care more about making money than getting all tangled up in pesky things like morals and ethics. It's great when you can help the balance sheet by converting "ongoing support costs" and "loss of paying customers" into what economists call "externalities" (in other words, they make the decisions, but somebody else gets to actually pay for the choices made).
S. Ryan wrote:
Or it was a minor oversight and you're all pissing and moaning over nothing?
That's a thought too.
Well, if the oversight involves filtering the "should never be filtered" abuse@ address, it might be a bit more than minor. But they ought to have a chance to fix it before being labeled the scum of the earth, eh? -- Jeff Shultz
Or it was a minor oversight and you're all pissing and moaning over nothing?
That's a thought too.
Pretty much all of network operations is "pissing and moaning over nothing," if you wish to consider it such. Some of us actually care. In any case, I believe that I've found the Cox abuse folks to be pretty helpful and clueful in the past, but they may have some of the typical problems, such as having to forward mail for "abuse@" through a large e-mail platform that's designed for customers. I'm certainly not saying that it's all right to have this problem, but I would certainly encourage you to try sending along a brief note without any BL-listed URL's, to see if you can get a response that way. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Tue, 20 Nov 2007 Valdis.Kletnieks@vt.edu wrote:
On Tue, 20 Nov 2007 11:21:19 PST, goemon@anime.net said:
This seems a rather unwise policy on behalf of cox.net -- their customers can originate scam emails, but cox.net abuse desk apparently does not care to hear about it.
Seems to be perfectly wise if you're a business and care more about making money than getting all tangled up in pesky things like morals and ethics. It's great when you can help the balance sheet by converting "ongoing support costs" and "loss of paying customers" into what economists call "externalities" (in other words, they make the decisions, but somebody else gets to actually pay for the choices made). This is one of the threads where posting further will not be productive.
Cox abuse has been named and shamed, and hopefully, the next post we see to the thread will be from them. As a reminder, political discussions, and discussions about spam filtering (other than operational, such as abuse@ or noc@emails) are off-topic for nanog. Please keep it this way. -alex [mlc chair]
On Nov 20, 2007 3:11 PM, Alex Pilosov <alex@pilosoft.com> wrote:
On Tue, 20 Nov 2007 Valdis.Kletnieks@vt.edu wrote:
On Tue, 20 Nov 2007 11:21:19 PST, goemon@anime.net said:
This seems a rather unwise policy on behalf of cox.net -- their customers can originate scam emails, but cox.net abuse desk apparently does not care to hear about it.
Seems to be perfectly wise if you're a business and care more about making money than getting all tangled up in pesky things like morals and ethics. It's great when you can help the balance sheet by converting "ongoing support costs" and "loss of paying customers" into what economists call "externalities" (in other words, they make the decisions, but somebody else gets to actually pay for the choices made). This is one of the threads where posting further will not be productive.
Cox abuse has been named and shamed, and hopefully, the next post we see to the thread will be from them.
As a reminder, political discussions, and discussions about spam filtering (other than operational, such as abuse@ or noc@emails) are off-topic for nanog. Please keep it this way.
Actually, filtering techniques as applies to the operational aspect of a mailer, MX to MX, are fine. -M< (BTW: Next time please run this to the MLC beforehand. Our public policy says "consensus based" and public. You forgot the consensus part.)
On Nov 20, 2007 2:21 PM, <goemon@anime.net> wrote: [ snip ]
----- The following addresses had permanent fatal errors ----- <abuse@cox.net> (reason: 552 5.2.0 F77u1Y00B2ccxfT0000000 Message Refused. A URL in the content of your message was found on...uribl.com. For resolution do not contact Cox Communications, contact the block list administrators.)
This seems a rather unwise policy on behalf of cox.net -- their customers can originate scam emails, but cox.net abuse desk apparently does not care to hear about it.
I haven't had any issues between my network and cox related to mail operations lately. What URL? -M<
Heh better then my all time favorite was the "mailbox is full" reply from an abuse@ address for an ISP based in Nigeria who had a few servers trying to open umpteen fraud accounts :D -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of goemon@anime.net Sent: Tuesday, November 20, 2007 2:21 PM To: 'nanog@merit.edu' Subject: unwise filtering policy from cox.net if anyone from cox.net is reading... ----- The following addresses had permanent fatal errors ----- <abuse@cox.net> (reason: 552 5.2.0 F77u1Y00B2ccxfT0000000 Message Refused. A URL in the content of your message was found on...uribl.com. For resolution do not contact Cox Communications, contact the block list administrators.) This seems a rather unwise policy on behalf of cox.net -- their customers can originate scam emails, but cox.net abuse desk apparently does not care to hear about it.
On Tue, 20 Nov 2007 18:45:50 EST, "Raymond L. Corbin" said:
Heh better then my all time favorite was the "mailbox is full" reply from an abuse@ address for an ISP based in Nigeria who had a few servers trying to open umpteen fraud accounts :D
I've seen my share of 800-pound gorillas (we're talking the 10M+ customer range) who have bounced postmaster@ and/or abuse@ due to 'mailbox is full'. So it isn't just small ISPs in little corners of the world... My favorite was an abuse@ bounce from a smaller shop that read something like: 451 <abuse@smallshop.com> Mailbox Full of complaints, even though we nuked their butts 3 days ago. (I'm sure many readers of the list know *that* feeling - you found and fixed the problem before the first complaint arrives, but you still get deluged by more complaints for another week or so...)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 20, 2007, at 6:21 PM, Valdis.Kletnieks@vt.edu wrote:
(I'm sure many readers of the list know *that* feeling - you found and fixed the problem before the first complaint arrives, but you still get deluged by more complaints for another week or so...)
Or another 6 months from AOL ;-] Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~ A stupidity tax Hubris Communications Inc www.hubris.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iD8DBQFHQ4qaElUlCLUT2d0RAsjwAKDaurQh7y7hQq2MSs8vMQqSvk7zlgCgwETG +Xd6FcNqrBq1sYyrylWNtAc= =Lg9j -----END PGP SIGNATURE-----
(I'm sure many readers of the list know *that* feeling - you found and fixed the problem before the first complaint arrives, but you still get deluged by more complaints for another week or so...)
Or another 6 months from AOL ;-]
No... for AOL add 6 MORE months + three days <http://chuck.goolsbee.org/archives/478> --chuck
On Tue, 20 Nov 2007, goemon@anime.net wrote:
<abuse@cox.net> (reason: 552 5.2.0 F77u1Y00B2ccxfT0000000 Message Refused. A URL in the content of your message was found on...uribl.com. For resolution do not contact Cox Communications, contact the block list administrators.)
An unfortunate limitation of the SMTP protocol is it initially only looks at the right-hand side of an address when connecting to a server to send e-mail, and not the left-hand side. This means abuse@example.com first passes through the same server as all of the rest of *@example.com e-mail. A single high-volume or special address can easily overwhelm the normal email infrastructure (i.e. mailbox full) or the normal server administrators may make changes which affects all addresses passing through that server (i.e. block by IP address). Even the FTC's UCE uce@ftc.gov e-mailbox has had problems, which affected the rest of *@ftc.gov e-mail. So the FTC created a separate right-hand side name spam@uce.gov to separate UCE reports from normal FTC e-mail channels which lets them route the mail with separate mail handling policies based on the right-hand side.
On Wed, 21 Nov 2007, Sean Donelan wrote:
On Tue, 20 Nov 2007, goemon@anime.net wrote:
<abuse@cox.net> (reason: 552 5.2.0 F77u1Y00B2ccxfT0000000 Message Refused. A URL in the content of your message was found on...uribl.com. For resolution do not contact Cox Communications, contact the block list administrators.)
An unfortunate limitation of the SMTP protocol is it initially only looks at the right-hand side of an address when connecting to a server to send e-mail, and not the left-hand side.
full) or the normal server administrators may make changes which affects all addresses passing through that server (i.e. block by IP address).
I guess you're saying there's something architectural in email that makes it impossible/difficult (limitation) to apply different policy to the LHS. That's not correct though. The receiving MTA is quite free to apply differing policies to different LHSes. And at least one MTA allows you special-case measures applied to tables of addresses, such as whether DNSbl lookups should be applied. SMTP is distributed, so you do of course have to take care to keep distributed policy consistent. But, again, that has nowt to do with LHS/RHS of email addresses. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: A plumber is needed, the network drain is clogged
You're missing the point. xx@example.com is going to go to whatever MX example.com returns. Sean's point was that you can't cause, e.g., eg@example.com alone to go to a server other than the same set of servers listed for AnythingElse@example.com. If that (eg@example.com) overloads those servers, even if they're valiantly trying to pass the connection off to another machine, then you have to use some other method like eg@special.example.com or eg@other-domain.com and hope the clients will somehow use that tho for BIGCOMPANY there's a tendency to just bang in abuse@BIGCOMPANY.COM. It can be a problem in joe jobs, as one e.g. If you think I'm wrong (or Sean's wrong) even for a milisecond then trust me, this is going right over your head. Think again or email me privately and I'll try to be more clear. P.S. It's an interesting thought. The only approach to a solution I could imagine is that the whole address would have to be passed in the MX query. On November 21, 2007 at 21:06 paul@clubi.ie (Paul Jakma) wrote:
An unfortunate limitation of the SMTP protocol is it initially only looks at the right-hand side of an address when connecting to a server to send e-mail, and not the left-hand side.
full) or the normal server administrators may make changes which affects all addresses passing through that server (i.e. block by IP address).
I guess you're saying there's something architectural in email that makes it impossible/difficult (limitation) to apply different policy to the LHS.
That's not correct though. The receiving MTA is quite free to apply differing policies to different LHSes. And at least one MTA allows you special-case measures applied to tables of addresses, such as whether DNSbl lookups should be applied.
SMTP is distributed, so you do of course have to take care to keep distributed policy consistent. But, again, that has nowt to do with LHS/RHS of email addresses.
regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: A plumber is needed, the network drain is clogged
-- -Barry Shein The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On Nov 22, 2007 3:33 AM, Barry Shein <bzs@world.std.com> wrote:
If that (eg@example.com) overloads those servers, even if they're valiantly trying to pass the connection off to another machine, then you have to use some other method like eg@special.example.com or eg@other-domain.com and hope the clients will somehow use that tho for BIGCOMPANY there's a tendency to just bang in abuse@BIGCOMPANY.COM.
... and the RFC says that, and those people that still do manually report abuse will email abuse@domain or postmaster@domain instead of hitting report spam and letting their ISP forward it across in a feedback loop (which will go to an entirely different, machine parsed address as the ARF spec is designed to let you do). You can always alias abuse@ internally to a subdomain if you wish - but that wouldnt be because abuse@ slows down your MXs. The smtp load inbound to an abuse mailbox will be fairly small compared to the general load of smtp (and spam) coming your users' way for sure. There's lots of ways to manage an abuse mailbox (such as filter spam to your abuse mailbox into a bulk folder, review it and then feed it to scripts that parse the spam and feed the results to your filters). MAAWG's been working on an abuse desk bcp for quite some time (the hard / tech part of it, as well as soft abuse stuff like motivating and training abuse deskers, giving them career paths etc) --srs
It can be a problem in joe jobs, as one e.g.
If you think I'm wrong (or Sean's wrong) even for a milisecond then trust me, this is going right over your head. Think again or email me privately and I'll try to be more clear.
P.S. It's an interesting thought. The only approach to a solution I could imagine is that the whole address would have to be passed in the MX query.
On November 21, 2007 at 21:06 paul@clubi.ie (Paul Jakma) wrote:
An unfortunate limitation of the SMTP protocol is it initially only looks at the right-hand side of an address when connecting to a server to send e-mail, and not the left-hand side.
full) or the normal server administrators may make changes which affects all addresses passing through that server (i.e. block by IP address).
I guess you're saying there's something architectural in email that makes it impossible/difficult (limitation) to apply different policy to the LHS.
That's not correct though. The receiving MTA is quite free to apply differing policies to different LHSes. And at least one MTA allows you special-case measures applied to tables of addresses, such as whether DNSbl lookups should be applied.
SMTP is distributed, so you do of course have to take care to keep distributed policy consistent. But, again, that has nowt to do with LHS/RHS of email addresses.
regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: A plumber is needed, the network drain is clogged
-- -Barry Shein
The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Login: Nationwide Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
-- Suresh Ramasubramanian (ops.lists@gmail.com)
Happy after-Thanksgiving to the USAians still digesting turkey. Indeed, I can give thanks to the NANOG community for existing; I've gained a great deal from it and want to keep giving back. I'm writing a Wikipedia article on the overall topic of swarming, which, of course, included DDoS. Unfortunately, I can't remember the title or author of a presentation that either was at NANOG or a Cisco security event. Precise, huh? :-< Anyway, I'm hoping someone will remember it and can give a URL. It was from a network security group at a European physics lab, had very good economic analysis, and one of its more powerful example is that an oscilloscope running Windows -- which no one thought of in applying security patches -- was the place the malware hid while the security admins were scrubbing every obvious computer. Anyone happen to know where I can find it?
We have a load of test kit here running Windows, it frightens me as it gets moved from lab to lab office to office and nobody runs anything on it to keep in check. It's a sad sad world when you need anti virus software on your lab test kit! I mean really, how screwed up is it to run Windows on a spectrum analyser and then leave everything open, on SP1 with no firewall and no patches and then go plugging it into peoples networks. -- Leigh Howard C. Berkowitz wrote:
Happy after-Thanksgiving to the USAians still digesting turkey. Indeed, I can give thanks to the NANOG community for existing; I've gained a great deal from it and want to keep giving back.
I'm writing a Wikipedia article on the overall topic of swarming, which, of course, included DDoS. Unfortunately, I can't remember the title or author of a presentation that either was at NANOG or a Cisco security event. Precise, huh? :-<
Anyway, I'm hoping someone will remember it and can give a URL. It was from a network security group at a European physics lab, had very good economic analysis, and one of its more powerful example is that an oscilloscope running Windows -- which no one thought of in applying security patches -- was the place the malware hid while the security admins were scrubbing every obvious computer.
Anyone happen to know where I can find it?
On Fri, Nov 23, 2007, Leigh Porter wrote:
We have a load of test kit here running Windows, it frightens me as it gets moved from lab to lab office to office and nobody runs anything on it to keep in check.
It's a sad sad world when you need anti virus software on your lab test kit!
I mean really, how screwed up is it to run Windows on a spectrum analyser and then leave everything open, on SP1 with no firewall and no patches and then go plugging it into peoples networks.
I believe a local university physics department had a STM (microscope) running Windows 95 or Windows 98 + embedded stuff. The drivers broke whenever you tried patching it away from the shipped software version. The academics demanded that the device be accessible from everywhere so they could drag/drop data files to/from other universities on the thing. With a public IP address. Adrian
On Wed, 21 Nov 2007, Barry Shein wrote: | Sean's point was that you can't cause, e.g., eg@example.com alone to | go to a server other than the same set of servers listed for | AnythingElse@example.com. Yes of course - but only a fundamental problem where the MX servers are hopelessly overloaded. This is different from the situation described in the original post, where filtering policy is being applied indiscriminately regardless of recipient LHS, which is generally a sign of substandard software or foolish admin. As others have said, normal practice is to apply different filtering policy to certain LHS values (abuse@) and to provision enough MX capacity such that the service as a whole is functional (including receiving abuse reports).
Barry Shein <bzs@world.std.com> writes:
P.S. It's an interesting thought. The only approach to a solution I could imagine is that the whole address would have to be passed in the MX query.
Once upon a time (1987) there was this experimental facility called MB (mailbox) records which did exactly that. Unfortunately, they never caught on in any real way, and the only historical mark that they seem to have left is the rather odd way in which we express the RNAME (mailbox of the responsible party) in an SOA record. Maybe it's an idea whose time has come again. How many years would it take to have a meaningful rollout if we start now? 10? 20? OK, nevermind then. :-P ---Rob
Robert E. Seastrom wrote:
Barry Shein <bzs@world.std.com> writes:
P.S. It's an interesting thought. The only approach to a solution I could imagine is that the whole address would have to be passed in the MX query.
Once upon a time (1987) there was this experimental facility called MB (mailbox) records which did exactly that. Unfortunately, they never caught on in any real way, and the only historical mark that they seem to have left is the rather odd way in which we express the RNAME (mailbox of the responsible party) in an SOA record.
Maybe it's an idea whose time has come again. How many years would it take to have a meaningful rollout if we start now? 10? 20? OK, nevermind then. :-P
---Rob
Yeah 'cus by then there will be no address space left, all the routers would have blown up with too many prefixes, sea levels would have risen by 100 M and half the world will be under water. Not to mention the fallout from the middle east nuclear exchange, the bird flu epidemic, the asteroid hit and that the oil shortage means that China can no longer make any cheap plastic tat. If there is no cheap plastic tat, then Internet commerce will die because there will be nothing to buy! -- Leigh
On Nov 22, 2007 1:27 PM, Leigh Porter <leigh.porter@ukbroadband.com> wrote:
longer make any cheap plastic tat. If there is no cheap plastic tat, then Internet commerce will die because there will be nothing to buy!
Great. So half the world's population is dead, lots of dotbombs are out of business .. but you have LOTS of IP space that's suddenly unused and available. Fun.
On Nov 22, 2007 6:15 PM, Adrian Chadd <adrian@creative.net.au> wrote:
On Thu, Nov 22, 2007, Suresh Ramasubramanian wrote:
Great. So half the world's population is dead, lots of dotbombs are out of business .. but you have LOTS of IP space that's suddenly unused and available.
Is this actually a serious alternative to migrating to IPv6?
Dotbombs are, if they occur. Not that you can bank on them to occur .. though given silly valley, they just might occur. If they do occur, and if the RIRs are on the ball about reclaiming IP space ... Lots of ifs.
Suresh Ramasubramanian wrote:
On Nov 22, 2007 6:15 PM, Adrian Chadd <adrian@creative.net.au> wrote:
On Thu, Nov 22, 2007, Suresh Ramasubramanian wrote:
Great. So half the world's population is dead, lots of dotbombs are out of business .. but you have LOTS of IP space that's suddenly unused and available. Is this actually a serious alternative to migrating to IPv6?
Dotbombs are, if they occur.
Except of course that the companies that are presently soaking up large amounts of address space have actually customers, who pay for the most part, so even a bankruptcy that address space is going someplace (think psinet genuity etc).
Not that you can bank on them to occur .. though given silly valley, they just might occur.
If they do occur, and if the RIRs are on the ball about reclaiming IP space ...
I expect that legacy holders will be entombed in their pyramids with v4 space just-in-case they have use for it in the afterlife.
Lots of ifs.
Just a more likely one. -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Adrian Chadd Sent: Thursday, November 22, 2007 7:45 AM To: Suresh Ramasubramanian Cc: nanog@merit.edu Subject: Re: unwise filtering policy from cox.net On Thu, Nov 22, 2007, Suresh Ramasubramanian wrote:
Great. So half the world's population is dead, lots of dotbombs are out of business .. but you have LOTS of IP space that's suddenly unused and available.
Is this actually a serious alternative to migrating to IPv6? :) Adrian
On Wed, 21 Nov 2007, Barry Shein wrote:
xx@example.com
is going to go to whatever MX example.com returns.
Yes, I'm aware.
Sean's point was that you can't cause, e.g., eg@example.com alone to go to a server other than the same set of servers listed for AnythingElse@example.com.
Right, his point was that load or policy (" administrators may make changes which affect all addresses) would cause a problem, and this was, for some reason, due to routing of email addresses. I took issue with the policy side of the comment. While it's possible, it's got nowt to do with limitations in SMTP routing, it's just operator error.
If that (eg@example.com) overloads those servers, even if they're valiantly trying to pass the connection off to another machine, then you have to use some other method like eg@special.example.com or eg@other-domain.com and hope the clients will somehow use that tho for BIGCOMPANY there's a tendency to just bang in abuse@BIGCOMPANY.COM.
Right, I do understand that. There are obvious ways to horizontally scale inbound mail using MX records and more, so the load issue shouldn't be an issue for any given organisation. Least not more than once. However, I didn't comment on the load part of Sean's point.
If you think I'm wrong (or Sean's wrong) even for a milisecond then trust me, this is going right over your head. Think again or email me privately and I'll try to be more clear.
I don't think this is over my head. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Love thy neighbor as thyself, but choose your neighborhood. -- Louise Beal
participants (21)
-
Adrian Chadd -
Alex Pilosov -
Barry Shein -
Chris Edwards -
Chris Owen -
chuck goolsbee -
goemon＠anime.net -
Howard C. Berkowitz -
Jamie Bowden -
Jeff Shultz -
Joe Greco -
Joel Jaeggli -
Leigh Porter -
Martin Hannigan -
Paul Jakma -
Raymond L. Corbin -
Robert E. Seastrom -
S. Ryan -
Sean Donelan -
Suresh Ramasubramanian -
Valdis.Kletnieks＠vt.edu