stg mail
- From
Karl Hasselström <kha@treskal.com>
- Date
- Oct 26, 2006, 14:06 UTC
- Message-ID
- <20061026140615.GA19268@diana.vm.bytemark.co.uk>
- In-Reply-To
- <b0943d9e0610260457m780dd7d4t95fe36130cbdf551@mail.gmail.com>
On 2006-10-26 12:57:50 +0100, Catalin Marinas wrote:
Show 8 quoted lines
> On 26/10/06, Karl Hasselström <kha@treskal.com> wrote: > > > Hmm. So now I know why you haven't taken my "stg email" patches. I > > guess I'll have to fix 'stg import' then. :-) > > That's one of the reasons (and I didn't have time to document myself > before giving a proper reply). The other is that Gnus (and gmail) > doesn't display the messages properly - it shows a lot of "=20".
Hmm, this sounds like a mistake in my code, since one would expect those two to be able to handle QP-encoded bodies properly. In fact, if they didn't, all mails from me would look like that to you, since mutt seems to QP-encode mails that I send.
I only viewed the mails in mutt, and they looked fine there.
> Is it possible not to affect the body (or make it optional)?
The vger mail server breaks 8bit encoded mails (which was what stg mail generated previously), at least if they don't stick to ascii. So if the body contains non-ascii stuff (such as my name in the sign-off line), we do need the encoding. I could certainly do the QP-encoding conditionally on there being non-ascii characters, though, and use 7bit or whatever it's called otherwise.
> People only using "patch" to apply the diffs would have problems > with this encoding.
People feeding the raw email to patch would have this problem, yes. But with the "8bit" encoding not working on all mail servers, there is no way around this for non-ascii patches. But as I said, we certainly could avoid QP-encoding pure ascii patches.
-- Karl Hasselström, kha@treskal.com