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.
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.
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 ...
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.
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 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...
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.
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.
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.
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.
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)
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.