Jump to:
| Project: | Mailhandler |
| Version: | master |
| Component: | Mailhandler |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
Plain text email messages generated by most email clients have lines wrapped before the 80 column mark for standards-compliance. Different encoding methods may be used to perform this wrapping while still preserving enough information to reconstruct the original lines.
One such encoding standard, used by the iPhone and others, is format=flowed: http://www.ietf.org/rfc/rfc3676.txt
An example message:
Return-Path: <myaddress@example.com>
Received: from ?10.90.205.193? ([166.205.7.16])
by mx.google.com with ESMTPS id 20sm649597pxi.8.2009.09.16.09.31.28
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Wed, 16 Sep 2009 09:31:29 -0700 (PDT)
Message-Id: <71F201A1-430E-469D-8103-6296640DDA25@example.com>
From: Alex Markley <myaddress@example.com>
To: Alex Markley <myaddress@example.com>
Content-Type: text/plain;
charset=us-ascii;
format=flowed;
delsp=yes
Content-Transfer-Encoding: 7bit
X-Mailer: iPhone Mail (7A400)
Mime-Version: 1.0 (iPhone Mail 7A400)
Subject: Stuff foo
Date: Wed, 16 Sep 2009 12:31:21 -0400
Here is a very long test line. Experimenting with iPhone email. Here
is a very long test line. Experimenting with iPhone email. Here is a
very long test line. Experimenting with iPhone email. Here is a very
long test line. Experimenting with iPhone email.
Foobar
--
Alex Markley / 740.927.3588Notice the format=flowed and the delsp=yes flags on the Content-Type. Those two flags together mean that any SPACE CR LF character sequences should be removed. (With no delsp flag or delsp=no, the SPACE CR LF character sequence should be replaced with a single space.) Notice also that the first three wrapped lines of the "very long test line" are trailed by two space characters. These wrapped lines are reconstructed appropriately by conforming mail clients.
For more information about the format=flowed parameters, please see the relevant RFC: http://www.ietf.org/rfc/rfc3676.txt
So, my question: Can MailHandler be modified to support format=flowed messages? Reconstructing wrapped lines is critical to me being able to post content from my iPhone. :)
Thanks for your time!
Comments
#1
Let's give a try to this, but this requires a totally decoupled retrieve - parser process, or the code could end being a complete mess, so don't expect to be done quickly.
#2
It seems to me that it would be nearly trivial to write an input filter that converts the line returns into spaces. Would that work for you? Does Mailhandler really have to do anything extra to support this?
If you really need info from the message headers to accomplish this, I still think an input filter is the way to go, and you could write a mapper for the appropriate header to help.
#3
I guess I could see how you might need a little more than an input filter to accomplish this, since you need to know whether to insert spaces at the end of lines (although you might be able to figure this out contextually/heuristically). I would accept a patch to the 2.x branches that adds an input filter and/or updates the message cleaners to take this into account.
Just brainstorming for a second here... it seems the ideal solution would be to read the message format at import time, and offer the option (as with the latest mailcomment cleaners/filters) of either fixing the formatting at import time and storing the cleaned-up message in the database, or applying an input format. The format would have to be either dynamically assigned based on the value of delsp (not sure if this would be possible), or the cleaner would have to insert a flag into the message body that an input filter could use to determine whether delsp is enabled.
Let me know if you have any other ideas.
#4
Marked #986440: Question: length of lines imported as dupe.