Re: [gnso-pednr-dt] Post expiry domain email functionality.

[Sivasubramanian M <isolatedn@xxxxxxxxx>]

 Dear Mike O'Connor,


Thank you for having taken the time to write such an elaborate explanation
on why this can't be done. I find most of what you have valid and sound. and
broadly I agree that there are finer points that make this proposal
complicated in implementation. But there are answers to some of the
questions that you have raised, if not for all questions, as given below:

Please scroll down:

On Sun, May 30, 2010 at 3:29 AM, Mike O'Connor <mike@xxxxxxxxxx> wrote:

> sorry to revive this thread, but i thought i'd chime in with a few things.
>
> to make things clear, i hold the "all services should immediately stop"
> view with regard to expiring domain names -- one possible exception being a
> web-page redirect to a page that says something like "this domain has
> expired, here's how to get it fixed."
>
> i'm interested in consistent behavior (across all ports) when a domain
> expires.  having one service (email) continue, while all other drop, doesn't
> do a lot for me.  i think if *every* registrar dropped *all* services when
> domains expire we would have an easier time writing the educational material
> to help registrants understand what is happening and what they should do.
>
> one difficulty with the "deliver email through an external provider" plan
> is the security problem that might well be raised by having email
> unexpectedly redirected to that provider.  for example, let's say
> BigSecretCorp lets their domain expire and all email suddenly flows across
> an external email provider, thus allowing the external provider to read all
> of BigSecret's email.  their security folks would probably go crazy.  so
> would their corporate legal folks.
>


> same goes for privacy -- in this case the email of a medical or financial
> service organization whose email suddenly switches from their
> closely-guarded servers to an external service provider who may not be able
> to maintain the same level of privacy and access controls.  now those
> medical or financial records aren't private any more.
>

The scenario that you have outline above may not arise as the idea is to
take prior consent from Registrants to designate the expiry-phase email
server as the redundant server. Also, the expiry-phase email server wouldn't
be any unreliable service but one that is pre-screened and approved, so it
wouldn't be any third party with slipshod standards.

>
> then there's the authentication problem.  let's say that the domain for a
> multi-person organization expires.  each of those accounts have
> username/password authentication to retrieve email.  since there's no way
> the external provider could know those credentials, all of the email for all
> the people people in the organization would fail until credentials could be
> reestablished for them.
>

If Mx records can be copied to this trusted expiry-phase mail server, the
account particulars can also be copied so that the exercise of repeating
credentials is obviated.


> and, let's further presume that the domain is restored within a few hours.
>  now those redirected emails would be unretrievable using the organization's
> domain because the domain would be pointing back at the normal server rather
> than the temporary/external one.
>

At that stage the interim server could store all the email data undle ter a
subdomain retrievable and transferable to the renewed domain.


> then there's the "alias" problem.  there's no way that the external
> provider could know what names were real accounts, which ones were aliases
> for those accounts and which ones were email lists with multiple recipients.
>  so each separate email address would have to have its own account
> established -- which would break a lot of internal email routing within an
> organization.
>


If the idea of this expiry-phase email service is implemented, there would
be a mechanism for the server to know what aliases within the domain are
assigned and functional. And by default, it wouldn't capture
anybody@xxxxxxxxxx mail traffic.

>
> then there's the possibility of malicious use.  let's say i'm a Bad Guy and
> i want to cloak my email.  i could let one of my throw-away domains expire
> and then abuse the external email provider by sending buckets of spam
> through their servers.  i would gain a couple of things -- free email
> services and perhaps a more legitimate email IP address than the ones i
> normally use.
>

True. But some filtering mechanisms, detection mechanisms and controls could
be pre-installed in the expiry-phase server to disable highly probable
malicious activity.


>
> then there's the email-volume problem.  let's use some real-world examples
> here.  the University of Minnesota (i've got direct experience with that
> domain) has about 250,000 users.  the daily volume of email that crosses
> their servers is substantial.  by "substantial" i mean terabytes of storage
> and transport per day.  and that's just one domain.  my very own 
> CORP.comdomain sees traffic like this too, because of all the misdirected 
> email that
> should be sent to CORP.BigBux.com instead of BigBux.CORP.com.  we now
> block Corp.com email two ISPs upstream from me to protect us from all that
> misdirected email traffic.  and that's just one more domain in the hundreds
> of thousands of domains that drop every day.  the volume of mail created by
> fielding email for all expired domains is going to be simply stupendous.
>

Traffic and Storage limits can be a solution.  As this exercise necessary
needs prior approvals from the domain owner, the expiry-phase email service
could also specify variable fees based on the number of users within a
domain. ( The idea of this service is not particularly intended for large,
multiple-user domains as they are expected to be more organized than the
individual domain registrants. )

