Right but the email library we are using this for is from GitHub, they use it internally, so it would be highly unlikely that it handles (or expects) forwarded emails at all.
Forwarded email conversations may have one indentation of quoting. However, multiple forwards can turn into a nightmarish situation. How about including an option for “max indent level for email replies” with a default value of 1. This way, if we want to include a forwarded message or two, we can do that.
How difficult would that be to implement? Wouldn’t the parser simply need to look for the leading “>” character in plain text emails and just decide whether or not to include that?
Additionally, since multiple levels of plain text forwarded messages just have more “>” “>>” “>>>” characters. Couldn’t you just include them and format them to collapse/expand within Discourse?
The handling of forwarded email into discourse is certainly a frustrating issue.
I just had an oddball idea: what we really need is another special email address that takes the forwarded email and automagically attaches it as a PDF, then forwards it on with original headers to the forum. That way legibility is retained at least. Or an admin setting in discourse to convert to PDF and attach everything that would normally be truncated.
But @mochabcha the real issue is that discourse is using a library intended for github, which has a different purpose than ours. Not sure when/if that will be resolved.
In the meantime it’s about user training. I have been telling my team to edit what they forward or to post forwarded messages directly on the forum. In the end, arguably, this leads to better discussions anyway.
aside: I am loving the newly discovered (by me) collapsible text syntax. It would be nice to see forwarded email text presented like this instead of simply being truncated. But it will still have legibility problems because of the github parser. Ah well.
Typing in this:
<details><summary>Click this to view the longer transcript</summary>This part could be could be a huge long text</details>
Click this to view the longer transcriptThis part could be could be a huge long text
I see what you mean. I’m more than likely going to make a video or series of GIFs that clearly explain posting rules for the forum. I would however, and my apologies but this is unrelated, like to know how to customize the reply and error emails. I’m going to look that up. I do believe the process of evolving the digital conversation is going to hinge on boundary setting and proper education.
Is this still being worked on?
I’ve spent the day trying to resolve what works (and what doesn’t) for inline replies. Is there somewhere I should post email examples that one would think should work but don’t?
Apologies for more lack of Ruby knowledge, but can you let me know what version of the
email_reply_parser is currently being used by Discourse? Is it the relatively recent version of Github’s or @sam’s original fork?
My albeit brief reading of the Github parser suggests it should be working better than the observable Discourse behaviour, but i don’t have any sort of test harness to throw failing emails at.
Any help much appreciated.
It is on my list, but low priority.
A PM to me with details/findings would be appreciated.
Latest version of GitHub email_reply_parser.
MOSS Roadmap - Mailing lists
Can't forward an email to a group & preserve the content
Migrating from Google Groups
<details><summary> trick (which I never knew before as well) also work the same on emails, though? As email standards suck, I doubt it.
I don’t like the attachment idea either, as attachments should just not exist in emails. It’s wrong in so many levels and I believe the discourse team also relinquishes it.
Probably a better idea would be simply showing the full body of email on site:
But even that, how much is it really needed? How many cases for a real problem of this really are there? Aren’t people slowly adjusting and learning how to properly use it? Can’t mods just fix the cases that slip by?
This is the last show stopper for us. Forwarded emails are common on our mailing list and essential.
Has any progress been made on this?
Any movement on allowing forward emails?
I’ve been slowly moving our internal teams over from Basecamp to private categories on Discourse and email forwarding will help bridge the gap when people rely on email or when a third party communicates with us.
I’ve been reading other topics here about this issue, and it seems that the solutions proposed are fairly complex.
All that my users were expecting to happen when they send an email to an email address associated with a category is that body of the forwarded email would be preserved. (It’s currently cut.) For our purposes it would be fine if it just created one post with the forwarded content inside a blockquote.
The more information we have here, the better:
You’re familiar with the envelope icon? Staff can select that to see the email source there and repair broken posts. Not ideal but works.
@tobiaseigen: I hadn’t tried clicking on the envelope icon. That’s neat, but it not feasible as a workaround. I can’t possibly go around looking for posts sent by email and looking for forwarded content. Especially because we have some private categories on our site which I purposefully ignore unless I am @mentioned.
@sam: No forwarded email works. They come out like this:
(Obviously, a forwarded email followed that line, but it was cut.)
As far as I understand, email forwarding as a feature is not implemented at all. What kind of information are you looking for at this stage?
The behavior I expected is this:
We just hit this problem in a test instance where we are assessing Discourse as a ticketing system.
The test was done using GMail, a pretty popular service. Getting emails forwarded is not unusual in our context. This problem is quite a blocker for us…
It’s a bit strange that nobody has complained in the last years. Maybe there is another thread with a workaround somewhere?
Latest commit e50e502 on Jul 22, 2016
Ouch. I was about to file an issue upstream (nobody seems to have complained about forwarded emails there), but the lack of activity is discouraging. Maintaining a local patch isn’t a great prospect either.
Our users are totally external, people sending email to what they think is a normal mailbox.
Any ideas to unblock this situation?
The answer you quoted is quite out of date. We stared using our own gem a long time ago.
If you post the raw email with all its headers (or send me a PM) and tell as what you saw and what you expected to see, we might be able to figure this out.
You did enable the
enable forwarded emails site setting, right?
OK, I tested again with the same email and now the forward does appear, no problem. It appears in a different way than expected (the topic appears as created by the author of the email being forwarded, not the email being sent, an this has implications we have to consider).
In any case, thank you. The big blocker is now solved.
Is it possible that this problem can still be reproduced when Creating a read-only mailing list mirror?
We cannot get forwarded email through in a mailing list mirror category, while forwards land just fine in another category in the same test instance with posting via email enabled.
Maybe the solution is to skip any removal of content in mailing list mirror mode? Mirror is mirror, and the risk of missing content is way more expensive than the convenience of not showing signatures (especially when we are thinking that Discourse becomes the de facto archive of a mailing list).
I guess we could add a setting to disable trimming for mailing list mirrors. It could make sense for lists where members know how to behave and don’t include hundreds of useless lines of text from previous emails. Can you create a feature request for it?
Nevertheless, I’ll try figure out why forwarded emails do not work for mailing list mirrors.
Content of incoming emails shouldn't be deleted when the "Mailing list mirror" setting is enabled