Bye Snubby, hello Mail Rejector
Ooh, when did Verisign get rid of their Snubby program and put in something that actually behaves like an SMTP server? Seems verisign are watching the community reaction and acting to rectify their errors.. well some of them $ telnet sdfjsdfjsdjflsd.com 25 Trying 64.94.110.11... Connected to sdfjsdfjsdjflsd.com. Escape character is '^]'. 220 VeriSign mail rejector (Postfix) HELO as 250 OK MAIL FROM:me 250 Ok RCPT TO:you 550 unknown[193.0.255.132]: Client host rejected: The domain you are trying to send mail to does not exist. DATA 554 Error: no valid recipients hello 502 Error: command not implemented 421 Error: too many errors Connection closed by foreign host.
Looking for clue at NetSOL/Verisign
Is there anyone with a clue at verisign who's able to actually repair a broken entry in their database? I've got a companies domain name that seems to be stuck with nameservers listed in whois, but none in the .com zone. This means that everything for this companies domain is hitting the sitefinder crap, mail is being rejected, etc. A call to netsol got me a rather clueless person who claimed that sitefinder was created by ICANN, and that it's normal for a domain to have no nameservers for up to 3 days when changing name server entries. (instead of an immediate transition) I had this problem before with the exact same set of nameservers, it required a week worth of calls to verisign and a threat of legal action before someone manually touched something in their database to fix it. Unfortunately they claimed at the time that it was normal, and the changes had been processed normally (after a week!), so I have no contact information for the clued person who fixed it. -- Matthew S. HallacyFUBAR, LART, BOFH Certified http://www.poptix.net GPG public key 0x01938203
Re: Worst design decisions?
I think it was the new MG F, where if you had the top down on the car and there was moisture on the boot [trunk] when you opened the boot [trunk] people in the car would get showered! They fixed it by adding a tighter spring so that the boot [trunk] opened slowly and the water dripped down the sides slowly! The biggest design flaw that really used to drive me nuts was with AS5300 cards and the fact you needed some special tool to pull them out. Also the good old cbus complex error when doing anything on a 7500 router, and the chopping up of memory when adding subinterfaces on ATM PA card. Another great one was in the early days of Demon, BT would only present telephone lines if they where terminated via their normal domestic wall socket, so at Demon there was like 200 odd wall sockets with phone connectors to the back of total control boxes. Talk a about a cable management nightmare, as well as dimensioning the network based upon wall size! Regards, Neil.
RE: Worst design decisions?
Its even funnier what happens when a customer confuses a Netopia console connector with that of the power connector from the next revision :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, September 18, 2003 10:57 AM To: [EMAIL PROTECTED] Subject: Re: Worst design decisions? Without a question: PS/2 style keyboard and mouse connectors. Impossible to tell from each other, or the right way up without eyeballs directly on them. A real PITA when trying to reach behind a desk or rack. The console port is a close second, though...
Re: Looking for clue at NetSOL/Verisign
On 9/20/03 6:33 AM, Matthew S. Hallacy [EMAIL PROTECTED] wrote: Is there anyone with a clue at verisign who's able to actually repair a broken entry in their database? I've got a companies domain name that seems to be stuck with nameservers listed in whois, but none in the .com zone. LOL! I think we'll all see the next asteroid smack into the earth before you find anyone at Verisign who will respond to this! (on or off list) :-) -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] PGP: http://www.inoc.net/~dev/ Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9 I don't need parents. All I need is a recording that says, 'Go play outside! - Calvin and Hobbes
Re: Looking for clue at NetSOL/Verisign
On Sat, 2003-09-20 at 06:29, Robert Blayzor wrote: On 9/20/03 6:33 AM, Matthew S. Hallacy [EMAIL PROTECTED] wrote: Is there anyone with a clue at verisign who's able to actually repair a broken entry in their database? I've got a companies domain name that seems to be stuck with nameservers listed in whois, but none in the .com zone. LOL! I think we'll all see the next asteroid smack into the earth before you find anyone at Verisign who will respond to this! (on or off list) :-) I suggest (Matthew) call network solutions back and tell them to call verisign NDS customer service. They are wrong about ICANN. -- Mark Foster [EMAIL PROTECTED]
bind patches++ (Re: Wildcards)
if you installed the first isc wildcard patch you probably want the second.
see www.isc.org/products/BIND/delegation-only.html for details. the first
patch didn't handle NS lookups (which don't occur in nature but it's sort of
unnerving when they don't work in dig).
in addition to the type delegation-only zones, the latest release candidate
has an additional root-delegation-only option. this looks like:
options {
root-delegation-only exclude { de; museum; };
};
thus the delegation-only behaviour becomes the default for the root domain,
and all tld's except those listed. DE has no wildcards but they do put
customer A RRs into the DE zone itself. MUSEUM has a wildcard but this was
part of their application and it was approved and has not been a problem.
f.6to4-servers.net is now running this if you want to try before you, um, buy.
thanks very much to the membership of the bind forum who make this possible.
--
Paul Vixie
VeriSign SMTP reject server updated
Folks, One piece of feedback we received multiple times after the addition of the wildcard A record to the .com/.net zones concerned snubby, our SMTP mail rejection server. This server was designed to be the most modest of SMTP implementations and supported only the most common sequence of SMTP commands. In response to this feedback, we have deployed an alternate SMTP implementation using Postfix that should address many of the concerns we've heard. Like snubby, this server rejects any mail sent to it (by returning 550 in response to any number of RCPT TO commands). We would like to state for the record that the only purpose of this server is to reject mail immediately to avoid its remaining in MTA queues throughout the Internet. We are specifically not retaining, nor do we have any intention to retain, any email addresses from these SMTP transactions. In fact, to achieve sufficient performance, all logging has been disabled. We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. One alternate option we are considering is rejecting the SMTP transaction by returning a 554 response code as described in Section 3.1 of RFC 2821. Our concern is if this response effectively causes most SMTP servers to bounce the message, which is the desired reaction. We are researching common SMTP servers' handling of this response code; at least one popular server appears to requeue mail after receiving 554. Another option is remaining with the more standard SMTP sequence (returning 250 in response to HELO/EHLO), but then returning 550 in response to MAIL FROM as well as RCPT TO. I would welcome feedback on these options sent to me privately or the list; I will summarize the former. Matt -- Matt Larson [EMAIL PROTECTED] VeriSign Naming and Directory Services
Re: VeriSign SMTP reject server updated
At 02:01 PM 9/20/2003, Matt Larson wrote: In response to this feedback, we have deployed an alternate SMTP implementation using Postfix that should address many of the concerns we've heard. Like snubby, this server rejects any mail sent to it (by returning 550 in response to any number of RCPT TO commands). ICANN has requested that Verisign remove the wildcards in .com and .net. So what you're basically saying here is: that ain't gonna happen. Correct?
Re: bind patches++ (Re: Wildcards)
Hello Paul , Am I correct in the understanding that the below
tells me that 9.2.2p2 does NOT contain the ablility to do
root-delegation-only ? Tia , JimL
On Sat, 20 Sep 2003, Paul Vixie wrote:
if you installed the first isc wildcard patch you probably want the second.
see www.isc.org/products/BIND/delegation-only.html for details. the first
patch didn't handle NS lookups (which don't occur in nature but it's sort of
unnerving when they don't work in dig).
in addition to the type delegation-only zones, the latest release candidate
has an additional root-delegation-only option. this looks like:
options {
root-delegation-only exclude { de; museum; };
};
thus the delegation-only behaviour becomes the default for the root domain,
and all tld's except those listed. DE has no wildcards but they do put
customer A RRs into the DE zone itself. MUSEUM has a wildcard but this was
part of their application and it was approved and has not been a problem.
f.6to4-servers.net is now running this if you want to try before you, um, buy.
thanks very much to the membership of the bind forum who make this possible.
--
+--+
| James W. Laferriere | SystemTechniques | Give me VMS |
| NetworkEngineer | P.O. Box 854 | Give me Linux |
| [EMAIL PROTECTED] | Coudersport PA 16915 | only on AXP |
+--+
RE: VeriSign SMTP reject server updated
One piece of feedback we received multiple times after the addition of the wildcard A record to the .com/.net zones concerned snubby, our SMTP mail rejection server. Did you miss the other pieces of feedback about how wildcard records in .com and .net are simply a bad idea for numerous reasons? We would like to state for the record that the only purpose of this server is to reject mail immediately to avoid its remaining in MTA queues throughout the Internet. We are specifically not retaining, nor do we have any intention to retain, any email addresses from these SMTP transactions. Right. We can't trust you to do the right thing with regard to the wildcards themselves, so now we have to trust you when you tell us what your SMTP server does. Why should we trust you, again? I would welcome feedback on these options sent to me privately or the list; I will summarize the former. I'll take the list, even though I'm sure it'll get beaten to death by the time I check my mailbox again. Matthew Kaufman [EMAIL PROTECTED] Ps. Are you planning on operating servers which reject, with proper status codes, every other common service that might be found at an Internet address?
Re: VeriSign SMTP reject server updated
On Sat, Sep 20, 2003 at 02:16:34PM -0400, Dave Stewart wrote: implementation using Postfix that should address many of the concerns we've heard. Like snubby, this server rejects any mail sent to it (by returning 550 in response to any number of RCPT TO commands). ICANN has requested that Verisign remove the wildcards in .com and .net. So what you're basically saying here is: that ain't gonna happen. Correct? Please don't try to force the benevolent techie into making further policy statements - I think Matt is doing us enough of a favour already by keeping us into the loop to the extent he can. Don't try to bait him. Thanks. -- http://www.PowerDNS.com Open source, database driven DNS Software http://lartc.org Linux Advanced Routing Traffic Control HOWTO
Re: VeriSign SMTP reject server updated
On Sat, 20 Sep 2003, Matt Larson wrote: Folks, One piece of feedback we received multiple times after the addition of the wildcard A record to the .com/.net zones concerned snubby, our SMTP mail rejection server. This server was designed to be the most modest of SMTP implementations and supported only the most common sequence of SMTP commands. In response to this feedback, we have deployed an alternate SMTP implementation using Postfix that should address many of the concerns we've heard. Like snubby, this server rejects any mail sent to it (by returning 550 in response to any number of RCPT TO commands). We would like to state for the record that the only purpose of this server is to reject mail immediately to avoid its remaining in MTA queues throughout the Internet. We are specifically not retaining, nor do we have any intention to retain, any email addresses from these SMTP transactions. In fact, to achieve sufficient performance, all logging has been disabled. We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. One alternate option we are considering is rejecting the SMTP transaction by returning a 554 response code as described in Section 3.1 of RFC 2821. Our concern is if this response effectively causes most SMTP servers to bounce the message, which is the desired reaction. We are researching common SMTP servers' handling of this response code; at least one popular server appears to requeue mail after receiving 554. Another option is remaining with the more standard SMTP sequence (returning 250 in response to HELO/EHLO), but then returning 550 in response to MAIL FROM as well as RCPT TO. I would welcome feedback on these options sent to me privately or the list; I will summarize the former. Matt, I think you haven't gotten it. I'm getting the message from you that the changes made to the com and net gTLD's are fait accompli. From the message above it sounds like by changing your smtp server everything will be perfect and back to normal on the internet. The problem here is by adding wildcard records Verisign has broken lots of software (the internet is NOT just the web no matter what Verisign would like one to believe). Many spam algorithms have relied on the fact that nonexitent domain names are one of the ways (and a very effective one at that) to filter spam. Other registrars do and nslookup on a domain name when attempting to register and if this comes back positive then the domain is considered taken. Is Verisign expecting everyone else to modify software which has been working for years (based on what have been valid assumptions for well over a decade)? This will cost millions (if not billions) of dollars. As those in the spam world would say, the collateral damage is very high for this type of change. Is Verisign going to hold the internet hostage to its whims? So let us know why exactly you should be able to redirect any protocol you wish to your IP addresses if someone mistypes a domain. I look forward to your response. bye, ken emery
Re: VeriSign SMTP reject server updated
Oh come on people, this guy *implements* stuff. Here he is on the list describing how he has implemented something to alleviate the problems caused by PHBs at Verisign. ISC bind mods, ICANN displeasure, and other sources of pressure will either remove this issue or make it irrelevant. Rather than bashing someone who is doing something positive we should see if we can paypal him $$$ for a box of tacks so he can mine the chairs of the tack head marketing weasels who decided this would be a good idea ... Matthew Kaufman wrote: One piece of feedback we received multiple times after the addition of the wildcard A record to the .com/.net zones concerned snubby, our SMTP mail rejection server. Did you miss the other pieces of feedback about how wildcard records in .com and .net are simply a bad idea for numerous reasons? We would like to state for the record that the only purpose of this server is to reject mail immediately to avoid its remaining in MTA queues throughout the Internet. We are specifically not retaining, nor do we have any intention to retain, any email addresses from these SMTP transactions. Right. We can't trust you to do the right thing with regard to the wildcards themselves, so now we have to trust you when you tell us what your SMTP server does. Why should we trust you, again? I would welcome feedback on these options sent to me privately or the list; I will summarize the former. I'll take the list, even though I'm sure it'll get beaten to death by the time I check my mailbox again. Matthew Kaufman [EMAIL PROTECTED] Ps. Are you planning on operating servers which reject, with proper status codes, every other common service that might be found at an Internet address? -- mailto:[EMAIL PROTECTED] phone:402-301-9555 After all that I've been through, you're the only one who matters, you never left me in the dark here on my own - Widespread Panic
Re: VeriSign SMTP reject server updated
We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. One alternate option we I would welcome feedback on these options sent to me privately or the list; I will summarize the former. OK feedback, I suggest you withdraw the facility whilst you figure out the details the Internet is not your playground Steve
Re: VeriSign SMTP reject server updated
On Sat, 20 Sep 2003, Matt Larson wrote: One piece of feedback we received multiple times after the addition of the wildcard A record to the .com/.net zones concerned snubby, our [..] * [EMAIL PROTECTED] (ken emery) [Sat 20 Sep 2003, 20:35 CEST]: I think you haven't gotten it. I'm getting the message from you that the changes made to the com and net gTLD's are fait accompli. From the [..] I think Mr Larson understands perfectly well the consequences of his management's decisions. I believe he is one of the fine people working for the root servers group, who Paul Vixie recently praised unanimously in this august forum. Unfortunately, I have the feeling that questioning Mr Larson about the policies of his management is about as useful as writing an RFC that mandates world peace when it comes to effect sorted. Alternate contacts within Verisign who do have influence on com/net policy will, of course, be welcomed. Is Verisign going to hold the internet hostage to its whims? To the tune of $100M/year? Apparently so. So let us know why exactly you should be able to redirect any protocol you wish to your IP addresses if someone mistypes a domain. Someone delegated com and net to them. Simple. They can also do it with existing domains, but apparently they're unwilling to take the backlash that would result from such an action... Regards, -- Niels.
Re: VeriSign SMTP reject server updated
On Sat, 20 Sep 2003, neal rauhauser wrote: Oh come on people, this guy *implements* stuff. Here he is on the list describing how he has implemented something to alleviate the problems caused by PHBs at Verisign. He is a representative of Verisign and asked for feedback. He has gotten some. I honestly think that the person who made the decision to implement the A records thought the internet was only web and thus everything would be just great and Verisign would take in all sorts of advertising money and nothing else would happen. ISC bind mods, ICANN displeasure, and other sources of pressure will either remove this issue or make it irrelevant. Doubtful, the dollar number I heard was $100 million/year. Verisign won't let a bind mod get in their way with that much money at stake. They will do everything in their power to keep this in place. Rather than bashing someone who is doing something positive we should see if we can paypal him $$$ for a box of tacks so he can mine the chairs of the tack head marketing weasels who decided this would be a good idea ... I wrote a response to Matt (it went to the list). I used the directives Verisign and you a bit interchanably. They both were to mean the same thing, Verisign the company, not Matt Larson the person. I think the other responses I've seen so far were much the same. I'm hoping Matt doesn't take any of this personally. bye, ken emery Matthew Kaufman wrote: One piece of feedback we received multiple times after the addition of the wildcard A record to the .com/.net zones concerned snubby, our SMTP mail rejection server. Did you miss the other pieces of feedback about how wildcard records in .com and .net are simply a bad idea for numerous reasons? We would like to state for the record that the only purpose of this server is to reject mail immediately to avoid its remaining in MTA queues throughout the Internet. We are specifically not retaining, nor do we have any intention to retain, any email addresses from these SMTP transactions. Right. We can't trust you to do the right thing with regard to the wildcards themselves, so now we have to trust you when you tell us what your SMTP server does. Why should we trust you, again? I would welcome feedback on these options sent to me privately or the list; I will summarize the former. I'll take the list, even though I'm sure it'll get beaten to death by the time I check my mailbox again. Matthew Kaufman [EMAIL PROTECTED] Ps. Are you planning on operating servers which reject, with proper status codes, every other common service that might be found at an Internet address? -- mailto:[EMAIL PROTECTED] phone:402-301-9555 After all that I've been through, you're the only one who matters, you never left me in the dark here on my own - Widespread Panic
Verisign vs ICANN
I don't think anyone holds Matt personally responsible for what has happened so please remember that when responding. Verisign has broken everything and unlike the success of their grandfathered monopoly on registrations this might spell the end of their reign over these zones. This has broken the net, an intense attack on the domain name system would probably have had less impact than the havoc Verisign has caused with their point everything to Verisign hack. I'd think this was very irresponsible behaviour, and conjures up shades of past ghosts (does anyone remember CORE?) if I were an oversight authority I'd be very incredibly pissed off right about now. (stupid question) Doesn't the IAB have any authority left? It's interesting that now ICANN -- perhaps for the first time ever -- might be in the position to do something positive and prove it's not all about backroom politics. It's also ironic that someone would have had to spend years in prison for doing what they've done with or without notice or malicious intent. When people are running around hacking new code into BIND, several MTAs, and bog knows what else you can't say you didn't break anything. Throwing up piles of servers and network equipment to be able to respond to garbage IP traffic because you're aiming the world at your network isn't particularly intelligent either but what do I know about it? Len
Re: bind patches++ (Re: Wildcards)
this feature is only in the latest release candidate is 9.2.3rc3. our patches to 9.2.2 and 9.1 only support delegation-only zones. to get the root-delegation-only option you need 9.2.3rc3. see www.isc.org/products/BIND/delegation-only.html for details. re: Date: Sat, 20 Sep 2003 14:22:57 -0400 (EDT) From: Mr. James W. Laferriere [EMAIL PROTECTED] To: Paul Vixie [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: bind patches++ (Re: Wildcards) Hello Paul , Am I correct in the understanding that the below tells me that 9.2.2p2 does NOT contain the ablility to do root-delegation-only ? Tia , JimL -- +--+ | James W. Laferriere | SystemTechniques | Give me VMS | | NetworkEngineer | P.O. Box 854 | Give me Linux | | [EMAIL PROTECTED] | Coudersport PA 16915 | only on AXP | +--+
Re: Providers removing blocks on port 135?
Has anyone else notice the flip-flops? To prevent spam providers should block port 25. If providers block ports, e.g. port 135, they aren't providing access to the full Internet. Should any dialup, dsl, cable, wi-fi, dhcp host be able to use any service at any time? For example run an SMTP mailer, or leave Network Neighborhood open for others to browse or install software on their computers? Or should ISPs have a default deny on all services, and subscribers need to call for permitssion if they want to use some new service? Should new services like Voice over IP, or even the World Wide Web be blocked by default by service providers? As a HOST requirement, I think all hosts should be client-only by default. That includes things when acting as like hosts such as routers, switches, print servers, file servers, UPSes. If a HOST uses a network protocol for local host processes (e.g. X-Windows, BIFF, Syslog, DCE, RPC) by default it should not accept network connections. It should require some action, e.g. the user enabling the service, DHCP-client enabling it in a profile, clicking things on the LCD display on the front ofthe printer, etc. If the device is low-end and only has a network connection (e.g. no console), it may have a single (i.e. telnet or web; but not both) management protocol enabled provided it includes a default password which can not be discovered from the network (i.e. not the MAC address), is different for each device (i.e. not predictable), and is only accessiable from the local network (e.g. the internal subnet interface). A proprietary protocol is not an adequate substitute. Static passwords are inherently insecure if you get enough guesses, so the device should block use of the default password after N failed attempts until the device is manually reset. I recognize this is a potential denial of service, and for non-default passwords vendors may decide to do something else. But if the user hasn't changed the default password; they probably aren't using it anyway. SERVICE PROVIDERS do not enforce host requirements.
Re: Verisign vs ICANN
On Sat Sep 20, 2003 at 03:28:59PM -0400, Len Rose wrote: Verisign has broken everything and unlike the success of their grandfathered monopoly on registrations this might spell the end of their reign over these zones. This has broken the net, an intense attack on the domain name system would probably have had less impact than the havoc Verisign has caused with their point everything to Verisign hack. Sorry, the Internet is broken, because of this? I can still access the websites I could access before. I can still send and receive email. I can still FTP files from FTP servers. To users of the Internet, nothing is broken. Okay, to Internet Experts, things are broken - their domain checking scripts no longer return domain available (why not just check whois.internic.net?). Some spam filtering has stopped working (I've not noticed any increase in the spam in my inbox). Maybe some other tools are misbehaving, but in general, all user-level stuff is just working as before. Not that I condone what Verisign have done - it's an abuse of monopoly as far as I'm concerned - but I do belive there is a lot of emotion involved in this. Simon -- Simon Lockhart | Tel: +44 (0)1628 407720 (x37720) | Si fractum Technology Manager | Fax: +44 (0)1628 407701 (x37701) | non sit, noli BBC Internet Operations | Email: [EMAIL PROTECTED]| id reficere BBC Technology, Maiden House, Vanwall Road, Maidenhead. SL6 4UB. UK
Re: VeriSign SMTP reject server updated
While 550 may be the proper answer for a domain that does not exist, it is an improper answer for a domain that does exist but that is not included in the zone for some reason. Verisign is not the owner of the domain and, as such, has no right to discard mail destined for that domain. Mail should remain in the queue of the sender. Matt Larson wrote: Folks, One piece of feedback we received multiple times after the addition of the wildcard A record to the .com/.net zones concerned snubby, our SMTP mail rejection server. This server was designed to be the most modest of SMTP implementations and supported only the most common sequence of SMTP commands. In response to this feedback, we have deployed an alternate SMTP implementation using Postfix that should address many of the concerns we've heard. Like snubby, this server rejects any mail sent to it (by returning 550 in response to any number of RCPT TO commands). We would like to state for the record that the only purpose of this server is to reject mail immediately to avoid its remaining in MTA queues throughout the Internet. We are specifically not retaining, nor do we have any intention to retain, any email addresses from these SMTP transactions. In fact, to achieve sufficient performance, all logging has been disabled. We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. One alternate option we are considering is rejecting the SMTP transaction by returning a 554 response code as described in Section 3.1 of RFC 2821. Our concern is if this response effectively causes most SMTP servers to bounce the message, which is the desired reaction. We are researching common SMTP servers' handling of this response code; at least one popular server appears to requeue mail after receiving 554. Another option is remaining with the more standard SMTP sequence (returning 250 in response to HELO/EHLO), but then returning 550 in response to MAIL FROM as well as RCPT TO. I would welcome feedback on these options sent to me privately or the list; I will summarize the former. Matt -- Matt Larson [EMAIL PROTECTED] VeriSign Naming and Directory Services
Re: VeriSign SMTP reject server updated
[EMAIL PROTECTED] (Matt Larson) writes: We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. One alternate option we are considering is rejecting the SMTP transaction by returning a 554 response code as described in Section 3.1 of RFC 2821. Our concern is if this response effectively causes most SMTP servers to bounce the message, which is the desired reaction. is it? right now there are a lot of unintended consequences and several of them are rather painful. for example, let's say you were using a friend as your backup MX and he got put on domain-hold. or in the more common case you misspell your backup mx. either way mail that should be queued and then later would have been successfully delivered will bounce at the verisign server. We are researching common SMTP servers' handling of this response code; at least one popular server appears to requeue mail after receiving 554. Another option is remaining with the more standard SMTP sequence (returning 250 in response to HELO/EHLO), but then returning 550 in response to MAIL FROM as well as RCPT TO. no matter what you do you're turning nonfatal error conditions into fatal ones. i'm not sure it matters which kind of fatal condition you cause, or the specific smtp messages you use to cause it. either way you're in the loop and there's no good that can come of it from an e-mail p-o-v. before we deployed root-delegation-only here, i was also annoyed that my e-mail tool could not tell me about misspelled domain names at send time and i had to wait for the wildcard mail servers to bounce the traffic. i am much happier with nxdomain than i was with the wildcard. it's just sad that i'm going to have to move vix.com to a different parent domain name to get that behaviour to work for me as a recipient and others as senders. I would welcome feedback on these options sent to me privately or the list; I will summarize the former. i chose to send this to the list since some folks have been wondering if i'm a verisign apologist lately and i believe that open debate is better for this kind of thing. -- Paul Vixie
Re: Verisign vs ICANN
I have lots of dns-related activity on both systems and within applicaitons that are broken now because I am no longer able to differentiate between a bad domain name and a working domain. It's not at all minor. You underestimate what this has done, I think. A major change in key functionality of the domain name system (at least for GTLD .COM and .NET) has taken place. I know at least one voice/ip company that has been forced to re-write portions of their phone application because this suddenly broke how the domain name systsem had been functioning. To say it's all about running whois queries reveals the depth at which you must make use of the domain name system. I'm sure those who maintains your name servers for you, and those who maintain your network and systems for you probably would answer differently. Thanks. Len (I won't respond publicly to this thread again I promise) Simon Lockhart wrote: [..] Sorry, the Internet is broken, because of this? I can still access the websites I could access before. I can still send and receive email. I can still FTP files from FTP servers. To users of the Internet, nothing is broken. Okay, to Internet Experts, things are broken - their domain checking scripts no longer return domain available (why not just check whois.internic.net?). Some spam filtering has stopped working (I've not noticed any increase in the spam in my inbox). Maybe some other tools are misbehaving, but in general, all user-level stuff is just working as before. Not that I condone what Verisign have done - it's an abuse of monopoly as far as I'm concerned - but I do belive there is a lot of emotion involved in this. Simon [..]
Re: VeriSign SMTP reject server updated
On Sat, Sep 20, 2003 at 11:34:17AM -0700, ken emery wrote: I think you haven't gotten it. I'm getting the message from you that the changes made to the com and net gTLD's are fait accompli. From the That's the exact message I got from Verisign on Thursday. See: http://news.com.com/2100-1024-5078657.html Basically Verisign is willing to tweak the service to make it less controversial but not stop it. -Declan
Re: VeriSign SMTP reject server updated
Is it possible for the client resolver code to distinguish between a wildcard answer and an explicit answer? Or would the require another flag passed between the client and a recursive name server? If this was available, it would mail clients and other things interested in the specific domain name could get the answers they want. While other stuff would get the wildcard answers.
Re: VeriSign SMTP reject server updated
Is it possible for the client resolver code to distinguish between a wildcard answer and an explicit answer? no. If this was available, it would mail clients and other things interested in the specific domain name could get the answers they want. While other stuff would get the wildcard answers. right.
Re: VeriSign SMTP reject server updated
on 9/20/2003 1:01 PM Matt Larson wrote: We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. You need to: 1) fatally reject mail for domains that are not delegated with 5xx -and- 2) softly reject mail for domains that are delegated with 4xx so the messages are requeed and may get to an authorized server on the next run Used to be able to use DNS for this. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: VeriSign SMTP reject server updated
on 9/20/2003 3:01 PM Sean Donelan wrote: Is it possible for the client resolver code to distinguish between a wildcard answer and an explicit answer? Or would the require another flag passed between the client and a recursive name server? If this was available, it would mail clients and other things interested in the specific domain name could get the answers they want. While other stuff would get the wildcard answers. Internet architecture generally favors abstracting higher-layer data away from lower-layer services. EG, we don't have ~BGP that routes :80 traffic separate from :25 traffic, nor do we have a URI syntax that allows you to refer to svc/tcp separate from svc/udp, nor do we have a naming service that allows for service-specific address responses. Although any of these could could be emulated, it wouldn't do anything for today's apps. My feeling is that this architectural design feature is becoming more and more of a restraint as complexity seeps in, the conflation of DNS error codes being just one of many examples. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: VeriSign SMTP reject server updated
On 9/20/03 3:39 PM, Roy [EMAIL PROTECTED] wrote: While 550 may be the proper answer for a domain that does not exist, it is an improper answer for a domain that does exist but that is not included in the zone for some reason. Verisign is not the owner of the domain and, as such, has no right to discard mail destined for that domain. Mail should remain in the queue of the sender. Not to be picky, but the banner also violates RFC. The 220 should be followed by FQDN identifying the system. [flem:~] telnet zzfoobar.net 25 Trying 64.94.110.11... Won't send login name and/or authentication information. Connected to zzfoobar.net. Escape character is '^]'. 220 VeriSign mail rejector (Postfix) -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] PGP: http://www.inoc.net/~dev/ Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9 Press [ESC] to detonate or any other key to explode.
When is Verisign's registry contract up for renewal
What happens when Verisigns monopoly registry agreement for .COM and .NET expires on November 10 2007? http://www.icann.org/tlds/agreements/verisign/com-index.htm According to the contract signed between ICANN and Verisign, Zone File Data is defined as 13. Zone File Data means all data contained in DNS zone files for the Registry TLD, or for any subdomain for which Registry Services are provided and that contains Registered Names, as provided to TLD nameservers on the Internet. A wildcard name does not meet the definition of Registered Name in the Verisign/ICANN contract. 6. Registered Name refers to a domain name within the domain of the Registry TLD, whether consisting of two or more (e.g., john.smith.name) levels, about which Registry Operator or an affiliate engaged in providing Registry Services maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance. A name in a Registry Database may be a Registered Name even though it does not appear in a TLD zone file (e.g., a registered but inactive name). Because wildcard names are not Registered Names, Verisign appears to be in breach of their contract with ICANN by including them in the Zone File Data. ICANN can seek specific performance of the agreement by Verisign, or seek to terminate Verisign's contract as the .COM/.NET registry operator and transfer the operation to a successor registry. IANAL, ICANN and Verisign should seek the advice of their own legal advisors.
Re: When is Verisign's registry contract up for renewal
On 9/20/03 4:45 PM, Sean Donelan [EMAIL PROTECTED] wrote: ICANN can seek specific performance of the agreement by Verisign, or seek to terminate Verisign's contract as the .COM/.NET registry operator and transfer the operation to a successor registry. Quiet honestly I'd like to see all of the GTLD servers given to neutral companies, ones that ARE not registrars. Verisign is already engaging in a lot of unfair business practices because they hold the GTLD servers for net/com. The wildcard SNAFU is just one of their tactics to patch the financial hole since people have been switching registrars in droves. -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] PGP: http://www.inoc.net/~dev/ Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9 Sleep: A completely inadequate substitute for caffeine.
Re: Verisign vs ICANN
At 8:37 PM +0100 9/20/03, Simon Lockhart wrote: Okay, to Internet Experts, things are broken - their domain checking scripts no longer return domain available (why not just check whois.internic.net?). To quote Verisign, although this is true of all other whois providers: TERMS OF USE: You are not authorized to access or query our Whois database through the use of electronic processes that are high-volume and automated except as reasonably necessary to register domain names or modify existing registrations; the Data in VeriSign Global Registry Never mind that there isn't a standard format for the returned information between providers. The whois database is not a replacement for a DNS query. -- Kee Hinckley http://www.messagefire.com/ Next Generation Spam Defense http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Re: When is Verisign's registry contract up for renewal
ICANN can seek specific performance of the agreement by Verisign, or seek to terminate Verisign's contract as the .COM/.NET registry operator and transfer the operation to a successor registry. Quiet honestly I'd like to see all of the GTLD servers given to neutral companies, ones that ARE not registrars. [...] frankly i am mystified as to why icann awards registry contracts to for-profit entities. registrars can be for-profit, but registries should be non-profit or public-trust or whatever that specific nation's laws allow for in terms of requirements for open accounting, uniform dealing, and nonconflict with the public's interest. -- Paul Vixie
Re: Providers removing blocks on port 135?
Hi, NANOGers. ] I still disagree with this. To prevent SPAM, people shouldn't run open ] relays and the open relay problem should be solved. Breaking legitimate ] port 25 traffic is a temporary hack. I suspect that most spam avoids open relays. The abuse of proxies, routers, and bots for this purpose is far more in vogue. Watch out for worms such as W32.Sanper, which also provide a built-in spam relay network. Remove all of the open mail relays and you are left with...lots of spam. More at NANOG... ;) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: VeriSign SMTP reject server updated
Correction: They need to pull themselves out of the loop on this and allow DNS to work as intended. Owen --On Saturday, September 20, 2003 3:06 PM -0500 Eric A. Hall [EMAIL PROTECTED] wrote: on 9/20/2003 1:01 PM Matt Larson wrote: We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. You need to: 1) fatally reject mail for domains that are not delegated with 5xx -and- 2) softly reject mail for domains that are delegated with 4xx so the messages are requeed and may get to an authorized server on the next run Used to be able to use DNS for this. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Providers removing blocks on port 135?
However, I'm not convinced blocking port 25 on dialups helps much with that. What it does help with is preventing them from connecting to open relays. The real solution in the long run will be two-fold: 1. Internet hosts need to become less penetrable. (or at least one particular brand of software) 2. SMTP AUTH will need to become more widespread and end-to-endish. Owen --On Saturday, September 20, 2003 4:53 PM -0500 Rob Thomas [EMAIL PROTECTED] wrote: Hi, NANOGers. ] I still disagree with this. To prevent SPAM, people shouldn't run open ] relays and the open relay problem should be solved. Breaking legitimate ] port 25 traffic is a temporary hack. I suspect that most spam avoids open relays. The abuse of proxies, routers, and bots for this purpose is far more in vogue. Watch out for worms such as W32.Sanper, which also provide a built-in spam relay network. Remove all of the open mail relays and you are left with...lots of spam. More at NANOG... ;) Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
Re: When is Verisign's registry contract up for renewal
- Original Message - From: Robert Blayzor [EMAIL PROTECTED] To: Sean Donelan [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, September 20, 2003 5:01 PM Subject: Re: When is Verisign's registry contract up for renewal Quiet honestly I'd like to see all of the GTLD servers given to neutral companies, ones that ARE not registrars. Verisign is already engaging in a lot of unfair business practices because they hold the GTLD servers for net/com. The wildcard SNAFU is just one of their tactics to patch the financial hole since people have been switching registrars in droves. I've had long discussions with my admin team at the SOSDG on what would be the best way to prevent stuff like this from happening in the future. We came to the following conclusion: * Root servers or any critical DNS servers should not be in the control of companies. It should be handed over to Non-profit/not-for-profit orgs who will not be tempted to do the things Verisign has done.We feel completely comfortable with the root servers being in control of a group like the ISC or even govt. agencies like NASA. There is too much at stake here for people to be playing games with TLDs, especially ones as important as .com and .net. -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.2mbit.com ICQ: 8077511
Re: Verisign vs ICANN
KH Date: Sat, 20 Sep 2003 17:03:04 -0400 KH From: Kee Hinckley KH The whois database is not a replacement for a DNS query. Especially considering how Verisign whois info often lags waaay behind what is correct. Outdated NS info, anyone? Eddy -- Brotsman Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
If Verisign *really* wants to help ...
The logical follow-on to IP-based Sitefinder is SS7-based Phonefinder. I propose we redirect all not in service telephone numbers to Verisign's CEOs direct telephone number. --lyndon NT as a file server is faster than a dead bat carrying Post-It notes underwater. But not by much.
Re: When is Verisign's registry contract up for renewal
On 9/20/03 6:09 PM, Brian Bruns [EMAIL PROTECTED] wrote: * Root servers or any critical DNS servers should not be in the control of companies. It should be handed over to Non-profit/not-for-profit orgs who will not be tempted to do the things Verisign has done.We feel completely comfortable with the root servers being in control of a group like the ISC or even govt. agencies like NASA. Of course. Putting trust into big money corporations; look where that got us. (Hi Worldcom, Enron, Tyco, etc.) They have no respect for public interest, just the bottom line.. Hell and some don't even care about that. I don't believe in any one organization running the GTLD servers either. I believe giving it to two or three would be good. That way if one seems to do something seemingly stupid, we can effectively negate the perps and move on. There are lots of good organizations that can handle (and would be proud to handle) the GTLD servers. I don't know if I'd throw NASA in that group. (or any government agency for that matter) -- Robert Blayzor, BOFH INOC, LLC [EMAIL PROTECTED] PGP: http://www.inoc.net/~dev/ Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9 Supercomputer: Turns CPU-bound problem into I/O-bound problem. - Ken Batcher
Re: If Verisign *really* wants to help ...
On Sat, 20 Sep 2003, Lyndon Nerenberg wrote: The logical follow-on to IP-based Sitefinder is SS7-based Phonefinder. I propose we redirect all not in service telephone numbers to Verisign's CEOs direct telephone number. Actually, ATT already tried that once upon a time. If you dialed a number that was busy or not in service it redirected you to a helpful recording offering for a small charge to ring you back when the number was available. ATT discontinued it less than a week later. Of course, folks realize that Verisign is now one of the largest SS7 network operators in the world. Almost all CLECs in the USA use Verisign's SS7 network. Verisign has become the single point of failure for almost all of the USA's public networks (voice, data, Internet, etc).
Re: Providers removing blocks on port 135?
--On Saturday, September 20, 2003 2:46 PM -0700 Owen DeLong [EMAIL PROTECTED] wrote: I still disagree with this. To prevent SPAM, people shouldn't run open relays and the open relay problem should be solved. Breaking legitimate port 25 traffic is a temporary hack. Very little spam coming off dialups and other dynamically assigned, residential type connections has anything to do with open relays. The vast majority of it is related to open proxies (which the machine owners do not realize they are running) and machines that have been compromised by various viruses and exploits. These are machines that should not be running outbound mailservers, and in most cases, the owners neither intend nor believe that their systems are sending mail. Merely stating that people shouldn't run open relays didn't stop spam four years ago and it is less likely to do so now. My guess is that you haven't heard of the current issue with various servers running SMTP AUTH. These MTAs are secure by normal mechanisms, but are being made to relay spam anyway. It's hard enough to get mailservers secured when they are maintained by real sysadmins on static IPs with proper and informative PTR records. When the IP addresses sourcing the spam are moving targets, with generic PTR records, and the machines are being operated by end users with no knowledge that their computer is even capable of sending direct to MX mail, the situation is impossible to solve without ISP intervention via Port filtering, etc. If the person running the system in question chooses to do so, yes, they should be able to do so. If the person running the system in question wants to run server class services, such as ftp, smtp, etc, then they need to get a compatible connection to the internet. There are residential service providers that allow static IP addressing, will provide rDNS, and allow all the servers you care to run. They generally cost more than dial-ups or typical dynamic residential broadband connections. As a rule, you tend to get what you pay for. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Margie Arbon Mail Abuse Prevention System, LLC [EMAIL PROTECTED] http://mail-abuse.org
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003, Margie wrote: My guess is that you haven't heard of the current issue with various servers running SMTP AUTH. These MTAs are secure by normal mechanisms, but are being made to relay spam anyway. Would this be a reference to the qmail-smtp-auth patch that recently was discovered, that if misconfigured, could allow incorrect relays? If so, I would say that this was an isolated incident for a single patch for a specific MTA and only when it was misconfigured. I'm not sure I would describe that as secure by normal mechanisms nor quite the epidemic it was the first week or two. I'm not necessarily making a statement one way or the other on port 25 filtering, but SMTP Auth, when properly configured and protected against brute force attacks is certainly a useful thing. YMMV of course. andy -- PGP Key Available at http://www.tigerteam.net/andy/pgp
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003 15:05:08 -0700 Owen DeLong [EMAIL PROTECTED] wrote: | I'm not convinced blocking port 25 on dialups helps much with that. | What it does help with is preventing them from connecting to open | relays. There are so few open relays now that spammers have moved on. They now use, almost without exception, compromised Windows boxes acting as open proxies, or on which a trojan spam-sender of some sort has been installed - usually by one of the recent stream of viruses/worms. Blocking outbound port 25, other than via a designated smarthost, would at least prevent the direct-to-MX traffic from compromised boxes - which currently seems to be the spammers method of choice. | The real solution in the long run will be two-fold: | 1. Internet hosts need to become less penetrable. |(or at least one particular brand of software) | | 2. SMTP AUTH will need to become more widespread and end-to-endish. Right on both counts. But end-to-end may have to include the senders' fingers: as if bundled mail-client software contains the AUTH password it will be trivial for the spammers to hijack at the client level. And users won't like having to key in their password each time, meaning that trivial, guessable passwords will often be used. In recent weeks one particular spammer seems to have perfected a knack of breaking SMTP AUTH passwords on a widespread basis. Governments on both sides of the Pond may be reluctant to make spam illegal, but the issue is not spam (or we couldn't be discussing it here). This is a matter of system and network security, and if law enforcement had the skills, resources and motivation to deal with what are clear breaches of existing laws, admins' jobs would be significantly easier. Until then, we have to deal with issues as they arise. Networks need to be contactable quickly when compromised sites start to be misused, and to respond immediately. Not just wait until Monday Morning in their timezone ... if we can't deal with the incidents in real time, how can we expect law enforcement to do anything? Hello Comcast, Skynet, Ireland-onLine, NTL in the UK ... need I go on? Where's Declan McC when we need him? -- Richard
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003 23:22:34 +0100 Ray Bellis [EMAIL PROTECTED] wrote: What we do have though are (optional) *inbound* filters that make sure no-one can connect to their privileged ports over TCP/IP, and a mandatory filter that says only our network can deliver to their SMTP service. We don't get problems with open-relays on dialups. We didn't have any problems with MS-Blaster on dialups either... I would suggest instead that you have mandatory sending via your relays, and allow inbound connections to port 25. Sympatico, last I checked, didn't have any restrictions until you tripped off their alarms, at which point you needed to configure your smtpd to send mail via their relays. If they continued spewing copious amounts of spam, cut them off entirely until they fix their configuration. There are a couple of pluses to this type of setup; people like me who have dozens of (required) email addresses can forward them all to their home machine. Some of my family also much prefer this even though they've only got one or two email addresses. It also ensures that they can't send spam directly no matter what the source; blocking inbound connections will certainly stop open relays, but it won't stop trojans and worms and whatnot that are really just spamware. (Note that I consider spamware included in other applications and hidden from the user trojans.) pgp0.pgp Description: PGP signature
Re: Providers removing blocks on port 135?
* [EMAIL PROTECTED] (Ray Bellis) [Sun 21 Sep 2003, 00:25 CEST]: What we do have though are (optional) *inbound* filters that make sure no-one can connect to their privileged ports over TCP/IP, and a mandatory filter that says only our network can deliver to their SMTP service. There's an ISP in the Netherlands who do that too for their DSL customers. Unfortunately, their mail servers are not that reliable to begin with and also spool mail only for 4 hours, so if your connection is down for the weekend (happens more often if you work for a company in direct competition with the telco that owns this particular ISP) all your mail bounces instead of getting spooled somewhere and delivered later... -- Niels.
Re: If Verisign *really* wants to help ...
Verisign has become the single point of failure for almost all of the USA's public networks (voice, data, Internet, etc). I seriously don't like this situation, especially considering latest marketing twists with verisign's new services. What we have however are number of people working there have good technical experience running registry services (i.e. root dns, .com registry, ss7) but their managers who came from verisign itself are not interested in maintaining good level of service for such core services but rather extracting largest amount of money from these services which. If Verisign is to continue operating these core services (root dns, registry, ss7), they will need to be COMPLETELY separate from their other units (domain register) and run them as public trust. Or it may be best if Verisign were forced (by goverment and/or icann agreements) to move these into separate, possibly non-profit company like it was done when Internic (aka NSI) IP registration services were moved to ARIN. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003, Margie wrote: If the person running the system in question wants to run server class services, such as ftp, smtp, etc, then they need to get a compatible connection to the internet. There are residential service providers that allow static IP addressing, will provide rDNS, and allow all the servers you care to run. They generally cost more than dial-ups or typical dynamic residential broadband connections. As a rule, you tend to get what you pay for. So if someone wants to run Outlook or Netbios from home, they need to get a server-class connection to the Internet? If everyone buys a server-class connection, we end up back were we started. The problem is many clients act as servers for part of the transaction. Remember X-Windows having ports 6000-6099 open on clients? IRC users need to have Identd port 113 open. Microsoft clients sometimes need to receive traffic on port 135, 137-139 as well as transmit it due to how software vendors designed their protocols. Outlook won't receive the new mail message, and customers will complain that mail is slow. And do we really want to discuss peer-to-peer networking, which as the name suggests, peer-to-peer. It costs service providers more (cpu/ram/equipment) to filter a connection. And even more for every exception. Should service providers charge customers with filtering less (even though it costs more), and customers without filtering more (even though it costs less)? If the unfiltered connection was less expensive, wouldn't everyone just buy that; and we would be right back to the current situation? In the old regulated days of telephony, service providers could get away with charging business customers more for a phone line or charging for touch-tone service. But the Internet isn't regulated. There is always someone willing to sell the service for less if you charge more than what it costs.
Re: VeriSign SMTP reject server updated
Declan McCullagh wrote: On Sat, Sep 20, 2003 at 11:34:17AM -0700, ken emery wrote: I think you haven't gotten it. I'm getting the message from you that the changes made to the com and net gTLD's are fait accompli. From the That's the exact message I got from Verisign on Thursday. See: http://news.com.com/2100-1024-5078657.html Basically Verisign is willing to tweak the service to make it less controversial but not stop it. Then Verisign is no longer a responsible holder of the data and ICANN sould act to remove their control and invalid data. / Mat I wonder what ATT and InterNap have to say about it as the upstreams I can see of AS30060. While InterNap has a short but notable career of letting their customers do whatever they want (such as completely deaggregate all of their address space down to /24s), I'ld think ATT would be somewhat responsible. I would hope Verisign would abandon their experiment if they received no ill-gotten gains.
RE: If Verisign *really* wants to help ...
I fairly certain the previous poster is talking not-in-service numbers, not busy numbers. Busy number redial is available here in the states, but most places you have to bang a *XX code when you get the busy signal, you don't tend to get any recording for it. Not in service numbers may get the LATA unable to connect or unable to route service depending on if the number you dialed was even in LERG. The system only does that in the even that it actually rang (and ringing in this sense doesn't mean you heard a ring generator on your end). And yes, for the benefit of the others on NANOG, the process is more complicated than that, so lets not start another even further off-topic thread on the TDM/POTS system. And how it routes, or fails to route, calls. --On Saturday, September 20, 2003 6:59 PM -0400 Vivien M. [EMAIL PROTECTED] wrote: Just out of curiosity, why did they discontinue it? Here in Bell Canada land, this type of thing has been around for hm... 8 years or so? There was a big outcry the first week or so from dialup users (at the time, busy signals were more common than now), then eventually they all did the *XX code to permanently disable it. It is still enabled on new [residential, at least] POTS lines. Vivien -- Vivien M. [EMAIL PROTECTED] Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/ -- Undocumented Features quote of the moment... It's not the one bullet with your name on it that you have to worry about; it's the twenty thousand-odd rounds labeled `occupant.' --Murphy's Laws of Combat
Re: Bye Snubby, hello Mail Rejector
On Sat, 20 Sep 2003 09:39:34 + (GMT) Stephen J. Wilcox [EMAIL PROTECTED] wrote: Ooh, when did Verisign get rid of their Snubby program and put in something that actually behaves like an SMTP server? Seems verisign are watching the community reaction and acting to rectify their errors.. well some of them Worth noting that they don't accept mail to [EMAIL PROTECTED] [ [EMAIL PROTECTED]: ~/ ]$ telnet aabbefhkl.net 25 Trying 64.94.110.11... Connected to sitefinder-idn.verisign.com. Escape character is '^]'. 220 VeriSign mail rejector (Postfix) EHLO willow 250-OK 250-PIPELINING 250-SIZE 1024 250-ETRN 250-XVERP 250 8BITMIME MAIL FROM: [EMAIL PROTECTED] 250 Ok RCPT TO: [EMAIL PROTECTED] 550 unknown[24.101.18.86]: Client host rejected: The domain you are trying to send mail to does not exist. QUIT 221 Bye Connection closed by foreign host. pgp0.pgp Description: PGP signature
Re: Providers removing blocks on port 135?
--On Saturday, September 20, 2003 6:36 PM -0500 Andy Walden [EMAIL PROTECTED] wrote: Would this be a reference to the qmail-smtp-auth patch that recently was discovered, that if misconfigured, could allow incorrect relays? No, that was the tip of the iceberg. If so, I would say that this was an isolated incident for a single patch for a specific MTA and only when it was misconfigured. I'm not sure I would describe that as secure by normal mechanisms nor quite the epidemic it was the first week or two. We've seen the same behavior out of Postfix, QMail, Imail, Mdaemon, Exchange, Sendmail, Mercury, Merak, NTMail, and others that I can't recall off the top of my head. In some cases, the relaying was fixed with the release of a new patch or a conf change. In others, particulary Exchange, the guest account was enabled, allowing open authentication. The big BUT is that there is a not insignificant number of other machines that have either been shown to have been brute forced or we've yet to determine the mechanism that allows the relay. The problem is not small. I'm not necessarily making a statement one way or the other on port 25 filtering, but SMTP Auth, when properly configured and protected against brute force attacks is certainly a useful thing. YMMV of course. Yes, it is a useful thing. It's not the ultimate answer. A machine that tests secure by any test we are willing to run, that requires fifteen character passwords, with mulitple special characters required, that is STILL relaying indicates there is a bad thing happening somewhere. -- Margie
Re: Bye Snubby, hello Mail Rejector
On Sat, 20 Sep 2003, David B Harris wrote: Worth noting that they don't accept mail to [EMAIL PROTECTED] 250-SIZE 1024 250-ETRN Those two capabilities are bogus as well. --lyndon Always carry a short length of fibre-optic cable. If you get lost then you can drop it on the ground, wait 10 minutes, and ask the backhoe operator how to get back to civilization. -- Alan Frame
Re: Appreciation for Bind patches
I have been following the various threads relating to Verisign and wanted to make one comment that I feel has been missing. Simply put, I would like to publicly express my appreciation to Mr. Vixie for taking the time to add the root-delegation-only patch for Bind. I'm fairly new to NANOG, but I'm sure that others beside myself also feel a thank you is appropriate. thanks for those kind words, but rapid response of this kind is one of our obligations to the bind forum, and it's only because of our members that we're able to serve the community in this way. btw: here's the short term results of me deploying root-delegation-only on my personal mail server at home: Sep 20 22:06:25 named: enforced delegation-only for 'com' (ok61930.com) Sep 20 22:06:25 named: enforced delegation-only for 'com' (ok61930.com) Sep 20 22:08:23 named: enforced delegation-only for 'com' (helimore574.com) Sep 20 22:08:23 named: enforced delegation-only for 'com' (helimore574.com) Sep 20 22:08:42 named: enforced delegation-only for 'com' (netscape1008.com) Sep 20 22:08:43 named: enforced delegation-only for 'com' (netscape1008.com) Sep 20 22:16:02 named: enforced delegation-only for 'com' (aagf91512.com) Sep 20 22:16:02 named: enforced delegation-only for 'com' (aagf91512.com) Sep 20 23:11:48 named: enforced delegation-only for 'com' (ok62928.com) Sep 20 23:11:48 named: enforced delegation-only for 'com' (ok62928.com) Sep 20 23:14:51 named: enforced delegation-only for 'com' (2mails235.com) Sep 20 23:14:51 named: enforced delegation-only for 'com' (2mails235.com) Sep 20 23:19:44 named: enforced delegation-only for 'com' (gratis-gratiss.com) Sep 20 23:19:44 named: enforced delegation-only for 'com' (gratis-gratiss.com) Sep 20 23:31:22 named: enforced delegation-only for 'com' (bosfvp.com) Sep 20 23:31:22 named: enforced delegation-only for 'com' (bosfvp.com) Sep 20 23:31:26 named: enforced delegation-only for 'com' (xvarnf.com) Sep 20 23:31:27 named: enforced delegation-only for 'com' (xvarnf.com) Sep 20 23:31:31 named: enforced delegation-only for 'com' (abdknt.com) i send this just in case anyone doubts that spammers forge sources. after the wildcard went in and before i deployed root-delegation-only at home, those would have been spams reaching my inbox. this is not much compared to a real mail server, but it is after all just my family here. (and i can assure you all that nobody typo'd the above domain names here.)
Re: Appreciation for Bind patches
On Sat, 20 Sep 2003, Andrew Fried wrote: I have been following the various threads relating to Verisign and wanted to make one comment that I feel has been missing. Simply put, I would like to publicly express my appreciation to Mr. Vixie for taking the time to add the root-delegation-only patch for Bind. I'm fairly new to NANOG, but I'm sure that others beside myself also feel a thank you is appropriate. I have to second this. I started work on a bind8 patch for Anonymizer's DNS servers after learning of the .com/.net change well before the news that bind9 would have out of the box support for the features I needed. This comes as a great relief, since there is now a supported and de facto standard way of dealing with the Verisign breakage. I don't have to worry about maintaining an in-house solution to this problem over version changes, and I don't have to worry about possible unexpected behavior due to errors on my part. This is probably the most responsive I have ever seen any software vendor perform in providing a solution to someone else's problem. As a side effect of bind9's support for the root-delegation-only feature, general performance of our systems have improved. (We upgraded two of our caching name-servers from bind8 to bind9, and our proxy response times have jumped by nearly a second in some cases.) This certainly isn't a scientific benchmark of performance advantages for bind9 over bind8, but I am finding myself having to ask the question is it time to retire bind8 entirely? now. Thanks again, Len
Re: Appreciation for Bind patches
On Sat, 20 Sep 2003, Andrew Fried wrote: I have been following the various threads relating to Verisign and wanted to make one comment that I feel has been missing. Simply put, I would like to publicly express my appreciation to Mr. Vixie for taking the time to add the root-delegation-only patch for Bind. I'm fairly new to NANOG, but I'm sure that others beside myself also feel a thank you is appropriate. Absolutely. Special thanks are also due to the members of the ISC BIND Forum for their financial support of such efforts. Verisign's ill-advised actions have put DNS and other Internet governance issues on the radar of many, including myself. I'm considering an 'individual' ($200/yr) membership to the BIND Forum, and I encourage others who haven't already to do the same. -Graham Freeman http://www.jahiel.net/
Re: VeriSign SMTP reject server updated
On Sat, Sep 20, 2003 at 02:01:39PM -0400, Matt Larson wrote: [snip] We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. One alternate option we [snip] Wrong protocol. There should be *NO* SMTP transactions for non-extistant domains. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003, Margie wrote: Very little spam coming off dialups and other dynamically assigned, residential type connections has anything to do with open relays. The vast majority of it is related to open proxies (which the machine owners do not realize they are running) and machines that have been compromised by various viruses and exploits. These are machines that should not be running outbound mailservers, and in most cases, the owners neither intend nor believe that their systems are sending mail. Merely stating that people shouldn't run open relays didn't stop spam four years ago and it is less likely to do so now. This veers off the original topic. Of course I don't think any of us recall what that was anyways... I remember back when I first started using the DUL. Of all the DNSBLs I used at the time it blocked the most spam of any of them. I mean that by long shot. About the time the DUL and other MAPS lists went commericial is about the same time I noticed fewer and fewer hits on the DUL. We still pay for an AXFR (IXFR) of it but it doesn't block nearly as much as it used to. The open proxy lists block an unbelievable amount of spam. In theory the DUL would take care of this if it also list residential dynamically assigned cable/dsl lines (if it doesn't already, hmmm...). Still the open proxy DNSBLs seem to be more effective now. Bottom line, use every DNSBL you possibly can and don't be afraid to pay for them. I strongly recommend redirecting SMTP traffic for this same class of user as well. Now I'm going to get even more off-topic. It occurs to me that major changes to a protocol such as SMTP getting auth should justify utilizing a different tcp/ip port. Think about it like this. If authenticated forms of SMTP used a different TCP/IP port we netadms could justify leaving that port open on these same dynamically assigned netblocks in the theory that they are only able to connect to other authenticated SMTP services. Doesn't that seem logical? Justin
Bind 8 and delegation only ?
Is there any work being done on adding this support to BIND 8 ??
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003, Sean Donelan wrote: It costs service providers more (cpu/ram/equipment) to filter a connection. And even more for every exception. Should service providers charge customers with filtering less (even though it costs more), and customers without filtering more (even though it costs less)? If the unfiltered connection was less expensive, wouldn't everyone just buy that; and we would be right back to the current situation? Abosulutely. At least if the customer wants technical support or plans on paying for their bandwidth. It costs *more* resources for an ISP to *not* filter ports and it costs them *less* resources to filter known ports that are rarely used by Joe Blow average user but the cause of 99% of their (our) headaches. How many people here have ever worked in a helpdesk with hundreds of users calling you for help when they've been infected with the latest greatest Netbios-enabled virus and lost their report, thesis, archived email, pictures of the kids, you name it. I used to work at a Unv helpdesk. Every single time the mail server hiccuped for whatever reason, or the personal webserver was offline for a few minutes of maintenance in the week hours of the morning (no matter whether it was 2 minutes of 2 days) people would inundate us with complaints. All the real problems had to be put on hold so we could answer the phones. Technical support costs an ISP many times that of the neccessary CPU and RAM resources on an access server or border router needed to filter malicious ports. Why don't we just wait until we identify that a user has been infected or compromised (by whatever resource-hog of a method that entails). Then we can just disable their account and wait for them to call. Those calls are always the most pleasant of the day. When did proactive security measures become criminal? Was there a memo I missed? Justin
Any actual data to back up blocking Netbios ports?
On Sat, 20 Sep 2003, Justin Shore wrote: Abosulutely. At least if the customer wants technical support or plans on paying for their bandwidth. It costs *more* resources for an ISP to *not* filter ports and it costs them *less* resources to filter known ports that are rarely used by Joe Blow average user but the cause of 99% of their The majority of viruses still spread through port 25 and port 80. I've asked other providers about their experiences. Based on their experiences, the number of incidents for providers that filtered netbios was essentially the same as providers that didn't. It didn't significantly change the number of calls to their help desks over the long-term (e.g. 6 months) either. They were hit with the same number of drop-everything-all-hands-on-deck incidents. Microsoft Windows has more than enough vulnerabilities. Blocking a few ports doesn't change much. Deleting Outlook might help :-) I know how people working the help desk feel. But is this a case of do something rather than figuring out what the problem is. What data do people have to back up blocking specific ports. What were your control groups? With Trojan proxies appear on almost any port, blocking anything less than every port will be ineffective.
Re: Providers removing blocks on port 135?
On Sat, 20 Sep 2003, Justin Shore wrote: This veers off the original topic. Of course I don't think any of us recall what that was anyways... I remember back when I first started using the DUL. Of all the DNSBLs I used at the time it blocked the most spam of any of them. I mean that by long shot. About the time the DUL and other MAPS lists went commericial is about the same time I noticed fewer and fewer hits on the DUL. We still pay for an AXFR (IXFR) of it but it doesn't block nearly as much as it used to. At one time, signing up for throwaway dial-up accounts was a common spammer MO. We got hit a couple times, and they were like a plague of vermin [the spammers]. They'd sign up giving us bogus contact info and a freshly stolen (active) credit card. When the account was activated, they'd dial in using half a dozen or so lines and pump out as much spam (direct-to-MX) as they could. The really annoying bit is, we'd terminate them, they'd call right back, and sign up again, giving different bogus info and card numbers. We'd block them by ANI, and they'd block caller-ID when calling us. I ended up being forced to block access to some of our dial-up numbers both by ANI, and if there was no ANI, and then had to setup exceptions for a few customers in those areas who we never got ANI for. When I tried getting police in their areacode to investigate, they had no interest/were too busy...even though I could give them phone numbers the accounts were used from and stolen credit cards. To put a little operational spin in here...how many of you run dial-up networks where you refuse logins unless you get ANI?...and if you do this, do you also maintain an ANI blacklist? Anyway...they moved on to proxy abuse, then outright theft by creating their own proxies on compromised MS Windows boxes. Both methods have the advantage of totally hiding the spammer from the recipients and bandwidth amplification. I imagine you could utilize multiple spam proxies on broadband connections pumping out your spam while connected via dial-up yourself. If you look at the numbers at http://njabl.org/stats, about 5% of the hosts that have ever been checked are currently open relays (or nobody's bothered to remove them). IIRC, at one point, this was nearly 20%. 13.6% are open proxies...and the disparity is definitely still growing, with about 10x as many open proxies as relays being detected daily. Unfortunately, the new breed of purpose-built spam proxies are generally not remotely detectable, so the proxy percentage would be even higher if it included the newer spam proxies. -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Any actual data to back up blocking Netbios ports?
On Sat, 20 Sep 2003, Dan Hollis wrote: I'd like to see actual numbers I'm willing to be proved wrong. Go ahead.
Re: Appreciation for Bind patches
Andrew Fried writes: Simply put, I would like to publicly express my appreciation to Mr. Vixie for taking the time to add the root-delegation-only patch for Bind. You speak for many. Andrew Fried, Senior Special Agent United States Department of the Treasury Treasury Inspector General for Tax Administration Strategic Enforcement Division Now go audit Verisign's tax returns for the last 3 years :-).
Re: Any actual data to back up blocking Netbios ports?
On Sat, 20 Sep 2003, Dan Hollis wrote: On Sat, 20 Sep 2003, Sean Donelan wrote: On Sat, 20 Sep 2003, Dan Hollis wrote: I'd like to see actual numbers I'm willing to be proved wrong. Go ahead. you made the claim, lets see the data behind it its up to the claimant to support it with data, not for others to disprove it. Ok, you win. I withdraw the claim. Blocking Netbios ports will solve the world's problems. It will be just as successful as blocking port 25 was at solving the spam problem.
Re: VeriSign SMTP reject server updated
On Sat, Sep 20, 2003 at 08:31:27PM -0400, Joe Provo wrote: We are interested in feedback on the best way within the SMTP protocol to definitively reject mail at these servers. One alternate option we [snip] Wrong protocol. There should be *NO* SMTP transactions for non-extistant domains. Not so. The correct solution is to remove the wildcarding. Until that happens, the best thing to do IS accept and then reject mail. This is significantly better than leaving it to expire in a spool after 5 days. You might be find allowing the mail to sit in your spool, but for those admins who manage large-scale systems where a queue will grow to several gigabytes in a day or less under there conditions, verisign not answering SMTP would be BAD. Verisign aren't stupid. They know how much of a problem not talking on port 25 would be for the large ISP's around the world. They might put up with our bitching, but I'm sure they don't want multiple lawsuits sitting in their mailbox for breaking an ISP's mail.
