[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'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's address was repl= aced with their receiving proxy address, the receiver'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'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'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'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 <<a href=3D"mailto:[email protected]">[email protected]</a>> 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's email address.<br= > <br> Sometimes, this is done in a way to decouple the string from the <br> author'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'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==--