Re: [BULK] Re: SORBS contact
William Herrin wrote: > On Fri, Jul 29, 2011 at 2:46 AM, wrote: > >> And you might want to fix it, since your users will never get a bounce notice >> from any RFC-compliant mailer - even if they *wanted* to know that their mail >> wasn't delivered. <> is the RFC-standard way to denote "this mail is a >> bounce >> report or other programmatically generated mail, and if it bounces itself, >> do *not* >> generate another bounce, as that may start a bounce loop". >> > > Correction: It's a standard way to denote that "this mail is a bounce > report." Umm no... As has been pointed out by others, but in another section (maybe another RFC) it says that the null return path should be used when a return message is not required, not desired, or it is from an automated system or you wish to avoid mail loops (with particular reference to bounce messages and mailing lists.) The registration email has a null return path because people will put in forged addresses and we don't want them to do that in the first place, and if they do it, we certainly don't want any auto-responder from replying or it going to a mailing list (most mailing list software prevent delivery of null return path mail to the list members) - seems the like most responsible and desired setup.. which is why I chose it. Note (to answer another mail in this thread): MAIL FROM:<> and 'From: ' in the headers to be completely within standards (previously it used in the headers as well which is a violation of an RFC - I forget which one.) Michelle PS: Baracuda are not the only ones, Ironport has an option for it as well - but I believe the default in Ironport is 'Off' for bounce control. -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/
Re: SORBS contact
William Pitcock wrote: > On Thu, 28 Jul 2011 12:31:13 -0700 (PDT) > "Brian R. Watters" wrote: > > >> We are looking for a SORBS contact as their web site and registration >> process is less than friendly if somehow you get listed by them. >> > > As I recall it, you can manually create an account on their > request-tracker instance and open a ticket through that requesting > delisting... however, complaining on NANOG is probably just going to > result in a less than friendly response from Michelle (at least as > history as shown). > You have to have an account first. However you can create a ticket via Email if you use one of the input addresses for a queue (eg: supp...@support.sorbs.net). Friendly or non friendly response is usually gaugable in advance by the tone of the initial email. Regards, Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/
Re: [BULK] Re: SORBS contact
Landon Stewart wrote: > On 28 July 2011 14:16, Brian R. Watters wrote: > > >> Thanks .. their attempts to reach us are blocked via our Barrcacuda's due >> to the fact that they are sending with a blank FROM: and as such Barracuda >> thinks its SPAM .. just to darn funny .. I have whitelisted their domain so >> on my fourth attempt we will see .. Cant create tickets or communicate with >> them unless you have an account and you can not get an active account unless >> you can get an email to activate it .. very frustrating to say the least. >> >> > > "In Soviet Russia - Network block SORBS!" - Yakov Smirnoff > > Ok, he didn't really say that one. Seriously though, in the past I've found > their website so slow and generally parts were broken I couldn't use it. I > tried to email webmaster@ and some other addresses about issues with the > site but my emails were all blocked for whatever reason I can't recall. I > probably spelled my own name wrong or something in my signature and it was > detected and summarily blocked. Maybe its better now though, I'm not sure. > We haven't had much need for it lately . > > Emailing random non-existent email addresses (such as webmas...@sorbs.net) will earn you a listing... -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/
Re: [BULK] Re: SORBS contact
Dan Collins wrote: > On Sat, Jul 30, 2011 at 12:43 AM, Michelle Sullivan wrote: > >> Emailing random non-existent email addresses (such as >> webmas...@sorbs.net) will earn you a listing... >> > > webmaster@* isn't "random", it's a fairly standard way to reach the > administrator of a service. A failure to support that on your part > does not constitute abuse on my part. > > --Dan > > Feel free to point out the RFC/STD/BCP that states that (yes, there is one for abuse@ and postmaster@.. last time I checked there wasn't any mention of webmaster@ - both abuse@ and postmaster@ are valid addresses that go to real people, neither will respond to any type of delisting requests.) FWIW, you get an error on the SORBS website you get the email address to reach the administrators, it is not webmaster@, it's a lot more um... appropriate. SORBS gets messages to a lot of um "Standard" email addresses (eg sales@, marketing@, legal@, www@, root@, etc) which don't exist (and several that do exist or used to, eg noc@, support@, help@).. which I do smile at as it seems people who should have more sense, just don't. Every email address published for SORBS goes to a real person either directly or via RT (ticket type tracking system) and there are quite a few published email addresses... using something that is not published is not likely to get to a person and is most likely abuse. webmaster@ has never been a valid email address at SORBS and previously when people have commented on not getting a response I have indicated that it is not and has never been a valid address (and IIRC I have mentioned that on NANOG before) Yet people still use it... Addresses that used to exist and are not to be used any more, either re-direct to the appropriate contact or reject at the MX with an appropriate reason message. Everything else is fair game for the spam collectors. Regards, Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/
Re: [BULK] Re: SORBS contact
Rich Kulawiec wrote: > On Sat, Jul 30, 2011 at 01:45:52AM -0400, Dan Collins wrote: > >> On Sat, Jul 30, 2011 at 12:43 AM, Michelle Sullivan >> wrote: >> >>> Emailing random non-existent email addresses (such as >>> webmas...@sorbs.net) will earn you a listing... >>> >> webmaster@* isn't "random", it's a fairly standard way to reach the >> administrator of a service. >> > > Per RFC 2142 section 5, it's the standard way to reach the administrator > of the HTTP service, just as "hostmaster" is the standard way to reach > the administrator of the DNS service. So you're both wrong: SORBS, > since it has a web site, should support the "webmaster" address; and > you shouldn't send traffic there unless your enquiry is about the > web site (e.g., difficulty accessing it, broken links, malformed pages). > > ---rsk > > Ok I'll accept that reference..I must admit I didn't know that RFC/STD existed so I learnt something today. ;-) I would like to point out though that in section 1 it states 'are encouraged to support' not must or even should, a quick skim read later and I see there are mention of those that are required to be supported later in the document, Webmaster@ is not in the required list. As per my previous email, the webservers (all of them) report another email address which is more appropriate for our organisation, and will feed all mail to a real person or into a ticket system in a queue for bugs and errors with the SORBS service as appropriate (this does not include any reports about content of the DNSbl, there are other addresses published for that.) Thanks, Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/
Re: SORBS contact
Paul Graydon wrote: > It's pretty much customer service 101 to ensure that you keep your > communications as neutral and polite as possible, regardless of how > frustrated or vilified you feel by the person you're supporting, and > regardless of how tired you are of accusatory tickets. Being snarky > back gains little, if anything, and just helps promote a bad > reputation. People forget good customer service (unless it surpasses > that to brilliant), but remember bad service. > You will find that all responses from SORBS support staff to support requests are very helpful, polite and customer service orientated - there have been many exceptions in the past, but for sometime we have been working on it to ensure that the issues of the past are not repeated. Note: threats (legal or violence) are not answered by support staff, there is a blunt and factual templated response that goes out to any such messages. That said, emails to people directly that either do not deal with support, or are not support email addresses may not get the same polite helpful response. I think most of us have experienced that from many organisations past and present, and SORBS is certainly has been on *that* list. Regards, Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/
Re: [BULK] Re: SORBS contact
Ken Chase wrote: > On Sat, Jul 30, 2011 at 02:57:12PM +0200, Michelle Sullivan said: > > >Ok I'll accept that reference..I must admit I didn't know that RFC/STD > >existed so I learnt something today. ;-) > > That's pretty rich. > > You enforce people to adopt standards that are part of proposed RFC's, not > official by any standard, jump through 18 other hoops, and still won't > delist them because some bit in their named replies is the wrong number of > electronvolts on your wire, and then claim you dont know an RFC? > > p.k.b. > > /kc > What's the current RFC/BCP and STDs count? I'm sure you remember at least 95% of them by heart and can recite them word for word, just like me..! -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/
Re: [BULK] Re: SORBS contact
Jimmy Hess wrote: > On Sat, Jul 30, 2011 at 7:57 AM, Michelle Sullivan <mailto:matt...@sorbs.net>> wrote: > > Rich Kulawiec wrote: > > On Sat, Jul 30, 2011 at 01:45:52AM -0400, Dan Collins wrote: > [snip] > > later in the document, Webmaster@ is not in the required list. > As per > my previous email, the webservers (all of them) report another email > > [snip] > > > I wouldn't fault SORBS for not supporting optional addresses such as > webmaster@. > I would fault SORBS for automatically listing someone e-mailing > webmaster@ though, > as implied above. Whether the actual RFC existed or not. > > It's probably true that all the standard addresses are likely to be > subject to abuse. info@ sure is. > > However, they should not be listed without at least analyzing the > content of the actual message. > To decide if it is in fact abuse, OR if it's just a human failure, > somebody attempting to contact > an admin address/service that does not exist. > > There mere act of attempting to contact multiple standard addresses > alone, is certainly > not proof of abuse. A valid and well put argument. I don't know what we do with stuff to webmaster@ however I do know that it is possible that messages to it will go into the spamtrap system. (the spamtrap system has multiple entry points, and a mail going in does not guarentee a listing, but it is likely, especially if the message is repeated to multiple addresses and therefore is 'bulk'.) Michelle -- Vulnerabilities are weaknesses associated with an organisations assets that maybe exploited by a threat causing unwanted incidents. http://www.mhix.org/
Re: Urgent: rack mounting kit / rack shelf
If it's not 'standard' weird stuff in Sunnyvale (area) also has a big selection of pre-loved kits.. Michelle Michelle Sullivan http://www.mhix.org/ Sent from my iPad On 05 Jul 2013, at 22:16, Mike Lyon wrote: > Frys on Kifer have them as does Halted Specialties at Lawrence Expwy > and Central Expwy. > > -Mike > > Sent from my iPhone > > On Jul 5, 2013, at 12:56, Ilan Erenstein wrote: > >> Tim, >> >> You might want to check out Central Computers. I used to work in the area >> so there are tons of them around. >> >> Here is the shelf that might work for you: >> http://www.centralcomputers.com/ccp85433-startech-adjshelfhdv-1u-19--adjustable-vented-rac-adjshelfhdv-misstashel2r.htm >> >> And here is the manufacturer spec for it: >> http://de.startech.com/en/Server-Management/Racks/1U-Adjustable-Depth-Vented-Rack-Mount-Shelf-Heavy-Duty-Fixed-Server-Rack-Cabinet-Shelf-250lbs-113kg~ADJSHELFHDV >> >> My advice is to call ahead and make sure they have it before you go down >> there. >> >> -Ilan >> >> On Jul 5, 2013, at 12:40 PM, Tim Vollebregt >> mailto:t...@interworx.nl>> wrote: >> >> Hi, >> >> Colleagues are racking some very heavy routers in the Equinix SV1 (San Jose) >> location and are in need of rack shelf or a universal rack mounting kit. >> >> Does anyone know stores which might have these in stock in the SV area? >> >> Thanks in advance >> >> Tim >> >> Sent from my mobile device >> >
Re: Is there anyone from ASPEWS on this list?
John R. Levine wrote: So write to her from a gmail account. APEWS is pretty kooky, and I'm kind of surprised if SORBS is using it. We use ASPEWS not APEWS (there is a vast cookiness difference). Shells
Re: Is there anyone from ASPEWS on this list?
Seth Mattinen wrote: You should still be able to submit a ticket to SORBS, no? I was always under the impression that it was "open a ticket and wait or you are moved to the back of the line" with SORBS. That is correct on all counts. The ticket engine is web based and has an interface to email, so anyone listed on ASPEWS (or any other DNSbl we use) can still report issues with ASPEWS (for our continual evaluation on whether to use it) as well as log support tickets and issues about SORBS listings. The initial reply from the support ticket will give you an email and password that will allow you to login to the support interface. Regards, Michelle
Re: Is there anyone from ASPEWS on this list?
John Levine wrote: ASPEWS is listing 216.83.32.0/20 as being associated with the whole Atrivo incident of 2008. My memory does not recall 216.83.32.0/20 being involved, nor the provider that belongs to. Since nobody but the occasional highly vocal GWL uses ASPEWS, Guess I'm a highly vocal GWL then .. ;-) (what ever GWL means) Shells
Re: Is there anyone from ASPEWS on this list?
Michelle Sullivan wrote: Seth Mattinen wrote: You should still be able to submit a ticket to SORBS, no? I was always under the impression that it was "open a ticket and wait or you are moved to the back of the line" with SORBS. That is correct on all counts. Oh and to re-iterate a point made so many times in so many forums and so often ignored. Posting to any of my email personal addresses will not help your case at all.. ever.. in any way... and in fact posting to some of the old and disused ones will likely cause a spamtrap listing. SORBS Support is done through the SORBS support system (which is what it is there fore funnily enough!) Posting on mailing lists, or emailing to me, other SORBS staff, or GFI will result in various responses from completely ignoring you to sending you a PDF that tells you that you can only gain support through the SORBS support system - NO EXCEPTIONS. The only thing my email address is valid for is if the SORBS Support system is down for telling me such (and I have plenty of systems monitoring all components of it so an email is pretty pointless in most cases.) Robot rejection and refusal to delist is not a failure in the support system... Read the response and act upon the contents if you want a review. Sorry if that sounds harsh, but when you had seen even a couple of the idiotic messages I get, you'll understand why. Logging a ticket is simple if a little ownerous (it takes 7 clicks to get a ticket logged, 3 if you use the contact form!) Michelle PS: Here is an example or 5 of tickets logged in the support system (unedited except for the last) and all in the queue that specifically states "do not send listing or delisting requests here"... Name: Yiannos Efthymiou Company: AT Multitech Corporation Type: company Primary OS: windows Skill Level: admin DB: Yes a windows admin logged a support ticket with no IP address or domain, or well.. anything... Name: Andrzej Wojciechowski Type: person Primary OS: windows Skill Level: luser DB: And another .. these are the total contents of the tickets (email addresses are stored in the headers which I haven't reproduced for privacy... Name: german perez Company: roulette partners s.a. Type: company Primary OS: unix Skill Level: admin DB: Number 3.. ok now I'm going to skip down tickets until I find something other than just the auto-inserted stuff... This one logged no less than 3 of the same tickets... Name: Danilo Jaramillo Company: sistemas inalambricos Type: company Primary OS: unix Skill Level: admin DB: Additional Information: why if the ip it's not used, you do not delist automatically??? ... thought: "If it is not used how did it get listed in the first place?...and another... Name: Vladimir Goloshchuk Type: na Primary OS: windows Skill Level: admin DB: Additional Information: Our ip used to be listed in more than 10 blacklists due to the spam breaks. We have cleaned our system and most of email blacklist databases have white listed us. There are only 3 databases left that still have our IP blacklisted. your database is one of them. Please white list our IP as email is a vital part of our customers business and this prevents from sending/receiving legitimate emails with other clients. Regards, Vladimir Each of these have gone to http://www.sorbs.net/cgi-bin/support and clicked "No" to the question "Do you need help or support about a listing, delisting, or blocked IP address?" (it defaults to "Yes")* * They have also clicked through the following text: Please Note: Logging a support ticket about a listing using this form will result in nothing happening; you will not receive a reply from the support staff; nor will the request result in a listing or delisting. This form is for all the requests other than those for listing and delisting addresses, domains or mail servers. We also receive delisting request via the same method * *Name: Chris ** Company: Communications Type: company Primary OS: windows Skill Level: admin DB: Additional Information: We currentlym have a router with in our network that has its NAT listed with you. We have recently taken steps to elimanate this probelm. The IPs in question are within this subnet 24.***.***.225/29. Please let me know if we could have these delisted. Best Regards, Chris * Communications Inc. ***-***- **...@**.ca This one I did edit to remove the identifying details. It's obvious the person speaks English, so there is not the defense that they didn't understand the "STOP" sign or the text I have already posted. NO I DO NOT ACCEPT DELISTING REQUESTS OUT OF THE SUPPORT SYSTEM! Michelle
Re: Is there anyone from ASPEWS on this list?
William wrote: Hi, Perhaps people wouldn't have to email you if the robot actually did what it said it was going to do. Your website promises that the robot will get things delisted out of the DUHL zone in "3 to 5 hours". Please feel free to show me *any* SORBS webpage that says this because the robot cannot delist you, it just approves you for delisting. It has been more than "3 to 5 hours", and it is costing me money. Considering that you shouldn't have listed the space to begin with, I think it would be fantastic if you updated the website to reflect the reality of the situation. Then tell me where it says 3-5 hours and I'll correct the text. While I am sorry to hear that most of the people you deal with are morons, it does not change the facts that SORBS listed IP address space for no valid reason, other than the first version of the RDNS not having .static. in it. The robot doesn't list or delist so the entry was added at some point because of either spam, or it's an old entry that has not had any requests to update. The robot will reject certain patterns of DNS, you can always reply to the ticket as the whois contact to get delisted outside of what the robot says (as it says in the robot reply) thought it should be noted that I don't care who contacts me, if the rDNS is clearly dynamic (eg: ..dyn..) you're not going to get delisted at all. Perhaps if this sort of thing didn't keep happening, on a regular basis, we would never hear about SORBS, MAPS, or any other RBLs on NANOG in a bad light. Personally, I like SORBS. I would like to continue to be able to use SORBS on my mail servers. The fact that my addresses are listed as being dynamic in SORBS when they are not, and it hasn't been fixed in the timeframe that the website promises it would be fixed in, is making me re-evaluate whether or not I should use SORBS and recommend it to people looking for good DNSBLs to use on their mailservers. > NO I DO NOT ACCEPT DELISTING REQUESTS OUT OF THE SUPPORT SYSTEM! Then you should make your delisting process more streamlined. You already have a robot for most things, make it do the next step and just delist the IP ranges it is given. The process has been more and more streamlined as time has progressed. The support system will ask questions and will allow you to either delist or request delisting very easily. If you are an ISP you can (at the moment) use the mail/contact form to submit a request to the manual queue immediately... and anyone can send requests by email to the support system bypassing the whole "we'll gather the information via a web form" script, but the robot will reply, and if you do not meet the acceptance criteria by the robot you need to read the message and act upon it (eg: it will usually tell you to reply to the ticket after correcting something). In your case I have reviewed the address space and I see the robot will approve it for delisting, no questions (or should do) however it will have replied with something like the following: I'm a robot writing you on behalf of the SORBS' admins. The reason you're getting this automated response, is our desire to provide you with consistent and fast responses. I'm prepared to correctly analyze most of the cases appearing in the DUHL queue. You might want to keep your responses as short as possible (and to trim my own responses) to help humans better serve you should the need arise. I'm glad to report that the IP space will be submitted for delisting from the DUHL. Best regards. SORBS Read the last paragraph again.. "will be submitted for delisting" .. not "has been delisted and it will take 3-5 hours to propagate"... I have to process all removals manually after the robot because the robot does get it wrong, and then you have the likes of JustHost and the spammers there that keep requesting delisting with totally bogus (but static looking) hosts. Michelle
Re: Is there anyone from ASPEWS on this list?
Bill Weiss wrote: Michelle Sullivan(matt...@sorbs.net)@Mon, Dec 14, 2009 at 11:32:48AM +0100: Then tell me where it says 3-5 hours and I'll correct the text. On http://www.au.sorbs.net/cgi-bin/support , I read: "This will route any created ticket to the robot handler which will process and delist the netblock (upto /24) within a few hours" That says the robot will delist (not schedule to delist) "within a few hours". Thank you, I wasn't aware, and it will be corrected (doesn't say 3-5hours still so I'd love to find that one). Michelle
Re: Is there anyone from ASPEWS on this list?
Kevin Stange wrote: On 12/14/2009 04:32 AM, Michelle Sullivan wrote: I'm a robot writing you on behalf of the SORBS' admins. The reason you're getting this automated response, is our desire to provide you with consistent and fast responses. I'm prepared to correctly analyze most of the cases appearing in the DUHL queue. This last sentence seems to be my point of contention here. I am trying to get a /18 removed from the DUHL and every time the robot tells me some arbitrary ranges I did not mention explicitly are being tested and/or not eligible for delisting. Since the ranges not eligible are configured the same as those that are, I can't figure this out. Replying to the robot resulted in no response for a month, so I ended up submitting a ticket via the ISP contact form directly, with all the information requested, but the first time, someone just pushed my request back to the robot and it refused ranges again. This sometimes happens, particularly if the request doesn't come with an ASN and/or no authoritative contact (ie: not from the email used in the whois records for that netblock). For what it's worth using the following syntax when sending to d...@support.sorbs.net can force the robot's view: BEGIN SORBS LIST / . . . / END SORBS LIST Will force the robot to only look at the networks within the tags (case is sensitive) Submitting ranges over /16 with this method will result in ticket rejection. rDNS will be scanned in all cases, rDNS is cached locally for a minimum of 48 hours, so if you are rejected because some rDNS appears dynamic, you will need to get a human to manually rescan or approve for delisting, or wait 48 hours for the cache to be ignored. The cache is web viewable and publicly accessible, please email me offlist to miche...@sorbs.net if you want to know where the cache is. I understand you get a lot of traffic to your ticket system, but I have to wonder whether a system which is so complex and large that it is near impossible to support and keep maintained accurately is actually still useful. I assume you love (to some degree) helping kill spammers, but maybe you need to solicit (screened) volunteers to expand your staffing? We do, and getting technically clueful people who are trustworthy seems to be an issue. We got hit by the 'trustworthy' aspect some time ago, and the clueful aspect is a regular problem. I am hoping that the buy out by GFI will provide some paid 24x7 staff, obviously I cannot comment about where that is going any further, but we all know things take time Currently I am working full time on processing tickets as well as other duties in relation to improving all systems, but I actually need to stop answering tickets completely to complete those other systems... Those other systems will allow approved entities to access the SORBS database directly (and not just for DUHL requests) this system was devised in 2003, initially developed in 2004 and promised in 2005 however with everything that has happened to me in the last 4 years it has been delayed, delayed and delayed yet again. Patience seems to be the key for all concerned as there is currently only one of me. Michelle
Re: Arrogant RBL list maintainers
Ronald Cotoni wrote: Very true. At my old place of employment a DUHL listed an ip since before my previous company existed. For some reason, when we obtained it, they still listed it. Sounds like a bug in the DUHL bot to me. Also the standard makes a lot of sense. You may be on Trend Micros DUHL by following the rules on SORBS DUHL and vica versa. Makes life a pain. If you set non generic rDNS or generic following their suggestions you'd be removed from the SORBS DUHL pretty much automagically (a request initiates the rescan) - there is manual stuff on my behalf but nothing for a requestor to worry about. The only reason you wouldn't be is if you had a listing and too short a TTL for the robot to accept the delisting request... A reply would result in a human (usually me) processing netblocks of /24 or greater (greater as in number of IPs) providing the TTLs were not shorter than 1 hour. That is well documented in many places. Seems according to their rules if you follow the SORBS DUHL rules you'll also be delisted from them. To add my $0.02 I agree with many of the replies... If you have one generic pattern for a /16 you either: Don't care to setup DNS. Don't know how to setup DNS. Don't care what's in the netblock. Don't have the competency to run a network/mailserver/dnsserver/what ever>. In all the cases above I would not want your mail as it is 99.999% likely to be abusive in nature (spam, viruses etc.) Oh and many know I don't care if you are Peer1, Level 3 or Joe Blows Backyard VISP in outback Australia, you're all the same to me, you should all have competent people on staff, the only thing that changes between you is the number of *your* customers, and the amount you charge. Similar issues apply when looking at *.edu's vs *.com's, *.au's, and *.mt's. Just because you come from a certain country or certain type of establishment, doesn't make you different, it's only the number of people you service, you should still have competent staff. If you don't have enough staff that's not my problem (nor the rest of the world's) though it usually results in our problem when abuse starts flowing. I know most here are the admins and staff, so sorry if it sounds like I'm having a go at you guys, but really most on this list are the competent admins, a minority being people learning (nothing wrong with that!) but unfortunately there are some who are not and they don't care that they are not. I know that makes me an arrogant w***er, or another one of those "Arrogant RBL list maintainers" but think about it, and think about the following... Would you like to be prioritised down the queue because someone else was supposedly more important? . What happens to the poor mum and dad VISP in Somalia that never gets delisted because Telstra is logging 100's of tickets every day because their super size and constant rotating listings? . What happens if Telstra have a single IP blocked and Sprint come along and request delisting for a spamming customer's netspace they once hosted? Should we (RBL Maintainers, SORBS or anyone else) push the largest ISP in Australia out of the way for the bigger USA based Sprint? If not should we push the mum and dad operation out of the way for Telstra? . The obvious answer is if you have signed SLAs then you should adhere to those SLAs as a minimum and give better service if time allows... Hands up those who have an SLA (free or not) with an RBL maintainer... I don't expect to see any hands... . my answer to the question above is a very obvious take every issue in order, and if you get a super high priority issue, deal with it if necessary, but size of the ISP (or size of the admin's d***) is _not_ the prioritising factor. Note: Names chosen and mentioned above have no baring on any current abuse level or any logged issue, they are for example only. I don't want answers to the questions, I know some will post to the list or me regardless... it's stuff for *you* to think about when dealing with organisations such as RBLs.. especially when they are volunteer run. A little example about "arrogance" when it comes to ISPs... I know at least one member of this list (an ISP) has posted to every address in GFI in the last few days that they could think of (including the CEOs email) because their spamming netblocks have not been delisted. They have previously stated they would not deal with SORBS, so what changed, well as they found out in an email, nothing, they still need to log a support ticket, and their out of band request just pushed them down the queue. Sad thing based on their ticket ID, had they waited another 2 hours they would have been answered, now they have 112 manual processing tickets before theirs. I'm sure they'll guess who they are, I'd advise them to be patient or they might push themselves down further. ... and then of course there are some RBL Maintainers (
Re: Arrogant RBL list maintainers
Mikael Abrahamsson wrote: On Wed, 9 Dec 2009, Frank Bulk wrote: Two sides of an SP's coin: I want to maximize my e-mail servers' deliverability, so I make sure those have appropriately named PTRs and make sure that outbound messages aren't spammy; I also want to restrict The point he was trying to make is that there is no standard for what those "appropriately named PTRs" should look like. He has forward/reverse that is perfectly ok according to standard (forward/reverse matches) and if he had a automatic dictionary for naming those IPs instead of putting the IPs there, things would be different. If people want to make standards on how to put information into DNS for RBL use, they should take it to the IETF and make a standard out of it, not just ad-hoc I did.. a number of people went out of their way to bury it. One of who would do anything to bury anything SORBS does (I think we all know who that was.) create something of their own and expect everybody else to conform. If there is an "industry standard" (which the replies here seem to indicate), that should be written down and standardized by the people who actually make money out of it, in this case Trend Micro. This would remove the problem of having to maintain tens or hundred points of contacts for "what is dynamic dialup space" which is the problem right now as there are a lot of RBLs to deal with. Creating a standard on what to put in WHOIS/DNS for dynamic/static/infrastructure would make a lot of sense, seems nobody is doing it though. 100% with you ...and if people used "static" and "dynamic" keywords in DNS as I suggested in my previously mentioned draft, there would be *NO NEED* for DUL/DUHL/PBL lists at all because people could create a very simple set of patterns to match and therefore the RBLs would be unneccessary.. (and it would save me about 10 hours a day, every day of the week, every week of the year!) Currently I have a few 100 patterns and I know another on this list has more like the region of 10k patterns to do what in reality one should be able to do in 2 (10 at the most!). At 10k patterns it becomes a lot cheaper to use DUL/DUHL/DYNABLOCK to block dynamics, does anyone wonder why people do? Regards, Michelle
Re: Arrogant RBL list maintainers
Please reply to the list, not me and the list! Sven Olaf Kamphuis wrote: thing is that it's illegal to maintain a database with "personal details" which ip addresses according to various german courts are (don't ask.. mmk? ;) ofcourse we all know ip addresses identify nodes on a network, not persons, but the germans seem to mainain a different view on this, despite us isps being the owners of the internet and not the german government ;). therefore we are not even -allowed- to cooperate with trend micro *grin* sometimes laws really come in handy you know ;) Based on what you say there, then the RIPE whois database cannot contain the information either because it to would be maintaining a database of "personal details"... Love to hear the legal battle on that one! Michelle
Re: Is there anyone from ASPEWS on this list?
Kevin Stange wrote: On 12/15/2009 10:17 AM, Michelle Sullivan wrote: Thank you, I wasn't aware, and it will be corrected (doesn't say 3-5hours still so I'd love to find that one). There is this text I see, which seems to disagree with the robot's behavior in my case (from the Dynamic IP FAQ): "The Regional Internet Registry (RIR) Point of Contact (PoC) can request a listing or delisting of any address in their space. The only time this will be refused is when the netblock information in the RIR or in the reverse DNS naming clearly indicates the addresses are dynamically assigned (e.g. 0.1.pool.example.com). " I'm sending my request from our PoC and it's not taking my word for it like is claimed here (since the reverse DNS certainly doesn't imply the ranges are dynamic). If you don't consider this part of the policy anymore, you might want to clear that up in the FAQ. The robot has code to query whois, but we choose not to activate it (due to the possibility of abuse of the whois servers.) Mailing the ISP-support queue and identifying yourself as the RIR PoC will not result in the robot processing your message (unless supervised by a staff member aka me - sometimes I use it to do the ground work for me, not forgetting that clearly named dynamic rDNS will result in the complete refusal of the delisting request regardless of who it comes from.) ISP-Support queue maybe mailed directly or by using the webform: http://www.sorbs.net/cgi-bin/mail (or if you have a login to the Support website already you can log a ticket directly via the web). Note: blocks of smaller than /29 will not be delisted without appropriate rDNS being set. We do use information in local rwhois servers for authority, but there must be a referral to an authoritative rwhois server at the RIR (otherwise it could be some spammer's or home user's attempt to fool us.) Michelle
Re: Arrogant RBL list maintainers
Niels Bakker wrote: * matt...@sorbs.net (Michelle Sullivan) [Wed 16 Dec 2009, 17:41 CET]: [..] . The obvious answer is if you have signed SLAs then you should adhere to those SLAs as a minimum and give better service if time allows... Hands up those who have an SLA (free or not) with an RBL maintainer... I don't expect to see any hands... How much would you charge a company for it to get taken off immediately after it hits your list? Nothing. I don't believe in such a practice because it would be fraught with the danger of being accused of pandering to spammers, extortion and blackmail. Its bad enough requiring a donation to charity for expedited delisting of just the spam DB entries. As for an SLA the only type I would consider (hypothetically) is a "we will provide a phone/pager number for you to call" or "we will answer your ticket by email within x hours" type SLA. In either case there would be a clause the states clearly that the SLA does not provide any sort of guaranteed delisting. Michelle PS: Have been asked to take this off list by someone who didn't identify themselves as a list manager, but they did it politely and I respect that, so all future replies from me to this thread will be offlist. Please feel free to reply to me *offlist*. Thanks.
Re: SORBS on autopilot?
telmn...@757.org wrote: Did SORBS really cause you that much pain? Yes. We purchased colo space for some systems that didn't need high class of service (mostly development systems.) The IP space in a former lifetime was a dialup pool for analog modems. We of course changed the reverse DNS entries, and did the normal request with SORBS. Nothign really happened. I started looking into it, and finding stories of people doing the mandatory $90 donation to get express attention, ...and at this point we know the poster (like a fair few other in this thread) is either talking c**p or mixing SORBS with some other list. There is NO donation required for non spam listings (a DUHL entry is not a spam listing) and $90 is plucked from thin air... a cursory look at the SORBS website will attest to that. Michelle Note: The original poster was noted to have never opened a ticket @ SORBS by one of the staff.. I haven't verified that personally, but it does follow a common theme.. People complain about listings and have subsequently been found to have *not* requested delisting through the correct channel (the SORBS support system)... I wonder how many would get this sort of response (a firey NANOG thread) if they complained their ADSL was broken to the yellowpages sales line...?!?!?
Re: SORBS on autopilot?
Ken Chase wrote: Anyone got some pointers on how to get off SORBS' Dynamic IP lists? We've followed their RFC proposed static reverse DNS assignment naming and all elements of their FAQ. We are not spammers. The /24 in question isnt listed on any RBLs except SORBS DUL. We've submitted requests in various different formats, but get a robot reply and -ENOJOY. We've even had our upstream that is listed at the RIR as managing the supernet of our BGP announced prefixes submit requests to delist for the /24, but we are only ever replied to by a robot that lists 67.196.137.0/24 as dynamic except .163 (somehow manually excluded from their db, I think when they werent adrift in years past). Our upstream's techs are also at a loss now and suggested I seek arcane clue amongst the sages here. Pointers appreciated. /kc OK, following my last post I have been given 4 ticket numbers for the same network. 3 appear to be from Ken using a different email address (hence why we couldn't find a ticket from him.) Normally I would not post a public response, but this case is what seems to be a reoccurring theme, so maybe it's time to post comment. Each of the tickets are similar in that they all refer to the same space. All were rejected by the robot with the following text at the end of the reply: I'm now marking this request as 'answered' as I think there's nothing more for me to do. If you feel otherwise, please reply to this message to re-open your ticket. In particular, if you change your rDNS information. Each of the 4 tickets (the three by Ken) are all sitting in the state of "Answered" ... so at no point has a human had chance to see the issue and override the bot's decision. The common a reoccurring issue is the response by the robot has given the next logical step to progress any delisting request (as has been stated here recently, in another thread).. and the requester has either not read the response or chosen to ignore the response or reason which results in not responding to the ticket>... then the come here complaining about not getting a response from SORBS. The reality is they got a response from SORBS and did not act upon the response. Sorry Ken, this is not having a go at you, but it is a very common theme and deserves airing. Other issues are where the appropriate contact (as listed in the whois record at the RIR) also ignore the same two sentences, get rejected by the robot and choose to log a new ticket only to get the same response over and over again. Is it bad English? Is it not clear? Can anyone else give better wording that might result in less of an issue? The process is relatively simple: For fast approval: Log ticket -> robot checks rDNS for all networks listed in ticket -> robot confirms all space is static and submits the ticket to the removals queue where it is manually checked by a human and processed. For manual approval: Log ticket -> robot checks rDNS for all networks listed in ticket -> robot denies delisting request sending response -> OP changes something and replies, just states they are the whois listed appropriate contact, or gives some reason why the robot is wrong and reopens the ticket with the reply -> SORBS volunteer reviews the available information from the robot and the subsequent reply from the OP and manually submits to the removals queue or rejects and gives a human response as to why (eg like with Shaw, Road Runner, Verizon, etc listings) the information is provided by the ISP and any delisting will be reversed within a week. No NANOG is not about SORBS and SORBS should not really be discussed here, but telling people they would be better discussing it on Spam-L will not help you at all as I cannot post there and consequently I have since unsubscribed, as I have suggested to all my staff. Messaging me directly about listings will not help your case, unless something has gone wrong (and since Jan 09 I have only had one issue where something went wrong in the SORBS systems, all other requests were without tickets or twits that logged a ticket and sent me the ticket number before the robot had replied because they thought they might get special attention.) The best thing anyone can do is read the automated responses (some are from the system as the ticket is logged, some are from the robots) completely, and act upon what they say as majority of the time this will result in a fast delisting.. Christmas Eve 2009, DUHL delisting requests were happening within an hour of requesting a delisting. My moving internationally and 30 hours in the air have slowed that process, but I intend to get it back to within 60 minute responses again by the end of January. Michelle
Re: SORBS on autopilot?
Ronald Cotoni wrote: At the same time, I never hear this about spamhaus or outblaze. Go figure :( Maybe your system is too confusing and you might want to take a survey and revamp it to something a bit more functional. I have never heard it about Outblaze, but I have heard "at least we get a reply from you unlike with Spamhaus" several times. The only thing I can't work out is why those people never post that publicly... and yet the same 50-100 people keep getting the same attention over SORBS time and time again. I love searching "SORBS Sucks" in Google and counting the number of hits that are actually the same people over and over again on multiple lists (especially Mr "Be good to pigeons".) The SORBS support system has become more and more stricter because of the people trying to circumvent the process. There are many people that have no problem at all with the SORBS support system so why it is so hard for a few? Perhaps it's because they don't really care about delisting but do care about making noise? (for example there are a number of people on this list that are here only to response negatively to SORBS issues.) Michelle
Re: SORBS on autopilot?
Ken Chase wrote: Fair enough, but it wasnt just me. I have the customer who submitted his own tickets as well, as well as NAC.net who has admins (an email admin, actually), who seems to know his way around RBLs and the current state/reputation/happenings in the spam/RBL/mail world. Customer has posted these tickets: 260573, 260695, 261026, 261204, 261325, 261377, 261624 260573 - waiting for a response from a SORBS admin (originally requested the /22, but really only meant to request a /32) 260695 - is 260573 261026 - waiting for response from the requestor (and is now merged with 260695 as it's the same host) 261204 - waiting for response from the requestor (and is now merged with 260695 as it's the same host) 261325 - waiting for response from the requestor (and is now merged with 260695 as it's the same host) 261377 - had no information about any ticket and was logged to the lowest priority queue, and is actually the same as the above from the same requestor. 261624 - waiting for response from the requestor (and 260573, 260695, 261026, 261204, 261325, 261377 are all merged into it as then are all for the same host.) and the last ticket I posted was from NAC's admin, who received and acted on replies too. The NAC admin had not replied to the ticket as I stated previously. That makes 3 semi-clued people who found your system somewhat confusing (+1 interested party @coplanar = 4). The ironic thing is that if you make it any clearer, spammers may also figure out how to clear their networks easily as well from your list. :/ So I can see the reason for not doing so to some extent. Well 3 people have ignored the last 2 sentences... so please tell me what is unclear in them? The only correct response was in 260573 when someone responded to the robot response. For the onlookers, please note that the SORBS stated reply time has been complied with in all cases, and had the other tickets not been logged for the same issue by the same requestor it would have been answered by today to stay in that response time compliance. Michelle
Re: SORBS on autopilot?
paul wrote: Michelle, Thanks for your email. Please specifically look at ticket 260695. I created the ticket on January 5th at about 1:30EST. Immediately I got my response from the robot. See my other message in addition. I replied a few minutes later with: 67.196.137.188/32 TTL is right. PTR is right. That is my view, however most (if not all) of the tickets were for the /22 not the /32 which is why it was rejected. From your email, it is my understanding this should have went to a human. I have no idea why my IP address wasn't accepted in the first place. And I have no idea why I didn't get a human response. So go back to the robot response and tell me where it says it'll be sent to a human...please...? A couple suggestions: -program the robot to give the exact reason why it is denying: TTL wrong or PTR indicates dynamic or whatever It does give several responses, however the more exact the response the more issues we have had with people not understanding the reply. Our response has been to format the message with a link to the FAQ where there is a lot more of a detailed response. I will review the response with your suggestions and see if we can change it to some sort of compromise. -kind of leaping to conclusions here, but possibly the robot is caching DNS? Which means even if what was broken had been fixed, the robot wouldn't see it? The robot caches results for 48 hours to prevent people launching DoS attacks on our systems as well as yours. The results are easily checked here: http://nemesis.sorbs.net:82///.txt eg: http://nemesis.sorbs.net:82/67/196/67.196.137.0.txt In this case you can easily see why the robot was unable to process the request... PTR's were requested from the nominated authoritive servers, only to receive a "NODATA" response (commonly seen if TCP responses are required or CNAMEs are returned without the PTR.) There is an issue with the robot and some correctly assigned classless delegations due to the way we process the data, there are various catches to correct this and re-process the network with a more reliable (but considerably more resource hungry) method. Unfortunately it's not fool proof though, which is why we tell people to respond to the robot response to get a human to review it. If anyone out there is knowledgable in Perl, C and DNS and wants to take a shot at fixing that issue I'd love to have the help. Michelle
Re: SORBS on autopilot?
Leo Bicknell wrote: So, let me see if I got this right: 1) Network reports 1.2.3.0/24 has no dynamic IP addresses in it. Networks don't report anything, people do, and in the majority of cases not the network owner (where network owner = person listed in the RIR as the POC) 2) SORBS robot reponds with "you must change your rDNS." ... or respond to indicate why you think the robot is wrong... 3) Profit? What profit? What your telling me is the SORBS list of "dynamic IP's" is in fact not a list of dynamic IP's. Rather it is the "SORBS list of things that have DNS names that look like dynamic IP's". No, it's much more. Delisting requests are processed in the initial instance by a robot to save wasting valuable human time as we have received several 1000 messages a day from dynamic users demanding delisting. The robot leaves us with 50-100 messages a day to process manually (for the DUHL only.) Michelle
Re: SORBS on autopilot?
Logan Vig wrote: Here are some tickets to review: 205929 206524 207964 208986 and for the /24's which finally resulted in the /18 being delisted: 208996-209062 Well from the initial look you kept submitting new tickets and the SORBS staff kept merging them into the latest ticket as previously stated. You in effect delayed any human response yourself and it looks like you managed to exploit a flaw in the system to bypass the delisting rules as you were not entitled to be delisted at the time. I'd suggest you might want to not push things or I will review the entire entry with a view to correcting any incorrect delisting. No that's not retaliatory, that's just correcting an error that you have just alerted me to... (if however, you are entitled not to be listed now, the entry would not be re-instated..) Michelle
in-addr.arpa server problems for europe?
I see constant issues where I can't resolve PTR's in Europe. I see no reason for this except that a bunch of servers are either dropping my packets or are permanently f**ked... any other clues gratefully accepted. miche...@enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364340 IN NS J.ROOT-SERVERS.NET. . 364340 IN NS K.ROOT-SERVERS.NET. . 364340 IN NS L.ROOT-SERVERS.NET. . 364340 IN NS M.ROOT-SERVERS.NET. . 364340 IN NS A.ROOT-SERVERS.NET. . 364340 IN NS B.ROOT-SERVERS.NET. . 364340 IN NS C.ROOT-SERVERS.NET. . 364340 IN NS D.ROOT-SERVERS.NET. . 364340 IN NS E.ROOT-SERVERS.NET. . 364340 IN NS F.ROOT-SERVERS.NET. . 364340 IN NS G.ROOT-SERVERS.NET. . 364340 IN NS H.ROOT-SERVERS.NET. . 364340 IN NS I.ROOT-SERVERS.NET. ;; Received 332 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms ;; connection timed out; no servers could be reached miche...@enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364195 IN NS F.ROOT-SERVERS.NET. . 364195 IN NS G.ROOT-SERVERS.NET. . 364195 IN NS H.ROOT-SERVERS.NET. . 364195 IN NS I.ROOT-SERVERS.NET. . 364195 IN NS J.ROOT-SERVERS.NET. . 364195 IN NS K.ROOT-SERVERS.NET. . 364195 IN NS L.ROOT-SERVERS.NET. . 364195 IN NS M.ROOT-SERVERS.NET. . 364195 IN NS A.ROOT-SERVERS.NET. . 364195 IN NS B.ROOT-SERVERS.NET. . 364195 IN NS C.ROOT-SERVERS.NET. . 364195 IN NS D.ROOT-SERVERS.NET. . 364195 IN NS E.ROOT-SERVERS.NET. ;; Received 512 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. ;; Received 224 bytes from 192.112.36.4#53(G.ROOT-SERVERS.NET) in 5256 ms ;; connection timed out; no servers could be reached miche...@enigma:~/dultools$ dig +trace -x 213.219.184.23 ; <<>> DiG 9.3.3 <<>> +trace -x 213.219.184.23 ;; global options: printcmd . 364138 IN NS E.ROOT-SERVERS.NET. . 364138 IN NS F.ROOT-SERVERS.NET. . 364138 IN NS G.ROOT-SERVERS.NET. . 364138 IN NS H.ROOT-SERVERS.NET. . 364138 IN NS I.ROOT-SERVERS.NET. . 364138 IN NS J.ROOT-SERVERS.NET. . 364138 IN NS K.ROOT-SERVERS.NET. . 364138 IN NS L.ROOT-SERVERS.NET. . 364138 IN NS M.ROOT-SERVERS.NET. . 364138 IN NS A.ROOT-SERVERS.NET. . 364138 IN NS B.ROOT-SERVERS.NET. . 364138 IN NS C.ROOT-SERVERS.NET. . 364138 IN NS D.ROOT-SERVERS.NET. ;; Received 500 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. 213.in-addr.arpa. 86400 IN
Re: in-addr.arpa server problems for europe?
Stephane Bortzmeyer wrote: > On Mon, Feb 15, 2010 at 10:22:17AM +0100, > Michelle Sullivan wrote > a message of 185 lines which said: > > >> 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. >> 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. >> 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. >> 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. >> 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. >> 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. >> 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. >> ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms >> >> ;; connection timed out; no servers could be reached >> > > It is highly improbable that all these name servers are unreachable > from you. Therefore, I suspect that *content* is the issue. RIPE-NCC > zones are signed with DNSSEC. Are you sure you do not have a broken > middlebox which deletes DNSSEC-signed answers? > > (I tried from an US/Datotel/Level3 machine and everything works.) > > > Thanks... F**Kin' PIXs! Michelle
Re: in-addr.arpa server problems for europe?
Michelle Sullivan wrote: > Stephane Bortzmeyer wrote: > >> On Mon, Feb 15, 2010 at 10:22:17AM +0100, >> Michelle Sullivan wrote >> a message of 185 lines which said: >> >> >> >>> 213.in-addr.arpa. 86400 IN NS NS-PRI.RIPE.NET. >>> 213.in-addr.arpa. 86400 IN NS NS3.NIC.FR. >>> 213.in-addr.arpa. 86400 IN NS SUNIC.SUNET.SE. >>> 213.in-addr.arpa. 86400 IN NS SNS-PB.ISC.ORG. >>> 213.in-addr.arpa. 86400 IN NS SEC1.APNIC.NET. >>> 213.in-addr.arpa. 86400 IN NS SEC3.APNIC.NET. >>> 213.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET. >>> ;; Received 224 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 20011 ms >>> >>> ;; connection timed out; no servers could be reached >>> >>> >> It is highly improbable that all these name servers are unreachable >> from you. Therefore, I suspect that *content* is the issue. RIPE-NCC >> zones are signed with DNSSEC. Are you sure you do not have a broken >> middlebox which deletes DNSSEC-signed answers? >> >> (I tried from an US/Datotel/Level3 machine and everything works.) >> >> >> >> > > Thanks... F**Kin' PIXs! > Then again miche...@enigma:~$ dig +trace +bufsize=512 -x 81.255.164.225 ; <<>> DiG 9.3.3 <<>> +trace +bufsize=512 -x 81.255.164.225 ;; global options: printcmd .352606INNSL.ROOT-SERVERS.NET. .352606INNSM.ROOT-SERVERS.NET. .352606INNSA.ROOT-SERVERS.NET. .352606INNSB.ROOT-SERVERS.NET. .352606INNSC.ROOT-SERVERS.NET. .352606INNSD.ROOT-SERVERS.NET. .352606INNSE.ROOT-SERVERS.NET. .352606INNSF.ROOT-SERVERS.NET. .352606INNSG.ROOT-SERVERS.NET. .352606INNSH.ROOT-SERVERS.NET. .352606INNSI.ROOT-SERVERS.NET. .352606INNSJ.ROOT-SERVERS.NET. .352606INNSK.ROOT-SERVERS.NET. ;; Received 511 bytes from 111.125.160.132#53(111.125.160.132) in 1 ms 81.in-addr.arpa.86400INNSSNS-PB.ISC.ORG. 81.in-addr.arpa.86400INNSTINNIE.ARIN.NET. 81.in-addr.arpa.86400INNSNS3.NIC.FR. 81.in-addr.arpa.86400INNSSEC1.APNIC.NET. 81.in-addr.arpa.86400INNSSEC3.APNIC.NET. 81.in-addr.arpa.86400INNSSUNIC.SUNET.SE. 81.in-addr.arpa.86400INNSNS-PRI.RIPE.NET. ;; Received 235 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 179 ms ;; connection timed out; no servers could be reached miche...@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52112 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa.INPTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa.172800INNSproof.rain.fr. 255.81.in-addr.arpa.172800INNSns.ripe.net. 255.81.in-addr.arpa.172800INNSbow.rain.fr. ;; ADDITIONAL SECTION: ns.ripe.net.172800INA193.0.0.193 ns.ripe.net.172800IN2001:610:240:0:53::193 ;; Query time: 320 msec ;; SERVER: 192.134.0.49#53(192.134.0.49) ;; WHEN: Mon Feb 15 23:37:36 2010 ;; MSG SIZE rcvd: 170 miche...@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @SEC3.APNIC.NET ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @SEC3.APNIC.NET ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32853 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa.INPTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa.172800INNSns.ripe.net. 255.81.in-addr.arpa.172800INNSbow.rain.fr. 255.81.in-addr.arpa.172800INNSproof.rain.fr. ;; Query time: 200 msec ;; SERVER: 202.12.28.140#53(202.12.28.140) ;; WHEN: Mon Feb 15 23:29:41 2010 ;; MSG SIZE rcvd: 126 miche...@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @ns.ripe.net. ; <<>> DiG 9.3.3 <<>> +bufsize=4096 -x 81.255.164.225 @ns.ripe.net. ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY,
Re: in-addr.arpa server problems for europe? [SEC=UNCLASSIFIED]
Wilkinson, Alex wrote: > 0n Mon, Feb 15, 2010 at 01:40:31PM +0100, Michelle Sullivan wrote: > > >Michelle Sullivan wrote: > > >miche...@enigma:~$ dig +trace +bufsize=512 -x 81.255.164.225 > >miche...@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR > > Curious, why did you modify 'bufsize' ? > Well I started here: http://sel.icann.org/node/715#fn1 and figured that it was a way to force the packet size and protocol so that I could fit it to known constraints in the PIX eg: Fix to 512 bytes and if the PIX is rejecting anything over 512 bytes there is a simple answer. Fix to 4096 bytes and it forces to EDNS (v0) - as can be seen in the output, to see if the PIX is just dropping all EDNS.. obviously the resulting size sent back I cannot control (except by limiting the maximum size), so the next step was to query all (or a selection) of the servers being traced through. What I can't figure out is why I can query the servers directly and get a response but the trace fails. Any insight will be greatly appreciated. Michelle
Re: in-addr.arpa server problems for europe?
Stephane Bortzmeyer wrote: > On Mon, Feb 15, 2010 at 01:40:31PM +0100, > Michelle Sullivan wrote > a message of 298 lines which said: > > >> miche...@enigma:~$ dig +bufsize=4096 -x 81.255.164.225 @NS3.NIC.FR >> > > Bad test: the response is too small to exercice real size > problems. Try adding "+dnssec" to the dig command-line (that's what > BIND does by default). > > Thanks the query still works though miche...@enigma:~$ dig +bufsize=4096 +dnssec -x 81.255.164.225 @NS3.NIC.FR ; <<>> DiG 9.3.3 <<>> +bufsize=4096 +dnssec -x 81.255.164.225 @NS3.NIC.FR ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33097 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;225.164.255.81.in-addr.arpa.INPTR ;; AUTHORITY SECTION: 255.81.in-addr.arpa.172800INNSbow.rain.fr. 255.81.in-addr.arpa.172800INNSproof.rain.fr. 255.81.in-addr.arpa.172800INNSns.ripe.net. 255.81.in-addr.arpa.7200INNSEC0.26.81.in-addr.arpa. NS RRSIG NSEC 255.81.in-addr.arpa.7200INRRSIGNSEC 5 4 7200 20100317114227 20100215114227 19380 81.in-addr.arpa. dpdCyKkLsN4ts8DbSSBzsOPvr/65Z40Y3IbWFFuIBUf6/dhRFKbrpcgW HB6aPdFgpEyJ70uJgRY54d3eAS8S2U9oeAWlzj75n1wnrC8KAdLbCIS+ nbl1occ0PmIn0uuv0y/3oBvxLb2qVTB6KoBH2vxjSUIVsyLwthiUg34G Wyrn/yHT+gRfAbNdfmYRm8fa0/TGvNUN ;; ADDITIONAL SECTION: ns.ripe.net.172800INA193.0.0.193 ns.ripe.net.172800IN2001:610:240:0:53::193 ns.ripe.net.172800INRRSIGA 5 3 172800 20100317112654 20100215112654 51207 ripe.net. NWJBUydKjOtdlzqSAUkdOD3gMPLsKEQqE2z5LLvOmsdjltrJuQmkk2it bS+iyh4lzffi2Zc39D6rscy+MuNAnHNplnwUpIu2zOVAJwKs8NuChbon MfCS5K9Q0uEbYaiH1q+AIzekkPjhKfA/8uFFKTyw3fyQyoA6PXp+tbin GvwUdsrKzvpFrA7yiK4mlExfNnmcN7Qm ns.ripe.net.172800INRRSIG 5 3 172800 20100317112654 20100215112654 51207 ripe.net. Gz53F5uTq1nmr/t8x8hltVNZ/Rw3G/tRTJX6hz1CQWmU6YPK2xaRro47 Yk7St3z0I+H2plwhhRoF/3o5c4wI6h5jgMUQdf0YUQ0Uw9F3XUHqsGN/ zffk5mGBvK9bx8zxK3OBMd6cQ4O6uKgIGI7BwCacwhYU9lz+OZTxBRNB Es24jQ+h5HkV8gL++dG8m6InoFAn7cca ;; Query time: 322 msec ;; SERVER: 192.134.0.49#53(192.134.0.49) ;; WHEN: Tue Feb 16 00:09:36 2010 ;; MSG SIZE rcvd: 789
Re: in-addr.arpa server problems for europe?
Mark Andrews wrote: > In message <87iq9ys512@mid.deneb.enyo.de>, Florian Weimer writes: > >> * Stephane Bortzmeyer: >> >> >>> It is highly improbable that all these name servers are unreachable >>> from you. Therefore, I suspect that *content* is the issue. RIPE-NCC >>> zones are signed with DNSSEC. Are you sure you do not have a broken >>> middlebox which deletes DNSSEC-signed answers? >>> >> Ahem. dig's +trace doesn't use EDNS by default, so no signatures and >> (usually) no large responses. >> > > I actually suspect no IPv6 path rather than DNSSEC, add a -4 to force IPv4. > And that is the solution! (and I upgraded the resolver on all the machines to 9.6.1-P1 before getting that far.) Thanks, Michelle
Re: Spamhaus...
Laczo, Louis wrote: > Folks, > > I'm looking for comments / suggestions / opinions from any providers that > have been contacted by spamhaus about excessive queries originating from > their DNS resolvers, typically, as a proxy for customers. I know that certain > large DNS providers (i.e. google and level3) have either been banned or have > voluntarily blocked spamhaus queries by their resolvers. We're currently in > discussion with spamhaus and I wanted to see how others may have handled this. > They seem to be doing that a lot of late. They also contacted my employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our software. Next version will not have the ability to query Spamhaus unless a user configures it themselves in the "Custom RBL" settings. Michelle ? = could have been more, not sure without checking with the CEO, result was the same.
Re: Spamhaus...
Crist Clark wrote: > We received such a message from a Spamhaus Datafeed reseller > and eventually had our DNS servers blocked. What angered me was > that I analyzed our usage, and we were well below the thresholds > and met the TOS published at the Spamhaus website for no-cost use. > However, they said we had to subscribe to the Datafeed despite > that because we have a Barracuda appliance. > Well aside from I remember reading that they look for Barracuda Appliances*, it does say on: http://www.spamhaus.org/organization/dnsblusage.html *Definition: "non-commercial use" is use for any purpose other than as part or all of a product or service that is resold, or for use of which a fee is charged. For example, using our DNSBLs in a commercial spam filtering appliance that is then sold to others requires a data feed, regardless of use volume. The same is true of commercial spam filtering software and commercial spam filtering services. > And I want to know how they figured out we had a Barracuda. > > * well have you considered that the Barracuda may be very specific in it's IP stack, or they signature it produces in queries etc. Might have a very specific open port for administration - and not forgetting that if it's making queries very directly it's exposing it's IP address and therefore can be tested very simply. Many different ways, and I bet I could find out if I were to have a device to look at. Michelle
Re: several messages
Dean Anderson wrote: > [Damn. spit out my coffee on keyboard.] > > Levine and Vixie are partners in Whitehat. Whitehat is a commercial bulk > mailer that offers listwashing services (removing spam-traps). MAPS > employees were involved in listwashing. MAPS, Spamhaus, SORBS do not > block Whitehat, suggesting that the spamtraps removed come from > MAPS/Spamhaus/SORBS > LOL Dean's really lost it finally (if he hadn't before.) SORBS does not 'not block' anyone (many on here will attest to that) no one is to big or too small to get listed in SORBS. ..but more importantly, and almost on topic unlike Dean's entire post... I thought Dean was banned for his off continual off topic posts and all the attacks on other people and organisations? Michelle
Re: Spamhaus...
Crist Clark wrote: >>>> On 2/18/2010 at 11:47 AM, Michelle Sullivan wrote: >>>> >> Crist Clark wrote: >> >>> We received such a message from a Spamhaus Datafeed reseller >>> and eventually had our DNS servers blocked. What angered me was >>> that I analyzed our usage, and we were well below the thresholds >>> and met the TOS published at the Spamhaus website for no-cost use. >>> However, they said we had to subscribe to the Datafeed despite >>> that because we have a Barracuda appliance. >>> >>> >> Well aside from I remember reading that they look for Barracuda >> Appliances*, it does say on: >> http://www.spamhaus.org/organization/dnsblusage.html >> >> *Definition: "non-commercial use" is use for any purpose other than as >> part or all of a product or service that is resold, or for use of which >> a fee is charged. For example, using our DNSBLs in a commercial spam >> filtering appliance that is then sold to others requires a data feed, >> regardless of use volume. The same is true of commercial spam filtering >> software and commercial spam filtering services. >> > > We do not fit into that. We are not selling an appliance or service > to others (the 'Cuda is for our internal corporate email only, not > customers). If we were still using my home-built SpamAssassin system, > it'd be OK to use Spamhaus. Now that we've purchased an appliance > and manually added a Spamhaus to the user-customizable DNSBL list > on it, it's not OK? > > To use a phrase that I use for myself on SORBS... Their list their rules. If you don't like the rules, don't use the list. They've stated you have an appliance and regardless of volume, you are not 'non commercial' and have to pay a license. It's their list and their license, so you cannot fault them for that no matter how much you disagree with it. Michelle Michelle
Re: several messages
Patrick W. Gilmore wrote: > > Dean e-mails lots of people directly and CC's the list with his .. uh .. > missives. The list members do not see it, just the people individual on the > To or CC lines see it. > > When you reply to the list, /then/ people on the list see it. > > I am replying to the list because I want to educate people. The next time > someone gets e-mail from Dean, please do not reply to NANOG. > > My bad, I didn't realise I was in the CC list (in fact I specifically went back to check). Sorry all, it won't happen again. Michelle
Re: Spamhaus...
Crist Clark wrote: > We do not fit into that. We are not selling an appliance or service > to others (the 'Cuda is for our internal corporate email only, not > customers). If we were still using my home-built SpamAssassin system, > it'd be OK to use Spamhaus. Now that we've purchased an appliance > and manually added a Spamhaus to the user-customizable DNSBL list > on it, it's not OK? > I knew I had read it somewhere... http://www.spamhaus.org/faq/answers.lasso?section=Datafeed%20FAQ#153 Quote: > If you do not have a current Spamhaus Datafeed subscription, then you > are abusing Spamhaus's public DNSBL servers. If your email volume is > big enough that you need a Barracuda or similar spam filter appliance, > then you certainly CAN NOT use Spamhaus's free public DNSBL servers. > > Contrary to what you may have been told by the nice appliance > salesman, Spamhaus does not have any agreement with Barracuda for the > use of Spamhaus DNSBLs with Barracuda appliances. > > Because Spamhaus's public DNSBL servers get heavily abused by > companies with spam filter appliances, mostly Barracuda appliances, > Spamhaus has implemented a control system on the public DNSBL servers > to flag and firewall such users and Barracuda appliances in particular. Michelle
Re: Spamhaus...
Rich Kulawiec wrote: > On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote: > >> And I want to know how they figured out we had a Barracuda. >> > > It's not that hard, much of the time -- they tend to make > themselves visible via their poor behavior. > > Is there some very specific poor behavior you're referring to? > Finally, this discussion should really be on spam-l, not nanog. > Actually considering the original message was addressed to the 'large DNS server operators' this is probably more appropriate. Whether the non-followups in this thread should be there instead is a different issue. Michelle
Re: Spamhaus...
Bjørn Mork wrote: > Michelle Sullivan writes: > >> Rich Kulawiec wrote: >> >>> On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote: >>> >>> >>>> And I want to know how they figured out we had a Barracuda. >>>> >>> It's not that hard, much of the time -- they tend to make >>> themselves visible via their poor behavior. >>> >> Is there some very specific poor behavior you're referring to? >> > > I don't know what Rich referred to, but Barracudas used to be easy to > spot by backscatter levels: > http://www.dontbouncespam.org/#barracuda > > Yes that was what Rich was referring to, however, that I suspect is not what Spamhaus are doing. Regards, Michelle
Re: Spamhaus...
Marc Powell wrote: > On Feb 18, 2010, at 2:25 PM, Nick Hilliard wrote: > > >> On 18/02/2010 10:40, Michelle Sullivan wrote: >> >>> They seem to be doing that a lot of late. They also contacted my >>> employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our >>> software. >>> >> I sympathise. It's very frustrating when you try to deal with these >> anti-spam outfits in a reasonable way and you're met with almost completely >> arbitrary b/s. >> > > What's arbitrary about free for non-commerical use, everyone else pays? When > you include it in a commercial product, yes, you should have to pay for it. > If you're making money by reselling or providing access to the Spamhaus > lists, you should have to pay for it. There's a lot of work that goes into it > (I'm sure Michelle would agree) and they have very specific criteria under > which they will allow free use and under which they will not. If you don't > like it, make your own lists. If you *really* don't like it, make your own > lists, and provide a free public infrastructure to support billions of > requests a day. > > I can tell you that building infrastructure to support our current load of 30 billion DNS queries per day is not as simple as some people think. That said the difference in infrastructure from 5billion pre day to the 50 billion peak we had was just the number of boxes once the infrastructure was designed and put in place. I can build and deploy a new member of the infrastructure including OS build in around 30 minutes - of which 10 minutes are updating the config the remainder are jump starting the OS. The other points I agree with. If you don't like it or don't agree, don't use it and/or build your own. Michelle
Re: Spamhaus...
Scott Howard wrote: > On Fri, Feb 19, 2010 at 5:20 PM, William Herrin wrote: > >> On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec wrote: >> >>> Barracuda's engineers apparently think >>> that using SPF stops backscatter -- and it most emphatically does not. >>> >>> Reject good, bounce baaad. [1] >>> >> Whine all you want about backscatter but until you propose a >> comprehensive solution that's still reasonably compatible with RFC >> 2821's section 3.7 you're just talking trash. >> > > In the case of Barracuda's long history of Backscatter the solution is > simple, and is implemented by most other mail vendors - it's called > "Don't accept incoming mail to an invalid recipient". > > Barracudas used to have no way of doing address validation for > incoming mail, so they would accept it and then bounce it when the > next hop (eg, the Exchange server) rejected the recipient address. > They finally fixed this a few years ago, and can not integrate with > LDAP (and possibly others) for address validation. Of course, it's > still down to the admin to implement it... > > Actually they do (did?), as they run postfix, they should be configurable to use LDAP and a whole host of other methods. Michelle
Re: Spamhaus...
Jon Lewis wrote: > > The original question, "what do you do (or have you done) when DNSBL-X > approaches you saying that your network is hitting their public NS's > too hard and wants you to pay for continued access?" is something I'd > like to see some answers to. Despite the Subject:, Spamhaus is > neither the only DNSBL currently doing this nor the first to watch > statistics on their public NS's and approach networks asking for money > and/or cutting off access if you don't pay. As a matter of interest, who are the other current DNSBL's to do it? Michelle
Re: Spamhaus...
Paul Vixie wrote: > so, a uucp-only site should have upgraded to real smtp by now, and by not > doing it they and their internet gateway are a joint menace to society? > > that seems overly harsh. there was a time (1986 or so?) when most of the > MX RR's in DNS were smtp gateways for uucp-connected (or decnet-connected, > etc) nodes. it was never possible to reject nonexist...@uucpconnected at > their gateway since the gateway didn't know what existed or not. i'm not > ready to declare that era dead. > I was running a UUCP gateway not so long ago, and might revive it in the future (got an old school BBS with a UUCP gateway and no SMTP still.) The front end still knew the back end valid addresses though and that's going from a PCBoards BBS to a Postfix SMTP gateway via UUCP. That said there are many out there that refuse on the grounds "I don't have the time to fix it" .. and of course one could retort with "I don't have the time to receive mail from you." I'm on the fence, if it's SMTP there *should* be no reason for the front end not to know valid users at the back end... Something will know the valid list of email addresses, so you *should* be able to get that information to the front end. Michelle * should because there will be edge cases where you can't get the information, but then are there that many emails behind that gateway that couldn't be updated manually?
Re: Spamhaus...
Jon Lewis wrote: > On Sun, 21 Feb 2010, Michelle Sullivan wrote: > >> As a matter of interest, who are the other current DNSBL's to do it? > > To the best of my knowledge, MAPS was the first to do it. Uribl.com > currently does it (and does the sort of query aggregation across your > entire? network) that I mentioned. Can you access MAPS without a subscription at all? As far as SORBS goes, we monitor the individual DNS servers for excessive queries and ask any provider causing excessive queries to run their own local copy. We don't charge for any of it, we don't require them to run a public mirror (though sometimes we ask.) Regards, Michelle
Re: Spamcop Blocks Facebook?
deles...@gmail.com wrote: > Maybe I'm wrong on this, You are I'm afraid. > and I'm not a mailadmin anywhere nor have I been or pretended to have been in > the past. But I'm pretty sure FB only sends you mail based on the prefrences > you choose, and I know this is the answer you where given so mostly a > statement. How does that equal spam :) > The default is for everything 'on'. They will send to any email address with notifications and mail regardless of signup and they don't honor bounces in any 'email address doesn't work so don't mail it' lists they might or might not employ. Regards, Michelle
