Email obfuscation <https://redmine.iopen.net/issues/3419> has been on
our agenda for quite some time as a privacy feature. Our recently
implemented changes to respond to strict DMARC policies
<http://groupserver.org/r/topic/4MRol4mRK4dCo0u20N2Go2> accelerated our
implementation of it.
This raises one or two questions. The easy one, is have we correctly
constructed the obfuscated emails? The second is how do we handle email
to those email addresses? I'll deal with them in that order.
We have constructed obfuscated addresses using the domain of the site,
and a new local side made of the string 'user-' then the user's ID. Thus
if your profile is http://example.com/p/1VJQc2umoIC, your email address
would become <email obscured>.
This gives us the advantage that we can easily identify the user, even
if their original email address becomes invalid. Michael and I have
discussed shortening the prefix to 'p-'. That is similar to the path to
a profile.
Some other providers have added a munged version of the email address,
and even 'via ListTitle' to the name string. That makes the name
unnecessarily verbose. And it fails to enable the user to obfuscate
their email address by choice.
The above tweak aside, I am content with our decision about the
rewritten email address.
The requirement to respond individually to the original writer of a
message is occurs relatively infrequently. When it does occur, I think
we can take some responsibility
<http://onlinegroups.net/blog/2014/05/01/dmarc-taking-responsibility-sending-group-email/>
for enabling a group member to do that.
Currently, if you email one if the newly minted addresses, GroupServer
checks the left hand side with the group IDs on the site and if it fails
to match, sends you a "no such group" message.
To improve on this, GroupServer will need to recognise the emails that
addressed to users and handle them differently. I propose that we
implement picking up the new email recipients and some kind of handling
for them.
I can think of two options for handling emails to obfuscated site member
email addresses.
1 Use the Request contact feature on profiles.
2 Send the email on to a the user's preferred email address.
In both cases, we will almost certainly have to check that the reply is
coming from a valid address of a member of the same site and ideally
group as the recipient of the reply. If we do not, then we would be
forwarding emails for anyone which is not good.
I prefer 1 because it motivates people to use the web UI, which can
otherwise easily be forgotten. That is not does strictly facilitate the
immediate task, but may facilitate others. It also makes the process
slightly less prone to abuse.
It does raise the question of which site the replier should be linked
to. As the system already needs to determine the site and group
memberships of both users, that should not be too much of a problem.
If both happen to be in more than one site, then the system could link
to the profile of the recipient of the reply on both sites.
If we switch to emailing the reply ourselves, we will not have wasted
much effort.
our agenda for quite some time as a privacy feature. Our recently
implemented changes to respond to strict DMARC policies
<http://groupserver.org/r/topic/4MRol4mRK4dCo0u20N2Go2> accelerated our
implementation of it.
This raises one or two questions. The easy one, is have we correctly
constructed the obfuscated emails? The second is how do we handle email
to those email addresses? I'll deal with them in that order.
We have constructed obfuscated addresses using the domain of the site,
and a new local side made of the string 'user-' then the user's ID. Thus
if your profile is http://example.com/p/1VJQc2umoIC, your email address
would become <email obscured>.
This gives us the advantage that we can easily identify the user, even
if their original email address becomes invalid. Michael and I have
discussed shortening the prefix to 'p-'. That is similar to the path to
a profile.
Some other providers have added a munged version of the email address,
and even 'via ListTitle' to the name string. That makes the name
unnecessarily verbose. And it fails to enable the user to obfuscate
their email address by choice.
The above tweak aside, I am content with our decision about the
rewritten email address.
The requirement to respond individually to the original writer of a
message is occurs relatively infrequently. When it does occur, I think
we can take some responsibility
<http://onlinegroups.net/blog/2014/05/01/dmarc-taking-responsibility-sending-group-email/>
for enabling a group member to do that.
Currently, if you email one if the newly minted addresses, GroupServer
checks the left hand side with the group IDs on the site and if it fails
to match, sends you a "no such group" message.
To improve on this, GroupServer will need to recognise the emails that
addressed to users and handle them differently. I propose that we
implement picking up the new email recipients and some kind of handling
for them.
I can think of two options for handling emails to obfuscated site member
email addresses.
1 Use the Request contact feature on profiles.
2 Send the email on to a the user's preferred email address.
In both cases, we will almost certainly have to check that the reply is
coming from a valid address of a member of the same site and ideally
group as the recipient of the reply. If we do not, then we would be
forwarding emails for anyone which is not good.
I prefer 1 because it motivates people to use the web UI, which can
otherwise easily be forgotten. That is not does strictly facilitate the
immediate task, but may facilitate others. It also makes the process
slightly less prone to abuse.
It does raise the question of which site the replier should be linked
to. As the system already needs to determine the site and group
memberships of both users, that should not be too much of a problem.
If both happen to be in more than one site, then the system could link
to the profile of the recipient of the reply on both sites.
If we switch to emailing the reply ourselves, we will not have wasted
much effort.