I'm just as irritated as most about the new executive decision that has been currently forced on us by Verisign which I really hope is reverted. Certain pieces of the news blurbs are bouncing around in my head and I came up with something for you to think about. The part of the Verisign thing that bugs me most at the moment: They don't pay a thing for all of these domains that they are now accepting queries for. It would seem to me to our benefit as an Internet community to word this in our favor and send Verisign a bill for manipulating their monopoly on the .net and .com zones. My suggestion: Since they are now accepting web queries on all of these typo domains, they should pay a reasonable fee (close to a full domain name registration fee) for each misguided soul that winds up on the Verisign web site. I believe the proceeds from this new bill they have brought upon themselves should help fund the organizations that entrusted Verisign to the task of holding the .net and .com zone. (IAB, ICANN, ... whomever is supposed to slap them back into doing what they were previously assigned them to do no more, no less) Are IAB/ICANN...etc non-profit? I really don't know who it should go to, but if there is money there, I'm sure it can improve something we collectively need. I also believe those same organizations deserve a cut of any related profit. If Yahoo/Inktomi pays $0.50 per click/search through, send $0.25 to IAB to improve $X. I think the "for free" angle any overseeing body wants to address this from. Speak to them in their language: "You just misappropriated something for free." I think we need to be ready to consider both of their responses to that: - reverting to the proper error messages (Amen we all go home...err wherever you go when you're not doing this) - making use of fixing the "for free" part. (read: using the profit for the community) Thus far, I've heard no mention of putting this to our own use. ...and for heavens sake, stop accepting any kind of request at all on port 25!! Just shut it down altogether. There is no reason for you to accept any connection of any kind on port 25! ...shutting up now, Gerald - How are ya? Never been better, ... Just once I'd like to be better.
On Thu, 18 Sep 2003 00:25:48 -0400 (EDT) Gerald <gcoon@inch.com> wrote: <snip>
...and for heavens sake, stop accepting any kind of request at all on port 25!! Just shut it down altogether. There is no reason for you to accept any connection of any kind on port 25!
I shall only respond to this portion. The rest of it ... well, I'll just leave it at that :) If they don't accept anything on port 25, either by sending all packets to /dev/null or by responding with SYN+RST ("Connection refused"), MTAs everywhere will consider this a "temporary error." In other words, the mail will sit on queues for weeks, typically, until an error is finally sent to the sender. Currently an error is sent to the sender immediately.
On Thu, 18 Sep 2003 00:36:05 EDT, David B Harris <david@eelf.ddts.net> said:
If they don't accept anything on port 25, either by sending all packets to /dev/null or by responding with SYN+RST ("Connection refused"), MTAs everywhere will consider this a "temporary error."
They could save us a bunch of RTTs, remove concerns they were harvesting the MAIL FROM and RCPT TO, and lower their load if they just implemented RFC1846 and replied '521 64.94.110.11 Fleep Off'
From RFC1846:
1. Motivations Hosts on the Internet have shifted from large, general-purpose hosts to smaller, more specialized hosts. There is an increasing number of hosts which are dedicated to specific tasks, such as serving NTP or DNS. These dedicated hosts frequently do not provide mail service. Usually, these mailless hosts do not run an SMTP server. Unfortunately, users will occasionally misaddress mail to these hosts. Regular SMTP clients attempting to deliver this misaddressed mail must treat the lack of an SMTP server on the host as a temporary error. They must queue the mail for later delivery, should an SMTP server be started at a later time. This causes the mail to remain queued for days, until it is returned with what is usually a confusing error message.
On Thu, 18 Sep 2003, David B Harris wrote: : > ...and for heavens sake, stop accepting any kind of request at all on port : > 25!! Just shut it down altogether. There is no reason for you to accept : > any connection of any kind on port 25! : If they don't accept anything on port 25, either by sending all packets : to /dev/null or by responding with SYN+RST ("Connection refused"), MTAs : everywhere will consider this a "temporary error." Then the wildcard should have included a MX that points to nowhere, rather than implementing a fake MTA that allows the MAIL FROM and RCPT TO addresses to be transmitted. The record "IN MX 0 ." is commonly used for this purpose. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com>
* tv@duh.org (Todd Vierling) [Thu 18 Sep 2003, 14:34 CEST]:
On Thu, 18 Sep 2003, David B Harris wrote:
If they don't accept anything on port 25, either by sending all packets to /dev/null or by responding with SYN+RST ("Connection refused"), MTAs everywhere will consider this a "temporary error." Then the wildcard should have included a MX that points to nowhere, rather than implementing a fake MTA that allows the MAIL FROM and RCPT TO addresses to be transmitted. The record "IN MX 0 ." is commonly used for this purpose.
Postfix just throws a "Malformed name server reply" error and keeps the mail in the queue if you do that. No solution there. The expected behaviour is that mail addressed to recipients at nonexistent domains *bounces* with no delay and, of course, with as little information about the transaction leaked to third parties such as TLD name service operators. -- Niels.
On Thu, 18 Sep 2003 08:24:40 -0400 (EDT) Todd Vierling <tv@duh.org> wrote:
: > ...and for heavens sake, stop accepting any kind of request at all on port : > 25!! Just shut it down altogether. There is no reason for you to accept : > any connection of any kind on port 25!
: If they don't accept anything on port 25, either by sending all packets : to /dev/null or by responding with SYN+RST ("Connection refused"), MTAs : everywhere will consider this a "temporary error."
Then the wildcard should have included a MX that points to nowhere, rather than implementing a fake MTA that allows the MAIL FROM and RCPT TO addresses to be transmitted. The record "IN MX 0 ." is commonly used for this purpose.
Yeah, thanks for pointing this out. T'was an accidental omission in my mail.
In a message written on Thu, Sep 18, 2003 at 12:25:48AM -0400, Gerald wrote:
They don't pay a thing for all of these domains that they are now accepting queries for. It would seem to me to our benefit as an Internet community to word this in our favor and send Verisign a bill for manipulating their monopoly on the .net and .com zones. My suggestion:
I've seen a lot of knee-jerk responses on the list to this issue, but this one is the first idea I think actually holds up to more detailed inspection. Domain speculators have been registering typos for years, paying money for them, and redirecting you to all sorts of things. While this may not win them any friends it is generally accepted. Verisign can now do that without paying for each mistyped domain, giving them a huge (economic) advantage. [Note: yes, there are technical advantages, like they get everything with one record, but money talks.] Now, as much as I hate ICANN, I do think they are entitled to their cut of each one of these domains. If I worked at ICANN I would write a script to "find" domains, show that some large number of gTLD's respond, and then show Verisign only paid for a fraction of that number. Verisign's liability here is huge, if you just assume 36 characters (a-z0-9) and 64 character long domain names you could charge them for 36^64 domains. I strongly encourage ICANN to bill them for all the domains they are now redirecting (eg, all mathematically possible, more detailed analysis required), and for the domain speculators who've been registering for years to sue them for unfair monopolistic practices, or something, since they clearly have an unfair advantage. Heck, you might even be able to get an injunction against them pretty quick. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
participants (6)
-
David B Harris -
Gerald -
Leo Bicknell -
Niels Bakker -
Todd Vierling -
Valdis.Kletnieks＠vt.edu