Allow for email re-writing to solve the additional email address?

Continuing the discussion from Straightforward direct-delivery incoming mail:

Over in Two emails for one user the debate in:

Its pretty much settled on 2 emails. I think that’s best, but there will still be cases where we need to handle more.

I wonder if there could be a lookup table added to this discourse email processor which would have a rewrite table.

The idea is that incoming emails would be re-written, much like G-Suite Routing Rules so that by the time an email got to discourse, could be “from” a registered user in the name of

I’d be interested in getting the dev for this done but would need some pointers.

  • Would a PR for this be welcome?
  • Where would a loop like this best fit?

I don’t understand why you would want to “rewrite” e-mail addresses, especially the from address. That’s going to be more code than just matching e-mail addresses to users, because not only do you have to do the matching (you need to map from address to an account, to get the “canonical” address) you then also have to write the code to mangle the incoming e-mail.

If discourse were going to {n} extra emails route then sure, this wouldn’t be needed.

However, solving this for primary+secondary is going to fix the issue for ~90%+ of the use cases, and I’m just glad to see things going.

I’ve already got a project that re-writes outgoing emails (looking for a slug & replacing it with a custom value) so it’s not going to be that big of a project to re-use that here.

In two of the 4 forums I run, all users are members, but I don’t know them all personally and it’s hard to get them to reply to “would you please stop sending from the wrong address” requests. They are just annoyed their message didn’t post, and don’t understand that Apple Mail is really bad about ensuring new messages go out from the right address.

It’s going to be much less work on me to just say screw it, and know that user X might reply from A,B,C, or heck, even D and keep a table to match.

If there’s a good spot for it within Discourse, perhaps in the mail receiver:

I’d have someone on my team create this mapping component.

EDIT… it says right here I could use a add a pre-delivery milter,

I think I’ll try that.

Yeah, arbitrary from address rewriting isn’t going to go into the generic mail-receiver. It’s far, far too niche. On the other hand, forking it and layering your own logic on top isn’t hard – it’s built that way, because that’s how our internal mail handling works on forums. The Dockerfile moves the original script out of the way, and puts a new one in its place that loads the original script and just replaces the post_email method).

Even then, though, you’d probably be better off contributing n-email support into Discourse proper. I don’t think n-email support is something that we’d not accept a PR for, it’s just something that we’re not going to put together ourselves.


Thank Matt, I think I have a way forward I can understand well enough to take on.

The people I have at my disposal can get a postfix milter done easily, I don’t know what n-email support within discourse core would take, but I assume if it were easy-enough, it’d be done already. :wink:

1 Like

It looks like this:

Will solve the problem nicely. Looking forward to it.

That is totally unrelated to this topic. That is about forwarded email chains.

If an incoming email which doesn’t match is staged, and can be mapped to a current user… that’ll be just fine for my need.

I’ll redirect & tell the person not to use the unrecognized email address any more. Typically, they only need to be told once, and they’ll either stop, or we’ll change their primary email address.

As long as you’re clear that feature is about taking a giant forwarded email chain and forwarding it to Discourse to create a topic and stage the users based on the giant forwarded email chain.

Basically it is

take this giant email with dozens of participants and turn it into a sane Discourse topic for me automagically


ok, If that feature gets extended to any given email which comes in from an unknown address, it’ll be nice.

Nope that is not the plan.