github / email_reply_parser Goto Github PK

View Code? Open in Web Editor NEW

660.0 293.0 154.0 120 KB

Small library to parse plain text email content

License: MIT License

Ruby 99.81% Shell 0.19%

email_reply_parser's People

Contributors

Stargazers

Watchers

Forkers

alexkojin dball eric drydevelopment defunkt unloved fatfreecrm tarr11 3dna keeninstinct intrepidd wesgibbs dennis27 bmorton digitaltoad user234135134 digerata hooopo yubik9 timhaines tbauman wking crismilo tangentialism sunir-olark seth-macpherson epicagency apptentive-engineering cryptographrix royleexh tomups chrisfleming koniyan imclab endika ticketinghub-old pipao1128 nikhilvij remindcloud rgbkrk pombredanne paybygroup danielchatfield mtco jutaz rymohr xiegy fofr arcmode summera timothee-alby joebillings viclam clockwerx typpex chenkaigithub rickpastoor jwg2s jay3126 modulexcite stim371 hasimo flyeven yaoge-xy paranormalairbrush jdpopkin goodinc mmcquinn karamcnair miladr grossvogel bf4 kleopatra999 rtvt123 codextremist ztyan omgitsads tomoasleep olleolleolle lachlanjc lingyi-lk styfle bryant1410 rtbustamantec blockspring pkgodara notemaster11 jouhri nikhilperi shime mfbmina yossieilaty mort albertjan90 gymleads dothanthitiendiettiende easybroker maccman timkrins reviewtrackers

email_reply_parser's Issues

Signatures are not found when using Machine Learning

I've realized that the signature extraction that uses ML does not always work. I've tried it for 50 emails and it only worked for 16 of them. What is the success rate in more complex signatures? Like the one below.
"Name Surname
Job title

company name
website
telephone, mobile phone
fax
Address
email"
Is there something i can do to improve my results?

Markdown not parsed in emails

If you send an email reply in markdown (e.g. with backticks or some kind of:

list
and stuff )

It is not converted into Markdown on the actual site.
Moreover, editing the comment/reply on Github still does not convert the email to markdown

Golang Port: mailstrip

Hi,

thanks for email_reply_parser. I've ported it to golang and was wondering if you'd like to mention it as a port in the README? I'll send a pull request if you're interested.

http://github.com/ThomsonReutersEikon/mailstrip

Signature regular expression

I ran into some random situations where emails were not parsed correctly. Part of the email was chopped out, for example:
Hi Test,\n\n-This is a test
Will result in -This is a test fragment being hidden and considered as part of signature which it should not be. After digging more into the problem, we figured out that:
(?m)(--\s*$|__\s*$|\w-$)|(^(\w+\s*){1,3} ym morf tneS$)
The first matching group is testing against \w-, which is causing the problem. I can't think out of a better way to solve the problem other than take \w-$ part out so it opens to any suggestion.

Gmail's signature is not being detected

When you parse emails, you detect signature by -- (dash-dash-space). But, Gmail for some odd reason, adds asterisks before and after signature delimiter, you should, probably, support this as well. In raw email it looks like this: *-- *.

Comment generated by email reply will not respect line breaks

The initial comment generated by the email reply did not include any line breaks. Even after trying to edit the comment, add line breaks/paragraphs, and saving -- it will not apply them.

See link below:

fourkitchens/el-ocp-style@0c59d6a#commitcomment-3368080

Incompatible character encodings: UTF-8 and ASCII-8BIT

I'm getting an incompatible character encodings: UTF-8 and ASCII-8BIT error using parse_reply in a Rails view on certain strings.

I admittedly do not know much about encoding... so I spent a bunch of time googling but to no avail.

Here's an example of one offending string. I don't see anything wrong with it and hope Github isn't sanitizing any of it when I paste it in. But why not...

Hi Jaime,  This just came in last night from the local Nantucket dive shop I contacted: \"We do lobster diving charters all the time in August- just call or pop in at least a week in advance and talk to Phil Sr.  Thanks,  The Sunken Ship crew\"  If you'd like us to book something on your behalf, let me know, otherwise contact info is:  [omitted]  Thanks!  Rachel   On June 6 @ 01:19 PM, [omitted] wrote: Hey Jamie!  Here is Mike's info: [omitted]

I'm getting these strings from my database which is UTF-8. I've tried to use force_encoding and still get the error. Any clues? Am I not doing something foolishly obvious?