This email service would serve the function of a redundant service that
would be activated as a fall back server during the expiry phase. If this
idea is to be visualized as a commercial proposition by a commercial service
provider, he can consider this idea around the magic word "Insurance". What
would an individual and a corporate domain registrant would be willing to
pay as insurance fee to ensure that there wouldn't be an accidental
interruption of his email traffic during the renewal phase?

>
> then there's the problem of who does what, and who pays for it?  ultimately
> it is registrants who would have to pay,
>

Yes, true.


> either through a tax when they pay for the domain or directly,
> after-the-fact (they'd have to have agreed to pay the costs when they
> clicked on their registration agreement).  registrants would probably get
> cranky about paying a tax to take care of people who ignore their renewal
> notices (i know i would).  and they're probably howl if they got presented
> with an email-delivery bill after the fact.  but if we were to do something
> like this, i'd strongly favor after-the-fact billing.  failure to pay would
> mean losing the domain.  [see "abuse" above -- the bad guys wouldn't care,
> so this is impractical]
>

There are answers to some of the questions that arise from the situations
that you have described, and some more answers may emerge as we go, if we go
ahead. As I have mentioned, there could be mechanisms in place in the
expiry-phase email server to detect and isolate malicious activity and to
suspend service for malicious users. Also, this backup service could be
organized as for incoming mail only. Users within the domain may have to
configure an alternate smpt server/ go to an alternate email service
provider for outgoing mail, or Other solutions to other problems may emerge.


>
> but wait, then there's the problem of who pays if the domain registrant
> actually wants to let the domain expire?  there's no way to tell which
> domains are expiring by accident and which ones are expiring on purpose.  so
> the external provider would have to spin up accounts for all the email of
> all the domains that are actually supposed to expire.  who would pay for
> handling all that traffic?
>

I have covered this in my previous messages. The cost of providing service
to those who don't want to renew their domain names has to be 'factored-in'
in assessing the overall cost of providing this service per Registrant who
renews his domain. It is a bit unfair, but those air-travellers who travel
light pay for the baggage of those who carry baggage of average permissible
weight.  If I don't have a computer I would still be paying for the Internet
infrastructure in an indirect way.


> but wait, then there's the infrastructure-cost caused by letting the email
> flow at all.  if the domain is not responding to email, the traffic required
> find that out is on the order of 100 bytes or less (servers attempting to
> make a connection and failing).  but now all the email will successfully
> flow, increasing traffic all across the Internet to deliver the email.
>
> then there's the question of who decides whether this can/should be done.
>  my guess is that most of those decisions would probably have to run through
> the IETF, since this would represent a pretty fundamental change in the way
> that email behaves.
>

Yes. IETF may have to look into some broad and finer technical aspects of
effecting such a change delivering email bound for a certain domain.


>
> so, while i agree that it's a good thing to inform registrants that their
> domain is expired with an email, the mechanism to deliver that email raises
> a lot of very difficult problems.    the cost and complexity of solving
> those problems probably vastly outweigh the value of delivering that one
> last email to that one person who hasn't responded to a series of prior
> emails telling them that their domain has expired.  better (and cheaper) to
> have the email fail -- which will result in lots of non-email communication
> to get the problem fixed and the domain renewed.
>

The email functionality is not only to deliver domain renewal notices but to
ensure that the registrant does not lose his business or personal message
inwards because his Domain's technical contact has failed to renew the
domain. In most cases, the average user of a domain's services is not the
one concerned with the management of the domain, so the user can't he
penalized for the failure of the technical backend that he is normally not
concerned with.

