Re: unwise filtering policy from cox.net
Suresh Ramasubramanian wrote: On Nov 22, 2007 6:15 PM, Adrian Chadd [EMAIL PROTECTED] 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.
RE: unwise filtering policy from cox.net
Just a more likely one. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
Re: unwise filtering policy from cox.net
On Nov 22, 2007 1:27 PM, Leigh Porter [EMAIL PROTECTED] 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.
Re: unwise filtering policy from cox.net
On Wed, 21 Nov 2007, Barry Shein wrote: [EMAIL PROTECTED] 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., [EMAIL PROTECTED] alone to go to a server other than the same set of servers listed for [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] or [EMAIL PROTECTED] and hope the clients will somehow use that tho for BIGCOMPANY there's a tendency to just bang in [EMAIL PROTECTED] 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 [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Love thy neighbor as thyself, but choose your neighborhood. -- Louise Beal
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
Re: unwise filtering policy from cox.net
On Nov 22, 2007 6:15 PM, Adrian Chadd [EMAIL PROTECTED] 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.
Re: unwise filtering policy from cox.net
Hey Paul, -- Sean Donelan [EMAIL PROTECTED] wrote: On Tue, 20 Nov 2007, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (reason: 552 5.2.0 F77u1Y00B2ccxfT000 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. [...] Sure, it's an unfortunate limitation, but I hardly think it's an issue to hand-wave about and say oh, well. Suggestions? Given what Sean wrote goes to the core of how mail is routed, you'd pretty much need to overhaul how MX records work to get around this one, or perhaps go back to try to resurrect something like a DNS MB record, but that presumes that the problem can't easily be solved in other ways. Sean demonstrated one such way (move the high volume stuff to its own domain). Eliot
Re: unwise filtering policy from cox.net
On Nov 21, 2007 5:46 PM, Eliot Lear [EMAIL PROTECTED] wrote: Given what Sean wrote goes to the core of how mail is routed, you'd pretty much need to overhaul how MX records work to get around this one, or perhaps go back to try to resurrect something like a DNS MB record, but that presumes that the problem can't easily be solved in other ways. Sean demonstrated one such way (move the high volume stuff to its own domain). Most mailservers do allow you to exempt specific addresses from filtering. srs
Re: unwise filtering policy from cox.net
Suresh Ramasubramanian wrote: Most mailservers do allow you to exempt specific addresses from filtering. On the LHS of the @ of a remote address? I think that was Sean's point. Eliot
Re: unwise filtering policy from cox.net
Given what Sean wrote goes to the core of how mail is routed, you'd pretty much need to overhaul how MX records work to get around this one, or perhaps go back to try to resurrect something like a DNS MB record, but that presumes that the problem can't easily be solved in other ways. Sean demonstrated one such way (move the high volume stuff to its own domain). Moving abuse@ to its own domain may work, however, fixing this problem at the DNS level is probably an error, and probably non-RFC-compliant anyways. The real problem here is probably one of: 1) Mail server admin forgot (FSVO forgot, which might be didn't even stop to consider, considered it and decided that it was worthwhile to filter spam sent to abuse@, not realizing the implications for abuse reporting, didn't have sufficient knowledge to figure out how to exempt abuse@, etc.) 2) Server software doesn't allow exempting a single address; this is a common problem with certain software, and the software should be fixed, since the RFC's essentially require this to work. Sadly, it is frequently assumed that if you cannot configure your system to do X, then it's all right to not do X, regardless of what the RFC's say. The need to be able to accept unfiltered recipients has certain implications for mail operations, such as that it could be bad to use IP level filtering to implement a shared block for bad senders. ... 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.
Re: unwise filtering policy from cox.net
On Wed, Nov 21, 2007 at 06:51:42AM +, Paul Ferguson wrote: Sure, it's an unfortunate limitation, but I hardly think it's an issue to hand-wave about and say oh, well. Suggestions? There are numerous techniques available for addressing this problem. Which one(s) to use depends on the site's mail architecture, so I'm not going to try to enumerate them all -- only to give a few examples. Example 1: exempt abuse@ address from all anti-* processing; just deliver it. All the MTA's I've worked with provide features to support this; it's also sometimes necessary to make that exemption elsewhere (e.g., in programs called invoked as milters). Oh, and don't greylist it either. Example 2: if using a multi-tier architecture (increasingly a good idea, as it insulates internal traffic from the beating often inflicted by external traffic) then re-route abuse@ mail to its own dedicated system (using a mechanism like the sendmail virtual user table or equivalent). Make that system something relatively impervious, and choose hardware that can be replaced quickly at low cost. (My suggestion: OpenBSD on a Sparc Ultra 2, and use mutt as the mail client. Keep a couple of spares in the basement, they're dirt-cheap.) ---Rsk
RE: unwise filtering policy from cox.net
To be clear, should one be white listing *all* the addresses suggested in RFC 2142? Regards, Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Greco Sent: Wednesday, November 21, 2007 8:30 AM To: Eliot Lear Cc: nanog@merit.edu Subject: Re: unwise filtering policy from cox.net Given what Sean wrote goes to the core of how mail is routed, you'd pretty much need to overhaul how MX records work to get around this one, or perhaps go back to try to resurrect something like a DNS MB record, but that presumes that the problem can't easily be solved in other ways. Sean demonstrated one such way (move the high volume stuff to its own domain). Moving abuse@ to its own domain may work, however, fixing this problem at the DNS level is probably an error, and probably non-RFC-compliant anyways. The real problem here is probably one of: 1) Mail server admin forgot (FSVO forgot, which might be didn't even stop to consider, considered it and decided that it was worthwhile to filter spam sent to abuse@, not realizing the implications for abuse reporting, didn't have sufficient knowledge to figure out how to exempt abuse@, etc.) 2) Server software doesn't allow exempting a single address; this is a common problem with certain software, and the software should be fixed, since the RFC's essentially require this to work. Sadly, it is frequently assumed that if you cannot configure your system to do X, then it's all right to not do X, regardless of what the RFC's say. The need to be able to accept unfiltered recipients has certain implications for mail operations, such as that it could be bad to use IP level filtering to implement a shared block for bad senders. ... 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.
Re: unwise filtering policy from cox.net
On Nov 21, 2007 1:51 AM, Paul Ferguson [EMAIL PROTECTED] 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. This means Sure, it's an unfortunate limitation, but I hardly think it's an issue to hand-wave about and say oh, well. Suggestions? Standardize on [EMAIL PROTECTED] If an MX exists for abuse.the-domain-you're-looking-for then send to that instead of to [EMAIL PROTECTED] Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: unwise filtering policy from cox.net
On Wed, 21 Nov 2007, Sean Donelan wrote: On Tue, 20 Nov 2007, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (reason: 552 5.2.0 F77u1Y00B2ccxfT000 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 [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: A plumber is needed, the network drain is clogged
Re: unwise filtering policy from cox.net
You're missing the point. [EMAIL PROTECTED] is going to go to whatever MX example.com returns. Sean's point was that you can't cause, e.g., [EMAIL PROTECTED] alone to go to a server other than the same set of servers listed for [EMAIL PROTECTED] If that ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] or [EMAIL PROTECTED] and hope the clients will somehow use that tho for BIGCOMPANY there's a tendency to just bang in [EMAIL PROTECTED] 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 [EMAIL PROTECTED] (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 [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: A plumber is needed, the network drain is clogged -- -Barry Shein The World | [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Login: Nationwide Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: unwise filtering policy from cox.net
On Nov 22, 2007 3:33 AM, Barry Shein [EMAIL PROTECTED] wrote: If that ([EMAIL PROTECTED]) 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 [EMAIL PROTECTED] or [EMAIL PROTECTED] and hope the clients will somehow use that tho for BIGCOMPANY there's a tendency to just bang in [EMAIL PROTECTED] ... and the RFC says that, and those people that still do manually report abuse will email [EMAIL PROTECTED] or [EMAIL PROTECTED] 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 [EMAIL PROTECTED] (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 [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: A plumber is needed, the network drain is clogged -- -Barry Shein The World | [EMAIL PROTECTED] | 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 ([EMAIL PROTECTED])
Re: unwise filtering policy from cox.net
On Wed, 21 Nov 2007, Barry Shein wrote: | Sean's point was that you can't cause, e.g., [EMAIL PROTECTED] alone to | go to a server other than the same set of servers listed for | [EMAIL PROTECTED] 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).
Re: unwise filtering policy from cox.net
Barry Shein [EMAIL PROTECTED] 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
Re: unwise filtering policy from cox.net
Robert E. Seastrom wrote: Barry Shein [EMAIL PROTECTED] 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
unwise filtering policy from cox.net
if anyone from cox.net is reading... - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 552 5.2.0 F77u1Y00B2ccxfT000 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.
Re: unwise filtering policy from cox.net
On Tue, 20 Nov 2007 11:21:19 PST, [EMAIL PROTECTED] 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). pgpr5aTRGO1Jv.pgp Description: PGP signature
Re: unwise filtering policy from cox.net
Or it was a minor oversight and you're all pissing and moaning over nothing? That's a thought too. [EMAIL PROTECTED] wroteth on 11/20/2007 11:42 AM: On Tue, 20 Nov 2007 11:21:19 PST, [EMAIL PROTECTED] 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).
[admin] Re: unwise filtering policy from cox.net
On Tue, 20 Nov 2007 [EMAIL PROTECTED] wrote: On Tue, 20 Nov 2007 11:21:19 PST, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]) are off-topic for nanog. Please keep it this way. -alex [mlc chair]
Re: [admin] Re: unwise filtering policy from cox.net
On Nov 20, 2007 3:11 PM, Alex Pilosov [EMAIL PROTECTED] wrote: On Tue, 20 Nov 2007 [EMAIL PROTECTED] wrote: On Tue, 20 Nov 2007 11:21:19 PST, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]) 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.)
Re: unwise filtering policy from cox.net
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.
Re: unwise filtering policy from cox.net
On Nov 20, 2007 2:21 PM, [EMAIL PROTECTED] wrote: [ snip ] - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 552 5.2.0 F77u1Y00B2ccxfT000 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
RE: unwise filtering policy from cox.net
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] (reason: 552 5.2.0 F77u1Y00B2ccxfT000 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.
Re: unwise filtering policy from cox.net
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 [EMAIL PROTECTED] 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...) pgpSxgjoHMNTw.pgp Description: PGP signature
Re: unwise filtering policy from cox.net
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 20, 2007, at 6:21 PM, [EMAIL PROTECTED] 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-
Re: unwise filtering policy from cox.net
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Sean Donelan [EMAIL PROTECTED] wrote: On Tue, 20 Nov 2007, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (reason: 552 5.2.0 F77u1Y00B2ccxfT000 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 [EMAIL PROTECTED] first passes through the same server as all of the rest of [EMAIL PROTECTED] 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). Sure, it's an unfortunate limitation, but I hardly think it's an issue to hand-wave about and say oh, well. Suggestions? - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHQ9V5q1pz9mNUZTMRAvCjAJ9VGB/7LicKsAXUwSwbmRVntfXm8gCgjEYT y9YWpm8OhqCDI5nPDBy6kZY= =OqQL -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: unwise filtering policy from cox.net
On Tue, 20 Nov 2007, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (reason: 552 5.2.0 F77u1Y00B2ccxfT000 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 [EMAIL PROTECTED] first passes through the same server as all of the rest of [EMAIL PROTECTED] 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 [EMAIL PROTECTED] e-mailbox has had problems, which affected the rest of [EMAIL PROTECTED] e-mail. So the FTC created a separate right-hand side name [EMAIL PROTECTED] 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.
Re: unwise filtering policy from cox.net
(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