License missing from gemspec

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can image, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post aobut this project for more information.

Failure to strip replies from emails with parents lacking quote '>' char, e.g. Yahoo Mail.

As an example email body:

Here's a reply

On Tuesday, February 10, 2015 4:25 PM, TestAccount <test@_blank_.com> wrote:

And here's the parent

parse_reply() isn't able to separate the reply from the parent in this case, it appears because the parent is lacking '>' characters in front. I would have thought this case unusual, but it seems Yahoo mail uses this style by default. Has anyone gotten parse_reply to work with Yahoo mail replies?

Signature reconginized issue

I had an email come like the following

Quidem est perspiciatis omnis voluptatibus consequatur est et. Impedit occaecati quas voluptatem voluptas dolor eum consequatur.

Assumenda voluptatem tempore dignissimos. Id omnis nisi--ratione omnis qui suscipit.

Name

Since there is a new line and then a '--' embedded in the sentence, the emails were getting cut short.

Kind regards

I would like to make a pull request that recognizes "Kind regards" as a signature.

What is the best way for me to contribute?

Not detecting quoted content in emails coming from Mail.app

See jdpopkin@bf9d5ce for an example of this.

Signatures of replies sent by Google Inbox are not detected

Signatures of replies sent by Google Inbox are not detected because there are no empty line between the quatation and the signature such as the following email.

Hi,
This is a test reply from Google Inbox.

On Wed, May 25, 2016 at 3:13 PM <[email protected]> wrote:

> LGTM
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly or view it on GitHub
>
--
This is signature, but it is not detected.

Dutch end of email is not detected correctly

This part of the gem: if text =~ /^(?!On.*On\s.+?wrote:)(On\s(.+?)wrote:)$/nm works correctly for non-Dutch emails, but this is not correctly parsed as the end of the email:

Op zondag 31 mei 2015 heeft Name <[email protected]> het volgende geschreven:

It would be awesome if this could be added!

issue in parsing email reply for html content

below is code, I am extracting the mail body using mailparser which is text/html content
and trying to get latest reply using EmailReplyParser.parse_reply, but it is extracting complete message not the reply only

