Simple self-hosted email connection/relaying system. Any ideas?

jakob · 2020-10-25 17:31:48

I’m not sure how to describe this, so I’ll describe the situation:

In a physical conference, people exchange business cards etc. and in the process implicitly give their permission to be contacted. When the conference shifts online that interaction is gone. At the same time data protection rules say we shouldn’t give out lists of contact details. I’m looking for something like an obfuscated “contact this person” relayer, e.g.

“Contact Mr XYY” – or perhaps a proxy email address that people can email to. The message or “contact request” gets sent to the proper recipient with the email address of the contacter and the recipient is free to answer as they please, only then revealing their actual email address.

Of course, it shouldn’t be abusable for spamming purposes.

I don’t really know myself yet what makes most sense: a “Hi, I’d like to contact you” contact request could be just as annoying to the recipient as a proper enquiry.

Does anyone recognise something like this?

I suppose I could set up multiple proxy forwarding email address at our host but they might have to be around for a long time. Then people could send true emails to that address and the recipient would know whether to reply. The forwarding address might make it possible for the recipient to filter that incoming mail. But if one provides “front”-email addresses for others, is one then oneself legally liable.

I’m sure there must be something for this kind of thing but I’m not sure even what to look for…

I’d be most grateful for any ideas. Thank you!

colak · 2020-10-25 17:39:35

Hi Julian,
If you are using txp on this, a com_connect form with different recipients might be a solution.

jakob · 2020-10-25 17:42:34

I forgot to write, it doesn’t have to be Textpattern, just needs to work with it. A contact form with multiple recipients could work but there’d be a lot of them.

I’d intuitively thought maybe something separately managed but installed alongside Textpattern but linked to from it. I do that with short links using YOURLS for example.

colak · 2020-10-27 14:11:21

i’m trying to picture what this might look like in order to research for a software. By proxy email addresses I take it that you mean forwarded ones? ie someone@domain.tld forwarded to someone@otherdomain.tld? If this is the case, it may be as bad as having their own emails listed.

Another txp way is to have the names, and each name linking to a separate com_connect form. These could be a lot of pages, but they could reside in a pageless section in a specially created subdomain.

Bloke · 2020-10-27 16:39:00

However you slice it, you need to map real emails to some intermediate request mechanism. You’ve not mentioned how this mapping might be set up in the first place.

Do they sign up, and get issued an obfuscated contact address?
Does it need to be an email? Could it be a difficult-to-guess (like smd_access_key style) unique URL? That might lend itself to a QR code.
Are the key mappings centrally administered? Or does each person control their own access to this service? To add/remove addresses or activate/suspend their redirection.

Answers to those questions might well drive the design of, or search for, a system that can meet the aims.

Last edited by Bloke (2020-10-27 17:22:17)

jakob · 2020-10-27 20:39:37

Yeah, you right, I haven’t thought it through. I guess I wondered whether you clever people knew of something along those lines already out there that I don’t know how to describe :-) I guess want I’m looking for is a kind of “email to this address and it will be relayed on. The recipient will contact you if they wish” thing.

I had imagined it as something we set up on behalf of the speakers so they don’t have to bothered with signing up to anything. If they do not want it, I can take it down again for them. That way they can be contacted but we don’t publish their email. They can choose then to answer if they wish. I’d use a proper name with a prefix/suffix from us and not some weird hash so people know where it’s coming from.

Yiannis’ idea of a multi-recipient contact form, or multiple contact forms would work but a contact form is a bit cumbersome to use and even with the preview and send steps, can still be spammed.

The other idea of setting up email forwarding addresses on our domain would also work but we’d need to obfuscate them damn well to avoid them being harvested. People find it easier to send an email, but I wonder whether we pollute the people’s email boxes with “false“ contact addresses that are designed to be a one-time means of contact.

Bloke · 2020-10-27 21:23:17

If it’s something you set up on behalf of someone else and you administer it, that’s much easier. In Textpattern parlance, an smd_bio field could extend your txp_users table (one user per speaker) to hold your ‘obfuscation token’, which could be anything you like. You could issue that to speakers as a URL/QR Code that they can dish out to anyone. That URL lands on, perhaps, a hidden section:

example.org/touch?token=abc123def456cab789

