wow again the same discussion...
imo the right way to process any e-mail subscriptions
is to send back an e-mail and only after the customer
replies the subscription is processed. for such a thing
only checking for .+@.+\..+ is ok, but it is OK not to check
for anything, too.
this is the safest way because:
- someone else will not be able to use third party's e-mail for
that subscription
- if he mispelled the e-mail (not just put any of *&^W#!*&
on it but typed for example ...@blabla.con which couldn't
be checked other way) he will know this if he doesn't
receive the confirmation to proceed further.
also the owner of the web site will be sure that the e-mail
is exsting one.
so if the particular e-mail address bla.@bla.com is ok
and functional it will be OK for you, too. and you don't have
to care about RFC 822 if it is obsoleted by RFC 2834 or
anything else.
just my opinion -- i do this on my web sites and it is working
very well.
regards,
doytchin
----- Original Message -----
From: Derek J. Balling <dredd@megacity.org>
To: William X. Walsh <william@userfriendly.com>
Cc: Mark Collette <mark@hyperbyte.ab.ca>; <discuss-list@opensrs.org>
Sent: Monday, June 19, 2000 11:32 PM
Subject: Re[6]: "." before the "@"
> At 01:18 PM 6/19/00 -0700, William X. Walsh wrote:
> >Great, than you can make a tighter requirement, and enforce it on your
> >end, and use it as a selling point. You can do this without forcing
> >your narrow view on the rest of us, Derek.
>
> The problem is -- if the registry is polluted with bad data, then the
> registry's data is worthless.
>
> For an example of the problems inherent in this, please consult
> whois.networksolutions.com at your leisure.
>
> >You control that, Derek. You can adhere to the standard, and that is
> >what your customers are getting. What you give them, Derek, is what
> >they are REALLY getting. You are in complete control of that, on
> >your own, and do not need to force the rest of the world to conform to
> >that same standard.
>
> I'm giving them access to a database that will (in time) suffer the same
> problems as NSI. If there is committment to data integrity at the
registrar
> level, it's only a matter of time before the data is as worthless as
NSI's.
>
> >I do not consider accepting an email address to be affecting the
> >quality or standard of service. Personally, I see anyone taking that
> >high road to be overly rigid. And this is nothing personal, but the
> >ones I see taking that road are typically your old school internet
> >admins, who bemoan the state of the internet :)
>
> Maybe because old-school internet types are the ones who remember when the
> system worked - always. We remember when petty profit interests weren't
put
> before interoperability, stability, reliability, and standards-compliance.
>
> Funny, I thought those were the GOOD features of the net? If wanting the
> network to follow the rules is "old school", then I really _DO_ weep for
> the future of the net.
>
> >Great, you sell it that way. Personally, I don't see that nitpickiness
> >as being a strong selling point, and instead see it as a disadvantage.
> >The great part about the way OpenSRS could implement this is that it
> >would satisfy us both, giving us both the tools to implement our
> >views. Except for your need to enforce your view on the rest of us,
> >that is :)
> >
> >I would hope that OpenSRS doing this would not affect your decision to
> >remain an RSP. I really think there are higher, more important, issues
> >than the
> >parsing of an email address here.
>
> The parsing of an e-mail address is a symptom of problems to come. If they
> truly don't care about the data they collect to actually adhere to
> standards, then what is the point of HAVING standards? Registrars, as I've
> said before, are no place to 'play fast and loose' with standards.
>
> And the answer is that, if OpenSRS _DOESN'T_ correct this, then, yes, as
> soon as there are more registrars doing what SRS does, and one of them
with
> a committment to standards-compliance emerges, I would transfer everything
> there in a hot second.
>
> We should be taking the high ground versus NSI's practices... otherwise,
> all we are is the same crappy NSI service at a cheaper price.
>
> D
>
>
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:35:38 EDT