ICANN ICANN Email List Archives

[stld-rfp-mail]


<<< Chronological Index >>>    <<< Thread Index >>>

Public Comments for .mail TLD Proposal

  • To: <stld-rfp-mail@xxxxxxxxx>
  • Subject: Public Comments for .mail TLD Proposal
  • From: "Nasser Dassi" <nasserd@xxxxxxxxxx>
  • Date: Fri, 9 Apr 2004 11:15:23 -0400
  • Thread-index: AcQeRXp4qodsBomARWiafWy+Cwz6Mg==

Title: Public Comments for .mail TLD Proposal

Hello everyone,

After having first peered through the archives, I still believe what I have to say has not been established.  There are three major points, and each one gives new insight into the realities of the Internet and the email problem we all face.

FIRSTLY, to echo many other claiments, the ultra-high cost of "over US$2000" is down-right ridiculous.  That means if I were to register a new domain (either as a small business, personal portfolio, online journal, photo journal, etc) I would have to a) pay anywhere from usd$10 to usd$200 for a domain name (.com, .net… to .ca, .us, .biz)… then, b) pay an additional us$2000+ for the capability of sending 'authenticated' email… then, c) pay us$??? for a web-hosting package, and email solution… then, d) pay us$??? for both a new email client (software upgrade, or brand new purchase)… then, e) pay us$??? for a new email server (if I choose to host email in-house). 

That's expensive and *not* really worth the extra money (to which "slush fund" comes to mind, "dot-com days" mentality come to mind, and "corporate greed" come to mind).  It sounds more like a big-business scheme to make the wealthy email-verified, and everybody else *must* rely on yahoo.com.mail to send/receive email because it is too expensive to acquire one's own email domain.  Conspiracy theory, anyone?!

SECONDLY, the ease-of-use would dramatically change.  It seems of greater hardship for remote workers of even big businesses, all the way down to the little guys and boys and girls, to send email from anywhere *but* their corporate offices.  That means all remote workers and travelling workers and users would *have* to use VPN technology to get INTO their corporate offices from wherever they are in order to send an email that shows it has originated from a specific building (effectively the only way a system can verify that the email is not spam, as it would trace the origin of the email as being from a set of email servers).

As such, it would actually HAMPER big businesses with work-from-home or work-remotely policies.  The security administrators would have a headache and a field day opening up system resources (either in web-based corporate email, or opening up corporate POP3/SMTP gateways).  Furthermore, to this point of remote-workers, it would also be a hinderance for anyone who might use either their LOCALHOST as an SMTP gateway (because most email providers, whether they host your domain or not in their DNS, do not provide SMTP as a feature).  And SMTP-through-localhost is also one of two ways to go when using email from an ISP.  Certainly they *might* want to open up their SMTP gateways for their clients to send email, but the moment that happens, the spam messages will flood their networks and seem to come from an *authenticated* SMTP/DNS gateway/server… in turn nullifying the effects of using a .mail domain to begin with!!!  Everyone else who is not part of a big-business… FORGET ABOUT IT!!!!!!!!!!!!

So far acquisition of a .mail TLD is already a headache (as established in point One), and using it to its seemingly intended ways (as established in point Two), the natural progress of thought brings me to point Three, the next generation of emails we can expect to swamp our systems with the unevitable next generation.

THIRDLY, to introduce a new concern: the landscape for a new wave of viruses, worms, and spam… all meshed into one:

This new method would basically make criminally-minded (and intrusion-minded) hackers to build even more clever means of dirty-work (and corporate espionage, if you can believe it).  Their methodology is quite simple: these developers would build more-clever means of getting programs into the corporate network, which would make them for-hire by spammers… these new programs would then propogate through a network's architecture and learn and capture the layout of the systems.  They would then latch onto emails being sent legitimately and 'mysteriously' manage to spread spam in a self-propogating manner.

Or, better yet, because the system would be transparent, DDoS attacks can happen against the white-list database, or even the hackers can be hired to reverse-engineer packets and digital papertrails in the classic example of *spoofing* an email's origin.

After these 3 steps, the end result is the same: unwanted email will persist, email and security will still be a problem (it makes them both one, instead of two distinct issues), the TLD company would make millions of dollars American for the benefit of merely requiring the bulk emailers to sit-back and think of a new plan (which takes about a day or two), and the end-users (corporate, small biz, personal users, or vanity sites…. Including porn sites) would shelve out a lot of money for absolutely zero gain.

… You might not agree with me, ICANN, but you cannot deny that these are overall three very valid points.  There is very little that can be done to curb bulk emailers without the assistance of imposing criminal charges against them.  It is the harsh readily… and you know this as well as I do, you're mother told you so.

Have a good day.

- nasser

PS: I've been a software developer/architect since high school (almost a decade ago)… and I'm proud of it.  I would love to see the email issues resolved, but realistically there are more safe heavens in the world than can be imposted within the Internet's governing bodies themselves.  As many drone users are out there, there are a heck of a lot of free-thinkers who do not follow the norm.  The .mail solution proposed to which I responded to is just another solution that assumes the world is filled with drones, and that everyone follows the norm.



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy