[ietf-smtp] Re: Examples of pseudonymous email services

Mike Hillyer <[email protected]> Tue, 28 May 2024 12:43:23 -0400
Newsgroups gmane.ietf.smtp
Message-ID <CAFw+viba1jJ5+unYsfcEFM-2MaephZUVoqbY0FekBr_A=vsnxA@mail.gmail.com>
--===============2431141228220247132==
Content-Type: multipart/alternative; boundary="0000000000009f5adb06198655eb"

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

I've implemented this twice, once for a dating site that wanted to proxy
the email communications between its members, and once for a contractor
site that wanted to proxy the communications between customer and
contractor. Both times the site was providing value through the connection
and so it was in their interests to prevent direct contact prematurely.

In both cases it was implemented in the MTA with database connectivity.
When a connection was established, each party was provided with an email
address specific to that interaction, allowing either party to terminate
contact without the other party being able to use the address any further.

The flow was pretty simple: incoming message to the contact subdomain
triggered a DB lookup on the sender/receiver address pair. If there was a
match, the sender's address was replaced with their receiving proxy
address, the receiver's proxy address was replaced with their actual email
address, and the message was forwarded on.

When the other party replied the process repeated, with their actual
address replaced with their proxy address for the specific pairing, and the
original sender's actual address replacing their proxy address.

Of course there was also logging done, and since the sites in question
provided value in the introduction there was also code to detect email
address patterns, phone number patterns, things that were attempts to
bypass the proxy. Naturally once a direct meeting was arranged they could
do what they liked, but the goal was to keep them using the proxy for a
certain amount of time.

In situations where one or both parties desire the privacy, you wouldn't
need as much effort around bypassing the proxy.

Mike



Mike Hillyer
Co-Founder
443-472-7226

Let's Meet: https://cal.com/mike-kumomta/meet



On Tue, May 28, 2024 at 12:01=E2=80=AFPM Dave Crocker <[email protected]> wr=
ote:

> A gracious good morning from the US West Coast.
>
> I should know some answers to this, but am not recalling specifics.
>
> There is a long-standing construct of creating a one-time -- or
> recipient-specific -- mailbox string for the author's email address.
>
> Sometimes, this is done in a way to decouple the string from the
> author's registered login, thereby offering a degree of pseudo-anonymity.
>
> A service offering that decoupling -- so, for example, the string does
> not contain the user's login string -- must create a mapping between the
> pseudonymous string and the user associated with it.
>
> What are some examples of this being done?
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> mast:@[email protected]
>
> _______________________________________________
> ietf-smtp mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>

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

<div dir=3D"ltr">I&#39;ve implemented this twice, once for a dating site th=
at wanted to proxy the email communications between its members, and once f=
or a contractor site that wanted to proxy the communications between custom=
er and contractor. Both times the site was providing value through the conn=
ection and so it was in their interests to prevent direct contact premature=
ly.<div><br></div><div>In both cases it was implemented in the MTA with dat=
abase connectivity. When a connection was established, each party was provi=
ded with an email address specific to that interaction, allowing either par=
ty to terminate contact without the other party being able to use the addre=
ss any further.</div><div><br></div><div>The flow was pretty simple: incomi=
ng message to the contact subdomain triggered a DB lookup on the sender/rec=
eiver address pair. If there was a match, the sender&#39;s address was repl=
aced with their receiving proxy address, the receiver&#39;s proxy address w=
as replaced with their actual email address, and the message was forwarded =
on.</div><div><br></div><div>When the other party replied the process repea=
ted, with their actual address replaced with their proxy address for the sp=
ecific pairing, and the original sender&#39;s actual address replacing thei=
r proxy address.</div><div><br></div><div>Of course there was also logging =
done, and since the sites in question provided value in the introduction th=
ere was also code to detect email address patterns, phone number patterns, =
things that were attempts to bypass the proxy. Naturally once a direct meet=
ing was arranged they could do what they liked, but the goal was to keep th=
em using the proxy for a certain amount of time.</div><div><br></div><div>I=
n situations where one or both parties desire the privacy, you wouldn&#39;t=
 need as much effort around bypassing the proxy.</div><div><br></div><div>M=
ike</div><div><br></div><div><br clear=3D"all"><div><div dir=3D"ltr" class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><i=
mg width=3D"96" height=3D"42" src=3D"https://ci3.googleusercontent.com/mail=
-sig/AIorK4xuRouyBW1lrKqTmHYY0M777luVEvvVA-CAb6JT4UX79uxqdlWf8wlYC1fIIR0yv_=
-PMFuYzFs9A4do"><br><div><font face=3D"arial, sans-serif">Mike Hillyer</fon=
t></div><div><font face=3D"arial, sans-serif">Co-Founder</font></div><div><=
font face=3D"arial, sans-serif">443-472-7226</font></div><div><font face=3D=
"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-serif">=
Let&#39;s Meet:=C2=A0<a href=3D"https://cal.com/mike-kumomta/meet" target=
=3D"_blank">https://cal.com/mike-kumomta/meet</a></font></div><div><br></di=
v></div></div></div><br></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, May 28, 2024 at 12:01=E2=80=AFPM Dave=
 Crocker &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A gracious=
 good morning from the US West Coast.<br>
<br>
I should know some answers to this, but am not recalling specifics.<br>
<br>
There is a long-standing construct of creating a one-time -- or <br>
recipient-specific -- mailbox string for the author&#39;s email address.<br=
>
<br>
Sometimes, this is done in a way to decouple the string from the <br>
author&#39;s registered login, thereby offering a degree of pseudo-anonymit=
y.<br>
<br>
A service offering that decoupling -- so, for example, the string does <br>
not contain the user&#39;s login string -- must create a mapping between th=
e <br>
pseudonymous string and the user associated with it.<br>
<br>
What are some examples of this being done?<br>
<br>
d/<br>
<br>
-- <br>
Dave Crocker<br>
Brandenburg InternetWorking<br>
<a href=3D"http://bbiw.net" rel=3D"noreferrer" target=3D"_blank">bbiw.net</=
a><br>
mast:@[email protected]<br>
<br>
_______________________________________________<br>
ietf-smtp mailing list -- <a href=3D"mailto:[email protected]" target=3D"_=
blank">[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:[email protected]"=
 target=3D"_blank">[email protected]</a><br>
</blockquote></div>

--0000000000009f5adb06198655eb--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaWV0Zi1zbXRw
IG1haWxpbmcgbGlzdCAtLSBpZXRmLXNtdHBAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBh
biBlbWFpbCB0byBpZXRmLXNtdHAtbGVhdmVAaWV0Zi5vcmcK

--===============2431141228220247132==--