Looks good to me, but I'm new to the library, so I would want either another opinion or to look at the RFCs before merging.

@bf4, RFC-2822 would support the change that kjg made. Depending on how the library splits up the original (raw) message header, the Regex would use either a start of string (\A) or a start of line (^). With proper unfolding of the header lines, the best option would be a start of string (\A) as kjg has committed.

Please refer to RFC-2822 section 2.2 for the information that would be pertinent to the change being requested (https://www.ietf.org/rfc/rfc2822.txt).

cc @jeremy @mikel @grosser @jeremyevans

I agree that the current behavior (stripping anywhere in the string) is wrong and the proposed behavior (only stripping at the start of the string) is better.

@bf4 @jeremy I just rebased this to remove the conflict in the README, it sounds like this is ready to be merged now. Thanks!

this still strips Subject: Subject: Foobar-> I think a better fix is doing less work / dirty hacks -> #766

@grosser I fully support #766 as a long term solution, but it sounds like it needs more work to address the API change by adding deprecation and what not. This is at least an improvement over what's currently released and it's ready to go today and has support from others.

Is there anything I can do to help you get #766 into a state that the project will accept?

I so far did not see anything breaking from this 'api change', I don't
expect anyone to use this afaik internal apis.
I'm fine with merging this, just sad that this is doing a shady change to
avoid solving the real problem :(

On Thu, May 14, 2015 at 10:28 AM, Kevin Glowacz notifications@github.com
wrote:

@grosser https://github.com/grosser I fully support #766
#766 as a long term solution, but it
sounds like it needs more work to address the API change by adding
deprecation and what not. This is at least an improvement over what's
currently released and it's ready to go today and has support from others.

Is there anything I can do to help you get #766
#766 into a state that the project
will accept?

—
Reply to this email directly or view it on GitHub
#719 (comment).

What is shady about this change?

It's still doing the wrong thing, just being more elaborate about it :D

I'm not sure what's more elaborate about only matching at the beginning of the string, but I'm in full support of #766. Unfortunately it does seem like they are willing to accept #766 as is. If you'd like help getting it to a place that the maintainers are willing to accept, i'm very willing to help out.

This change at least makes the behavior more correct that it was before, and it's a pretty simple change to merge.

Agreed, this is better than before and should not break anything.
No idea what is missing in 766 though ...

On Thu, May 14, 2015 at 11:55 AM, Kevin Glowacz notifications@github.com
wrote:

I'm not sure what's more elaborate about only matching at the beginning of
the string, but I'm in full support of #766
#766. Unfortunately it does seem like
they are willing to accept #766 #766
as is. If you'd like help getting it to a place that the maintainers are
willing to accept, i'm very willing to help out.

This change at least makes the behavior more correct that it was before,
and it's a pretty simple change to merge.

—
Reply to this email directly or view it on GitHub
#719 (comment).