what the heck do i do now?
bear with me, this appears to be about DNS but it's actually about e-mail. maps.vix.com has been gone since 1999 or so. mail-abuse.org is the new thing. i've tried just about everything to get traffic toward the old domain name to stop... right now there's a DNAME but it made no real difference. i've taken the maps.vix.com domain away. i've set its NS to "localhost". i've put long TTL's on both good and bad data. the traffic continues. clearly this is my pennance for starting MAPS, and i hear you giggling about it, but i need some advice. once upon a time, someone more insane than myself wanted to close an RBL and did so by replacing it with a wildcard entry. we all hated that since it caused a lot of mail to bounce. (all mail that would otherwise have been received by that RBL's subscribers, in fact.) it did however have the effect of causing the subscribers to reconfigure their mailers to stop querying the now-dead RBL in question. what's the current thinking on this? oh and even though this isn't about bgp i can put some numbers in so that it will seem on-topic. out of 100K DNS queries received by a vix.com nameserver (which is about five minutes worth), here are the toptalkers for maps.vix.com. (and we all know by now that public shaming and notification won't work, i'm not sure why this is relevant, but it looks good, so here it is.) "thoughts?" 2208 68.216.187.10 2156 192.106.1.99 1348 213.239.240.162 1024 192.106.1.100 808 192.106.1.1 742 216.156.2.29 659 216.55.144.5 594 192.203.136.10 592 80.247.227.1 556 24.111.1.180 535 217.18.160.2 523 87.127.246.222 438 192.106.1.9 430 192.203.136.1 384 69.20.2.227 378 213.249.17.10 355 87.98.222.35 353 216.218.185.16 331 213.251.136.18 319 72.41.223.229 274 216.65.0.148 264 61.194.193.9 257 200.75.51.132 251 213.234.128.211 248 213.251.134.167 222 69.38.230.2 208 219.232.224.89 193 213.249.17.11 178 200.75.51.133 175 204.212.38.12 170 209.244.4.235 167 211.5.1.220 158 200.62.191.36 150 195.178.70.10 147 212.125.128.91 147 192.247.72.254 145 202.180.64.9 144 216.46.201.220 135 164.164.149.13 134 203.97.32.3 132 66.98.240.151 129 84.14.44.250 122 206.40.201.230 118 195.14.50.1 108 211.5.1.219 102 64.234.192.7 98 66.235.216.48 88 200.205.163.168 85 69.20.2.243 85 69.20.2.231 85 146.83.183.94 80 202.239.113.18 79 199.60.229.4 79 140.186.4.4 78 68.125.191.131 78 203.97.32.5 72 80.88.192.200 71 192.189.54.17 70 82.210.64.18 69 217.106.235.214 68 202.229.192.20 66 202.154.3.2 64 217.19.24.18 61 213.203.124.146 61 195.96.33.249 57 168.95.1.128 56 203.94.129.130 56 200.69.193.111 56 168.95.1.133 55 72.3.128.125 54 168.95.1.145 53 216.231.41.2 53 210.119.192.6 52 203.141.32.247 52 168.95.1.132 50 80.80.231.223 50 204.145.230.31 49 213.225.90.203 48 61.129.66.75 48 38.115.131.10 47 195.220.32.99 46 64.60.208.40 46 207.12.35.170 46 168.95.1.129 46 168.95.1.126 44 212.42.168.116 44 209.128.208.11 44 168.95.1.148 43 84.14.176.166 43 200.62.191.38 43 154.11.147.2 42 168.95.1.144 41 168.95.1.131 41 168.95.1.127 40 81.240.254.45 40 218.223.31.252 40 209.82.111.202 39 69.20.2.237 39 217.22.50.3 39 211.72.171.75 39 131.188.3.89 38 203.166.97.12 38 199.201.145.162 38 168.95.1.147 38 12.98.160.66 37 69.36.241.228 37 168.95.1.146 37 131.130.199.155 36 200.31.192.18 34 216.174.17.6 34 209.61.163.233 34 200.207.88.142 34 168.95.1.92 32 80.247.228.1 32 69.60.117.147 31 67.18.97.50 30 202.175.151.10 27 168.95.1.99 26 216.127.136.207 26 212.245.255.2 26 195.2.96.2 25 216.244.191.38 25 212.86.129.142 25 199.64.0.252 24 212.55.197.117 24 199.166.210.2 24 154.11.136.2 23 216.65.0.156 23 198.63.210.55 23 194.204.0.1 22 202.134.64.12 21 84.22.6.100 21 211.125.124.33 21 203.198.7.66 21 203.144.168.6 21 203.116.1.94 21 202.96.102.3 21 158.234.250.70 20 65.106.2.117 20 213.191.73.65 19 66.77.137.9 19 64.65.208.6 19 64.122.97.116 19 203.23.72.2 19 194.106.218.42 17 80.255.128.145 17 168.95.192.81 16 194.242.40.3 16 168.95.192.83 15 69.20.2.225 15 210.104.1.13 15 207.7.4.66 15 207.218.192.26 15 207.106.1.2 15 168.95.192.89 15 168.95.192.84 15 140.123.181.1 14 217.10.104.109 14 216.145.96.10 14 212.45.26.98 14 210.238.234.242 14 210.236.36.2 14 193.50.240.2 14 193.225.16.111 14 168.95.192.86 14 150.186.1.1 13 24.96.32.18 13 218.232.110.37 13 213.130.10.10 13 202.237.13.66 13 161.142.201.17 12 168.95.192.80 11 62.252.64.17 11 213.171.195.168 11 211.125.124.34 11 210.253.165.8 11 203.30.161.1 11 202.45.84.68 10 216.127.136.213 10 212.49.128.65 10 203.10.110.104 10 202.134.99.162 10 192.114.65.50 10 168.95.192.88 10 168.95.192.85 ...
once upon a time, someone more insane than myself wanted to close an RBL and did so by replacing it with a wildcard entry. we all hated that since it caused a lot of mail to bounce. (all mail that would otherwise have been received by that RBL's subscribers, in fact.) it did however have the effect of causing the subscribers to reconfigure their mailers to stop querying the now-dead RBL in question. what's the current thinking on this?
one problem with this is that the pain is not felt by the misconfigured folk, but by distant innocents. randy
Randy Bush wrote:
once upon a time, someone more insane than myself wanted to close an RBL and did so by replacing it with a wildcard entry. we all hated that since it caused a lot of mail to bounce. (all mail that would otherwise have been received by that RBL's subscribers, in fact.) it did however have the effect of causing the subscribers to reconfigure their mailers to stop querying the now-dead RBL in question. what's the current thinking on this?
one problem with this is that the pain is not felt by the misconfigured folk, but by distant innocents.
I don't necessarily agree with that. First off, if you set up your mail server to use "maps.vix.com", you did it a LONG time ago, before scoring systems were all the rage. In all likelihood people are using this in a binary operation "accept or don't based on this DNSBL entry's return code". Flipping that switch will completely break mail for the offending site, and (in all likelihood) they'll notice it pretty quick and stop. Or they won't, in which case, they're pretty much an unattended domain, and who really cares what happens to them anyway? I think that at some poing, Paul has a right to attempt to reclaim the sane use of his domain name, and considering how long the DNSBL in question has been out of commission, and people who use it should know that by now, the carrot needs to be traded in for a stick. Cheers, D -- Derek J. Balling Manager of Systems Administration Vassar College 124 Raymond Ave Box 0406 - Computer Center 217 Poughkeepsie, NY 12604 W: (845) 437-7231 C: (845) 249-9731
On Wed, 31 Jan 2007, Derek J. Balling wrote:
I think that at some poing, Paul has a right to attempt to reclaim the sane use of his domain name, and considering how long the DNSBL in question has been out of commission, and people who use it should know that by now, the carrot needs to be traded in for a stick.
100% in agreement with everything Derek says. In the immediate term, it's *very* rude to just return false positives for everything, but maps.vix.com hasn't been a live DNSBL since 1999... -- Steve Sobol, Professional Geek ** Java/VB/VC/PHP/Perl ** Linux/*BSD/Windows Victorville, California PGP:0xE3AE35ED It's all fun and games until someone starts a bonfire in the living room.
one problem with this is that the pain is not felt by the misconfigured folk, but by distant innocents.
etc. One problem we have is that we tend to see the internet as a perfect simulation of a fair and just system, at least as a first goal. I don't know if that's possible or not. I don't know if anyone has actually explored the issue deeply. One problem is that there are many different notions of justice present globally. Probably thousands with significant real-world referents. -- -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 Wed, 31 Jan 2007, Barry Shein wrote: :One problem we have is that we tend to see the internet as a perfect :simulation of a fair and just system, at least as a first goal. : :I don't know if that's possible or not. I don't know if anyone has :actually explored the issue deeply. One problem is that there are many :different notions of justice present globally. Probably thousands with :significant real-world referents. : : Ultimately, the problem is that the idealism which was more or less the rule a decade ago has taken a backseat to commercialism and what some see as practicality; and arguably, some consider such a reasonable excuse for lax maintenance (to the tune of "if it's not hurting me/my customers, it's not a priority"). Considering the time passed since maps went defunct, Paul is entirely justified in doing whatever is necessary to cluebat the offending networks, imho.
On Wed, 31 Jan 2007, Brian Wallingford wrote:
it's not a priority"). Considering the time passed since maps went defunct, Paul is entirely justified in doing whatever is necessary to cluebat the offending networks, imho.
here's the funny thing... what if the cluebat doesn't actualy change any delivery on the mailserver end? :) now THAT would be pretty funny. -Chris
Brian Wallingford wrote:
... Considering the time passed since maps went defunct, Paul is entirely justified in doing whatever is necessary to cluebat the offending networks, imho.
That's my opinion too. But I do have some domain name server addresses that get a lot of traffic due to historical misconfiguration by people who are likely too clueless to adjust it properly. And I tried some interesting experiments around providing "wrong" wildcard answers to queries that were received. And then, after getting some nasty complaints (including threats of legal action) from people who, for instance, didn't like that whenever their PC tried to use me as a resolver, they couldn't get to their favorite web sites any more and who weren't interested in removing me from their resolver list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their "email firewall" is checking your server, and someone dies as a result of the delay) So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts. Matthew Kaufman matthew@eeph.com
list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their "email firewall" is checking your server, and someone dies as a result of the delay)
So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts.
Uhm. I don't follow? Once you've taken all reasonable measures to tell said hospital that you're no responsible, nor inclined, to forward their mail - and they continue to ignore your warnings - surely responsibility passes to the person who ignores the warnings? (Hospital Systems Engineer and/or IT Management? Or the person who relied on Email for a life-or-death application?) If theres no contract between you and said hospital, and you've taken reasonable steps to prevent a mishap, how is it your liability? Or is this where I get to say 'only in America' ?? To be more relevant to the original problem, I think Paul has every right to do what he wishes with the DNS entry, short of causing anyone else a Denial of Service. (Can't be said hes denying service to any of the clients involved, as they've had no 'service' from him since 1999, as stated...) Mark.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 31, 2007, at 9:16 PM, Mark Foster wrote:
list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their "email firewall" is checking your server, and someone dies as a result of the delay)
So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts.
Uhm. I don't follow?
I my experience, people who tell stories like this really just need to get a better lawyer. I've had several lawyers contact us on things about this lame and have found that that the one sentence reply letter is often the most effective: Dear Sir: Kiss my what? Never hear from them again. Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFwV6ZElUlCLUT2d0RArP9AKC4JaEP5QJiB70SfrCWGkI9eTdxBwCcC+wA +DFKKXKMUqluFDF1DNCBJ0o= =sndk -----END PGP SIGNATURE-----
As an, ahem, lawyer, I think what you do and how you do it matter a lot here. And it would be prudent to talk to someone who understood your facts and situation before doing some of the things discussed in this thread. (I won't be more specific for fear of sounding like I'm giving legal advice, YMMV, probably not admitted where you live, if this were advice it would trigger a bill, see generally disclaimers at http://www.law.tm/disclaimers.html .) Pulling a plug after reasonable/lots of warnings (did you miss anyone? how do you know for sure?) is on the safer end of the legal spectrum. Trying something that has the noble intention of directing cluebat to cranial density... well, that's different. It has the ability to be spun as malicious. Will the judge and jury get it? Who will pay for the lawyer who will explain it to them? What if it was a government computer that got hosed? Will this be civil or criminal liability? Bottom line is that in the absence of a promise -- explicit or implicit (!) -- to the contrary, you can usually turn off your gear and get on with your life (but would you want to if it was a hospital that got hosed? how would you feel in the morning?). The more your actions deviate from that, the more likely you are taking on some level of risk. In some scenarios it's an acceptable level, but it all depends. It is impossible to know with any confidence without knowing more details, but from the face of it, it is far from obvious to me that Mark Foster's lawyer got this wrong. (Meanwhile, this will make a great exam question some day.) On Wed, 31 Jan 2007, Chris Owen wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jan 31, 2007, at 9:16 PM, Mark Foster wrote:
list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their "email firewall" is checking your server, and someone dies as a result of the delay)
So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts.
Uhm. I don't follow?
I my experience, people who tell stories like this really just need to get a better lawyer. I've had several lawyers contact us on things about this lame and have found that that the one sentence reply letter is often the most effective:
Dear Sir:
Kiss my what?
Never hear from them again.
Chris
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin)
iD8DBQFFwV6ZElUlCLUT2d0RArP9AKC4JaEP5QJiB70SfrCWGkI9eTdxBwCcC+wA +DFKKXKMUqluFDF1DNCBJ0o= =sndk -----END PGP SIGNATURE-----
-- http://www.icannwatch.org Personal Blog: http://www.discourse.net A. Michael Froomkin | Professor of Law | froomkin@law.tm U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm -->It's warm here.<--
It is impossible to know with any confidence without knowing more details, but from the face of it, it is far from obvious to me that Mark Foster's lawyer got this wrong.
(Meanwhile, this will make a great exam question some day.)
I agree, except it wasn't my Laywer. You mean Matthew Kaufman. Note the number of quotede layers. I made the mistake of removing the quote-intro-line when I posted, apologies.
On Wed, 31 Jan 2007, Chris Owen wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jan 31, 2007, at 9:16 PM, Mark Foster wrote:
list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their "email firewall" is checking your server, and someone dies as a result of the delay)
So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts.
Uhm. I don't follow?
I my experience, people who tell stories like this really just need to get a better lawyer. I've had several lawyers contact us on things about this lame and have found that that the one sentence reply letter is often the most effective:
Dear Sir:
Kiss my what?
Never hear from them again.
Chris
*snip*
At 11:19 PM -0500 1/31/07, Michael Froomkin - U.Miami School of Law wrote:
As an, ahem, lawyer, I think what you do and how you do it matter a lot here. And it would be prudent to talk to someone who understood your facts and situation before doing some of the things discussed in this thread. (I won't be more specific for fear of sounding like I'm giving legal advice, YMMV, probably not admitted where you live, if this were advice it would trigger a bill, see generally disclaimers at http://www.law.tm/disclaimers.html .)
Pulling a plug after reasonable/lots of warnings (did you miss anyone? how do you know for sure?) is on the safer end of the legal spectrum.
Trying something that has the noble intention of directing cluebat to cranial density... well, that's different. It has the ability to be spun as malicious. Will the judge and jury get it? Who will pay for the lawyer who will explain it to them? What if it was a government computer that got hosed? Will this be civil or criminal liability?
Bottom line is that in the absence of a promise -- explicit or implicit (!) -- to the contrary, you can usually turn off your gear and get on with your life (but would you want to if it was a hospital that got hosed? how would you feel in the morning?). The more your actions deviate from that, the more likely you are taking on some level of risk. In some scenarios it's an acceptable level, but it all depends.
That would seem to apply to the original decision to stop the service in 1999, water under the bridge. The current "users of the service" haven't gotten service since then. Does that change the promise any?
It is impossible to know with any confidence without knowing more details, but from the face of it, it is far from obvious to me that Mark Foster's lawyer got this wrong.
(Meanwhile, this will make a great exam question some day.)
On Wed, 31 Jan 2007, Chris Owen wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jan 31, 2007, at 9:16 PM, Mark Foster wrote:
list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their "email firewall" is checking your server, and someone dies as a result of the delay)
So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts.
Uhm. I don't follow?
I my experience, people who tell stories like this really just need to get a better lawyer. I've had several lawyers contact us on things about this lame and have found that that the one sentence reply letter is often the most effective:
Dear Sir:
Kiss my what?
Never hear from them again.
Chris
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin)
iD8DBQFFwV6ZElUlCLUT2d0RArP9AKC4JaEP5QJiB70SfrCWGkI9eTdxBwCcC+wA +DFKKXKMUqluFDF1DNCBJ0o= =sndk -----END PGP SIGNATURE-----
-- http://www.icannwatch.org Personal Blog: http://www.discourse.net A. Michael Froomkin | Professor of Law | froomkin@law.tm U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm -->It's warm here.<--
-- Ken Eddings, Hostmaster, IS&T, eddingsk@apple.com, eddingsk@mac.com Work:+1 408 974-4286, Cell: +1 408 425-3639, Fax: +1 408 974-3103 Apple Computer, Inc., 1 Infinite Loop, M/S 60-MS Cupertino, CA 95014 The Prudent Mariner never relies solely on any single aid to navigation.
Just add to your services price list "high-reliability electronic mail service: $10,000/month" or whatever with some general wording about how suitable it is for customers who rely on email for critical and high-dollar business dealings, life and death situations, and similar. Point to it from your general email services menu item. If someone nibbles you could always say you're not taking on new high-reliability email customers for a few months due to demand (theirs.) If what you describe happens you can point to how if they were so concerned they could have purchased the high-reliability email option. They aren't likely to be successful suing you for failure to deliver a service they haven't purchased. Remember the rule: If it isn't worth much to you, it certainly isn't worth much to me. -- -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 Wed, Jan 31, 2007 at 07:04:37PM -0800, Matthew Kaufman wrote:
(As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their "email firewall" is checking your server, and someone dies as a result of the delay)
A hospital which relies on email for laboratory results is obviously negligent. They should know that email is "best-effort", no better, and that as a result it's an unreliable transport medium. (And increasingly so given the massive abuse being heaped on it as well as any number of ill-conceived "anti-abuse" ideas (C/R, callbacks) that actually make the problem worse.) Using it for life-critical data is foolish. There are much better choices available (including offline ones such as FedEx) for the transfer for critical information. ---Rsk
On Jan 31, 2007, at 7:04 PM, Matthew Kaufman wrote:
(As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their "email firewall" is checking your server, and someone dies as a result of the delay)
Moral issues aside, I'd love to see this litigated. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // 408.527.6376 voice The telephone demands complete participation. -- Marshall McLuhan
On February 1, 2007 at 05:34 rdobbins@cisco.com (Roland Dobbins) wrote:
On Jan 31, 2007, at 7:04 PM, Matthew Kaufman wrote:
(As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their "email firewall" is checking your server, and someone dies as a result of the delay)
Moral issues aside, I'd love to see this litigated.
About 20 years ago, probably a little more, I got a call at Boston University from an IT admin working at a hospital in Rhode Island. He told me IBM was making a competitive bid for the hospital's campuswide network and was pushing hard for their own token-ring solutions against his preferred ethernet solutions. What he wanted me to help him think through was that IBM had told the hospital's administration that because ethernet is designed to drop packets (i.e., collisions, let's not quibble my quick description you all know what I mean) that data could be LOST and a patient could DIE and the hospital could be held LIABLE! He said that thus far explaining TCP/IP's reliability had gone right over their heads and all they could see were the materials about ethernet's lossiness IBM had left with them. I forget what I advised, I think I tried to get some other similar players already using ethernet in touch as reference sites. It was 20+ years ago. My only point is that this "unreliability could cause children to die, and, worse, lawsuits!" is awfully old grist for the mill. -- -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*
brian@meganet.net (Brian Wallingford) writes:
... Considering the time passed since maps went defunct, Paul is entirely justified in doing whatever is necessary to cluebat the offending networks, imho.
thanks for those supportive words. note that MAPS is not defunct. the domain MAPS.VIX.COM is defunct, in favour of MAIL-ABUSE.ORG, which was originally an asset of MAPS LLC, then Kelkea, and lately Trend Micro. i've received some excellent private suggestions due to this thread. my two leading candidates are (a) ask dan bernstein to take over MAPS.VIX.COM and run his own RBL there; vs (b) hack up a BIND server so that it can return a positive answer 1% of the time (chosen randomly). -- Paul Vixie
On Thu, 1 Feb 2007, Paul Vixie wrote:
thanks for those supportive words. note that MAPS is not defunct. the domain MAPS.VIX.COM is defunct, in favour of MAIL-ABUSE.ORG, which was originally an asset of MAPS LLC, then Kelkea, and lately Trend Micro.
They seem to have preferred mail-abuse.com since summer 2004 - at least that's about when the lookup CGI at mail-abuse.org stopped working. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ IRISH SEA: SOUTHWEST VEERING NORTHEAST 3 OR 4, INCREASING 5 OR 6 FOR A TIME. SLIGHT OCCASIONALLY MODERATE. OCCASIONAL DRIZZLE, FAIR LATER. GOOD, OCCASIONALLY MODERATE OR POOR.
brian@meganet.net (Brian Wallingford) writes:
Ultimately, the problem is that the idealism which was more or less the rule a decade ago has taken a backseat to commercialism ...
i dunno about that. i see a lot of idealism still. volunteers at spamhaus, and within the da/mwp community, and at cymru, are still going quite strong. and in an odd twist of fate's knife, i still hold the "cix.net" domain which was very quiet until COX went into the internet business a few years back. since "i" and "o" are adjacent in qwertyland, i get a whole lotta misdirected e-mail, including a lot of 1x1 correspondance from folks who mistyped their source-email-address in their e-mail reader and then proceeded to correspond. rather than bounce it all, i answer it with the following template: there is no such person here at cix.net. try cox.net. re: and then i include-all the mail they sent to me by mistake. eventually i got tired of explaining to the senders why "paul@vix.com" was answering their e-mail, and so i started forging the source of my response to be the cix.net address they were trying to reach. i've got it all down to a couple of MH-E keystrokes and macros and e-lisp functions now. i just don't like the idea of bouncing the stuff outright, since a lot of the senders will never guess what went wrong. (i also appreciate the extra spam, for robot-training use.) it's only a dozen messages a day, on average, and thus: idealism isn't dead. -- Paul Vixie
Set up a nameserver there. Configure it to return 127.0.0.2 (or whatever the old MAPS reply for "spam" was) to all queries. Let it run for a week. See if anything changes in terms of it getting hammered. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
On Thu, 1 Feb 2007, Jay Hennigan wrote:
Set up a nameserver there. Configure it to return 127.0.0.2 (or whatever the old MAPS reply for "spam" was) to all queries. Let it run for a week. See if anything changes in terms of it getting hammered.
Well I've seen some RBLs do this with about 2 days notice. Perhaps a special value could be defined ( 127.255.255.255 ? ) to tell users that the DNSBL is no longer in operation and shouldn't be used, standard software can then raise an error or whatever. -- Simon J. Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
On Mon, 5 Feb 2007, Simon Lyall wrote:
On Thu, 1 Feb 2007, Jay Hennigan wrote:
Set up a nameserver there. Configure it to return 127.0.0.2 (or whatever the old MAPS reply for "spam" was) to all queries. Let it run for a week. See if anything changes in terms of it getting hammered.
Well I've seen some RBLs do this with about 2 days notice. Perhaps a special value could be defined ( 127.255.255.255 ? ) to tell users that the DNSBL is no longer in operation and shouldn't be used, standard software can then raise an error or whatever.
That doesn't help get the old/unwatched installations to stop sending queries. It's been established that regardless of what you return, those installations will continue querying the dead BL. That's why I think your best/only option is to attempt to misdirect them by pointing NS at . or unreachable space...effectively giving them someplace harmless to send their queries or to fail them without even having to send them. Killing the parent domain is an option too, but that only pushes the problem onto someone else's plate (the TLD servers). ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Feb 4, 2007, at 2:49 PM, Jon Lewis wrote:
On Mon, 5 Feb 2007, Simon Lyall wrote:
On Thu, 1 Feb 2007, Jay Hennigan wrote:
Set up a nameserver there. Configure it to return 127.0.0.2 (or whatever the old MAPS reply for "spam" was) to all queries. Let it run for a week. See if anything changes in terms of it getting hammered.
Well I've seen some RBLs do this with about 2 days notice. Perhaps a special value could be defined ( 127.255.255.255 ? ) to tell users that the DNSBL is no longer in operation and shouldn't be used, standard software can then raise an error or whatever.
That doesn't help get the old/unwatched installations to stop sending queries. It's been established that regardless of what you return, those installations will continue querying the dead BL.
Sure, but if we could all agree that 127.255.255.255 (or something) means that the BL has been shutdown then in the future this sort of issue could be mitigated. If software were written so that receiving this would drop the BL from the list, then you would only get one query each time the software starts up -- even better would be that this response removes (or comments out) the blacklist from the config file so that it doesn't come back after a restart.... Yes, this doesn't fix Paul's problem (or anyone who setup a blacklist before this is standardized) and there is no way to enforce this, but it is bunch better than not doing anything...
That's why I think your best/only option is to attempt to misdirect them by pointing NS at . or unreachable space...effectively giving them someplace harmless to send their queries or to fail them without even having to send them.
Killing the parent domain is an option too, but that only pushes the problem onto someone else's plate (the TLD servers).
---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
W -- With Feudalism, it's your Count that votes.
"Warren" == Warren Kumari <warren@kumari.net> writes:
Warren> Sure, but if we could all agree that 127.255.255.255 (or Warren> something) means that the BL has been shutdown then in the Warren> future this sort of issue could be mitigated. You don't need to agree on something - it's already possible to apply automated checks to a DNSBL that detect all known methods of shutting it down. Applying these same checks in configuration tools would also prevent users specifying things which are not live DNSBLs, thus avoiding a lot of excess query load on nameservers that just happen to serve domains that have been mistaken for DNSBLs. The algorithm is very simple: - if 1.0.0.127.dnsbl.example. is not NXDOMAIN, this is a hard failure. - if 2.0.0.127.dnsbl.example. is NXDOMAIN or SERVFAIL, or lacks an A record, or has an A record which is not 127.x.x.x, then this is a soft failure. - otherwise the test passes. DNSBLs that soft-fail should be removed from use but continue to be tested regularly, and at least optionally added back automatically if they pass within a reasonable period (days, say) of failing - after that they should be treated as hard failures and removed completely. Warren> Yes, this doesn't fix Paul's problem (or anyone who setup a Warren> blacklist before this is standardized) and there is no way to Warren> enforce this, but it is bunch better than not doing Warren> anything... It has been possible all along, so why aren't people doing it already? -- Andrew, Supernews http://www.supernews.com
Andrew - Supernews wrote:
"Warren" == Warren Kumari <warren@kumari.net> writes:
Warren> Sure, but if we could all agree that 127.255.255.255 (or Warren> something) means that the BL has been shutdown then in the Warren> future this sort of issue could be mitigated.
You don't need to agree on something - it's already possible to apply automated checks to a DNSBL that detect all known methods of shutting it down.
You could also say if it returns anything outside of 127.0.0.0/8 then it's dead - that would stop it the moment it is wildcarded. In any case the software writers would need to be persuaded to alter it in code. / Mat
Matthew Sullivan wrote:
Andrew - Supernews wrote:
> "Warren" == Warren Kumari <warren@kumari.net> writes: >
Warren> Sure, but if we could all agree that 127.255.255.255 (or Warren> something) means that the BL has been shutdown then in the Warren> future this sort of issue could be mitigated.
You don't need to agree on something - it's already possible to apply automated checks to a DNSBL that detect all known methods of shutting it down.
You could also say if it returns anything outside of 127.0.0.0/8 then it's dead - that would stop it the moment it is wildcarded.
In any case the software writers would need to be persuaded to alter it in code.
/ Mat
No amount of good software can make up for a bad administrator. The question is how much notice is appropriate on both a legal and practical measure. Sadly, as we all know, there are plenty of unqualified, or apathetic (e-mail) administrators on the Internet, some of whom have their systems configured such that they cause damage to the Internet-at-large (The Dlink NTP fiasco comes to mind, among others), some of which damages only certain domains (this particular case, the Osirusoft case, and others). According to The Internet Archive, Paul posted a notice on October 11, 2001 that maps.vix.com was replaced with the following notice: "MAPS.VIX.COM is no longer a valid URL MAPS is no longer associated with Vixie Enterprises, and the MAPS.VIX.COM URL has long since been replaced by http://mail-abuse.org/." This notice was taken down on or after August 8, 2002. It was posted for almost a full year, this posting period ended almost 5 years ago. Is there a point where enough is enough? When do I as a RBL administrator/owner stop being responsible for the incompetence of Joe Blow postmaster? Andrew
... the effect of causing the subscribers to reconfigure their mailers to stop querying the now-dead RBL in question. what's the current thinking on this?
one problem with this is that the pain is not felt by the misconfigured folk, but by distant innocents.
i am one of those who believes that e-mail is a shared benefit. so in my worldview, both the intended recipients and actual senders would feel pain. (bulk e-mail disproportionately benefits the sender, but i'm thinking 1x1 e-mail in this thought experiment.)
DNS forward all queries and replies to myspace, Im sure they'll enjoy that! -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Paul Vixie Sent: Wednesday, January 31, 2007 3:48 PM To: nanog@merit.edu Subject: Re: what the heck do i do now?
... the effect of causing the subscribers to reconfigure their mailers to stop querying the now-dead RBL in question. what's the current thinking on this?
one problem with this is that the pain is not felt by the misconfigured folk, but by distant innocents.
i am one of those who believes that e-mail is a shared benefit. so in my worldview, both the intended recipients and actual senders would feel pain. (bulk e-mail disproportionately benefits the sender, but i'm thinking 1x1 e-mail in this thought experiment.)
it caused a lot of mail to bounce. (all mail that would otherwise have been received by that RBL's subscribers, in fact.) it did however have the effect of causing the subscribers to reconfigure their mailers to stop querying the now-dead RBL in question. what's the current thinking on this?
I know the guy, in fact was talking to him on the phone earlier this afternoon and it wasn't as effective as you might hope. He may have had to abandon the domain. A probably not surprising number of people have decided that my abuse.net is a DNSBL, and nothing I've been able to do makes a serious dent. Look up the TXT record for any n.n.n.n.abuse.net where the n's are decimal numbers.
2208 68.216.187.10
This is Integrity On Line, which purports to be a "filtered solution provider", which I presume means a big thick firewall that keeps out anything that might upset their subscribers. It might be illuminating to give them a call, express concern that a computer in their center is sending 400 unwanted messages a minute to you, and see if you can find anyone who has any idea how the mail servers are configured. I realize they're only a tiny percentage of your junk traffic, but their clue level is probably typical. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "More Wiener schnitzel, please", said Tom, revealingly.
Paul Vixie wrote:
bear with me, this appears to be about DNS but it's actually about e-mail.
maps.vix.com has been gone since 1999 or so. mail-abuse.org is the new thing. i've tried just about everything to get traffic toward the old domain name to stop... right now there's a DNAME but it made no real difference. Paul,
Not offering a solution but a bit of an explanation perhaps... From: http://cr.yp.to/ucspi-tcp/rblsmtpd.html "If you do not supply any -r options, rblsmtpd tries an RBL source of rbl.maps.vix.com. This will be changed in subsequent versions." So checking the last released version: /ucspi-tcp-0.88# grep -hn maps.vix.com rblsmtpd.c 193: if (flagwantdefaultrbl) rbl("rbl.maps.vix.com"); Looks like that could be a cause of some of your pain... Not everyone runs rblsmptd on their mailserver, but I know lots of large mail servers that run rblsmptd (qmail). The fact that the option is the default without being explicit means that at least some folks don't even know maps.vix.com zones are no longer present and the current failure case is not impacting them. -david ulevitch
Or just have everydns [or insert other free dns provider] handle your primary dns and let them handle the traffic, problem solved (for you atleast) :-) Personally I have no sympathy to people who are using outdated dnsbl's (especially from 1999), I would consider the wildcard if you want to actually solve the problem instead of dealing with it yourself or having to hand it off to someone else. You may also take that list of ips (with over 100 queries or so) and turn on the dnsbl with those ips added (they will only reject mail from each other but it might give some a clue). ----- Original Message ----- From: "David Ulevitch" <davidu@everydns.net> To: "Paul Vixie" <paul@vix.com> Cc: <nanog@merit.edu> Sent: Wednesday, January 31, 2007 7:15 PM Subject: Re: what the heck do i do now?
Paul Vixie wrote:
bear with me, this appears to be about DNS but it's actually about e-mail.
maps.vix.com has been gone since 1999 or so. mail-abuse.org is the new thing. i've tried just about everything to get traffic toward the old domain name to stop... right now there's a DNAME but it made no real difference. Paul,
Not offering a solution but a bit of an explanation perhaps...
From: http://cr.yp.to/ucspi-tcp/rblsmtpd.html "If you do not supply any -r options, rblsmtpd tries an RBL source of rbl.maps.vix.com. This will be changed in subsequent versions."
So checking the last released version: /ucspi-tcp-0.88# grep -hn maps.vix.com rblsmtpd.c 193: if (flagwantdefaultrbl) rbl("rbl.maps.vix.com");
Looks like that could be a cause of some of your pain... Not everyone runs rblsmptd on their mailserver, but I know lots of large mail servers that run rblsmptd (qmail).
The fact that the option is the default without being explicit means that at least some folks don't even know maps.vix.com zones are no longer present and the current failure case is not impacting them.
-david ulevitch
David Ulevitch wrote:
Not offering a solution but a bit of an explanation perhaps...
From: http://cr.yp.to/ucspi-tcp/rblsmtpd.html "If you do not supply any -r options, rblsmtpd tries an RBL source of rbl.maps.vix.com. This will be changed in subsequent versions."
So checking the last released version: /ucspi-tcp-0.88# grep -hn maps.vix.com rblsmtpd.c 193: if (flagwantdefaultrbl) rbl("rbl.maps.vix.com");
Looks like that could be a cause of some of your pain... Not everyone runs rblsmptd on their mailserver, but I know lots of large mail servers that run rblsmptd (qmail).
The fact that the option is the default without being explicit means that at least some folks don't even know maps.vix.com zones are no longer present and the current failure case is not impacting them. The solution then:
maps.vix.com. IN NS a.ns.yp.to. maps.vix.com. IN NS b.ns.yp.to. / Mat
Thinking this out, out loud. Well, in black and white, anyway. Your vix.com name servers are authoritative for the zone. If a name server wants to do a lookup on maps.vix.com, it will get it from cache, or send a query to the listed IP address for one of the name servers. You said you had tried, e.g., putting up a maps.vix.com zone with a huge negative TTL - or did you say negative TTL? - but that would only work for multiple queries for the same value from the same name server. I don't see a clean way to "poison" even a large number of caches to forget about you completely. Does a large negative TTL on vix.com really not reduce the traffic much? But then that hurts you when you add a new record, if someone has been trying to get to that record. And there are name servers out there that ignore negative TTL. The only way for it not to arrive at the name server is for something in the way to block it. Perhaps a transparent filter, or perhaps the IP addresses of the "name servers" are your firewalls, which will block and pass the rest on to the real name servers behind them. Or maybe that's more work than it's worth. ;-) Is anything suffering besides your logs? -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
<snip>
The only way for it not to arrive at the name server is for something in the way to block it. Perhaps a transparent filter, or perhaps the IP addresses of the "name servers" are your firewalls, which will block and pass the rest on to the real name servers behind them.
The problem here is, most people that have experiences this problem, are significantly overwhelmed with traffic of people so much as trying to do a lookup, even if you firewall it you are still going to get an array of queries. In some cases, also, firewalling these queries makes it worse as servers will query multiple times, where as if you give a response with a large TTL they will go away. But then you have to have enough server power to handle these queries (and outbound bandwidth to match). I don't know how much of an impact there is in this case but I know of other people who've had this exact same problem and the traffic load of the attempted queries was immense. Cheers, Trent
On Thu, 1 Feb 2007, Trent Lloyd wrote:
<snip>
The only way for it not to arrive at the name server is for something in the way to block it. Perhaps a transparent filter, or perhaps the IP addresses of the "name servers" are your firewalls, which will block and pass the rest on to the real name servers behind them.
The problem here is, most people that have experiences this problem, are significantly overwhelmed with traffic of people so much as trying to do a lookup, even if you firewall it you are still going to get an array of queries.
In some cases, also, firewalling these queries makes it worse as servers will query multiple times, where as if you give a response with a large TTL they will go away. But then you have to have enough server power to handle these queries (and outbound bandwidth to match).
I don't know how much of an impact there is in this case but I know of other people who've had this exact same problem and the traffic load of the attempted queries was immense.
We can discuss this forever. Paul can either maintain the service until he is sick of it, and hope they go away - or kick it. He waited long enough that even if we don't agree, hopefully non of us will have arguments with him. Depending on time investment issues, contacting some of the big hitters and seeing why they hit him may be interesting and may help stop a lot of these. Some generic emails to the hitters may also be an over-kill, but would satisfy some of the prettier souls among us. Gadi.
We've told people for years that when they choose to use a DNSBL or RHSBL that they need to (a) subscribe to the relevant mailing list, if it has one and/or (b) periodically revisit the relevant web site, if it has one, so that they can keep themselves informed about any changes in its status or policies and/or (c) pay attention to what their own logs are telling them. They have not listened, for many values of "they". Maybe it's necessary to speak to them in a language they understand, despite the large downside of doing so. As someone who has had his own lapses into denseness, I can certainly understand that this isn't pleasant, but on the other hand, the lessons I've learned that way have been sufficiently clear that I've never made those particular mistakes again. I would argue that among the lessons here are "do not hardwire any DNSBL/RHSBL into any piece of software" "do not blithely use any such piece of software and assume it'll work" and "if you choose to use a DNSBL/RHSBL, then pay attention". <chuckle> Perhaps you should list (in the zone) all IP addresses which are repeatedly querying the zone -- after announcing this policy, of course. ;-) More seriously, I'll see what I can do to pass the word along in the faint hope that this will have some effect. ---Rsk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 1, 2007, at 6:44 AM, Rich Kulawiec wrote:
<chuckle> Perhaps you should list (in the zone) all IP addresses which are repeatedly querying the zone -- after announcing this policy, of course. ;-)
Actually, looking at that list it looks like many of those addresses (including the top vote getter) are just someone's caching proxy. Probably wouldn't hurt much since those machines probably aren't relaying mail but it also wouldn't have the effect you are looking for. Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) iD8DBQFFwgT0ElUlCLUT2d0RAouSAKCADcqbnww+XbOkAriKDq3bz/gaPgCdEmS5 wrNkoPMJQ9gux5dcEQMcLQ4= =/CCE -----END PGP SIGNATURE-----
On Jan 31, 2007, at 5:57 PM, Paul Vixie wrote:
bear with me, this appears to be about DNS but it's actually about e-mail.
maps.vix.com has been gone since 1999 or so. mail-abuse.org is the new thing. i've tried just about everything to get traffic toward the old domain name to stop... right now there's a DNAME but it made no real difference. i've taken the maps.vix.com domain away. i've set its NS to "localhost". i've put long
Instead of using localhost how about you set the NS record to 'baddns.vix.com' and have an A record pointing to some of your dead IP space. That way the RBL client on the mail server will wait for a while attempting to connect to a dead machine. This will create a log jam at the inbound SMTP daemon, spinning off lots of processes, hopefully jacking up the load on the box and tweaking somebody's interested. Maybe even a tarpit type machine that can string the RBL client along long enough to cause enough delay/processes on the server to mean something. It is probably safe to assume if they are still using the domain after 8 years they probably don't have timeouts set for the RBL client lookups. Route the dead IP to a bogus LAN so you don't ARP yourself to death. -Matt -- Matthew S. Crocker President Crocker Communications, Inc. Internet Division PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com
participants (31)
-
Andrew - Supernews -
Andrew Kirch -
Barry Shein -
Brian Wallingford -
Chris L. Morrow -
Chris Owen -
David Ulevitch -
Derek J. Balling -
Gadi Evron -
Gregory Taylor -
Jay Hennigan -
John Levine -
Jon Lewis -
Joseph S D Yao -
Ken Eddings -
Mark Foster -
Matthew Crocker -
Matthew Kaufman -
Matthew Sullivan -
Michael Froomkin - U.Miami School of Law -
Paul Vixie -
Paul Vixie -
Randy Bush -
Rich Kulawiec -
Roland Dobbins -
Ross Hosman -
Simon Lyall -
Steve Sobol -
Tony Finch -
Trent Lloyd -
Warren Kumari