I receive quite a lot of emails with blockquoted text which is in fact the whole original email that's being replied to.

Quickly looking at the source of this package, I don't think <blockquote> is being search for. Imho this should be a non-visible part.

What do you think?

Hey. i noticed that the parser "cleans" the text from new lines.

This is problematic since it modifies the input.

For example if you want to print the output to html nl2br will not work. This is a huge problem.

Compare the fragment extracted:

"2015-06-18 10:40 GMT+02:00 REDACTED : > Bounce! > > 2015-06-18 10:06 Cristobal Wetzig : >> > > >> > >> > Reply >> 2015-06-18 10:38 GMT+02:00 REDACTED : >> >> ok >> 2015-06-18 10:06 Centerpartiet :\n>>> Reply"

From the original

"Pong\r\n\r\n2015-06-18 10:40 GMT+02:00 REDACTED :\r\n> Bounce!\r\n>\r\n> 2015-06-18 10:06 Cristobal Wetzig :\r\n>> > >\r\n>> >\r\n>> > Reply\r\n>> 2015-06-18 10:38 GMT+02:00 REDACTED :\r\n>>\r\n>> ok\r\n>> 2015-06-18 10:06 REDACTED :\r\n>>> Reply"

Hi, I was attempting to commit the EmailReplyParser library in Git when I got the following error:

You are about to commit CRLF line separators to the Git repository. It is recommended to set the core.autocrlf Git attribute to input and and avoid line separator issues.

I've done a bit of a Google and I can't find any conclusive advice.

Based on the limited understanding of email that I have, formatting and line endings are crucial, so I'd rather not proceed without some guidance first.

I just found some real world scenario where this lib fails to preserve formatting. Basically the problem is where we have a whole email thread as a content. All new lines are replaced with one space here. I made in commit https://github.com/perajovic/EmailReplyParser/commit/79aebccd4dac497066b5a151dc19906b9b2025c6 failing test with an example. Here is also a diff from test:

1) EmailReplyParser\Tests\Parser\EmailParserTest::testEmailThreadPreservesNewLines
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'On Nov 21, 2014, at 10:18, John Doe <[email protected]> wrote:
-
-> Ok. Thanks.
->
-> On Nov 21, 2014, at 9:26, Jim Beam <[email protected]> wrote:
->
->>> On Nov 20, 2014, at 11:03 AM, John Doe <[email protected]> wrote:
+'On Nov 21, 2014, at 10:18, John Doe <[email protected]> wrote:  > Ok. Thanks. > > On Nov 21, 2014, at 9:26, Jim Beam <[email protected]> wrote: > >>> On Nov 20, 2014, at 11:03 AM, John Doe <[email protected]> wrote:
 >>>
 >>> if you take a look at a short video from attachment, why full-typed filename does not stay in CMD+T pane?
 >>> When I type last character, it is not shown anymore.
 >>
 >> We think we’ve tracked down the cause of this issue, write back if you see the issue after the next update. (Which will be out shortly.)
 >>
 >> --
 >> Jim Beam – Acme Corp
 >>
 >'

I'm aware that with this line we can normalize some poorly formatted emails, but here this is not the case.

I hope I can fix this issue later today, but if someone have any idea how to do this right now, please write a comment.

Hello,

I just got a bug on EmailReplyParser::parseReply. In some specific case, the reply is truncated in the middle.

I tried to reduce at maximum a case, here it is :

Bonjour ​Test​,

​Text paragraph 1​


Le paragraphe qui pose problème.

​Text paragraph 2​


- Le 2021-04-09 23:25, ​Test a écrit :

The correct result should be :

Bonjour ​Test​,

​Text paragraph 1​


Le paragraphe qui pose problème.

​Text paragraph 2​

The current result is :

Bonjour ​Test​,

        ​Text paragraph 1​

Context :

• This is french. If I remove the first "Le" : problem solved. If I remove "écrit" : problem solved.
• Le paragraphe qui pose problème means The paragraph which provoke issue.
• Le 2021-04-09 23:25, ​Test a écrit : means On 2021-04-09 23:25, ​Test wrote :

So the issue is here :

'/^\s*(Le(?:(?!^>*\s*Le\b|\bécrit:).){0,1000}écrit(\s|\xc2\xa0):)$/ms', // Le DATE, NAME <EMAIL> a écrit :

