Reply by email - additional addresses

Thanks that’s exactly what I was querying.

So as an end user on another Discourse product, I need to contact an admin to enable this at present?

2 Likes

Correct - only an admin with ssh access to the server would be able to do it.

3 Likes

Is there any future plan to allow this to be accessible through the Web interface?

I’m not sure this is a legitimate problem, Gmail natively supports aliases with both plus addressing and gmail dots on accounts, I use both quite regularly for this. They can be added via settings->accounts.

What would be the point of using such approaches to identify the source of email (and potential future spam) only to later provide your main alias?

Rather than needing to educate Discourse about additional addresses, you can simply respond using the alias which mail was received via.

That’s surely neater and safer, no?

6 Likes

You’re right, it’s far from ideal.

But the solution does make sense (bear with me). First of all, the outgoing email address can be outgoing-only, just as the receiving address is incoming-only. This allows you to reduce unwanted spam as well as identify the source.

As explained, aliasing is not a solution when you still have to manually set each one up. If Gmail or other platforms could intelligently reply from the appropriate plus-address or dot-address the issue would be resolved but that seems unlikely (not to mention dot addressing is non-standard).

Frankly, I have not had the security issue with replying from alternative addresses explained to me. Surely if we trust the recipient with the (sometimes-private) data they receive, we equally trust them to post. Why not include a token with the email notification allowing any email address to reply (as long as the token is valid).

Just thinking things through here - please feel free to pick these points apart…

Again, look at your settings in gmail, this works today:

You’ve two choices:

  • Configure addresses to identify the source of email (and go one extra step to add an alias within gmail to close the loop)
  • Ask every service you use which handles inbound mail to handle additional aliases.

I know which one I’d favor, in that it works today and requires nothing extra from third parties. If you’re not willing to go to the effort to maintain the aliases, why ask anyone to go to the effort of writing extra code?

4 Likes

I’m not sure if you’re actually reading what I’m saying. All the above requires you to have created every single plus/dot address which as I have explained over and over is not feasible. As it happens transparently when receiving my use of the phrase “intelligently reply from the appropriate plus-address or dot-address” implied exactly the mirror-image behaviour.

I’m more than aware of the settings in Gmail as well as a variety of other email interfaces. That’s precisely why I started this topic with the specific points I raised. Please re-read.

  • Configure addresses to identify the source of email (and go one extra step to add an alias within gmail to close the loop)

In the modern world that’s literally not possible.

why ask anyone to go to the effort of writing extra code?

Even if you ignore my token suggestion (still waiting for constructive criticism), that’s absolutely not what I’m doing.

They can configure Gmail to send from that address (I’m almost certain). If they want to use some +address, they’ll need to do the work.

It’s a pain but it’s pain that the user asked for.

If you’re not afraid of work or paying for it, you could get a plugin that would strip the +part of the address

1 Like

No need to be argumentative here, the use case is clear and it is something we planned for.

4 Likes

This topic has made me remember that Discourse should send a different error message reply if the from email is similar to the account’s email than if it’s completely differently, something like “it looks like your email was from an address that was similar but may have used a + string or had periods in different places. Emails must be sent from the exact email address the forum account is registered to.”

Please. Of course it’s possible. Even if you’re using this scheme for hundreds of sites as you claim, it’s still possible. It’s 10 extra seconds per site, and you’re not signing up to them all on one day are you?

Bit redundant now but a) it’s not just plus addressing as per my first post, b) it’s not just adding the alias, it’s making the From field unusable as per my fifth post, c) we’re not just talking about Gmail as per my second and most recent posts but, in any case, I think that I’m fairly quick around Gmail’s user interface but would struggle to add and confirm a new alias in ten seconds.

Less redundant: are there any legs to the token idea I have mentioned multiple times but that has been ignored in favour of ranting about lazy Gmail users?

When it’s a Gmail period or plus alias, you don’t need to confirm. I just tried it and it only took 12 seconds.

Yes there are other kinds of weird delivery setups. The devs have already said they’ll eventually make it easier for admins (and maybe users) to add secondary emails for users. I don’t think they should go out of their way to do any more than that. Users should take responsibility for their own email setups if they want to reply to email received at an address they can’t send from.

As an option admins could enable, the token idea could work. We already trust that if users forward their forum emails to others then they could unsubscribe them using the links inside. Of course posting is potentially more destructive than unsubscribing.

As a feature request, the devs often say they have a rule of three, where once three people have request it they’ll start considering it more. Or if you’re a paying customer.

2 Likes

My bad. I’ve only ever added non plus or dot aliases in the Gmail interface.

Sorry. I’m exceedingly lazy, and not a very talented Rails programmer and always look for solutions that don’t involve changing Discourse. (No, that’s not being sarcastic. I recently started a conversation to write a $1000 plugin and talked the non-customer into a solution using only existing features.)

Without looking at the code, I think that it might be possible to remove or relax the code that checks the sender From: address, as I think it’s the case, as you suggest, that the token is unique and that if you don’t care that someone might get that token some other way (say a forwarded message?) that you could override process_destination in a plugin and allow those replies to be delivered with the understanding that it’s something of a security risk. I think you’d need to just change this:

to something that either allowed any address to reply or maybe did some kind of “is it close enough” logic that I can’t see now how you’d come up with (not to say that one couldn’t).

1 Like

Thanks for this. Very interesting. If, as has been stated, there are already security issues with tokenised unsubscribe links (and that these are deemed acceptable risks), it sounds promising.

It seems fairly obvious so I assumed if nobody had requested it before there were implications that I had overlooked, but if that’s not the case this seems a far superior way to accommodate people like me and appease the naysayers too.

Don’t know who else to tag to weigh in with thoughts/critiques but what do you think @codinghorror?

1 Like

If staged users were enabled, would it just allow replies from any email? I don’t know, haven’t tried that kind of system (I only have staged users for handling support type emails.)

1 Like

I don’t know what you mean by staged users here.

Search: staged user #howto

1 Like

I can’t say I see the relevance.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.