Open Bug 204478 Opened 21 years ago Updated 2 years ago

Can't mail patches in body to non-f=f mailers

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect

Tracking

(Not tracked)

People

(Reporter: BenB, Unassigned)

References

(
URL
)

Details

As mandated by RFC 2646, Mozilla adds a space in front of every line starting
with a space. As stated by Andrew Morton in bug 141983 comment 19, this causes a
problem, if you paste a patch into the body of an email, send it via
format=flowed and a non-f=f-supporting mailer receives it. There is no problem
(to my knowledge), if the receipient mailer supports f=f or if the message is
sent as HTML or if the sender uses plaintext and Mozilla receives it.

I filed this bug to search for and track implementation of a workaround to
minimize the impact of this problem.

One possible solution would be to always space-stuff all lines, but that would
have impact on every message sent and is likely to cause greif for users for
other reasons.

Any discussion, if f=f is good or bad or should be default or not is offtopic
here. Please keep that to the newsgroups.
Does adding :

user_pref("mailnews.display.disable_format_flowed_support", true);

to user.js work around this problem successfully ? (I long since
disabled it for other reasons)
Yes, it does, but that's not the point.
oh, wait, you said display. No, you'd need to disable sending support.
user_pref("mailnews.send_plaintext_flowed", false);
as the problem appears on other mailers.
Note:
You can attach patches/diffs as files (which you should do anyways, IMHO), and
they won't be altered.
If you want to discuss a patch, you can also still do this, the patch will look
a bit wrong, but still readable for humans.
There is only a problem, if you want to copy&paste the patch in/from the body of
the message and then feed it to the program |patch| to apply it. The reciepient
would have to manually unmangle the patch in that case, if his mailer doesn't
support f=f.
Ben, that's really not an acceptable workaround. Many many people
expect inline patches simply because it makes quoting a lot lot easier
in mail clients such as mutt on the *other* end. Never mind the fact
that attaching a patch and sending it to Linus or whatever gives you
little chance of him taking it, since it's less convenient for them.

It's good that there's a simple work around but it's undeniable that
the default Mozilla setup simply makes it unusable for working with
patches for many people.
OK, I guess that conventions are different in some projects, then. Leaves us
iwht having to figure out a way to solve this bug, if we can.
An alternative would be to try to get (at least) rudimentary f=f support into
Mutt and Pine :). Seems a bit like wanting to change the world, but may the the
right way in the end.
Ben closed bug 141983, marking it invalid - but jfrancis and I question
this.  At best it should be a WONTFIX if it is decided to retain 
"format=flowed" sending on by default.

Ben continued discussion in this bug here - but I choose to continue the 
discussion of these matters at the original bug 141983.  Please see my 
comment number 30 there and the discussion which precedes it.

There are an unknown number of scenarios where adding a space to an 
indented line causes serious problems for the user.  I discuss some
of these in bug 141983 - but we must remember we can never anticipate
the impact of such alterations to messages for all the millions of 
users in all sorts of contexts, such as web archives, digital 
signatures etc. into the future.

 - Robin
Product: MailNews → Core
Assignee: ducarroz → nobody
QA Contact: esther → composition
Product: Core → MailNews Core
New standard now says:
On generation, any unquoted lines which start with ">", and any lines which start with a space or "From " MUST be space-stuffed. 
RFC 2646 was only recommend it (SHOULD)
Hardware: x86 → All
This is a dupe, or a superset, of bug 86607.  The checkbox for format=flowed could then default to "no" when replying to a non-flowed message such as the ones generated by git-format-patch.
This bug has been open for nearly 8 years with no fix.  Various projects have had to write guides on submitting patches with Thunderbird, to prevent getting broken patches.  Even with such guides, email threads still occur regularly in which a patch submitter has to re-submit a patch due to this issue.

