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, johndoe@example.org could be “from” a registered user in the name of jdoe@example.com
I’d be interested in getting the dev for this done but would need some pointers.
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:
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 discourse.org-hosted 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.
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
