|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical 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 >
|