Put a com_connect form there that asks for the requestee’s email address and a message box, passing along the URL fragment (accessed via <txp:page_url />) as a hidden key field, and a secret field that indicates this is an ‘email request’ type of form.

A tiny plugin hooked into the com_connect.deliver callback could check this is an ‘email request’ submission and, if so, do a lookup of the received token in the txp_user table to match the bio field of the obfuscation token. Fetch the corresponding real email address and use that to overwrite the To: field in the payload, then return to let com_conect finish the job.

The beauty is, the /touch form is potentially displayed to anyone who might stumble upon it. But only people who supply a valid unguessable token, as given out on virtual business cards, will be able to get through. Anything else passed in will fail the user lookup as the message will be sent to nobody@example.org (a fake address in your com_conect to= attribute). You could still get the plugin module to respond with a ‘thanks’ message to the screen of course, to make the spammers think they’re getting somewhere :)

The email will only get through to valid recipients and it’s up to them to reply to the requestee directly if they wish. There’s no need for preview steps or other complicated stuff. Yeah, a contact form’s not as immediate as an email address, but it’d work, and it’s only one message field (which they’d type anyway into a real email) plus their own email address.

If you want to go a step further, you could even add an optional second parameter to the link with &from=somone@example.net which pre-fills in the ‘Your email address’ field in the /touch form. If you add a nice ‘generator’ admin-side panel dashboard, speakers could then create custom URLs/QR codes combining their obfuscation token with a given email address that they could dish out to specific people as a means of them getting in touch without revealing their true address. Seems a bit OTT, but easy to do if you thought speakers might like the feature as a service. The dashboard could be as simple as a com_connect form:

Send a virtual business card to: [ recipient@example.net ]

They fill the person’s address in and hit Send. It refreshes the page, which mails off the custom link/QR code to the given recipient email address via a no-reply@example.org reply-to address.

The recipient clicks/scans the link in the email, lands on the /touch form with the token and their email address pre-filled (the latter of which they could change of course). They add a one-line message or whatever, hit send, and the speaker receives the message, as detailed above.

Does any of that work?

EDIT: if you didn’t want to use smd_bio, the txp_token table could be used to generate a token with no expiry date that links back to the txp_user record (ID). You could use the generated selector or the token (your call) as the obfuscation link, and simply look that value up in the txp_token table when a request comes in, then visit the corresponding reference_id row in txp_users to find the user to whom the token relates, and their real email address. smd_bio gives you the advantage that users can alter their own token or make their own custom one, but increases the risk they’ll choose something guessable. The txp_token approach is guaranteed cryptographically secure.

Last edited by Bloke (2020-10-27 21:57:32)

gaekwad · 2020-10-28 16:42:43

Left of field idea – collate your thoughts and put something on old.reddit.com/r/selfhosted/ since it’s entirely possible this is a solved problem.

jakob · 2020-10-28 20:31:00

Great ideas! Only problem is, there’s no time. The conference is … was to be on … Friday. We bit the bullet and emailed everyone again to ask their permission to publish their contact details … and so far everyone’s fine with it. I didn’t expect it, but through the process we got lots of warm messages of support. My mood’s already a bit better.

Thanks for your ideas all the same. I’m sure they’ll come in handy.

Textpattern CMS

Textpattern CMS support forum

#1 2020-10-25 17:31:48

Simple self-hosted email connection/relaying system. Any ideas?

#2 2020-10-25 17:39:35

Re: Simple self-hosted email connection/relaying system. Any ideas?

#3 2020-10-25 17:42:34

Re: Simple self-hosted email connection/relaying system. Any ideas?

#4 2020-10-27 14:11:21

Re: Simple self-hosted email connection/relaying system. Any ideas?

#5 2020-10-27 16:39:00

Re: Simple self-hosted email connection/relaying system. Any ideas?

#6 2020-10-27 20:39:37

Re: Simple self-hosted email connection/relaying system. Any ideas?

#7 2020-10-27 21:23:17

Re: Simple self-hosted email connection/relaying system. Any ideas?

#8 2020-10-28 16:42:43

Re: Simple self-hosted email connection/relaying system. Any ideas?

#9 2020-10-28 20:31:00

Re: Simple self-hosted email connection/relaying system. Any ideas?

Board footer