Allow post by email to take the post as an attachment rather than the body

[andrewducker]

Title:
Allow post by email to take the post as an attachment rather than the body

Area:
Posting by email

Summary:
I should be able to email a .txt file in and have that be my post.

Description:
If I post by email then I end up with all the lines truncated at 80 characters (or thereabouts) with the remainder of the line pushed onto the next line(s).

It would be great if rather than taking the body of the email as the post I could send a .txt attachment that would be posted instead. That way I could write the post in the text editor of my choice, attach it, and it would be posted.

Poll #7752 Allow post by email to take the post as an attachment rather than the body

Open to: Registered Users, detailed results viewable to: All, participants: 53

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
11 (20.8%)

Should be implemented with changes. (please comment)
5 (9.4%)

Shouldn't be implemented.
3 (5.7%)

(I have no opinion)
32 (60.4%)

(Other: please comment)
2 (3.8%)

Comments

[msilverstar]

It would be better to avoid the 80 character hard return, or to remove it if the mail client generates it.

[zvi]

+1 with changes.

[holyschist]

Agreed.

[sophie]

It's almost always generated by the client. The trouble with removing it is that you then can't tell whether or not whether the next line is meant to be on a new line or not. For example, if you had:

* Point one, which is long enough so that it takes up nearly 80 characters,
* Point two, which is on a separate line and meant to be displayed as such.

Then an algorithm would probably string those two lines together, resulting in:

* Point one, which is long enough so that it takes up nearly 80 characters, * Point two, which is on a separate line and meant to be displayed as such.

Which kind of looks ugly. :/

[pauamma]

http://www.rfc-editor.org/rfc/rfc3676.txt

[justhuman]

+1 with changes

[kerravonsen]

Is this truncation caused by Dreamwidth or by the mail client?

[matgb]

Mail client, but some people are stuck with settings not under their control (work provided machines, mobile phone clients, etc). I just checked Gmail, and cannot find if there is a character width limit, I believe there is if so i have no control over it.

[azurelunatic]

Or have to keep the mail client settings as-is for one's outgoing mail to remain usable in other settings.

[matgb]

Aye-worked briefly in one place where all outgoing mail would have a fairly long disclaimer "sig" attached regardless of whether I wanted it there at all, sometimes you've no control whatsoever about the format of your outgoing mail.

[pauamma]

Either/both. If the mail client doesn't use http://www.rfc-editor.org/rfc/rfc3676.txt or Dreamwidth ignores it, the line wrapping will get through.

FYI to the OP

[ct]

I agree that some sort of permanent solution to this would be a good thing, but in the meantime, there is a workaround if you're comfortable with HTML.

In your email, surround the text for the body of the entry with <lj-raw>...</lj-raw>. This will keep the site from trying to format the text itself as it posts the entry - the equivalent of checking the "Disable Auto-Formatting" checkbox. Then, use html to format the text as you like. For example the body of your email might look like this:

post-icon: your icon keywords
post-tags: tag anothertag

<lj-raw>
<p>This is a very long
sentence that goes on and
on but will display all
on one line when the entry
is posted.</p>

<p>And here's another,
shorter one.</p>

</lj-raw>

Make sense?

Re: FYI to the OP

[andrewducker]

That's a good tip. Thanks!

Re: FYI to the OP

[justhuman]

This tip is made of awesome!

[voldsom]

Is the emphasis on this trying to fix an existing problem, or to broaden the scope of functionality. :) Because it does both, nicely.

My personal usage case is that if I'm updating by email then it's because I'm doing a quick update from my phone, so I wouldn't have ready access to a text file anyway. Weirdly, and I've been meaning to check this, but if I email from my phone I don't remember having the 80 line truncation issue, but if I email from my web client, I definitely do. I use gmail in both cases.

If the main emphasis is on resolving the 80 character truncation issue, this feels like the wrong solution. It's a brilliantly neat lateral solution, and avoids having to smart parse the entry and occasionally get things wrong (per the comment by sophie above).

If we're happy to extend the functionality, I'm all in favour, but then I start getting carried away. Primarily, how do you manage user input?

Do you auto detect, or rely on the user explicitly naming a file? I can never remember the post options, I find them confusing for no reason at all, but auto detect has its own share of issues, normally brought about by a lack of control over externally imposed (and overly complicated) signatures.

Do you allow for multiple file posting? I'd be inclined to say no, otherwise you have to decide if it's a single entry or one entry per file, and that's way too close to spam. This also leaves you with the question of how you manage multiple attachments to an e-mail, which might be covered by the explicit naming, above.

Do you support other formats? Text only is a good start, but the web UI already supports HTML and RTF, so if I wanted to use this method for uploading to my journal a document I'd already written elsewhere, should that be catered for.

I'm assuming that the content detection / control on e-mail is already strong enough to manage most of what would be in an external file as well, but no matter the restrictions on external file type, I'm assuming that this would have to be beefed up a little.

Sorry to be more questions than answers, but if this is adding functionality as much as solving a problem then it has the potential to go a little further. Whether it should or not, I don't know.

[denise]

FYI, I'm going to call this rejected for right now for an issue that nobody brought up in the comments: having to carefully scan the attachment for a) making sure it's a plain text file and b) making sure it doesn't contain any harmful stuff. If anybody can think of a way to do it safely, I'm totally open to revisiting it.

[andrewducker]

Is that a bigger attack surface than me taking the contents of that file and pasting it into a post?

And if so, why? I'd expect exactly the same code to be called whether the post was made via client, web or email.

[pauamma]

Hmm. I'm not sure it's that hard, actually. I think there are 3 cases to consider:
- The attachment claims to be plain (in the MIME type field) but is lying. That is, it's actually binary data for an image, an executable program, or something along those lines. DW needs to reject it, but it also needs to do that for the (implicit or explicit) attachment of single-part emails.
- The attachment is plain text as it claims, but contains HTML fragments (which is a reasonable use IMO). Those need to be fed to the HTML cleaner, but again, this is also true for single-part emails.
- The attachment claims (correctly or not) to be something other than plain text, This is the only case that can't happen with attachment-less emails, but then all that's needed is to discard the attachment based on its type. (Or handle it appropriately, eg if it's an image the user means to picpost.)