[ietf-smtp] Re: Proposal: SMTP Address Migration Protocol (SAMP) Concept.

--===============3771616321704018809==
Content-Type: multipart/alternative; boundary="000000000000c69dde0657301c4e"

--000000000000c69dde0657301c4e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes agree with a lot of that you said. But my concept was more about
providing the tools and protocol for a user to self initiate the protocol,
not for automatic record updating on a mass to automated scale.

A legitimate business would no doubt like to ensure there mail is reaching
their customer. So telling their current provider to initiate the migration
protocol at least would pass that info along.

I think we now in a world where 1 user might have several mail accounts.
Info spread about without consistency. So many services, so many emails.
People get lost and dont want to hunt to change everything. To initiate
something like this these days could allow people to close them all down
bar the 1 they wish to use.

On Wed, 22 Jul 2026, 10:27 John C Klensin, <[email protected]> wrote:

>
>
> --On Wednesday, July 22, 2026 09:21 +0100 Jeremy Harris
> <[email protected]> wrote:
>
> > On 2026/07/22 9:12 AM, C D wrote:
> >> =E2=80=8BFollowing a suggestion from the EMAILCORE Working Group, I am
> >> sharing a protocol concept here just in case it is of interest or
> >> useful to anyone thinking about email evolution.
> >
> >> =E2=80=8BThe concept explores using an ephemeral migration lock state =
on
> >> the legacy server, an SMTP status intercept (350 Address Migrated),
>
> > Cf. the existing "251" advisory response.   Which I've never seen
> > actually used...
>
> Yes.  Please look at Section 3.4.1 of
> draft-ietf-emailcore-rfc5321bis.  My recollection was that I saw it
> used, albeit probably not really frequently, decades ago when most
> SMTP operations were specific to institutions, and those institutions
> were almost entirely academic or research in nature, and so on.  As a
> matter of policy and mutual cooperation, in an environment where
> there were not significant concerns about the privacy of such things
> a message like "<Fred Example> got promoted, left here and can now be
> reached at <foo>" made sense and was common, whether it came over and
> was about email, telephone numbers, or even the traditional post.
>
> Today, the incentives are different.  In particular, it is less easy
> to imagine "<Fred Example> left this company and went to work for
> <competitor> where their contact information is <foo>", nor the
> incentives for some giant email provider to have incentives to
> maintain databases of former users.   One can also imagine multiple
> privacy problems and attack surfaces in a world when many email
> providers have no real idea who their users are and hence could not
> really authenticate a user and their address well enough to safely
> remove a mailbox and replace it with a message like these.
>
> None of that is about the technical merits of the proposal, just the
> environment, motivations to deploy it, and reasons why we have not
> seen wide contemporary deployment of this predecessor feature.  I
> also think there would be considerable resistance to introducing a
> new 3yz code now, but that is, relatively, a minor issue.
>
>     john
>
>
>
>

--000000000000c69dde0657301c4e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Yes agree with a lot of that you said.  But my concept wa=
s more about providing the tools and protocol for a user to self initiate t=
he protocol, not for automatic record updating on a mass to automated scale=
.<div dir=3D"auto"><br></div><div dir=3D"auto">A legitimate business would =
no doubt like to ensure there mail is reaching their customer.  So telling =
their current provider to initiate the migration protocol at least would pa=
ss that info along.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I th=
ink we now in a world where 1 user might have several mail accounts.  Info =
spread about without consistency. So many services, so many emails.  People=
 get lost and dont want to hunt to change everything.  To initiate somethin=
g like this these days could allow people to close them all down bar the 1 =
they wish to use.</div></div><br><div class=3D"gmail_quote gmail_quote_cont=
ainer"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, 22 Jul 2026, 10:27 Joh=
n C Klensin, &lt;<a href=3D"mailto:[email protected]">[email protected]</a>=
&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
--On Wednesday, July 22, 2026 09:21 +0100 Jeremy Harris<br>
&lt;<a href=3D"mailto:[email protected]" target=3D"_blank" rel=3D"noreferrer"=
>[email protected]</a>&gt; wrote:<br>
<br>
&gt; On 2026/07/22 9:12 AM, C D wrote:<br>
&gt;&gt; =E2=80=8BFollowing a suggestion from the EMAILCORE Working Group, =
I am<br>
&gt;&gt; sharing a protocol concept here just in case it is of interest or<=
br>
&gt;&gt; useful to anyone thinking about email evolution.<br>
&gt; <br>
&gt;&gt; =E2=80=8BThe concept explores using an ephemeral migration lock st=
ate on<br>
&gt;&gt; the legacy server, an SMTP status intercept (350 Address Migrated)=
,<br>
<br>
&gt; Cf. the existing &quot;251&quot; advisory response.=C2=A0 =C2=A0Which =
I&#39;ve never seen<br>
&gt; actually used...<br>
<br>
Yes.=C2=A0 Please look at Section 3.4.1 of<br>
draft-ietf-emailcore-rfc5321bis.=C2=A0 My recollection was that I saw it<br=
>
used, albeit probably not really frequently, decades ago when most<br>
SMTP operations were specific to institutions, and those institutions<br>
were almost entirely academic or research in nature, and so on.=C2=A0 As a<=
br>
matter of policy and mutual cooperation, in an environment where<br>
there were not significant concerns about the privacy of such things<br>
a message like &quot;&lt;Fred Example&gt; got promoted, left here and can n=
ow be<br>
reached at &lt;foo&gt;&quot; made sense and was common, whether it came ove=
r and<br>
was about email, telephone numbers, or even the traditional post. <br>
<br>
Today, the incentives are different.=C2=A0 In particular, it is less easy<b=
r>
to imagine &quot;&lt;Fred Example&gt; left this company and went to work fo=
r<br>
&lt;competitor&gt; where their contact information is &lt;foo&gt;&quot;, no=
r the<br>
incentives for some giant email provider to have incentives to<br>
maintain databases of former users.=C2=A0 =C2=A0One can also imagine multip=
le<br>
privacy problems and attack surfaces in a world when many email<br>
providers have no real idea who their users are and hence could not<br>
really authenticate a user and their address well enough to safely<br>
remove a mailbox and replace it with a message like these.<br>
<br>
None of that is about the technical merits of the proposal, just the<br>
environment, motivations to deploy it, and reasons why we have not<br>
seen wide contemporary deployment of this predecessor feature.=C2=A0 I<br>
also think there would be considerable resistance to introducing a<br>
new 3yz code now, but that is, relatively, a minor issue.<br>
<br>
=C2=A0 =C2=A0 john<br>
<br>
<br>
<br>
</blockquote></div>

--000000000000c69dde0657301c4e--


--===============3771616321704018809==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaWV0Zi1zbXRw
IG1haWxpbmcgbGlzdCAtLSBpZXRmLXNtdHBAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBh
biBlbWFpbCB0byBpZXRmLXNtdHAtbGVhdmVAaWV0Zi5vcmcK

--===============3771616321704018809==--