Fixes for the rewritefrom functionality

[keithbare2]

Closes #12

Gmail has been rejecting some of the messages sent to ezmlm-idx mailing lists I help run. Eventually I determined it was due to the outgoing messages having two different Cc headers: one from the original poster and then a second with the poster's address, the latter having been added by the rewritefrom logic (we use replytolist). I saw that issue #12 mentions the same problem happening with Reply-To headers.

We had not noticed the issue with encoded words that is perhaps the main complaint in issue #12. (We tend to all be Americans with 7-bit ASCII names.)

In any case, the duplicated headers problem is causing us a lot of trouble. Essentially we lose messages whenever somebody tries to use reply-all to messages sent on our lists. So I've implemented a fix. And since it was in the same GitHub issue, I also took a swing at maintaining encoded words in the author name of the rewritten From header.

[keithbare2]

The primary purpose of the update was to resolve an issue in my original changes that arose for MIME messages with a multipart Content-Type. In that case, flagbadpart would get set on the header -> body transition, and inhibit output of the line containing the rewritten From and new Reply-To/Cc headers. To resolve, the actual line content is output when flagbadpart is set, rather than assuming only a "\n" is required.

[raboof]

This looks great, thanks so much for working on this! We're also running into the duplicate Reply-To/Cc issue, and at first glance c179dfd looks like a reasonable solution.

Perhaps it should be its own PR, to make it more self-contained and likely to get merged?

[keithbare2]

This looks great, thanks so much for working on this! We're also running into the duplicate Reply-To/Cc issue

You're welcome. Starting in March 2023, I've been running several cmucc mailing lists with the changes I posted here and haven't noticed any problems.

In preparation for Google's sender requirements going into effect, I wanted to switch everything to use rewritefrom unconditionally. I found myself rebuilding ezmlm-idx and was reminded that I faced a few problems building and installing code based on the master branch here. I collected my fixes for those problems and posted them in #22. I figure that might help if you or anybody else wants to build and run with changes from this PR.

[A]t first glance c179dfd looks like a reasonable solution.

Perhaps it should be its own PR, to make it more self-contained and likely to get merged?

The only problem with using that commit on its own is that the tests I wrote have a dependency on the way 3bf20d9 changed the quoting of the From header's display name. Should be straightforward to resolve though.

I haven't heard anything from the owner or anybody else that could merge a PR. I certainly could create a new PR with just the duplicate header fix if they ask.