>
>
> On May 26, 2010, at 5:04 AM, Sivasubramanian M wrote:
>
> Dear Michelle,
>
> On Wed, May 26, 2010 at 2:50 PM, Michele Neylon :: Blacknight <
> michele@xxxxxxxxxxxxx> wrote:
>
>>
>>
>> On 26 May 2010, at 09:23, Sivasubramanian M wrote:
>>
>> > Hello Helen
>> >
>> >
>> > On Wed, May 26, 2010 at 1:29 AM, Helen <helen@xxxxxxxxxxxxxxx> wrote:
>> > A suprising number of registrants notice their domain has expired only
>> because the email stops functioning.
>> >
>> > Again it is the idea of ruining a communication line, discarding all
>> email communication to the domain just to give the registrant a wake up call
>> ! It is harsh if this is the reason why email functionality should be
>> interrupted.
>> >
>> > So they might try asking questions of their registrar.
>> > Or they might actually look at their website.
>> > If it doesn't resolve or preferably:
>> > If it says clearly "this domain has expired.. click here to renew"
>>  isn't that much better?
>> >
>> > A domain continued to resolve with a visible marque or pop up that gives
>> a renewal message is definitely a better and acceptable idea. If the domain
>> name continues to resolve then email could also be undisturbed, perhaps with
>> a pop up warning in the log in page, or elsewhere.
>>
>> Siva
>>
>> What login page?
>>
>> By the sounds of things you seem to be suggesting that people only access
>> email using a web based system? Or maybe I'm picking you up wrong.
>>
>
> If it is a webbased system the warning could be from the log in page, but
> if the Registrant accesses email from an email client, a message could even
> be set to pop up through the client. I think this should be possible, just
> like how a server send out a message to the client when the login password
> is wrong.
>
>>
>>
>> >
>> > Do we really want third parties involved?
>> > And Google IS a registrar so wouldn't this be a conflict?
>> >
>> > In the event where it is decided not to allow the domain name to
>> resolve, it becomes imperative that the messages inwards are not discarded.
>>
>> Why?
>>
>> If the domain is so important surely renewing it is "imperative"?
>>
>
> I don't deny that. Any registrant who attaches any importance to his domain
> name must be of the same opinion - that renewing the domain is imperative.
> But among 150 + million domain registrants, it is natural to expect a ten
> million of them to be a little disorganized, forgetful or due to some reason
> there is a temporary issue in renewing the domain in time. The panalities
> such as an interrupted email service is certainly harsh on them, especially
> if an alternate solution existed and if the community hasn't opted to
> implement it.
>
>>
>> > If Registrars don't want to extend that courtesy to the Registrants at
>> least they could refrain from blocking an icann service or a third party
>> service.
>>
>> It's not a "courtesy". It's a service that costs money to provide and that
>> registrants need to pay for.
>>
>> Opening the door for a lady is a "courtesy". Providing email services to
>> thousands of domains without payment is just madness.
>>
>
> In business, anything offered 'free' is in some way factored in, either
> directly or indirecly. If a free email service ( some kind of limited email
> service ) is provided to thousands of domains in their expiry phase, of
> which a sizable number wouldn't be renewed at all, and if it costs a certain
> sum, over a period of time, this cost would be recovered by an INCREASE in
> the price of the domain or the domain services.
>
>>
>> You're making out as if it's some kind of "social service" that should be
>> provided for free and that registrants have some "magical" entitlement to
>> even when they're not paying for it
>>
>
> What if there is a decision to charge a marginally higher fee for a
> slightly delayed renewal,  (not just a higher fee for post expiry
> restoration) in exchange for continued email functionality?
>
>
>>
>> And "blocking" is not the same as "not providing"
>>
>
> By blocking, I referred to your resistance to exploring a solution to this
> situation.
>
>>
>>
>>
>> >
>> > I dropped the Google name illustratively. The service provider could be
>> anyone.
>>
>> No it couldn't be, because of the sheer volume of mail that you are
>> dealing with.
>>
>> To illustrate my point I chose one of our mail servers at random.
>>
>> In 2009 the mail server, which isn't that busy, received 84 million emails
>> for a total of over 3 terrabytes of data.
>>
>> And that's only on about 50 domains or so.
>>
>> Do you have any idea of the amount of hardware, bandwidth and other
>> resources that you would need to handle mail for thousands of domains?
>>
>
> Yes I do have an idea.
>
>>
>> The funny thing is that most of the email that is hitting servers isn't
>> even legitimate, yet it still uses resources
>>
>
> There can be a stricter spam filter to discard spam at the door during the
> extended email service period.
>
>>
>> Regards
>>
>> Michele
>>
>> >
>> >  Helen
>> >
>> > On 25/05/2010 10:57 AM, Michele Neylon :: Blacknight wrote:
>> >> On 25 May 2010, at 14:53, Sivasubramanian M wrote:
>> >>
>> >>
>> >>
>> >>> Dear Michelle
>> >>>
>> >>>
>> >>> On Tue, May 25, 2010 at 4:24 PM, Michele Neylon :: Blacknight
>> >>> <michele@xxxxxxxxxxxxx>
>> >>>  wrote:
>> >>>
>> >>>
>> >>> On 25 May 2010, at 11:31, Sivasubramanian M wrote:
>> >>>
>> >>>
>> >>>
>> >>>> Hello
>> >>>>
>> >>>> I asked some Google Executives if there could be a technical solution
>> from an external service provider such as Gmail to the post expiry domain
>> email situation. The question was sent by email with a copy to Olivier
>> Crepin Leblond of ISOC England / Euralo.
>> >>>>
>> >>>> While he doesn't find the commercial prospects for the external
>> service provider convincing, his response points to the fact that
>> technically there is a definite way out of the problem.
>> >>>>
>> >>>>
>> >>> So who is going to pay for it?
>> >>>
>> >>> Definitely not the Registrars. It it takes it will take shape as a
>> service for which the Registrants will pay
>> >>>
>> >>>
>> >> Siva
>> >>
>> >> Pay who and how?
>> >>
>> >> Bearing in mind that you're talking about registrants who haven't
>> renewed their domain names ...
>> >>
>> >>
>> >>
>> >>
>> >>> or it will be a service offered on a neo-Interent-business model by a
>> company such as Google or MSN or it will be an ICANN supported service by a
>> third party.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>> It is not necessary to abruptly discontinue email service in a post
>> expiry situation.
>> >>>>
>> >>>>
>> >>> Until you can answer the key question about who is going to pay for it
>> then it is going to be necessary
>> >>>
>> >>> Just because it's technically "possible" doesn't render it viable and
>> the email exchange clearly supports the view that we have all been promoting
>> for months. It makes MORE sense for the registrant to simply renew the
>> domain name in a timely fashion.
>> >>>
>> >>> I agree that it makes more sense for Registrants to renew their domain
>> names in time. But I am concerned about those Registrants (even if they are
>> a smaller proportion) whose domain names expire unnoticed.
>> >>>
>> >>>
>> >> And so you expect this "magical" email service to "know" where the mail
>> is meant to go?
>> >>
>> >> You also expect people to be able to access it as well I assume?
>> >>
>> >> How?
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>> Also your suggestion in this email exchange suggests that ICANN would
>> somehow want to get involved with an "icann owned or icann-assigned server"
>> (sic) is disturbing.
>> >>> Do you even understand what ICANN's role is in all this?
>> >>>
>> >>> What is wrong if I want ICANN to get involved in an ICANN owned or
>> icann-assigned server? It is not disproportionately expensive and it is a
>> direct service to domain Registrants about whom ICANN is supposed to care !
>> >>>
>> >>>
>> >> How are you qualified to decide what is expensive and what isn't?
>> >>
>> >> Just to satisfy my own curiousity ...
>> >>
>> >> How many mail users do you currently manage?
>> >>
>> >> How many mail servers do you currently manage?
>> >>
>> >> How many mail servers have you configured?
>> >>
>> >>
>> >>
>> >>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>> The email exchange is attached as a PDF for the committee to act upon
>> futher.
>> >>>>
>> >>>>
>> >>> What committee?.
>> >>>
>> >>> Sorry, I meant WG. This PEDNR WG
>> >>>
>> >>>
>> >> OK
>> >>
>> >>
>> >>
>> >>> Sivasubramanian M
>> >>>
>> >>>
>> >>>
>> >>> Mr Michele Neylon
>> >>> Blacknight Solutions
>> >>> Hosting & Colocation, Brand Protection
>> >>> ICANN Accredited Registrar
>> >>>
>> >>> http://www.blacknight.com/
>> >>> http://blog.blacknight.com/
>> >>> http://mneylon.tel
>> >>>
>> >>> Intl. +353 (0) 59  9183072
>> >>> US: 213-233-1612
>> >>> UK: 0844 484 9361
>> >>> Locall: 1850 929 929
>> >>> Twitter:
>> >>> http://twitter.com/mneylon
>> >>>
>> >>> -------------------------------
>> >>> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business
>> Park,Sleaty
>> >>> Road,Graiguecullen,Carlow,Ireland  Company No.: 370845
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >> Mr Michele Neylon
>> >> Blacknight Solutions
>> >> Hosting & Colocation, Brand Protection
>> >> ICANN Accredited Registrar
>> >>
>> >> http://www.blacknight.com/
>> >> http://blog.blacknight.com/
>> >> http://mneylon.tel
>> >>
>> >> Intl. +353 (0) 59  9183072
>> >> US: 213-233-1612
>> >> UK: 0844 484 9361
>> >> Fax. +353 (0) 1 4811 763
>> >> -------------------------------
>> >> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business
>> Park,Sleaty
>> >> Road,Graiguecullen,Carlow,
>> >>
>> >> Ireland  Company No.: 370845
>> >>
>> >>
>> >> .
>> >>
>> >>
>> >>
>> >
>>
>> Mr Michele Neylon
>> Blacknight Solutions
>> Hosting & Colocation, Brand Protection
>> ICANN Accredited Registrar
>> http://www.blacknight.com/
>> http://blog.blacknight.com/
>> http://mneylon.tel
>> Intl. +353 (0) 59  9183072
>> US: 213-233-1612
>> UK: 0844 484 9361
>> Locall: 1850 929 929
>> Direct Dial: +353 (0)59 9183090
>> Twitter: http://twitter.com/mneylon
>> -------------------------------
>> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business
>> Park,Sleaty
>> Road,Graiguecullen,Carlow,Ireland  Company No.: 370845
>>
>>
>>
>
>    - - - - - - - - -
> phone  651-647-6109
> fax   866-280-2356
> web  www.haven2.com
> handle OConnorStP (ID for public places like Twitter, Facebook, Google,
> etc.)
>
>