Reply to email - key in subject instead of email address?


(Brian Barlow) #1

Any chance of an option to have the key for the reply in the Email subject or body instead of in the email address itself? Would help for those of use with email servers that don’t support it directly. (ie Exchange 2010)

thanks, Brian

Continuing the discussion from New: Reply via Email Support!:

Using subject line for reply-by-email identifier
(Michael John Kirk) #2

I see the rationale for avoiding putting key-like information in the subject, since it’s reasonable to expect someone will fiddle with (corrupt) a subject. It’s a human field, not machine data storage.

I can also see how this doesn’t work for you at all. Does Exchange interpret it as a different email all together? Or drop the wildcard? Or something else?

(Brian Barlow) #3

Exchange doesn’t recognize it as an email, since it doesn’t support/understand wildcards.

The workaround I found on technet was to add a “Catch-All” email address to your transport server, that just sends everything not to a valid exchange email to a catch email.

Multiple challenges with that obviously. Emails that aren’t actually to the Discourse reply email would clog up the system, plus you could only have 1 email like that for your whole exchange organization. So, not the best workaround.

We will probably just end up setting up a gmail account for it. Drawback of that is data flowing into and out of our enterprise for a forum that is internal/intranet only. And, someone will have to periodically check it for spam filter catching the emails, or other weirdness.

thanks for the comments and questions though.

(Kevin P. Fleming) #4

Another option would be to embed a ‘cookie’ into the initial message’s Message-ID field; most (at least decent) email clients will include this Message-ID into an In-Reply-To header in reply messages, and Discourse could then extract the cookie and use it to locate the target topic.

(Michael Downey) #5

This seems like it could be rather foolproof. Our project’s support desk system uses this header to allow e-mail updates to support cases, so we don’t have to worry about quoting parts of messages or preserving subject lines, etc. Works really well.

(Michael Brown) #6

I would suggest either adding a transport agent that strips the localpart or having your mail gateway strip out the localpart from the envelope recipient address.

You could have that happen right on the docker host if you set up postfix to do the email delivery.

(seriously, Exchange doesn’t support localpart subaddressing? crazytown)

(Jeff Atwood) #7

Latest support:

are supported by several email services, including Runbox (plus and hyphen), Gmail (plus), Yahoo! Mail Plus (hyphen), Apple’s iCloud (plus), (plus), FastMail (plus and Subdomain Addressing), and MMDF (equals).

(Michael Downey) #8

I still think using the Message-Id header seems like the most reliable way to do this, or am I missing some reason that it simply must be a local-part UUID?

(Jeff Atwood) #9

And yet

Reply-To: discourse/discourse <>
To: discourse/discourse <>

That’s how GitHub does it, with 100 million in VC.

(Michael Downey) #10

With all due respect, that’s pretty irrelevant. GitHub isn’t an open source project, and gets to control what type of incoming mail servers it uses. Discourse can’t safely make those types of assumptions about its install base, can it?

(Andre Kosak) #11

I also would like to use my company Exchange server for receiving reply-emails. So the feature with an alternate way of handling replies would be great, because Microsoft seems not planing to support “plus addressing”.

(Dean Taylor) #12

You can already do this by setting up a subdomain for handling all replies with a “catch all” for that subdomain.

Similiar to what’s detailed here:

(Raghav) #13

Has any progress been made regarding the message-id approach? I have the same problem of having an enterprise MS exchange server and no way to use the plus addressing approach. Not possible to add subdomains to the mail server as it’s restricted.