Re: VeriSign SMTP reject server updated
> Date: Thu, 25 Sep 2003 11:12:05 -0400 (EDT) > From: Gerald <[EMAIL PROTECTED]> [...snip...] > > Ugh...sucked in. Can we get back to network operation discussions. Someone > make a Verisign gripe/commiserate list. I'll sign up. [EMAIL PROTECTED] ...? Regards, Gregory Hicks > > G > > - How are ya? Never been better, ... Just once I'd like to be better. --- Gregory Hicks| Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | "The trouble with doing anything right the first time is that nobody appreciates how difficult it was." When a team of dedicated individuals makes a commitment to act as one... the sky's the limit. Just because "We've always done it that way" is not necessarily a good reason to continue to do so... Grace Hopper, Rear Admiral, United States Navy
Re: VeriSign SMTP reject server updated
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.
Re: VeriSign SMTP reject server updated
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 [EMAIL PROTECTED] & 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 dead20915-1433
Re: VeriSign SMTP reject server updated
>At anytime, Verisign could remove your .COM domain from their DNS for >a short period of time which would result in all of your inbound >email going to the Verisign collector servers. If this was only done >for a brief interval, say 10 minutes, you might never notice that it >had happened. But Versign's industrial espionage department would have >your email in their hands and could do whatever they wish with it. >How profitable might that be? Actually... If they were to accidentally remove someone's .COM domain and do that, that would be a criminal violation of ECPA, says my not-an-attorney analysis. Even if they did it by accident. Even if they didn't keep a copy. Even if their mail server didn't accept it and returned a 550 on the RCPT, if the sending mail agent did something braindead like just pump out a whole message plus embedded SMTP headers like... oh, I dunno... a bunch of Spamware does. It seems... wrong... to consider that we could file criminal charges against Verisign for illegally intercepting spam between the spammer and our systems, but it appears to be a legally consistent postulate. As Verisign is doing SiteFinder for commercial gain, it might even qualify for the higher penalties (1 yr first offense 2 yr each subsequent offense). I wonder if 'offense' would map to 'domain' or 'individual email message' or what. Conceivably could be very very bad news. -george william herbert [EMAIL PROTECTED]
Re: VeriSign SMTP reject server updated
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
Re: VeriSign SMTP reject server updated
On Mon, 22 Sep 2003 10:42:51 +0100 [EMAIL PROTECTED] wrote: | Meanwhile, I would have diverted a copy of the mailserver | communications at the Ethernet switch to a secret server that | does the actual logging of addresses and messages. | | Son of Carnivore? Son? or Brother? See: http://lists.insecure.org/lists/politech/2002/Oct/0009.html -- Richard
Re: VeriSign SMTP reject server updated
>> 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*. At anytime, Verisign could remove your .COM domain from their DNS for a short period of time which would result in all of your inbound email going to the Verisign collector servers. If this was only done for a brief interval, say 10 minutes, you might never notice that it had happened. But Versign's industrial espionage department would have your email in their hands and could do whatever they wish with it. How profitable might that be? Of course, the right way to do this would be to resend the email onward so that you never notice any missing messages at all. In fact, if I were designing the system to do this, I wouldn't log anything at the mailserver. I'd let the mail server and web server technical folks have plausible deniability. Meanwhile, I would have diverted a copy of the mailserver communications at the Ethernet switch to a secret server that does the actual logging of addresses and messages. Son of Carnivore? --Michael Dillon
Re: VeriSign SMTP reject server updated
>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. In other words, Verisign is actually increasing the amount of misspelled domain name traffic by sabotaging the spell-checking feature of your email program. Under normal circumstances you would have noticed your error and corrected it before sending the email. This implies that Verisign could be collecting a much larger number of valid email addresses by logging these seemingly misspelled domain names and then "correcting" the misspelling by closest match against the .COM database. This would be an immensely valuable list for spammers to acquire, whether they do it by paying Verisign or by infiltrating the company to steal it. And don't pay any attention to Matt Larson's comments regarding logging. If he is unable to shut off the wildcard redirection then he has no say over what data is collected and what is done with it. Verisign could easily reassign him with a promotion and then turn on the logging and collection of email addresses. We already know that this company is unscrupulous and not to be trusted. In future we need to ensure that the registry operating the .COM domain works under some sort of contract that controls how they function. This is a public resource that we ourselves have created and not a commercial asset to be milked for profit. --Michael Dillon
RE: VeriSign SMTP reject server updated
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Matthew S. Hallacy > Sent: Sunday, September 21, 2003 2:02 PM > To: [EMAIL PROTECTED] > 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. HallacyFUBAR, LART, BOFH Certified > http://www.poptix.net GPG public key 0x01938203 >
Re: VeriSign SMTP reject server updated
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 <[EMAIL PROTECTED]>... 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 [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
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. HallacyFUBAR, LART, BOFH Certified http://www.poptix.net GPG public key 0x01938203
Re: VeriSign SMTP reject server updated
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: VeriSign SMTP reject server updated
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
Re: VeriSign SMTP reject server updated
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. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: VeriSign SMTP reject server updated
SJW> Date: Sun, 21 Sep 2003 15:17:34 + (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 : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: VeriSign SMTP reject server updated
On Sun, 21 Sep 2003, Daniel Roesen wrote: > On Sun, Sep 21, 2003 at 10:08:27AM +, 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
Re: VeriSign SMTP reject server updated
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
Re: VeriSign SMTP reject server updated
On Sun, Sep 21, 2003 at 10:08:27AM +, 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
Re: VeriSign SMTP reject server updated
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
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.
Re: VeriSign SMTP reject server updated
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.
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: 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 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.
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
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: 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.
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/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
> 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
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
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
[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 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
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 >
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
> 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
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
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
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
> 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
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?
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
