Re: FW: Re: type for storing emails?

------=_Part_255_1265220853.1573577092627
Content-Type: multipart/related; 
	boundary="----=_Part_256_546946730.1573577092627"

------=_Part_256_546946730.1573577092627
Content-Type: multipart/alternative; 
	boundary="----=_Part_257_979245069.1573577092637"

------=_Part_257_979245069.1573577092637
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



P=C3=A5 tirsdag 12. november 2019 kl. 16:50:35, skrev Steve Midgley <
[email protected] <mailto:[email protected]>>:=20

[...]=20
Not to be pedantic but in the data model, you could have a couple of=20
verification data fields (e.g. verification_code; email_verified), and actu=
ally=20
send an email and record if the user comes back with the correct verificati=
on=20
code. It's obviously not something that can be handled solely via specs or=
=20
database, but a data model can accommodate actual email verification (as I =
know=20
you know, but thought I should make clear for future readers of the archive=
s).=20

My point is; There is no way to tecnichally verify that an email actually=
=20
=C2=ABexists=C2=BB (as in being active and will be routed to an actual reci=
pient). Yes,=20
you can do all sorts of acrobatics, and may in many attempts succeed, but t=
here=20
exists no method guaranteeing this. Many email-servers will for example hap=
pily=20
receive the email, respond "OK, got it", but throw the email in an "unknown=
=20
recipients"-bin, effectively ignoring any email sent to a non-existing addr=
ess.=20

--
 Andreas Joseph Krogh
------=_Part_257_979245069.1573577092637
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>
<div>P=C3=A5 tirsdag 12. november 2019 kl. 16:50:35, skrev Steve Midgley &l=
t;<a href=3D"mailto:[email protected]">[email protected]</a>&gt;:</div>

<blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt=
 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir=3D"ltr">
<div dir=3D"ltr">[...]</div>

<div class=3D"gmail_quote">Not to be pedantic but in the data model, you co=
uld have a couple of verification data fields (e.g. verification_code; emai=
l_verified), and actually send an email and record if the user comes back w=
ith the correct verification code. It's obviously not something that can be=
 handled solely via specs or database, but a data model can accommodate act=
ual email verification (as I know you know, but thought I should make clear=
 for future readers of the archives).</div>
</div>
</blockquote>

<div>=C2=A0</div>

<div>My point is;=C2=A0=C2=A0There is no way to tecnichally=C2=A0<em>verify=
</em>=C2=A0that an email actually =C2=ABexists=C2=BB (as in being active an=
d will be routed to an actual recipient). Yes, you can do all sorts of acro=
batics, and may in many attempts succeed, but there exists no method=C2=A0g=
uaranteeing this. Many email-servers will for example happily receive the e=
mail, respond &quot;OK, got it&quot;, but throw the email in an &quot;unkno=
wn recipients&quot;-bin, effectively=C2=A0ignoring=C2=A0any email sent to a=
 non-existing address.</div>

<div>=C2=A0</div>

<div class=3D"visena-email-signature" data-visena-message-id=3D"&lt;VisenaE=
mail.3a.b9f9cd2d9bf1026e.16e6077551b@tc7-visena>">--<br>
Andreas Joseph Krogh</div>
</div>
------=_Part_257_979245069.1573577092637--

------=_Part_256_546946730.1573577092627--

------=_Part_255_1265220853.1573577092627--