I think she’s just hoping the functionality can be made more equivalent to what she’s used to. That would happen if the file were actually attached to the message and not provided as a link. She really is a candidate for mailing list mode in a big way - she does not log into our discourse at all and, even now after a year, misses the google groups we replaced.
3 Likes
Update - 6. April, 2016
- Major enhancement of incoming emails. This work effected a whole bunch of email improvements, the vast majority of which you can find listed in our v1.5 changelog.
- Attachments support
- Email notifications in user’s language. gh#4004
- Layout improvements gh#3969, gh#4008
- Unsubscribe by email gh#3952
- Better email context.
Major shoutout to @simon, @gdpelican and @joebuhlig for stepping up to the email plate and taking on a portion. @zogstrip please let me know if I missed anything major.
Will post another update in a couple of months!
15 Likes
amazing. congrats 
and many thanks! 
1 Like
I think I fixed that one. Not sure though, will have to confirm this.
Hello @erlend_sh. I wonder if you would consider adding the feature to allow replying only to sender to within this work? Before I found this thread, I described the problem in another topic that you commented in. Thank you!
1 Like
If that topic culminates in (1) a clear specification that (2) multiple users clearly want, then it’s a great candidate for MOSS work, yes.
1 Like
Could you point to an example of a clear specification so that I could generate one?
Sure, you can peruse our many #feature:spec topics to get an idea of what we’re looking for in a spec. But there’s no point spending too much time putting together a spec until you’ve reached a semblance of a consensus in the topic where this feature request is currently being discussed.
3 Likes
Understood. Because of the utility of the feature for me (essentially, it’s a must-have for our group), it seems prudent to develop a spec for me to work from, no? That way, people with strong programming skills / experience might be able to comment / stop me from making errors before I make them / contribute code?
3 Likes
I agree let’s get
I have some input on the reply-to-sender feature and a request from my customer. I will post back on the other topic shortly.
3 Likes
As well as migrating existing posts I’m keen to forward posts (for a period) that will continue to arrive at our old mailing list (a googlegroup). @erlend_sh suggested back in 2013 that this could be achieved by simply subscribing a Discourse email recipient to the mailing list.
The problem is that the mail gets rejected by discourse on the basis that it’s from a list :-/
Is there a way to whitelist particular mailing lists so we can make this work?
1 Like
Been holding out for Web Archive for a long time 
Is there any update? Has the MOSS budget run out?
1 Like
I’m working on a proof of concept for this… might take some time though…
5 Likes
It has, but of course we still care about email 
Post-MOSS we’ve continued to approach developers from our community with bite-sized paid projects. The web archive is one such project, which we’ve enlisted @gerhard to work on. But like he said, it’ll certainly take some time as we’ve definitely pushed the limits of our usual “bite-sized” requirement here.
4 Likes
I’ve made some improvements to the mbox importer. I could imagine some cron job solution that used that importer as a stop gap.
3 Likes
Is there some kind of development report? I remember reading a plan when it was announced. Any debrief?
Added:
How far are you from this? I have Web-angry users that complain the mailing-list mode sends HTML email (and I didn’t try subscription by email). That suggests me we’re not there yet, but I’d be very happy if we were.
2 Likes
Not true; it is always multi part email where the text part is raw Markdown. If you don’t want the HTML bit then don’t use that and look at the plain text payload.
Maybe that’s an issue with their MUA. I don’t have this problem. I will ask for more precision.
Most mail clients will default to showing HTML content if present. I’m not sure Mail.app actually has a way to force it to show the text content by default. That said most of those clients also stopped loading remote content by default and it would be hard to imagine a case where a security issue would be a real concern. But as Discourse rolls into more “traditional” (read: with expectations of traditional mailing list features) environments, you’re going to get more and more pushback on not having this as a user preference. I’ve certainly had a fair bit of flak from Chef folks about it.
1 Like
Here’s what RFC 2046 has to say (emphasis mine):
Systems should recognize that the content of the various parts are interchangeable. Systems should choose the “best” type based on the local environment and references, in some cases even through user interaction. As with “multipart/mixed”, the order of body parts is significant. In this case, the alternatives appear in an order of increasing faithfulness to the original content. In general, the best choice is the LAST part of a type supported by the recipient system’s local environment.
From that reading, the Discourse emails are properly formatted, and the problem comes with mis-configuration on the user’s side. BUT according to mailing list tradition, HTML and email do not mix well, and plain text is always preferred. Maybe there could be a switch in the admin section for the order of parts?
3 Likes