The Rails conductor that facilitates composing and routing ActionMailbox inbound emails only has support for plain text. There doesn’t seem to be a way to route html emails.
HTML email responses feel like they might be a lot more difficult to parse to me. Can you think of the default behavior you’d want to see here?
So my use case for this is I’m using ActionMailbox to extract certain properties from the content of an inbound email. Most emails sent these days consist of rich content so I’d like to be able to generate html emails as part of my ActionMailbox development workflow.
I agree they’re certainly more difficult to parse than html but in my use case it would be unreasonable to expect all emails to be plain text.
Re. default behaviour. I do like how with action mailer previews we can switch between html and plain text emails via a dropdown select. Maybe a similar dropdown select could exist for the ActionMailbox inbound email form that would allow you to switch between accepting html vs plain text inside the text area.
The onus would be on the user here to ensure they’re composing/pasting valid html which might cause some issues for them if they have malformed content but I don’t think it’s an unreasonable tradeoff to make at least in light of having no avenue for html at the moment.
Many/most e-mail applications compose messages with an HTML “part” and a text/plain “part”. The latter is sometimes a sort of “strip tags” version of the HTML, if HTML was the original authoring intent. It’s not 100% clear to me if it’s an actual MUST or just a MAY or a SHOULD in the RFCs, but text came first, and is considered the bedrock of internet mail. I would personally consider any e-mail message that did not have any text/plain component (or an empty one) to be broken and undeliverable.
Whether or not your application “replies” in HTML is immaterial to the version of the originating message that ActionMailbox consumes for its various parsing purposes. Are you looking to reply including the HTML form of the message you are replying to? Do you worry about your application getting attacked on this surface? (I have no particular proof of threat here, just wondering if that’s an angle you’ve considered.) How would you go about sanitizing that input while preserving its look and feel in the message “thread”, assuming that’s your goal here?
Walter
We have a custom conductor controller of sorts that allows uploading an .eml file or choosing an .eml fixture from test/fixtures/files. I’d support upstreaming something like that.
I think I’d also be okay with adding an optional textarea to the existing form for an HTML part.
This seems like a nice approach. I’ve been using eml fixtures in the test environment as a way to get quick feedback during development so exposing this to the development environment sounds like a nice way to go about it.