If I change it to have the same format as the english work : problem half solved (not truncated).

'/^\s*(Le(?:(?!^>*\s*Le\b|\bécrit:).){0,1000}écrit:)$/ms', // Le DATE, NAME <EMAIL> a écrit :

But I think that (\s|\xc2\xa0) was here for some reason ? @Spone ?

see also : https://github.com/willdurand/EmailReplyParser/commit/e888d795f277916ec62c2e812b9a10a9614682e8#diff-5e5f4da6cc02b271ae11752a0b5e45ecb842d913728f7b7d9756d88d9219a0f8 https://github.com/willdurand/EmailReplyParser/commit/b71d9983c07b0455cb5b9727b90642a32bc11ae0#diff-5e5f4da6cc02b271ae11752a0b5e45ecb842d913728f7b7d9756d88d9219a0f8

1. composer install --dev is the default for some time now and the --dev flag is deprecated.
2. Composer 1.0.0-alpha.9 comes with an important update to composer require. When you don't specify a version, Composer would automatically choose the latest stable version according to SemVer.

With this pull request we don't need to duplicate our custom quote regex by have to write it backward.. Regular expression is already annoying as it is. =x

Let me know if you see any problem. =]

This fixes #77

The rule is more permissive for prefixes, however more strict and secure as I disabled the s modifier which allowed multiline for some reason.

Important Note : I only fixed FR. I prepared (commented) a failing test for EN, which failed. But if I do the same change for EN regexp, other tests are failing and I don't want to mess up things, so I'll let you have a look at this.

Catches signature and quotes for Windows 10 Mail.

I've probably made this too generalized, but I needed to catch signature and quotes coming from Mail for Windows 10. They look like this...

My reply here.

Sent from Mail for Windows 10

From: John Doe
Sent: Tuesday, November 13, 2018 12:30 PM
To: [email protected]
Cc: [email protected]
Subject: Subject Line Here

The quoted message.

Unfortunately, the existing regex's miss both the signature and the quote. The signature is missed because it lacks a "my" after "Sent from", so I just went ahead and removed the "my" requirement. The quote is missed because the "From:" line only includes a name and lacks an email address in brackets. I loosened it up to only bother checking for a line beginning with "From:".

This is probably related to Issue #66. I haven't run the unit tests, and I'm pretty sure these fixes loosen things up too much, so not exactly suggesting this be merged in as-is. Hoping someone better at regex's comes up with a more proper fix, honestly :)

Hello,

I write a additionnal regex because a mail does not be good parsed. This is a yahoo mail in French with space before HeaderQuoted and between keyword (here De) and colon ( : )

I had a test from the email received which don't work. I have of course anonymized the data in.

Thanks for your Lib, It's very useful. I wait for your reviews if needed

more understandable if you need to debug something

mentioned here: https://github.com/willdurand/EmailReplyParser/pull/42#issuecomment-184572081

ps: tests pass!

In this PR:

1. Use an array of signature regexes instead of a single one. This is similar to how it works for quote headers.
2. Added the Dutch "sent from my iPhone" signature.

Breaking changes:

1. setQuoteHeadersRegex and getQuoteHeadersRegex use arrays instead of strings. Applications using these methods must be updated.

Related to https://github.com/willdurand/EmailReplyParser/issues/69 but I went in a different direction.

I'm trying to send email from my server and then get a reply, in reply email when I get fragments there is always isHidden and isSignature as true.

Doese somebody has idea what could be wrong? I assume in my HTML code is something wrong. How should I form my HTML content?

Hello again,

While working and searching in the Parser/EmailParser.php file, I thought about something:

Instead of having things like

