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 <mlarson@verisign.com> VeriSign Naming and Directory Services
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?
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
<quote who="bert hubert">
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.
Bert, Matt works for (at clearly a high enough level to make technical recommendations) a dishonest and unethical company -- please don't try to defend his choice of employer. There are plenty of hardworking people at good companies who get crap on NANOG all the time, why don't we save our relief for them. Tight job market or not, everyone has a choice of where they work. He's made a poor choice. -davidu ---------------------------------------------------- David A. Ulevitch Washington University in St. Louis http://david.ulevitch.com -- http://everydns.net ----------------------------------------------------
On Sat, Sep 20, 2003 at 06:06:06PM -0500, David A. Ulevitch wrote:
There are plenty of hardworking people at good companies who get crap on NANOG all the time, why don't we save our relief for them. Tight job market or not, everyone has a choice of where they work. He's made a poor choice.
I think now would be an appropriate time for you to wake up and smell pretty things with pollen in them. The job market does still suck. Not just in North American, but in most of Europe too. And it seeks that whereas a year or two ago people with great skillsets (ie, which who were worth hiring even in a hiring freeze) are now also having hard times finding a job. I really don't think it's a "choice" to work for a good or bad employer at the moment.
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 matthew@eeph.com 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?
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 matthew@eeph.com
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:neal@lists.rauhauser.net 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
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 matthew@eeph.com
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:neal@lists.rauhauser.net 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
neal rauhauser wrote:
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 ...
Could we convince Washington that this is an operation of the axis of evil and they should send appropriate forces to remove the dictator(s) and liberate the .com and .net domain spaces to the people with freely elected governing body looking after them in the future? Pete
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
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 [..]
* ken@cnet.com (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.
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
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
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 AT&T 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 AT&T would be somewhat responsible. I would hope Verisign would abandon their experiment if they received no ill-gotten gains.
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
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 <mlarson@verisign.com> VeriSign Naming and Directory Services
On 9/20/03 3:39 PM, "Roy" <garlic@garlic.com> 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 rblayzor@inoc.net 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.
mlarson@verisign.com (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
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.
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. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
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. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
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" <ehall@ehsco.com> 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. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Sat, 20 Sep 2003, Eric A. Hall 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.
I had a thought, its a hack but.. What if you change the behaviour of the GTLD named daemons to return an NXDOMAIN response to any MX queries on non-existent domains, you will then take this whole debate on SMTP out of the equation ... Steve
On Sun, Sep 21, 2003 at 10:08:27AM +0000, Stephen J. Wilcox wrote:
What if you change the behaviour of the GTLD named daemons to return an NXDOMAIN response to any MX queries on non-existent domains, you will then take this whole debate on SMTP out of the equation ...
MTAs fall back to the A RR if there are no MX RRs for a given recipient domain. Regards, Daniel
On Sun, 21 Sep 2003, Daniel Roesen wrote:
On Sun, Sep 21, 2003 at 10:08:27AM +0000, Stephen J. Wilcox wrote:
What if you change the behaviour of the GTLD named daemons to return an NXDOMAIN response to any MX queries on non-existent domains, you will then take this whole debate on SMTP out of the equation ...
MTAs fall back to the A RR if there are no MX RRs for a given recipient domain.
That was my understanding but on checking with Paul he said that NXDOMAIN means dont do further checks so dont look for A... Steve
SJW> Date: Sun, 21 Sep 2003 15:17:34 +0000 (GMT) SJW> From: Stephen J. Wilcox SJW> That was my understanding but on checking with Paul he said SJW> that NXDOMAIN means dont do further checks so dont look for SJW> A... Return NOERROR for one type of RR, but NXDOMAIN for another? Is that valid?! Hit me with a clue-by-four if appropriate, but I thought NOERROR/NXDOMAIN was returned per-host, regardless of RRTYPE requested. Giving NXDOMAIN for MX yet returning NOERROR for A RRs doesn't sound kosher. Time for me to dig through a few RFCs. 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 : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.
on 9/21/2003 11:19 AM E.B. Dreger wrote:
Return NOERROR for one type of RR, but NXDOMAIN for another? Is that valid?! Hit me with a clue-by-four if appropriate, but I thought NOERROR/NXDOMAIN was returned per-host, regardless of RRTYPE requested. Giving NXDOMAIN for MX yet returning NOERROR for A RRs doesn't sound kosher.
It's not valid and it won't work very well if it works at all. Your local cache will use whatever it learned on the last query. This is the seed for another problem set with the various workarounds as well, although I'm still thinking these through. Different servers that provide different kinds of glue could theoretically trip your cache. At this point, I think we're on the verge of having multiple (different) namespaces, which is extremely dangerous. At the same time, the arguments against multiple roots are pretty much going out the window. To be clear, however, I don't think the workarounds are the problem. I think VeriSign has broken DNS by conflating error codes. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Sun, 21 Sep 2003, Eric A. Hall wrote:
on 9/21/2003 11:19 AM E.B. Dreger wrote:
Return NOERROR for one type of RR, but NXDOMAIN for another? Is that valid?! Hit me with a clue-by-four if appropriate, but I thought NOERROR/NXDOMAIN was returned per-host, regardless of RRTYPE requested. Giving NXDOMAIN for MX yet returning NOERROR for A RRs doesn't sound kosher.
It's not valid and it won't work very well if it works at all. Your local cache will use whatever it learned on the last query.
I didnt say it was valid :) just that if Verisign can't be stopped with their A record we might be able to mitigate on some of the things they broke (of course for a gtld to respond this way implies verisign actually implement this broken idea)
This is the seed for another problem set with the various workarounds as well, although I'm still thinking these through. Different servers that provide different kinds of glue could theoretically trip your cache.
Maybe, needs more thought for sure..
At this point, I think we're on the verge of having multiple (different) namespaces, which is extremely dangerous. At the same time, the arguments against multiple roots are pretty much going out the window.
Not at all, the problem is with .com and .net ... you arent seriously going to use an alternative root using someone elses .com/.net zones surely..
To be clear, however, I don't think the workarounds are the problem. I think VeriSign has broken DNS by conflating error codes.
Yup, it perhaps needs a couple more weeks for the dust to settle but early indications are that they do not intend to give this up without a fight and thus far no one has engaged them properly Steve
on 9/21/2003 12:00 PM Stephen J. Wilcox wrote:
At this point, I think we're on the verge of having multiple (different) namespaces, which is extremely dangerous. At the same time, the arguments against multiple roots are pretty much going out the window.
Not at all, the problem is with .com and .net ... you arent seriously going to use an alternative root using someone elses .com/.net zones surely..
I'm not advocating it, just pointing out the inconsistency that is exposed by this practice. On the one hand, we've got different servers returning different kinds of data for domains under com/net, depending on whether they are using a workaround or not (some give A or NODATA, others give NXDOMAIN). The namespace is inconsistent. Meanwhile, the argument against multiple roots (at the high level) is that the namespace becomes inconsistent. I don't see any substantitive difference at the high level of the debate. Sure there are other substantitive differences -- workarounds are contained to an administrative scope (until you consider the impact of cached glue data, anyway) -- but not at the high level. This is something VeriSign has invited. Just like when they post queries about fixing mail servers that were broken by their own deployment. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Beating up the spokestech may feel good but is pointless. The way to solve the Verislime problem is straightforward, but not simple. Make it unprofitable for them. Maybe that is by political pressure [but I doubt it -- they have big lobbying muscle..] from the Hill. It may be by lawsuits. It may be by driving their costs up. It may be by hurting their other revenue lines, including registration. I donno. (Today, all I wish is that all this &^%^&*^ swen garbage was choking their pipes, not mine.) -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
On Thu, 25 Sep 2003, David Lesher wrote:
The way to solve the Verislime problem is straightforward, but not simple.
Make it unprofitable for them.
...can't resist hitting reply. First there is little to no way to make this unprofitable for them since they already have people paying for the opportunity to catch the eyes of these lost Internet travellers. Second, it would have to be a negative cash flow to be nixed in a corporate setting. ("unprofitable" does not necessarily convey: negative cash flow) Ugh...sucked in. Can we get back to network operation discussions. Someone make a Verisign gripe/commiserate list. I'll sign up. G - How are ya? Never been better, ... Just once I'd like to be better.
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
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.
On Sat, 20 Sep 2003, Avleen Vig 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]
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.
Did someone already suggest adding an MX to the * record that points to a nonexistent host (obviously in some other TLD)? At least in my environment (sendmail/bind9/Linux), I can setup a wildcard record with an A record and an MX record pointing to a bogus host, and mail bounces immediately. 550 5.1.2 <jlewis@nomail.wild.lewis.org>... Host unknown (Name server: nomail.invalid.: host not found) I think the whole wildcards in .com/.net is a bogus idea...but this sort of setup would at least keep lots of mail from trying to get delivered to VeriSlime. I've already had to fix one old SpamAssassin installation that was scoring mail based on hits in one of the dorkslayers.com dnsbls that no longer exists. It seems dorkslayers.com has decided to fix this by registering some name servers again. Until recently, they'd taken the name server records off the domain, and so VeriSlime had hijacked dorkslayers.com, turning it and all its subzones into a 0/0 dnsbl. modified: 2003-09-16 15:52:46 UTC JORE-1 ---------------------------------------------------------------------- Jon Lewis *jlewis@lewis.org*| I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Sat, Sep 20, 2003 at 08:31:27PM -0400, Joe Provo wrote:
Wrong protocol. There should be *NO* SMTP transactions for non-extistant domains.
After being bit by this over the weekend I would have to agree, due to a screwup at netSOL a companies domain I manage was resolving to their sitefinder service, and all mail just went *poof*. -- Matthew S. Hallacy FUBAR, LART, BOFH Certified http://www.poptix.net GPG public key 0x01938203
Just wait until they start accepting the mail, logging it, and then returning it to sender. Make one hell of an interesting way to monitor whats going on out there .... Nahh, wouldn't happen, would it .... Eric
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Matthew S. Hallacy Sent: Sunday, September 21, 2003 2:02 PM To: nanog@merit.edu Subject: Re: VeriSign SMTP reject server updated
On Sat, Sep 20, 2003 at 08:31:27PM -0400, Joe Provo wrote:
Wrong protocol. There should be *NO* SMTP transactions for non-extistant domains.
After being bit by this over the weekend I would have to agree, due to a screwup at netSOL a companies domain I manage was resolving to their sitefinder service, and all mail just went *poof*.
-- Matthew S. Hallacy FUBAR, LART, BOFH Certified http://www.poptix.net GPG public key 0x01938203
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).
Matt, The problem is that some systems have a specially formatted response message that they send to their users under certain conditions. For example, commonly used Exchange servers will send User unknown for any 550 issued on a RCPT command, where as they would inform the user that the domain did not exist for nxdomain. I have heard that these messages were also sent back in the proper language. How will users of such systems know if it was a recipient issue or a domain issue? Granted, part of this problem in the example is the smtp implementation (which any abuse desk will tell you that it is aggrivating to get a call about a "User unknown" message when a Security Policy 550 5.7.1 was issued with comment). Of course, mail is the least of concerns. There are millions of programs written that check for NXDOMAIN. A lot of this software cannot readily be changed to recognize the wildcard, requiring recursors to be patched; which is almost as repulsive as the wildcard to begin with. Here's just 2 commonly used applications, who's output has changed which will break many expect scripts and then some. $ ftp jkfsdkjlsfkljsf.com ftp: connect: Connection refused ftp> quit $ ftp jklfskjlsfljks.microsoft.com jklfskjlsfljks.microsoft.com: unknown host ftp> quit $ telnet jlkfsjklsfjklsfd.com Trying 64.94.110.11... ^C$ telnet jksfljksfdljkfs.microsoft.com jksfljksfdljkfs.microsoft.com: Unknown host -Jack
participants (29)
-
Avleen Vig -
bdragon＠gweep.net -
bert hubert -
Daniel Roesen -
Dave Stewart -
David A. Ulevitch -
David Lesher -
Declan McCullagh -
E.B. Dreger -
Eric A. Hall -
Eric Germann -
Gerald -
Jack Bates -
jlewis＠lewis.org -
Joe Provo -
ken emery -
Matt Larson -
Matthew Kaufman -
Matthew S. Hallacy -
Matthew Sullivan -
neal rauhauser -
Niels Bakker -
Owen DeLong -
Paul Vixie -
Petri Helenius -
Robert Blayzor -
Roy -
Sean Donelan -
Stephen J. Wilcox