Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
grossvogel opened this issue Dec 9, 2015 · 1 comment

Comments

@grossvogel
Copy link

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
Copy link

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 <[email protected]> into

From: Human Resources 
<[email protected]> 

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants