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

["Mike O'Connor" <mike@xxxxxxxxxx>]

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.

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

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.  

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.

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.com domain 
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.  

then there's the problem of who does what, and who pays for it?  ultimately it 
is registrants who would have to pay, 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]

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?

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.  

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.


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