mail = mailparser.parse_from_bytes(file.read()
reply_text = EmailReplyParser.parse_reply(mail.text_html[0])

it is working file for text/plain content
mail = mailparser.parse_from_bytes(file.read()
reply_text = EmailReplyParser.parse_reply(mail.text_plIn[0])

any suggestions are appreciated, thanks in adavnce

Is there a way to turn off signature parsing?

Hey,

I've had a quick look at the code and this doesn't look like it's possible. Just wanted to double check, there's no was to optionally turn off the signature removal right?

If an email reply ends with a markdown-style quote, email reply parser includes this quote in the fragment corresponding to the quoted email reply

For example:

Hi! I'm replying to an email! let me end it with a quote:

> this is a quote! 

On Oct 9, 2011, at 3:47 PM, Maboo <[email protected]> wrote:

> THIS IS THE ORIGINAL EMAIL!
> HI!

This produces the following fragments:

--- 
- !ruby/struct:EmailReplyParser::Fragment 
  quoted: false
  signature: false
  hidden: false
  "@content": "Hi! I'm replying to an email! let me end it with a quote:"
  "@lines": 
- !ruby/struct:EmailReplyParser::Fragment 
  quoted: true
  signature: false
  hidden: true
  "@content": |-

    > this is a quote!

    On Oct 9, 2011, at 3:47 PM, Maboo <[email protected]> wrote:

    > THIS IS THE ORIGINAL EMAIL!
    > HI!
  "@lines":

Maybe ERP should look for the On Oct 9, 2011, at 3:47 PM, Maboo <[email protected]> wrote business as well as the angle bracket?

Issue with parsing when two consecutive replies are on email from same person

When a person replies twice on the same thread via email consecutively, second time the email parsing seems buggy.

For example, see this.

Emails from Microsoft Outlook ios app get parsed wrong

So I may be making an incorrect assumption you all use this repo for also parsing the replies to issues and pull requests but I found this bug as visible here: moby/moby#16847 (comment)

Thanks!

Fragment incorrectly hidden if two underscores are present

E.g.

This is some example text.

I think we should use __setattr__ for that

Second sentence will be hidden.

I'm looking at the code and will submit a pull request if I figure out where the bug is, I have no ruby experience though so I might not be able to.

cc @technoweenie

Kiran

Where we type reply message at the bottom of the actual email, Gem is not able to parse such type of emails...
It is returning whole email as it is, without parsing...

wrong comment display (when sent by email)

I have just realized that GitHub displays wrong the comments that have been sent by email.

One sample would be jgm/pandoc#1765 (comment). I received the email message and only the first paragraph should be displayed as a comment (it contains the required > in the message). The other two paragraphs are the actual reply (they aren’t formatted as comments in the email message).

Another sample is jgm/pandoc#1612 (comment). In that case, the paragraphs after the last shown without expansion are considered comments. The original message has no comments in that paragraphs.

I think this is an important issue. Otherwise it is really hard to make a distinction between what has been replied and which the reply itself is.

Windows Live Mail reply parsed wrong

If the reply comes from Window Live Mail the parsing is wrong.
Example of the body received:

risposta da mail di notifica anche se ora non seguo più il post

From: Airesis Forum 
Sent: Tuesday, November 19, 2013 12:03 AM
To: [email protected] 
Subject: [gruppo prova] Ambarabà cicci Coccò



                   Airesis - Test
--------------------------------------------------------------


                        A topic you have subscribed to has received a reply. You can view it here: http://www.arengo.org/groups/805-gruppo-prova/forums/forum-pubblico/topics/ambaraba-cicci-cocco 

                         mammarameo To unsubscribe from this topic, use the following link: http://www.arengo.org/groups/805-gruppo-prova/forums/forum-pubblico/topics/ambaraba-cicci-cocco/unsubscribe 



                          follow us on Twitter | follow us on Facebook | follow us on Google+    
                        Copyright © 2013 Airesis - Test. 
                        You receive this email because you are registered on www.arengo.org. 

                         Edit alarms and notifications preferences

Cannot start line with ‘On’ in reply

A bottom-quoted email that has a line in the reply start with “On” will discard that line and everything below it.

The code responsible can be found on line #87-90 of email_reply_parser.rb:

if text =~ /^(On\s(.+)wrote:)$/nm
  # Remove all new lines from the reply header.
  text.gsub! $1, $1.gsub("\n", " ")
end

An example email that shows the issue follows:

On your remote host you can run:

     telnet 127.0.0.1 52698

This should connect to TextMate (on your Mac, via the tunnel). If that 
fails, the tunnel is not working.

On 9 Jan 2014, at 2:47, George Plymale wrote:

> I am having an odd issue wherein suddenly port forwarding stopped 
> working in a particular scenario for me.  By default I have ssh set to 
> use the following config (my ~/.ssh/config file):
> […]
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/textmate/rmate/issues/29

hidden quotes

When replying a GitHub mail, I usually do inline quoting.

Only recently I realised that lines starting with ">", the common quote character, will not show in issue comments. Thus replies created by emails may get a very different meaning.
Compare what is shown:

with the real content shown after clicking "edit":

Either GitHub should show both quote and answer or suppress any quoting to avoid confusion.
If quoting is not desired GitHub should state so in its emal notifications.

Question: Python port

Hi,

Just wanted to let you know that I'm working on a Python port of this package, if you want to you can link to it from here. I've included your LICENSE file ✌️

String that makes email_reply_parser hang forever(?)

bad_text = <<~EOF
          >> I use Virtru to send and receive encrypted email. Click the "unlock
          >> message" button below to decrypt and read my message. If you have any
          >> questions, please contact me.
          >> Unlock Message
          >> <https://secure.virtru.com/start/?c=barebones&t=barebones-1-0-2&s=&p=0df370ca-d15d-4cb8-816f-cb598187af#v=3.0.0&d=https%3A%2F%2Fstorage.virtru.com%2Fapi%2Fpolicies%2F0df370ca-d15d-4cb8-816f-cb898187af%2Fdata%2Fmetadata&dk=IaLXRLoS0TX1W0uUofnFT0Ub7FyuCDKcgJqxFXXM%3D>
          >> [image: virtru] Virtru encrypts emails to keep private information safe.
          >> Learn more at Virtru.com <https://www.virtru.com>.
          >>
          >> Virtru Secure Email: v1.4.0
          >>
          >> Message ID: 0df370ca-d15d-4cb8-816f-81598187af
          >>
          >> Virtru Metadata: eyJ2ZXJzaW9uIjoiMS40LjAiLCJtZXNzYWdlSWQiOiIwZGYzNzBjYS1kMTVkLTRjYjgtODE2Zi1jYjgxNTk4MTg3YWYiLCJyZW1vdGVDb250ZW50TGluayI6Imh0dHBzOi8vc2VjdXJlLnZpcnRydS5jb20vc3RhcnQvP2M9YmFyZWJvbmVzJnQ9YmFyZWJvbmVzLTEtMC0yJnM9Y2hyaXMlNDBkYXRhNGFtZXJpY2Eub3JnJnA9MGRmMzcwY2EtZDE1ZC00Y2I4LTgxNmYtY2I4MTU5ODE4N2FmI3Y9My4wLjAmZD1odHRwcyUzQSUyRiUyRnN0b3JhZ2UudmlydHJ1LmNvbSUmFwaSUyRnBvbGljaWVzJTJGMGRmMzcwY2EtZDE1ZC00Y2I4LTgxNmYtY2I4MTU5ODE4N2FmJTJGZGF0YSUyRm1ldGFkYXRhJmRrPUlhTFhSTG9TMFRYMVcwdUxTOVVvZm5GVDBVYjdGeXVDREtjZ0pxeEZYWE0lM0QiLCJ1c2VyLnBsYXRmb3JtIjoiYnJvd3Nlcl9leHRlbnNpb24iLCJ1c2VyLnBsYXRmb3JtLnZlcnNpb24iOiIifQ==
          >>
          >>  --- START PROTECTED MESSAGE TDF 0 --- PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pgo8dGRmOlRydXN0ZWREYXRhT2JqZWN0IHhtbG5zOnRkZj0idXJuOnZpcnRydTp0ZGYiIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiIHRkZjp2ZXJzaW9uPSIyLjAiIHRkZjppZGVudGlmaWVyPSJkYzc4NjU3Mi1kM2ZkLTQ5MTctOTIxYy05MDEzZGU3ZTgxZGIiPgogIDx0ZGY6RW5jcnlwdGlvbkluZm9ybWF0aW9uPgogICAgPHRkZjpLZXlBY2Nlc3M+CiAgICAgIDx0ZGY6UmVtb3RlU3RvcmVkS2V5IHRkZjp1cmk9Imh0dHBzOi8vYWNtLnZpcnRydS5jb20vYXBpL3BvbGljaWVzLzBkZjM3MGNhLWQxNWQtNGNiOC04MTZmLWNiOTgxODdhZi9jb250cmFjdCIgdGRmOnByb3RvY29sPSJ2aXJ0cnUtcHJvdG9jb2wiLz4KICAgIDwvdGRmOktleUFjY2Vzcz4KICAgIDx0ZGY6RW5jcnlwdGlvbk1ldGhvZCB0ZGY6YWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDA5L3htbGVuYzExI2FlczI1Ni1nY20iLz4KICA8L3RkZjpFbmNyeXB0aW9uSW5mb3JtYXRpb24+CiAgPHRkZjpCYXNlNjRCaW5hcnlQYXlsb2FkIHRkZjplbmNyeXB0ZWQ9InRydWUiPnBueHBNUUlyblhtRTAyZzFMa09HbisybG9oSVFkdW5saXNYNWczYlllK2E3a1kraVBPNzFYbVZHM3hWV016cnhHUlZYQTVaUzExMFlkRWdYYzZlOEdtNUJyVTVKbGZaaVdhUjBsUklPb0U4NUhpL1FVdnJaOUNIN1NXWU9mQVlpOFVIMTVOdlVOQWRRZWdqd1VZTWcrWmY1anREc0JNclQyTTY5S3hvc1loaDFKN2NzYlNvWDk3RGx2dWx2eW1SeXVIcEUwdiszbHFzQ2xSb0JJRTd3dXFxcnZHOFZGWUpaeEVDdjZscENBR0NRNnVMUEVoV3F0ZFYzQVhZZTU3ZXg0NEtLUHJxT1pFRHZWeThEY0pMSkMxWFZmUjlVQyswaC9JU1UvOFcrc0gwdVlWem1CUlpJa3lKb2l2aGJEWXZ2NWJ6czVrTzVXcXlXQXBDWStYVzdYZytPdUJhOXNMRUpKaDZHVGxDNU1NV3JOODdLMWFUYjAwd290VHFDSEtTanVPMEsvZnlOdVZ2cjRJcVVBbmJ5T0hrcWE1MURrM0R0NkZQN3lJMkRqcnpidlhFTDZGUVBBaTZEN3pDYy9vbkJNSnZHaFVPUlNmOGFGSGJhSW1JVXhzMks0Ulp4Q3JQTG5KWGZEMStBM2RuRGZ1Q1lNb1FYTFpBdk1tQW1iUFVQbWtqQk9sOXpUSDIyLzZDRFlUbEtTamtjVENZOWVyaVJhaUNlYmIvM1pQdDBLRnNYKy9rU3kzc2tzczNJNkZIK0dhRzJ6NVFTQzhqc0hXUEI0Qk1Pd09qcmZ3QzFPdjczdEg2N3BxdVFGdXJPb0pBdU9VaTNRbU9mdmltUXpqbDN1TkRndXZlbjJvOTJTTGZHYkZsMEVpRWVqYy9nV0I0UlJyS1A2UzhYa2ROSzk5aUJMQmY4blhMei84VHViWDc3S1E2UFp6aGlOTmdiZmhla29aTXpUUHk3c0ltRitLWkRwMVZIQWpxY2hPbkVVUDVwTVoyeUVWaWlLNVZhemNhSlZvMVRwQmtTd1NGTXNRWmhJdGk2SW44L1RZWDVSek40NndNNFRNVnVOZmpEbmttcGpONlFXcHF4OUx5S2hjZkN2dlc5QmVuUU4zTEh2QUZOakUyVEZjbkE4SjFsTGNVL1B1WEoyYjlxOTd5a3dNTEozcnZIY25yc1lrRnZUSm5SQWhKWGM5SnRqdk5EcUVtdnAvdWY5RTBMbDhyM0g2L3krSjlnOEVJOXhJTEZxS2FHZG9TbnFZMWgzQ3BSTEVQajhGYW9wWXEyNlVqOUE3VVk5enNzT1J3NEh4cUUvamtka2lLdTNpMjYwWEtrZ2xJMHF1dTM4N2FDSHAyVS9BdkpRM2lKMGRmZGxJUVJOS3lhdkVTclFQak40bDNKRUdsUFBaUTV3YWFwVzc2dnlMdHphZWFQQ3VDT2p6ZjViSXVrNHN4NmxwYWpDMEdNUVBMOVdrM1UyWDFZVEtPV0o5YXgyYUwzcXdDbFEwbHRKb0trb2cxVTNmWHZkRE1iR1BOWEtMcEdlSFE2emdhbncvVzUvc2RjQWVHYnR6SzBtUmcrKzNKWlplNVUxaUcxMklSRlJsVmRxeTFQUWMvOVhQU3E1RVIyZ3RyOVlrVjFzTHNKTm5NbDF2MW1oUjBMT25JYzFJNWZ1a25oYlZEcnlmZUI2ZFQzTVlhM1ora1I0QlFoeGg1cWovcWJCY25xRGN0cU8zWFBhR3BkT0FQcXdYbkY1UTNTMlVtNnhqNjFPTEkwYTdOZEtHeHg4WGl3OVdnU2RiLytrdm5LNlNDejErMmc0YWhKNzAydEQybDVhK2JRZytSK3kwcVZkd1FEWDI5RzJ6N0RJN01vY1lHLzhiWmpLcVA4ektGUTMyaWlQVHZzM0FpeTlsSm1xNGRzMXlUbU5YcWUzK1hGYlpuV0I5bmtlcFVweTE0ZUxObHpQanpzNGRQR3p4QzYvRThwYUNwTnQ5aU0rV0pSenVGSWtCQUtFRnoxekd6L29IdVU0SmduNm1MbytpWXNPS20zcXpEb2xjSlNwUTdZd1hSOUFDYTIyQTJIZFduSUhLWkhZZmRRWkNQeitrcHR1dEVjcHkrZzZ3bThRTzVyODN0Vkg3RThRVWlWMFA3S2xxM3lYVlRiL0J6VVZweCtNelNaTzYzZzM5a1lFZEtiNmVPejkvRloxSkprWGlGWit5eTJnS0ZNZlFYVXZ2cjQvZ1ZVRDFPUEN0YXhORkIvYkF1OVpEWTlwcUFoYWF0dHlBOVBINWM1NnloUWxLL2RpR2FMaCtDVHhHYzNoNkxSRzhhczdEZkNBYmJYYzdtQjNZbzlTM051djFaZTFZeHBINHNUdVFHZ0dtZlRjSWpsMW1GOHJQTGNndnVWQ0NxYnNzMy9OSmUxNnJWMWg4a3M4STFlb0cxRjFyU2loOEJVNEdqcG0wZXhrczNqcVMxdS81TkZ2VnhVUnVBWWxxZVVwNW5oeUN4K1RFSzYvbEZwTjZLTmtVOXJUZndFRWJiSFV4RTVJUEhWWGlaV3gvZUV1TnBrc3d6d0k2K0FZY2Y5ZktWWVlRY0IvOXFxV3lJbGJsVm5Calg1bnhJM01EenBReGVjZnhsZ3BadkUwUXZDbVAyeE52eUE0NlFReHpvNEQ4cDYxNTdvdTlsWisvMFZCWmtqbzNCRmZ6QjZ3V1E1SXBORzJlTWdIWWliWVl2MXN0eDlJdU1iVFptR2Vid2pWUGVGK2FZME5LUWxVZ0FNK2lNcGM5VFdxcE8rak8vcGREZ2NTR3R2enJDVlpVdEM0REN2Z01kQnZvSjh6RXRkMWNxeHFFZzBjbTVKc1gya29helFDakJNaWsrcWkrTzl4RG5DNUFTRlBOZUNkc3QzdXN6Q2MyMnR3T3c1cTVnb0FZdE5IZkpjMDM0Z04vSkdxRDl6Qzg4OCtadGlXOXVKczVUSE94eVM0ZkppeGVKY1NYd2M3NGtUcDJjZThJOWp3QUtJcFBKWmtnRGNQMzdWVUFyWmxZUnVZWUp3bWdMNXNkY01WQW9MTm4vUW9vMENmOGFIZ01RMnlBcEV3UUFVSXc1WUcvWnEvVlkya1lzbHhhVEI1NzJYS0FPc0VZN1lVM3dRTjBKTnBJME5lckU3Mmw0UXI3Uk1aamRhVHR6ZzZjMEppSE45N0l1cDRaREowaklCL2g1WC9sRUtKWlQyTmRrdXJVRGw1TFFPQUhFYlhVVFFHY0p2S0NXcjZZZVBSN2t6dkltTVNqSFA1am1WOWl2OVdpWmtRUFdpVXpmaGRNeGRFSGJ3ejdleVR0QmpESlVBeFBtdndtQmc2aG1sempsTzNEZ2dBY1VCblZxNWIydFB5dHZzM2Q5UkVTd2IrMmgvbzN4V3NTYmpYM3JUWE9CWjd5T013VE5NL0ViQUw2cHkxTlJaQ3ZVcmxUdjROL1JoY0dtS2ZZR2pMOElwcDU4ZERadGNOWkJaZUdXbGl4UytvSHJMWU96RldtWlFJZStsRStWV1FJTTNROGpnS0poSVhkSjNGbHI2WXVYUlVDWHZzQktSbWF3Q3dKQ3FzSEpIbTRnV1NBLzJBVjQzYUc3blljVGUwSk9Za3lDdjgrV2VDZ25xWE0wTFMxVE45SkE4Z3hVM3hLTGlFdW1vUmZidWxKRi8rNzJCNmVlc3ErekpINGxkWHdMNXJuSlA1VHRtOXBCbG80VDJXM3krQ1hxbXNnZmZBSlBLdllCSVdSaXhlalFmWkxKUVdCTXA5UEhUbXpzQm16eTFyeFZpY3p3L0NVL1lCdkFRNTF6eS91ZEdOWjZIdmZDcTdQUmw0N2Uyc2lXaTE2R0QvNzRmejVtd0M1dHU0SE9CZVFCVllOVlZINUVraW9SM1lJS0RERmFaU2JsZFVSdzJUcWJucHFRcnJxVEd6WnZYZm9HYU5BQTg3d1VVZDRFblJuaXE5Vk15MzltTHhocXkrUGJ2R0RpU2pQa3VLU0Nadll6R3JOK0ptZ1laTDhPY1FjcXNrZTRNQXVLay9qYWJRQklQeXpmZU42U0xtdGo0ckttemNaeEdqNk1WeDJ1UDMxSW81VTB2aGJKVUFRNFJjbEx1QzlqTmFFaytKME45OWhDTkY2bStaRDNIanZQWi9QVjRKSDdKOVpQdElYMU0vU3NTeGNhVmhGcUUzL0RoQ0xvb21udzhkK3ZTRFlYOVY1SUNHcDJUWlg3eldJNEQrM1dmUlN0UnRmekM4dW1wVzR5SjlwTXJtYzRpMmNrWFNTb0haK1IveVc5TEJ0RDZBNnQzejF5TzAwWmRMN29HaEhEWFJnNFFFL3RkSzJlQldpWlJpbWVBdXl0cG45c094czBvTytEMUt3bFdRZTg1NnZYYnVybkY0ZTdFZ0UzNUVEZ2hMcU1kT3l3Qit4eXdTbnpsQUlUd2YwdkQ3bm1QUUdsTGJuRFpGYmQrYmZVRG1kRTRrdFFJMEt2ZEtGLzd2UVVERVRIenVUTnArUnZMaFgwZ1NRZWwyRnV0L2FRbDZodDJTZUtkYllWQ1hHZm80a2xpSFUxc3liUFZlRUEwZGhUQkF1N1NnajZFUXI2bC8rNUNRaCtKSTUzanI4b3NkM1VSSXlzN0l2ZUxZQ2hUT05UbHJ4V3h0aWVodUVCTngvU3N5MWpqaTZJZTFmM09jYnNZSXJTcVpGK2VvSXdwNaT2RTWEMvK0NNVXlKOXM4MTVrMzJLUzU0SkxwUG9PRTNSUTFkS0d6UTNlVEk1bGxhdmR4MXpyVTBEUmFpWk9WdjJjQUE4NldqWG0wSmdxSFYrWU1GdGlaOW5KVW5NanVhTUh5VlBjd3pQZVFiUmNrN0tsNFJMb2dCYjZOWG8zZ2FocWowQlVka3ZTdUxuNjlwdEp0Sm0yRU9rSGJQRTNQeHFIM3Azd0xQS0hUVmJXSW52UzhrK0QyNjRXSDdqbys5NDNTT3hmWTFJVWZ6WW9VUUl2bndvdW5NS1ZtS3NCNnlDU2p3UE1Sc25aMUVXOEUrL1JDQk96dzBuaFNuVUV0T1Y3bkxzcG50dEU3N2NNQktWMW9TaWROK2FxcmVGd3lEVzdMbW1IREpqNjdWSmkrYW85UGZDaWhJTFhoZFUzbXlIL015VmsydHI3Ni96UkwraDNSaUNQZ2Juc2xGSTlNTzZRZ2FSYnBNc0ZGbEFYS2o1VUxVMVNpNkRSS2x6MzZOYzRUNENsQnZKMmI1YTJqRGIrOXZqRHYrZjZIQXI5ajlVZTJEMHF5NGdWY2FsaHdHWW40eVlaMHFVM0llUmo2TnJaaEhrSko4dWlqUDdycjZBaC9wQ2NuV1RRMWd3Wk05Q3lWdnUyOW82REQ3bmNWUzRLRncrOVQ3M0srUjY1UlpNbExaTiszcTBDUFFBeFd2UnFmSXZ1Y3JOa0QzNHA3SVo5Njh5Qk9kZWd3UE1sUGVOZWtZSFBmalNYOXBjb2o5Mk9jN21USUMrV3k2dDVVaTRmV21XdHRsR01oY1pLUHRoYjhaazNVNmVnV3lyRHNnT2g4dlF0bGpsTVpjbFRpSE1zNDdVMWlUYlVUd0R2c1d1SFhQOEdTMmhZcGpWQWtkS05EeUtBYjJyeWVSdXo1OE5wY0FrM3ROVG9pZUJCcVZ0WmMzZkRFYm10dHY5SUZJZ3g2QXdZOC9Say90RUs3bzZZZUFudGNUcHlqUDJNRTRRcFlPZ2lobWxNVWt4UEp2enY5Q1lPaHFXQSswY1doYW92WWpObjBPdGhQUTJNNHo2aDh0L05xcWI3NkdVTzJsTWdUZG9nK0UxVGdUK2RneldaN2V2R2lPRm9MRkcvUW5JTzRkRUFuWFNpek5yYnZ0dFExNDdzaThUamV5SnROZjVIQ3dZNjJJQU9mOTRPSFp3cFl6cEd2V2Y1MDN2OEJHRTAxNmlPcWJqMzZKUDMwK1FORUVENTY5eWVHS0ZIQUtuN0hxNXoxR2RGN1o4VHJ2SHBkdVRDMGgvaWtSbnU1Lzg1NjZiSFZhVjB2V1RvM2V0b0kxa3J4a29ERWJaN2F2aytoa2RNc3VvT3k1NEZabFp2Q2NGZUhXd24zQ09waUdZYkJ6cGRoSHh2cVp4R2todkE4UlY4aXFwU052Y2F0L0tIOHFFVGV4TWI0bmJBelJ6WlJLSXFZcHhDSWpabVpnZnYvVVlVeXV5cHRKM1FjNUdDd3ZqZmVlL1R5dXFwZFlia3l1M1l1MnlZTFBOL0pyYkpyVDdiU2pDL201TTJJWmxiamtRRUVpZWt4QzQ4RE0yaWJYN1dVaDBPM0NzQktWMzVQaDkyeUVqWVF4a3JiTUdFS1lQV0N4TFlScy9ZM0E4SkppakF3Q0Y1VHJvclpMRmFSdjN6V3Y3MVY0V1hSQjhmZlBRVS9WVGdIS1dIYkJ4Z0FrZXVGLzU0MFdUMExwTWJXcndMU0NVRmg1RU01cHZrakVGZ0thZlhuZUQ1VEIrTWF3dj
          >>
          >>
EOF

Timeout::timeout(2) { EmailReplyParser.read(bad_text) }

uninitialized constant Api::V1::PostsController::EmailReplyParser

Hey guys! I am trying to use your gem with sendgrid's inbound email hook, and it errors in uninitialized constant Api::V1::PostsController::EmailReplyParser when I try to do:
post = Post.create(
...
body: EmailReplyParser.parse_reply(params['text']),
...
)

Thanks for any help!

Microsoft Outlook headers not being detected in replies

Although #54 seems to fix one type of Outlook email reply, one with a quoted body, I don't believe that the following example reply from an Outlook mail client is currently working:

Outlook email reply with a team mention in the email body.

From: CRM Comments [[email protected]]
Sent: Friday, 23 March 2012 5:08 p.m.
To: John S. Greene
Cc: Jane Q. Codes
Subject: Re: [@organization/team] Discussion about mail replies. (#1)

Should the team mention from the subject line be parsed in the comment?

> Here is quoted text.
>

I've pushed up a test via 33ccba0 that fails locally on the example fixture (pushed in 5163940).

In the example here, I believe only the following string should be returned:

Outlook email reply with a team mention in the email body.

iPad Mail

Does not parse iPad emails correctly.

iPhone

Is there a test for iPhone?

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

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.

Documentation link broken in readme

This link to the documentation in the readme appears to be broken:

https://help.github.com/code/email_reply_parser/

I found a copy of the documentation on rubydoc, perhaps we can link there instead?

http://rubydoc.info/gems/email_reply_parser/

(or more specifically http://rubydoc.info/gems/email_reply_parser/0.5.2 since 0.5.3 is still processing)

This needs a decent website

Man, so many apps are suffering from this issue. How about we make this a pretty website and get some more contributors onboard

Support for other languages?

Are there plans to support other languages in the On, wrote regex?

One of our collaborators responded with the following email:

Just saw that when it stays in the valve panel, and the next measurement is done, it updates. Just as Jim expected. 

Op 13 jan. 2015 om 17:02 heeft "Jim Graham" <[email protected]<mailto:[email protected]>> het volgende geschreven: 

[previous comment]

— 
Reply to this email directly or view it on GitHub<https://github.com/Capilix/Capella/issues/117>.

Although this email is in English, his email client is configured in Dutch, so it wrote Op 13 jan. 2015 om 17:02 heeft "Jim Graham"

Doesn't strip previous comment when topposting

See: https://github.com/jmoeller/itugameengine/commit/49b7cefb96b2372a7ab273a0dab25df4f436db30

Comments 3 and 4 were written via Gmail, and as you can see, the quoted text isn't removed.

If emal body content > at the beginning of the line lib ignored the line

Hi,

keep in mind 😂
This is a test reply from Google Inbox.

On Wed, May 25, 2016 at 3:13 PM [email protected] wrote:

LGTM

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

--
This is signature, but it is not detected.

While if I reply to any github email and add > within the reply it dos not ignore the line.