Multi-line reply headers not recognized if quoted ones are found below

[grossvogel]

The fix to #23 seems to have broken reply header handling in emails like this one, containing more reply headers in the quoted text below.

Expected Behavior: The first reply header gets its line breaks removed, and ends up in the second fragment along with all of the quoted text.

Observed Behavior: The line breaks aren't removed, and therefore it's not recognized as a reply header later on. So the reply header ends up in the first fragment instead of the second.

[dannyjlaurence-exp]

I think that either this problem is a little more general, or perhaps this is just a different, related problem - the RFC's for Email have a section specifically outlining the line length of emails; the guidance specifically being:

Each line of characters MUST be no more than 998 characters and SHOULD be no more than 78 characters, excluding the CRLF.

As such, I've observed mail servers/clients (and services like send grid) edit the emails being exchanged with rules like this:

• If a line is > 78 characters and has a whitespace character, split on the last one
• If a line is > 78 characters and has no whitespace character, break the line into 78 character lines

So it will turn something like From: Human Resources <a-really-long-email-address+1234556@humanresources.com> into

From: Human Resources 
<a-really-long-email-address+1234556@humanresources.com> 

and in a related fashion, something like <https://d3k81ch9hvuctc.fake.cdn/company/MiZSL5/images/467c76ff-861d-4a32we-98b-92f5-b7958f3af726.png>
into

 <https://d3k81ch9hvuctc.fake.cdn/company/MiZSL5/images/467c76ff-861d-4a32we-
 98b-92f5-b7958f3af726.png>

I don't think that there is any great fix as

1. there's probably no standard set of rules and
2. it's trivial to construct cases that would break any kind of general solution.

Lastly, in addition to the fix you had for #48 you could do something like (in JS, sorry not a Ruby guy):

/^\s*(From\s?:.+\s?(\[|<).+(\]|>))/u

to detect the above case.

Don't have a real conclusion here - just did a bunch of research this morning to fix a specific problem we were seeing. Happy to try adding the above into your solution for #48 if anyone wants to give me some pointers on Ruby/this project.