AOL rejecting mail from IP's w/o reverse DNS ?
Since I'm 99% sure the idea (or stupidity thereof :-) of blocking SMTP servers without reverse DNS came up here in this discussion, I just ran a manual queue run to clean out a queue, and saw this come up: ... Connecting to mailin-04.mx.aol.com. via esmtp...220-rly-xn05.mx.aol.com ESMTP mail_relay_in-xn5.9; Wed, 03 Dec 2003 09:59:55 -0500 220-America Online (AOL) and its affiliated companies do not 220- authorize the use of its proprietary computers and computer 220- networks to accept, transmit, or distribute unsolicited bulk 220- e-mail sent from the internet. Effective immediately: AOL 220- may no longer accept connections from IP addresses which 220 have no reverse-DNS (PTR record) assigned.
EHLO westnet.com
I don't know if this is new -- I don't recall seeing it before, but it doesn't say they WILL refuse, just they may. If they do start blocking -- this WILL be an operational issue. ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
I don't know if this is new -- I don't recall seeing it before, but it doesn't say they WILL refuse, just they may. If they do start blocking -- this WILL be an operational issue.
you're right. it will be. people will have to clean up their in-addr.arpa. or am i missing some reason they can't, other than laziness? randy
On Wed, 3 Dec 2003, Randy Bush wrote:
you're right. it will be. people will have to clean up their in-addr.arpa. or am i missing some reason they can't, other than laziness?
See, this is the war I didn't want to start again. Unless I'm thinking of a discussion on a different list -- I was sure in the whole Verizon "spam measures hurting other servers" thread, the whole blocking w/o IN PTR records had come up, with people saying they were on hosting where they couldn't change PTR records, and the clients who couldn't get mail from small offices with Exchange servers on DSL lines where the ISP hadn't configured reverse DNS . Then there was the comment on how reverse DNS was meaningless, and did you still run identd ? Maybe I'm thinking of the wrong list. If AOL does it, in a way the question is moot. At least those of us who DO know how to configure DNS can get some clients from the ones who don't. ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
Christopher X. Candreva writes on 12/3/2003 10:42 AM:
discussion on a different list -- I was sure in the whole Verizon "spam measures hurting other servers" thread, the whole blocking w/o IN PTR records had come up, with people saying they were on hosting where they couldn't change PTR records, and the clients who couldn't get mail from
That must be some other thread I think - one thread soon starts to look a lot like another, and I doubt if there's a single topic of this sort that hasn't been discussed to death already. srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
At 10:42 AM 12/3/2003, Christopher X. Candreva wrote:
On Wed, 3 Dec 2003, Randy Bush wrote:
you're right. it will be. people will have to clean up their in-addr.arpa. or am i missing some reason they can't, other than laziness?
See, this is the war I didn't want to start again. Unless I'm thinking of a discussion on a different list -- I was sure in the whole Verizon "spam measures hurting other servers" thread, the whole blocking w/o IN PTR records had come up, with people saying they were on hosting where they couldn't change PTR records, and the clients who couldn't get mail from small offices with Exchange servers on DSL lines where the ISP hadn't configured reverse DNS . Then there was the comment on how reverse DNS was meaningless, and did you still run identd ?
The issue I think AOL was getting at was not whether PTR records matched the A record for the host. That is indeed a can of worms, and there are reasons why that isn't a good idea, primarily because many people don't have access to the PTR records for smaller blocks or single addresses. However, there are a great many hosts spewing email (spam, in most cases seen at our servers) that have no INADDR set up at all. It would indeed be helpful if there were reasonable PTR records everywhere, even if the PTR information didn't match the A record information. The PTR information could at least provide some clues as to the ISP involved, etc.
Maybe I'm thinking of the wrong list.
If AOL does it, in a way the question is moot. At least those of us who DO know how to configure DNS can get some clients from the ones who don't.
Many will turn on a flag to specify "some PTR must exist" if AOL or some other large provider does it and is able to stick with it. Yes, there'll be some work for DNS-clued consultants if that happens. The impact on the 'net will not be all that significant, though. A few providers will certainly be impacted, namely those who've not bothered to implement (or only partially implement) INADDR.
Daniel Senie <dts@senie.com> writes:
Many will turn on a flag to specify "some PTR must exist" if AOL or some other large provider does it and is able to stick with it.
Yes, there'll be some work for DNS-clued consultants if that happens.
The impact on the 'net will not be all that significant, though. A few providers will certainly be impacted, namely those who've not bothered to implement (or only partially implement) INADDR.
... and it will be a zero-sum game once the spammers (or their complicit ISPs) fix their in-addrs too. while i applaud the notion that people will fix their dns entries, we're long past the days where spammers could be assumed to be clueless twits who were operating without serious technical backing. making the presumed good guys fix their in-addrs will have the collateral effect of getting them fixed by the spammers too. in fact, i wouldn't be surprised if some of the spammers who subscribe to nanog have new to-do items on their whiteboards now. ---rob
On Wed, 3 Dec 2003, Robert E. Seastrom wrote:
... and it will be a zero-sum game once the spammers (or their complicit ISPs) fix their in-addrs too.
I disagree. I don't think the spammers, by and large, 'own' their IP addresses. They are using (as someone said) hijacked space, or compromised machines. Odds are since many of these machines aren't SUPPOSED to be sending mail in the first place, no one is going to complain, so nothing is going to be done about them. ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
On Dec 3, 2003, at 10:42 AM, Christopher X. Candreva wrote:
On Wed, 3 Dec 2003, Randy Bush wrote:
you're right. it will be. people will have to clean up their in-addr.arpa. or am i missing some reason they can't, other than laziness?
See, this is the war I didn't want to start again. Unless I'm thinking of a discussion on a different list -- I was sure in the whole Verizon "spam measures hurting other servers" thread, the whole blocking w/o IN PTR records had come up, with people saying they were on hosting where they couldn't change PTR records, and the clients who couldn't get mail from small offices with Exchange servers on DSL lines where the ISP hadn't configured reverse DNS . Then there was the comment on how reverse DNS was meaningless, and did you still run identd ?
AOL says the PTR record needs to be assigned. It doesn't specify it has to match the @domain.com in the MAIL FROM: header. Wouldn't it be enough to make sure every IP address you announce has a PTR and matching A record? Hasn't this been a requirement for MANY services for MANY years? -- Matthew S. Crocker Crocker Communications, Inc. Vice President PO BOX 710 Greenfield, MA 01302 P: 413-746-2760 F: 413-746-3704 W: http://www.crocker.com E: matthew@crocker.com
In message <01D22399-25C5-11D8-940C-000A956885D4@crocker.com>, Matthew Crocker
AOL says the PTR record needs to be assigned. It doesn't specify it has to match the @domain.com in the MAIL FROM: header. Wouldn't it be enough to make sure every IP address you announce has a PTR and matching A record? Hasn't this been a requirement for MANY services for MANY years?
Right -- and then folks will start creating wildcard PTR records... --Steve Bellovin, http://www.research.att.com/~smb
AOL says the PTR record needs to be assigned. It doesn't specify it has to match the @domain.com in the MAIL FROM: header. Wouldn't it be enough to make sure every IP address you announce has a PTR and matching A record? Hasn't this been a requirement for MANY services for MANY years?
Requiring the PTR record to match the MAIL FROM: header would be horrific. There goes any hope of virtual hosting of mail accounts, i.e. one server with one ip handling multiple email domains. Adi
Randy Bush writes on 12/3/2003 10:18 AM:
you're right. it will be. people will have to clean up their in-addr.arpa. or am i missing some reason they can't, other than laziness?
Well - unless you have a /24, in-addr.arpa is typically under the control of your upstream provider. And at least some few upstream providers I have seen over the past few years are ignorant of basic DNS principles, and don't know how to do proper delegation. Their sending senior management off on junkets abroad, ostensibly to attend APNIC tutorials, seems to be a common cause. The actual admins often remain untrained. Come to think of it, quite a few such ISPs don't know to do proper BGP or proper anything else either ... If that is not the case, and the ISP does know to do reverse DNS, they often charge you $$$ for each line they add into their bind configs. One of the providers we were looking at (we were shopping for a /24) was charging a rather high sum per line added to their bind configs. What's more - their support was insisting that the config we sent them (just enough to let them delegate in-addr.arpa authority for the /24 to our nameservers) was "wrong". They apparently were under the impression we were going to pay them for each IP in the /24, to add rDNS. So, especially in countries where most if not all the IP providers you get are dumber than rocks, rDNS is often dismissed as an unnecessary luxury. Especially when you have maybe one IP allocated for a colocated server, rather than a /24 or two. srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
On 3 Dec 2003, at 10:51, Suresh Ramasubramanian wrote:
Randy Bush writes on 12/3/2003 10:18 AM:
you're right. it will be. people will have to clean up their in-addr.arpa. or am i missing some reason they can't, other than laziness?
Well - unless you have a /24, in-addr.arpa is typically under the control of your upstream provider.
RFC2317.
So, especially in countries where most if not all the IP providers you get are dumber than rocks, rDNS is often dismissed as an unnecessary luxury. Especially when you have maybe one IP allocated for a colocated server, rather than a /24 or two.
Maybe more people should do what AOL says they may do, then. Joe
Joe Abley writes on 12/3/2003 11:11 AM:
RFC2317.
that'd still involve the ISP inserting stuff in their nameservers. when "isp admins" are substituted by "drones working out of templates / web forms" ... ps - there's of course the rather umm... interesting content below ;) http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.h...
Maybe more people should do what AOL says they may do, then.
I'm all in favor of it - but I'm still reluctant to dump legit mail that'll get dumped if I do this. I'll have to be pushed a lot farther before I start doing this (and with spam levels increasing the way they are ...). -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
On Wed, Dec 03, 2003 at 11:28:19AM -0500, Suresh Ramasubramanian wrote:
ps - there's of course the rather umm... interesting content below ;) http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.h...
Which is totally, completely wrong and causes, in both cases, servers to leak name space (which causes cache poisoning) and, in once case, servers to potentially be marked as lame. The man is flat out wrong. Don't follow his advice. -Pete
Pete Ehlke writes on 12/3/2003 11:38 AM:
On Wed, Dec 03, 2003 at 11:28:19AM -0500, Suresh Ramasubramanian wrote:
ps - there's of course the rather umm... interesting content below ;) http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.h...
Which is totally, completely wrong and causes, in both cases, servers to leak name space (which causes cache poisoning) and, in once case, servers to potentially be marked as lame. The man is flat out wrong. Don't follow his advice.
The ;) smiley and that "umm..." before the "interesting" were added for precisely that reason. Sorry if I was not too clear. And there should be an "as usual" after your "flat out wrong", I think. -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
On Wed, Dec 03, 2003 at 08:38:10AM -0800, Pete Ehlke wrote:
On Wed, Dec 03, 2003 at 11:28:19AM -0500, Suresh Ramasubramanian wrote:
ps - there's of course the rather umm... interesting content below ;) http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.h...
Which is totally, completely wrong and causes, in both cases, servers to leak name space (which causes cache poisoning) and, in once case, servers to potentially be marked as lame. The man is flat out wrong. Don't follow his advice.
How can delegating in-addr.arpa on a per-ip basis be any different or worse than delegating it using an rfc2317 scheme? --Adam
On Wed, Dec 03, 2003 at 09:48:44AM -0800, Randy Bush wrote:
How can delegating in-addr.arpa on a per-ip basis be any different or worse than delegating it using an rfc2317 scheme?
consider the label of the ns rr to delegate only 1.2.3.42
Do you mean ns.42.3.2.1.in-addr.arpa? I still don't see what's wrong with the following, or how it leads to cache poisoning or leaky name space. 42.3.2.1.in-addr.arpa IN NS ns.42.3.2.1.in-addr.arpa. ns.42.3.2.1.in-addr.arpa IN A 5.6.7.86 --Adam
On Wed, Dec 03, 2003 at 09:53:37AM -0800, Adam McKenna wrote:
On Wed, Dec 03, 2003 at 09:48:44AM -0800, Randy Bush wrote:
How can delegating in-addr.arpa on a per-ip basis be any different or worse than delegating it using an rfc2317 scheme?
consider the label of the ns rr to delegate only 1.2.3.42
Do you mean ns.42.3.2.1.in-addr.arpa? I still don't see what's wrong with the following, or how it leads to cache poisoning or leaky name space.
42.3.2.1.in-addr.arpa IN NS ns.42.3.2.1.in-addr.arpa. ns.42.3.2.1.in-addr.arpa IN A 5.6.7.86
Eight hours later, and I'm still waiting for a reply on this. Were the original attacks by Pete Ehlke warranted, or would he care to retract his statements? --Adam
Adam McKenna wrote:
On Wed, Dec 03, 2003 at 09:53:37AM -0800, Adam McKenna wrote:
On Wed, Dec 03, 2003 at 09:48:44AM -0800, Randy Bush wrote:
How can delegating in-addr.arpa on a per-ip basis be any different or worse than delegating it using an rfc2317 scheme?
consider the label of the ns rr to delegate only 1.2.3.42
Do you mean ns.42.3.2.1.in-addr.arpa? I still don't see what's wrong with the following, or how it leads to cache poisoning or leaky name space.
42.3.2.1.in-addr.arpa IN NS ns.42.3.2.1.in-addr.arpa. ns.42.3.2.1.in-addr.arpa IN A 5.6.7.86
Eight hours later, and I'm still waiting for a reply on this. Were the original attacks by Pete Ehlke warranted, or would he care to retract his statements?
$ dig 3.2.1.in-addr.arpa soa $ dig 42.3.2.1.in-addr.arpa soa -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com
On Thu, Dec 04, 2003 at 02:04:54PM -0800, Crist Clark wrote:
$ dig 3.2.1.in-addr.arpa soa $ dig 42.3.2.1.in-addr.arpa soa
This email contains approximately the same information as Randy's did. Yes, the SOA's will be different. That is what is intended. The nameserver that is authoritative for 3.2.1.in-addr.arpa is delegating 42.3.2.1.in-addr.arpa to 5.6.7.86. Were you trying to make some other point or just showcasing your 'dig' skills? --Adam
Adam McKenna wrote:
On Thu, Dec 04, 2003 at 02:04:54PM -0800, Crist Clark wrote:
$ dig 3.2.1.in-addr.arpa soa $ dig 42.3.2.1.in-addr.arpa soa
This email contains approximately the same information as Randy's did. Yes, the SOA's will be different. That is what is intended. The nameserver that is authoritative for 3.2.1.in-addr.arpa is delegating 42.3.2.1.in-addr.arpa to 5.6.7.86. Were you trying to make some other point or just showcasing your 'dig' skills?
Sorry, I was not clear. I was looking at the examples on the webpage that was pointed to previously. The pain killers for my injured foot have made me a bit fuzzy today. You could set things up to look a little less broken than in his examples. I guess you can get around, $ dig @<isp-server> 3.2.1.in-addr.arpa soa $ dig @<your-server> 3.2.1.in-addr.arpa soa Breaking your own server, by setting up a zone for each IP address. Not pretty. You have in-addr.arpa domains with A records. Uck. It's based on a strange premise. From that web page, The fundamental mistake made by the authors of RFC 2317 is that it didn't occur to them that a delegation from a superdomain's content DNS servers does not have to point to the apices of the "zones" in the subdomain's content DNS servers. Or, put another way, it is not necessary for the apex of a "zone" to be a domain that the rest of the world considers to be within the content DNS server's bailiwick. Whereas I think the "mistake" they made seems to be that they follow RFC1034, - NAME SERVERS are server programs which hold information about the domain tree's structure and set information. ... ... Name servers know the parts of the domain tree for which they have complete information; a name server is said to be an AUTHORITY for these parts of the name space. Authoritative information is organized into units called ZONEs, and these zones can be automatically distributed to the name servers which provide redundant service for the data in a zone. All of that aside, I don't see how it is any easier than RFC2317. In fact you double the number of records when you add additional nameservers to your zone (which isn't really a zone). To quote one of his examples, I don't see how getting your ISP to do, $ORIGIN 168.50.204.in-addr.arpa. $GENERATE 0-15 $ NS a.ns.$ $GENERATE 0-15 a.ns.$ A 204.50.168.2 Is any harder than, $ORIGIN 168.50.204.in-addr.arpa. $GENERATE 0-15 CNAME $.0/28 0/28 NS ns.mydomain.org. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com
On Thu, Dec 04, 2003 at 04:59:59PM -0800, Crist Clark wrote:
$ORIGIN 168.50.204.in-addr.arpa. $GENERATE 0-15 $ NS a.ns.$ $GENERATE 0-15 a.ns.$ A 204.50.168.2
Is any harder than,
$ORIGIN 168.50.204.in-addr.arpa. $GENERATE 0-15 CNAME $.0/28 0/28 NS ns.mydomain.org.
That's the whole point. They are equivalent, but the former doesn't force you to invent your own naming scheme or use CNAMES (if using A records in in-addr.arpa domains is distasteful, then imho using CNAMES is even more distasteful, not to mention RR's containing the "/" character). --Adam
Quoting Adam McKenna <adam@flounder.net>:
On Thu, Dec 04, 2003 at 04:59:59PM -0800, Crist Clark wrote:
$ORIGIN 168.50.204.in-addr.arpa. $GENERATE 0-15 $ NS a.ns.$ $GENERATE 0-15 a.ns.$ A 204.50.168.2
Is any harder than,
$ORIGIN 168.50.204.in-addr.arpa. $GENERATE 0-15 CNAME $.0/28 0/28 NS ns.mydomain.org.
That's the whole point. They are equivalent, but the former doesn't force you to invent your own naming scheme or use CNAMES (if using A records in in-addr.arpa domains is distasteful, then imho using CNAMES is even more distasteful, not to mention RR's containing the "/" character).
--Adam
Why bother with CNAMES or A records? Is there anything wrong with simply using NS records for each adress? i.e.: $ORIGIN 109.246.64.in-addr.arpa. 1 NS ns1.customerA.com. 1 NS ns2.customerA.com. 2 NS ns1.customerA.com. 2 NS ns2.customerA.com. ... 16 NS ns1.customerB.com. 16 NS ns2.customerB.com. 17 NS ns1.customerB.com. 17 NS ns2.customerB.com. If the customer has a dozen name servers they want you to allocate reverse DNS for, it could become unwieldy, but technically, is there anything wrong with this setup? -Adam
On Sat, 6 Dec 2003, Adam Kujawski wrote:
Why bother with CNAMES or A records? Is there anything wrong with simply using NS records for each adress? i.e.:
$ORIGIN 109.246.64.in-addr.arpa. 1 NS ns1.customerA.com. 1 NS ns2.customerA.com.
This will work. For large blocks it would get tedious to manage, though a few lines of perl will spit out a file in short order. Definately not easy to manage on a large scale however. ========================================================== Chris Candreva -- chris@westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
On Sat, Dec 06, 2003 at 09:53:15PM -0500, Adam Kujawski wrote:
If the customer has a dozen name servers they want you to allocate reverse DNS for, it could become unwieldy, but technically, is there anything wrong with this setup?
I believe that this setup could be susceptible to the 'gluelessness' problem described at http://cr.yp.to/djbdns/notes.html. At the very least it takes a few more lookups to find the right answer. --Adam
Christopher X. Candreva writes on 12/3/2003 10:13 AM:
Since I'm 99% sure the idea (or stupidity thereof :-) of blocking SMTP servers without reverse DNS came up here in this discussion, I just ran a manual queue run to clean out a queue, and saw this come up:
They have had this policy since several months now but it is still a "may" - and does give them a good excuse to take out large IP blocks that don't have proper reverse DNS assigned and emit a lot of spam. More at http://postmaster.info.aol.com If this is what it takes to push more people to get valid PTR records on their mailservers ...
I don't know if this is new -- I don't recall seeing it before, but it doesn't say they WILL refuse, just they may. If they do start blocking -- this WILL be an operational issue.
Lots of mailservers (such as the one for freebsd.org) already do this. I have not seen any large ISP other than AOL do this yet, though. However if they make it a "must" rather than a "may", I can see a whole lot of ISPs who will be quite eager to follow suit and do something on the same lines. srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Suresh Ramasubramanian wrote:
They have had this policy since several months now but it is still a "may" - and does give them a good excuse to take out large IP blocks that don't have proper reverse DNS assigned and emit a lot of spam.
As I understand it, they blacklist if an IP with no rDNS generates "some threshold of" complaints. Not just "no rDNS" by itself. We're doing something like that ourselves now. Covers about 25% of all of our spam with a .025% "would be blocked if we didn't whitelist" rate. Which is quite good. A simple "no rDNS" rule causes too much trouble with our overseas customers. I'm sure AOL discarded that idea for the same reason.
Chris Lewis writes on 12/4/2003 2:24 PM:
As I understand it, they blacklist if an IP with no rDNS generates "some threshold of" complaints. Not just "no rDNS" by itself.
That is a good way to go.
A simple "no rDNS" rule causes too much trouble with our overseas customers. I'm sure AOL discarded that idea for the same reason.
Yup. The model can be extended to "if no rDNS, and if spamtrap hits or other spammish behavior noted from more than X IPs per /24, then block the /24". srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Suresh Ramasubramanian wrote:
A simple "no rDNS" rule causes too much trouble with our overseas customers. I'm sure AOL discarded that idea for the same reason.
Yup. The model can be extended to "if no rDNS, and if spamtrap hits or other spammish behavior noted from more than X IPs per /24, then block the /24".
And why would blocking the /24 be appropriate instead of matching the registry? Pete
Petri Helenius writes on 12/4/2003 5:36 PM:
Yup. The model can be extended to "if no rDNS, and if spamtrap hits or other spammish behavior noted from more than X IPs per /24, then block the /24".
And why would blocking the /24 be appropriate instead of matching the registry?
I would refer you to the huge number of netblocks out there that stay at /16 or larger size, with the upstream not SWIP'ing or otherwise delegating netblocks in APNIC (or wherever, such as an rwhois server) as they provision IPs. srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Suresh Ramasubramanian wrote:
Petri Helenius writes on 12/4/2003 5:36 PM:
And why would blocking the /24 be appropriate instead of matching the registry?
I would refer you to the huge number of netblocks out there that stay at /16 or larger size, with the upstream not SWIP'ing or otherwise delegating netblocks in APNIC (or wherever, such as an rwhois server) as they provision IPs.
And I refer you to the blocks which are properly registered down to the /29 level and you are saying that if you are a good citizen collateral damage is recommended regardless because antispammers are either lazy or technically incompetent or like their ego boosted by intentional collateral damage? Pete
On Fri, 5 Dec 2003, Petri Helenius wrote: And I refer you to the blocks which are properly registered down to the /29 level and you are saying that if you are a good citizen collateral damage is recommended regardless because antispammers are either lazy or technically incompetent or like their ego boosted by intentional collateral damage? Pete Can you explain to the less hyperbolic among us, why I should be obligated to exchange packets with a provider who hosts abusive customers. --mghali@snark.net------------------------------------------<darwin>< Flowers on the razor wire/I know you're here/We are few/And far between/I was thinking about her skin/Love is a many splintered thing/Don't be afraid now/Just walk on in. #include <disclaim.h>
just me wrote:
On Fri, 5 Dec 2003, Petri Helenius wrote:
And I refer you to the blocks which are properly registered down to the /29 level and you are saying that if you are a good citizen collateral damage is recommended regardless because antispammers are either lazy or technically incompetent or like their ego boosted by intentional collateral damage?
Pete
Can you explain to the less hyperbolic among us, why I should be obligated to exchange packets with a provider who hosts abusive customers.
Disclaimer: I am not a lawyer. That said, IMHO you are free to do what you want as an individual, but collusion by a group to block a provider (even one with abusive customers) smells a lot like restraint of trade. Tony
On Thu, 4 Dec 2003, Tony Hain wrote:
Can you explain to the less hyperbolic among us, why I should be obligated to exchange packets with a provider who hosts abusive customers.
Disclaimer: I am not a lawyer.
That said, IMHO you are free to do what you want as an individual, but collusion by a group to block a provider (even one with abusive customers) smells a lot like restraint of trade.
Is this because the IP address you are using is listed in SORBS? Received: from tndh.net (evrtwa1-ar8-4-65-030-212.evrtwa1.dsl-verizon.net [4.65.30.212]) 4.65.30.212 found in Dynamic IP Space (Cable, DSL & Dial Ups) Address or Block 4.65.0.0 / 16 Information [Dynablock] Dynamic IP address, use your ISPs mail server Entry Created Mon Nov 24 12:44:38 2003 GMT Last Updated Mon Nov 24 12:44:38 2003 GMT
just me wrote:
Can you explain to the less hyperbolic among us, why I should be obligated to exchange packets with a provider who hosts abusive customers.
You, and nobody else is not. The difference is if you carpet-bomb the provider or launch a smart device to it´s intended target. I´ll leave the rest of the obvious analogies as an excersize to the reader. Pete
On Mon, 8 Dec 2003, Petri Helenius wrote: just me wrote:
Can you explain to the less hyperbolic among us, why I should be obligated to exchange packets with a provider who hosts abusive customers.
You, and nobody else is not. The difference is if you carpet-bomb the provider or launch a smart device to it�s intended target. I�ll leave the rest of the obvious analogies as an excersize to the reader. Pete Right. Just because a provider condones one of its customer's abusive and irrisponsible behavior, doesn't mean it would be OK for the rest of the provider's customers. You don't get it. And probably never will. Enjoy your future of Nigerian herbal viagra colonic spam. matto --mghali@snark.net------------------------------------------<darwin>< Flowers on the razor wire/I know you're here/We are few/And far between/I was thinking about her skin/Love is a many splintered thing/Don't be afraid now/Just walk on in. #include <disclaim.h>
Petri Helenius writes on 12/4/2003 5:46 PM:
And I refer you to the blocks which are properly registered down to the /29 level and you are saying that if you are a good citizen collateral damage is recommended regardless because antispammers are either lazy or technically incompetent or like their ego boosted by intentional collateral damage?
You are reading a lot more than I meant into my statements. -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
participants (18)
-
Adam Kujawski -
Adam McKenna -
Adi Linden -
Chris Lewis -
Christopher X. Candreva -
Crist Clark -
Daniel Senie -
Joe Abley -
just me -
Matthew Crocker -
Pete Ehlke -
Petri Helenius -
Randy Bush -
Robert E. Seastrom -
Sean Donelan -
Steven M. Bellovin -
Suresh Ramasubramanian -
Tony Hain