For a different but related issue (namely, the inability to send plaintext mails with word-wrapped text but preformatted non-word-wrapped code), I just filed bug 639261.  It occurred to me while writing that report that if the user chooses to "paste preformatted text", that seems like a pretty strong indication that they want that preformatted text to remain untouched.  Given that information, could Thunderbird then do something to avoid mangling the patch for mailers that ignore format=flowed?  Obviously it could avoid adding any trailing whitespace, for instance.  Space-stuffing the entirety of the preformatted block would improve things marginally, since at least that would preserve the relative positions of characters within lines, but that wouldn't preserve the applicability of patches.
Space-stuffling all lines that were inserted in "preformatted text" mode seems like a good compromise to me, yes.
I just had an idea that would have fixed this problem back when format=flowed came about, though unfortunately I don't see any way it can work now.

I wondered: what would happen if Thunderbird sent a multipart/alternative mail with both format=flowed and format=fixed parts?  That seems like precisely the standards-compliant way of providing two different formats and letting the *recipient* choose, which seems like precisely the problem expressed by the various format=flowed bugs: the recipient cares, but the sender currently has to choose.  Mailers like Thunderbird could then prefer the format=flowed part for display, and the format=fixed part would provide the original text the user typed with no modifications.  multipart/alternative tells any MIME-compliant mailer "only display one of these", so that should prevent any mailer from displaying both and quoting both when replying.  This would make plain-text mails somewhat larger, but then so does sending multipart/alternative with text/plain and text/html. :)

All sensible mailers do MIME these days.  I would hope that any mailer supporting format=flowed would take that into account when selecting its preferred part to display from a multipart/alternative.  The MIME specification requires ordering the representations from "least faithful" to "most faithful"; that works out well, since Thunderbird considers format=flowed "most faithful" and doing this for compatibility requires putting the format=fixed representation first.  That just leaves the question of what a non-format=flowed mail client does when it sees two text/plain parts in a multipart/alternative.  This would work perfectly if format=flowed worked as a Content-Transfer-Encoding or something else that mailers without format=flowed support would hopefully ignore since they can't decode it.  Unfortunately, as specified now, mail clients that want to use the format=fixed version would have to explicitly prefer it over format=flowed despite both using the Content-Type text/plain, which those mailers think they can understand but in the format=flowed case cannot fully decode (hence the problem in the first place).  I tested this, and such mail clients seem to use the format=flowed part rather than the part with just "text/plain".

OTOH, if you fed the undecoded mail into a patching tool, if Thunderbird took the approach of space-stuffing entire blocks of text in format=flowed, those blocks of text wouldn't look like a valid patch, so the patching tool would ignore them and use the version from the format=fixed alternative. :)

So, in short, the format=flowed standard could have used MIME to properly provide its new format to format=flowed mailers while not breaking existing mailers based on text/plain, but it didn't, and now no mechanism exists that will work in all mailers.

Another possible alternative would have involved using multipart/mixed to send preformatted text as a non-format=flowed part to avoid space-stuffing it, and then continue the mail body in another format=flowed part.  Unfortunately, multipart/mixed gets interpreted exclusively as "attachments" now (albeit displayed inline).

One probably crazy alternative that would work perfectly but that nobody will accept: multipart/alternative with text/plain and text/plain using quoted-printable. :)  That would probably annoy the same people that want inline patches, in any case.
(In reply to comment #15)
> Space-stuffling all lines that were inserted in "preformatted text" mode seems
> like a good compromise to me, yes.

That will still break the ability to apply patches or copy code from email, but it will at least break it in a reversible way (delete all the leading spaces), and perhaps patch tools can be taught to work around this particular brokenness.  As far as I can tell, no less-broken alternative exists to handle preformatted text within the constraints of the mangling required by the format=flowed standard.
A comment in bug 475712 helped me think of a good solution to this problem.

How about adding a heuristic for plain-text mails, which says that if the mail contains no long non-preformatted lines (meaning no lines which format=flowed would send with soft-wrapping by putting a trailing space), the mail gets sent as format=fixed?  This seems like a similar case to the heuristic used to send HTML-composed but unformatted mails as plain text.

With such a heuristic, sending a patch in email would work perfectly with Thunderbird, by inserting it as preformatted text.  (As long as the user didn't try to edit the mail further with Thunderbird.)

Ideally this heuristic will also work for "git format-patch"-generated mails put directly in the drafts folder with "git imap-send".  Such mails should have Content-Type: text/plain without format=flowed, so Thunderbird should treat them as preformatted text.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.