Email Reply Parser: pulling the new text out of a plain text reply

The problem: a reply is a new message plus a quoted history

An email reply arrives as a single blob of text. At the top is what the sender just wrote. Below it is the previous exchange, quoted line by line, usually with a header such as On some date, some author wrote, and often a trailing signature block. Any application that wants to store that reply as a comment, a ticket update or a timeline entry has to cut that blob at the right place, and the naive approach of splitting on the quote marker fails on ordinary mail. That is the job EmailReplyParser does. The README describes it as a small library to parse plain text email content, and the project description is shorter still. What matters for an adopter is the provenance: this is what GitHub uses to display comments that were created from email replies, and the README says the code is open sourced in an effort to crowdsource the quality of their email representation. So the library is a small piece of GitHub's own commenting pipeline, published as a gem.

One method does the work

The usage section of the README is a single line, and the whole public surface is correspondingly small. You hand the plain text body to a class method and get back the parsed body, with the call written as parsed_body = EmailReplyParser.parse_reply(email_body). The README points you at the rocco-documented source code for specifics on how it works, and the Ruby docs at rubydoc.info for the API reference. That is an unusual amount of reliance on generated documentation for such a small library, and it reflects how the code was written: the behaviour is described in comments and generated docs rather than in prose tutorials. The repository layout is consistent with that. There is a lib/ directory for the implementation, a test/ directory, a Rakefile, a gemspec, script/ and a .travis.yml for continuous integration. The primary language is Ruby and the licence is MIT, with a LICENSE file in the tree.

Installing the gem and running its tests

Installation is a single gem command, or a clone from the repository if you want to work on the source. The tests are driven by Rake, and the README names the command to run them.

gem install email_reply_parser

rake

For contributors the README gives a full sequence: fork the repository, clone the fork, create a thoughtfully named topic branch, make the change, add tests, and confirm everything still passes by running rake. Two rules in that list are worth internalising if you plan to send a pull request. If you add new functionality, document it in the README, and do not change the version number, because the maintainer handles that on their end. Commits should be rebased into logical chunks without errors before the branch is pushed and a pull request is opened against the github/email_reply_parser project.

Known issue one: quoted headers broken across lines

The first documented limitation is the one that catches most people. Quoted headers are not picked up if the email client breaks the header up into multiple lines, and the README says GMail breaks up any lines over 80 characters for you. The pattern the library looks for is a header of the form On a date, an author wrote, followed by quoted content. When the client wraps that header, the pattern no longer matches, and the parser treats the quoted part as if it were part of the new message. The README is direct about the cause of the fragility: the library is searching for the words on and wrote, so it will not work with other languages. It also floats a possible fix, removing lines addressed to [email protected], but presents it as an idea rather than as something the library does. Any adoption plan has to account for this, because a mail client that wraps at 80 columns will defeat the header detection.

Known issue two: signatures that look like quotes

The second documented limitation concerns signature blocks. Lines starting with a dash or a low line character sometimes mark the beginning of a signature, and the library treats them that way, which is correct for the common convention where a name follows the marker on the next line. The problem is that not everyone follows that convention, and the README shows the case where a plain name and title sit above a banner of asterisks and a disclaimer, with no dash or low line marker at all. In that case the signature text is not separated from the message body. Neither failure is a bug in the usual sense, both are consequences of a text format that carries no explicit structure. The library is doing line-oriented pattern matching on convention, so a sender who breaks convention is not detected. The practical consequence for an adopter is that the returned body may still contain a signature block, and your application should not assume the result is a perfectly clean message.

Why a small library was open sourced

The README explains the motivation in a paragraph that is worth reading as a design constraint. This is what GitHub uses to display comments created from email replies, and the code is being open sourced in an effort to crowdsource the quality of their email representation. That framing tells you what kind of library this is. It is not a general purpose email parsing framework and it does not try to be one. There is no MIME handling, no attachment logic, no HTML to text conversion and no address parsing. The input is plain text, and the output is the part of that text considered to be the new reply. Any project that needs to parse an email envelope, decode quoted-printable bodies or walk a message tree needs a different tool entirely, and would use this library for one step only.

Maintenance state and the age of the tags

The repository is not archived, and the last push was on 2026-09-18, so the code has moved within the last month. The published tags tell a different, slower story: v0.5.11 from 2023-05-16, v0.5.8 from 2014-08-25 and v0.5.7 from 2014-05-30. The gap between those dates and the recent push suggests the work is maintenance rather than new feature development, which fits a library whose job does not change. A version numbering note applies: the library has stayed on the 0.x series, so by the usual Ruby convention the public API is not promised to be stable across minor versions. The .travis.yml in the tree is the visible remnant of the older continuous integration setup, and the release tags are not versioned in lockstep with the commit history, so anyone pinning this dependency should pin a tag rather than track master.

Editorial conclusion

Adopt EmailReplyParser if you need to turn email replies into clean comments or records and you already have the plain text body, since it is a single method call with no configuration and it is the same code path GitHub uses. Do not adopt it for HTML only mail, for replies in languages other than English, or for mail clients that wrap long quote headers across several lines, because the README names those as known failure cases. Before you ship it, test it against the actual mail clients your users use, check whether quoted headers survive their wrapping, and decide how you will handle the signature convention that a line beginning with a dash or a low line introduces.

Frequently asked questions

Official sources

1. github/email_reply_parser on GitHub
2. Issues
3. License: MIT
4. README
5. Releases