#65 E-mail quotation re-wrap when PGP inline signing

open
nobody
None
before_1.4
Major
2015-05-20
2012-08-10
No

Bug 24641 migrated from Mozdev.org

Problem: rewrapping of quoted text called

If I create a test e-mail with the following content:

Very long line with much more characters then
that'll fit into one line, but no more then two.
Third line that should stay seperate.

Upon clicking send, before Enigmail replaces it with the (inline) signed
content, the quoted part is rewrapped into:

Very long line with much more characters then that'll fit into one
line, but no more then two. Third line that should stay seperate.

Flowed format is disabled, and this pertains specifically to quoted text, which
should stay intact from how it is before clicking send. I have disabled the
HTML rewrap to test, no effect. Disabled other wrap-options in TB, no effect
either.

If I do not select to sign it, this quote rewrapping does not take place.
Execution trace does not seem to work ("c:\windows\temp" does not sport a new
file :( )...

------- Comment #1 From Patrick Brunschwig 2012-08-07 08:22:39 [reply] -------

Bug 25065 has been marked as a duplicate of this bug.

------- Comment #2 From LRN 2012-08-07 08:43:24 [reply] -------

In addition to (now-closed duplicate) #25065 :
If you keep send-and-cancel'ing that message, new empty quoted lines will
appear between the first and the second line.

Also:
If the lines added are 1 character shorter, like this:

> 123456789012345678901234567890123456789012345678901234567890123456
> 123456789012345678901234567890123456789012345678901234567890123456
then no re-wrapping takes place. That is, text must be 67 characters long at
the least (+2 characters for "> ").

You can also have some fun with it.
Insert this in new message:
> 1234567890123456789012345678901234567890123456789012345678901234 5
> 1234567890123456789012345678901234567890123456789012345678901234 5
Send-and-cancel.
It'll turn into this:
> 1234567890123456789012345678901234567890123456789012345678901234 5 
> 1234567890123456789012345678901234567890123456789012345678901234 5
(you can't see it, but first line gets extra trailing space)
Send-and-cancel again.
Now you'll get this:
> 1234567890123456789012345678901234567890123456789012345678901234 5
>  1234567890123456789012345678901234567890123456789012345678901234
> 5
(extra space made the line too long, and was merged with the next line, which
had to be wrapped by moving the trailing '5' to a new line)
Send-and-cancel again.
Now you have this again:
> 1234567890123456789012345678901234567890123456789012345678901234 5 
> 1234567890123456789012345678901234567890123456789012345678901234 5

That way you can transform it back and forth as many times as you want! :)

Related

Bugs: #90

Discussion

  • LRN

    LRN - 2013-04-30

    I have found a way to fix this bug. In file content/enigmail/enigmailMsgComposeOverlay.js remove this snippet:

          if (wrapWidth && editor.wrapWidth > 0) {
            editor.wrapWidth = wrapWidth - 2;
            wrapper.rewrap(true);
            editor.wrapWidth = wrapWidth;
          }
    

    And all wrapping problems will magically disappear!

    Another option is to set wrapping width (via about:config) to 0, but that will completely disable any wrapping of your own message text (weirdly enough, you will still be able to wrap quoted text with Ctrl+R, but not your own).

     
  • Patrick Brunschwig

    I won't apply this patch, as it disables line wrapping entirely, which tends to break signatures. As you wrote correctly, you can disable line wrapping by setting the wrap width to 0.

     
    • LRN

      LRN - 2013-04-30

      That statement does not seem to be true, from my experience, at least not in all cases. I've sent signed messages with this patch applied, and Enigmail says that signature is good.

       
  • Patrick Brunschwig

    I wrote "tends to lead". There are MTAs (mail servers) that rewrap the messages to obtain a maximum line length of 80 characters. This rewrapping will break the signature unless the message has been pre-wrapped. I'm not saying that all MTA are doing this, but some.

     
    • LRN

      LRN - 2013-05-01

      Well, ok, if you really need to wrap, and the only way to do it is to re-use Thunderbird's own rewrapper (which does horrible things when re-wrapping quoted text), then maybe you can work around its problems:
      1) Apply to each line, not to the whole text. If the text look like this:

      1wiuerfhwiuhgwiugheirugh 2wiuefhwiefh 3wuehfiwehf 4iwuehfiwuhf 5wieufhwiuefh
      foobar

      then this will turn it into:

      1wiuerfhwiuhgwiugheirugh 2wiuefhwiefh 3wuehfiwehf 4iwuehfiwuhf
      5wieufhwiuefh
      foobar

      Which might not look very good (for "natural" text it would have been better to remove " foobar" and append it to "5wieufhwiuefh"), but will not screw up existing linefeeds (which might have had some meaning)
      2) Insert "\n" after each long line before wrapping it, and include that "\n" in the text that is fed to rewrapper. Then remove the trailing "\n". This prevents re-wrapper from doing stupid things, like turning

      very long line

      into

      very long line (part1)
      very long line (part2)
      very long line (part3)

      that is, prevent it from "forgetting" that it is working with quoted text.

      Or, as an alternative, you can just refuse to send a message until it's fully wrapped, and tell user to either press a button to re-wrap automatically and send it, or allow user to cancel and rewrap manually

       
  • Patrick Brunschwig

    The problem is that there are already some \n at various places. How
    would you distinguish between the already existing \n's and the ones
    inserted before re-wrapping? I.e. how to determine which \n's to remove
    again?

     
    • LRN

      LRN - 2013-05-01

      You don't.
      Do note that this observation is based on using re-wrap function from the Thunderbird message composer, not on using it from JS.

      I.e., you have this text:

      foo
      jrhberfgheirfgheirgh 34uher ierg iu234h riwuerhf ewuifh 23i43uhr 3i4ufh eirufh
      erigheirfh3ui4f herg ekrjf 3io4fhekrjghnejfjh23rhiowu4fhowefjl34h 3uy4hr werf2
      baz

      If you select the third line and rewrap, you'll get:

      foo
      jrhberfgheirfgheirgh 34uher ierg iu234h riwuerhf ewuifh 23i43uhr 3i4ufh eirufh
      erigheirfh3ui4f herg ekrjf 3io4fhekrjghnejfjh23rhiowu4fhowefjl34h
      3uy4hr werf2
      baz

      (note that SF.net quote detection does make the quote above look correct; it isn't - "3uy4hr werf2" is on a separate line, without "> " prefix; if you look at the e-mail you get on new comments, it should have the right text).

      If you add a newline after third line:

      foo
      jrhberfgheirfgheirgh 34uher ierg iu234h riwuerhf ewuifh 23i43uhr 3i4ufh eirufh
      erigheirfh3ui4f herg ekrjf 3io4fhekrjghnejfjh23rhiowu4fhowefjl34h 3uy4hr werf2

      baz

      and select only the third line and rewrap, you'll get the same result, only with an empty line:

      foo
      jrhberfgheirfgheirgh 34uher ierg iu234h riwuerhf ewuifh 23i43uhr 3i4ufh eirufh
      erigheirfh3ui4f herg ekrjf 3io4fhekrjghnejfjh23rhiowu4fhowefjl34h
      3uy4hr werf2

      baz

      (again, bear SF in mind).
      But if you instead select the third line AND the linefeed (place cursor at the beginning of the line, then press SHIFT+DOWN) and rewrap that, you'll get:

      foo
      jrhberfgheirfgheirgh 34uher ierg iu234h riwuerhf ewuifh 23i43uhr 3i4ufh eirufh
      erigheirfh3ui4f herg ekrjf 3io4fhekrjghnejfjh23rhiowu4fhowefjl34h
      3uy4hr werf2
      baz

      which is the desired result.

      Actually, now that i thoroughly tested this, you don't need to remove an extra "\n" you've added.

      Note that for 2nd line re-wrapping works just fine without extra efforts. Still, if you add "\n" to it and do rewrapping the same way you did it for 3rd line (i.e. with SHIFT+DOWN), it also re-wraps correctly and consumes the "\n", which means that you can use this for any long lines.

      So the logic is:

      i = 0
      while True:
        l = message.pick_line (i)
        if l is None:
          break
        if len (l) < wraplength:
          i += 1
          continue
        message.insert_line_after (i, '')
        message.select_lines_from (i, 2)
        message.rewrap_selection ()
        i += 1
      

      (i totally made up the "message" object, and the pseudo-code is, obviously, in Python; no idea how to do that in JS, but i did notice that wrapper object just re-wraps, like, everything, so you'll need to find a way to constrain it somehow)

       
  • Patrick Brunschwig

    I will try your proposed algorithm, but I fear it's too simple. E.g.
    you'll have to take special care of quotations, otherwise they will be
    mixed with the rest of your text. Similarly, you probably want to treat
    enumerations and indented text specially.

    Furthermore, HTML messages - even if converted to plain text first -
    might open a few more pitfalls.

     
  • Bernhard M. Wiedemann

    I think, this one is related:
    https://bugzilla.opensuse.org/show_bug.cgi?id=923402

    This still happens with enigmail-1.8.2 and thunderbird-31.6

    quotations are incorrectly rewrapped before enigmail pops up its
    "You have very long lines in your mail"-dialog

    IMHO, there could be an off-by-one (or two) somewhere in thunderbird/enigmail

     
  • Patrick Brunschwig

    The rewrap before the Enigmail dialog is shown is done by Thunderbird without Enigmail involved. There is nothing we could do about it.

     

Log in to post a comment.