private $quoteHeadersRegex = array(
    '/^.{0,5}(On(?:(?!\bOn\b|\bwrote(\s|\xc2\xa0)?:).){0,1000}wrote(\s|\xc2\xa0)?:)$/ms', // On DATE, NAME <EMAIL> wrote:
    '/^.{0,5}(Le\b(?:(?!\bLe\b|\bécrit(\s|\xc2\xa0)?:).){0,1000}écrit(\s|\xc2\xa0)?:)$/ms', // Le DATE, NAME <EMAIL> a écrit :
    '/^.{0,5}(El(?:(?!\bEl\b|\bescribió\s?:).){0,1000}escribió\s?:)$/ms', // El DATE, NAME <EMAIL> escribió:
    '/^.{0,5}(El(?:(?!\bEl\b|\bha escrit\s?:).){0,1000}ha escrit\s?:)$/ms', // El DATE, NAME <EMAIL> ha escrit:
    '/^.{0,5}(Il(?:(?!\bIl\b|\bscritto(\s|\xc2\xa0)?:).){0,1000}scritto(\s|\xc2\xa0)?:)$/ms', // Il DATE, NAME <EMAIL> ha scritto:
    [...]
    '/^\s*(From\s?:.+\s?(\[|<).+(\]|>))/mu', // "From: NAME <EMAIL>" OR "From : NAME <EMAIL>" OR "From : NAME<EMAIL>"(With support whitespace before start and before <)
    '/^\s*(发件人\s?:.+\s?(\[|<).+(\]|>))/mu', // "发件人: NAME <EMAIL>" OR "发件人 : NAME <EMAIL>" OR "发件人 : NAME<EMAIL>"(With support whitespace before start and before <)
    '/^\s*(De\s?:.+\s?(\[|<).+(\]|>))/mu', // "De: NAME <EMAIL>" OR "De : NAME <EMAIL>" OR "De : NAME<EMAIL>"  (With support whitespace before start and before <)
    '/^\s*(Van\s?:.+\s?(\[|<).+(\]|>))/mu', // "Van: NAME <EMAIL>" OR "Van : NAME <EMAIL>" OR "Van : NAME<EMAIL>"  (With support whitespace before start and before <)
    '/^\s*(Da\s?:.+\s?(\[|<).+(\]|>))/mu', // "Da: NAME <EMAIL>" OR "Da : NAME <EMAIL>" OR "Da : NAME<EMAIL>"  (With support whitespace before start and before <)
    [...]
);

couldn't we have only one variabilized line for each "type" of reply like that (of course it's only a draft):

private $quoteHeadersRegex = array(
    '/^.{0,5}($on(?:(?!\b$on\b|\b$wrote(\s|\xc2\xa0)?:).){0,1000}$wrote(\s|\xc2\xa0)?:)$/ms', // On DATE, NAME <EMAIL> wrote:
    [...]
    '/^\s*($from\s?:.+\s?(\[|<).+(\]|>))/mu', // "From: NAME <EMAIL>" OR "From : NAME <EMAIL>" OR "From : NAME<EMAIL>"(With support whitespace before start and before <)
    [...]
);

Then we would run these Regex checks using a list of language files, so for example $wrote would be checked with "wrote", then "a écrit", then "escribió", ...

Here are the advantages I see in that modification:

• Adding a new language or variation is easier
• You don't have to duplicate X times the same Regex, modifying one or two words each time
• You're less likely to make a mistake in a Regex

That was my two cents, thanks for reading 😉

Hello there !

While using a Mantis BT plugin which is using your awesome lib, I noticed the that the <EMAIL> is no longer present, and From : is prefixed with **, that's why I modified the according regex.

Outlook O365 replies are formatted as follows:

* * *

**From :** Firstname LASTNAME 

**Sent :** mardi 3 août 2021 18:41

**To :** Firstname LASTNAME ; Firstname LASTNAME 

**Object :** RE: Nouveau ticket par mail [0000051] 

I still have some questions to improve this PR

• Should I include * * * and the line-breaks to the regex (making them optional probably) ?
• Should I check for ** after the From : ? (adding a second [\*]{0,2})
• Should I replace [\*]{0,2} with [\*]* ? (So if Microsoft or another mailer decides to use more than two * it'll be handled)

I didn't modified or ran the tests yet.

Thanks in advance for your reviews !

I'm not sure what is classed as a 'signature' from the point of view of this module. I'm assuming, based on my testing, that it expects at least a single dash or underscore underneath the email content? My company emails do not include this, but have my name, job role and then some 'small print' about the confidentiality.

Basically, I'm assuming that if there's no visible separator between email content and signature, the whole this is classed as 'visible content' ?

@willdurand I would like to add "Sent via the", "Sent from the", and "Sent from" to the signature Regex. These are standard Android/Galaxy signatures.

/(?:^\s*--|^\s*__|^-\w|^-- $)|(?:^Sent (from|via) (my|the )?(?:\s*\w+){1,4}$)|(?:^={30,}$)$/s

Is this acceptable?