#<buffer *nntpd*> and split-fancy-:-unparseable base64-encoded header.

#<buffer *nntpd*> and split-fancy-:-unparseable base64-encoded header.

[Garreau, Alexandre]

I am unsure if this is an appropriate and well-descriptive subject for
this issue, please point it out to me otherwise.

I am currently splitting my mail with nnmail-split-fancy’s :, according
list-id content, and recently I noticed I got a lot of mail in garbage
directories named with long base64 strings: I then experimentally
noticed the buffer nnmail-split-fancy’s : acts on is still
base-64-encoded for utf-8 content.  However some mailing-list of online
(but graded) course of my college must have something wrong because
since the description of its list-id is in utf-8, the list-id itself is
too!

List-Id: =?utf-8?B?IkZvcnVtIFDDqWRhZ29naXF1ZSIgPG1vb2RsZWZvcnVtMjUvbW9vZGxlQG0=?= =?utf-8?B?b29kbGV1Ym8udW5pdi1icmVzdC5mcj4=?=

And what I normally read is:

List-Id: "Forum Pédagogique" <moodleforum25/moodle@moodleubo.univ-brest.fr>

So the thing between angle-brackets is readable in normal message-mode
but not by :…

How to make that readable? why doesn’t nnmail-split-fancy acts on a
decoded buffer? I need this to correctly receive and track that mail :/

PS: I maybe posted this also on ding@gnus, I was unsure of which mailing-list
was was appropriated, now I think I realized I was unsubscribed from it
and there are no online archive I guess…

Re: #<buffer *nntpd*> and split-fancy-:-unparseable base64-encoded header.

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

Alexandre Garreau [2018-09-23 02:04:44+02] wrote:

> How to make that readable? why doesn’t nnmail-split-fancy acts on a
> decoded buffer? I need this to correctly receive and track that mail
> :/

There is variable nnmail-mail-splitting-decodes which, with a non-nil
value, should cause the splitting mechanism to decode headers before
splitting.

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: #<buffer *nntpd*> and split-fancy-:-unparseable base64-encoded header.

[Garreau, Alexandre]

Le 23/09/2018 à 09h05, Teemu Likonen a écrit :
> Alexandre Garreau [2018-09-23 02:04:44+02] wrote:
>
>> How to make that readable? why doesn’t nnmail-split-fancy acts on a
>> decoded buffer? I need this to correctly receive and track that mail
>> :/
>
> There is variable nnmail-mail-splitting-decodes which, with a non-nil
> value, should cause the splitting mechanism to decode headers before
> splitting.

Thank you very much! it works excellently!

Why isn’t this behavior the default? is there any advantage to parse the
yet-encoded content (maybe its encoding?) or still big issue by decoding
before rather than after?

Re: #<buffer *nntpd*> and split-fancy-:-unparseable base64-encoded header.

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

Alexandre Garreau [2018-09-23 10:57:57+02] wrote:

> Le 23/09/2018 à 09h05, Teemu Likonen a écrit :
>> There is variable nnmail-mail-splitting-decodes which, [...]

> Why isn’t this behavior the default? is there any advantage to parse
> the yet-encoded content (maybe its encoding?) or still big issue by
> decoding before rather than after?

I don't know but I certainly think that non-nil would be better default
for nnmail-mail-splitting-decodes. Encoded headers are the norm (MIME)
and only decoded headers are meaningful for people and mail splitting.
The receiver can't control whether the headers come in encoded or plain
format.

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: #<buffer *nntpd*> and split-fancy-:-unparseable base64-encoded header.

[Andreas Schwab]

On Sep 23 2018, "Garreau, Alexandre" <galex-713@galex-713.eu> wrote:

> Why isn’t this behavior the default?

My guess would be that it was too slow.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

May t be the default for nnmail-mail-splitting-decodes in Emacs? (Was: Re: #<buffer *nntpd*> and split-fancy-:-unparseable base64-encoded header)

[Garreau, Alexandre]

On 2018-09-23 at 13:56, Teemu Likonen wrote:
> Alexandre Garreau [2018-09-23 10:57:57+02] wrote:
>> Why isn’t this behavior the default? is there any advantage to parse
>> the yet-encoded content (maybe its encoding?) or still big issue by
>> decoding before rather than after?
>
> I don't know but I certainly think that non-nil would be better default
> for nnmail-mail-splitting-decodes. Encoded headers are the norm (MIME)
> and only decoded headers are meaningful for people and mail splitting.
> The receiver can't control whether the headers come in encoded or plain
> format.

May it be t by default in next release then? have any maintainer saw
this to give their mind?

It’d be fantastic to see once more my config shrinking because of better
defaults!

Re: #<buffer *nntpd*> and split-fancy-:-unparseable base64-encoded header.

[Garreau, Alexandre]

Le 23/09/2018 à 13h36, Andreas Schwab a écrit :
> On Sep 23 2018, "Garreau, Alexandre" <galex-713@galex-713.eu> wrote:
>
>> Why isn’t this behavior the default?
>
> My guess would be that it was too slow.

than now? did it change?

Here I’m receiving (and splitting) some thousands of mail per day (most
of it lists, newsletters, and spam, all using list-id (yes even spam))
and it’s fine.

If that’s really an issue, since the buffer must be decoded anyway at
some time… cannot emacs store it decoded at worse? with some
emacs-specific way of specifying encoding (maybe utf-8 by default? in
file? per config?

I mean, it was pointed indeed having it to nil by default seems to imply
incorrect behavior since headers may be encoded anyway and I hardly see
a case where encoding is more important than encoded content (why not
still, but…) and since we’re in the case of a generalistic function… or
is the user supposed to find the function for decoding the headers she’s
interested in and decode it manually before parsing it?

Re: #<buffer *nntpd*> and split-fancy-:-unparseable base64-encoded header.

[Andreas Schwab]

On Sep 23 2018, "Garreau, Alexandre" <galex-713@galex-713.eu> wrote:

> Le 23/09/2018 à 13h36, Andreas Schwab a écrit :
>> On Sep 23 2018, "Garreau, Alexandre" <galex-713@galex-713.eu> wrote:
>>
>>> Why isn’t this behavior the default?
>>
>> My guess would be that it was too slow.
>
> than now? did it change?

It changed when the option was introduced (back in 2002).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Why nnmail-mail-splitting-decodes defaults to nil (Was: Re: #<buffer *nntpd*> and split-fancy-:-unparseable base64-encoded header)

[Garreau, Alexandre]

On 2018-09-23 at 13:50, Andreas Schwab wrote:
> On Sep 23 2018, "Garreau, Alexandre" <galex-713@galex-713.eu> wrote:
>> Le 23/09/2018 à 13h36, Andreas Schwab a écrit :
>>> My guess would be that it was too slow.
>>
>> than now? did it change?
>
> It changed when the option was introduced (back in 2002).

Why with this default then? to test it?

Re: Why nnmail-mail-splitting-decodes defaults to nil

[Eric Abrahamsen]

"Garreau, Alexandre" <galex-713@galex-713.eu> writes:

> On 2018-09-23 at 13:50, Andreas Schwab wrote:
>> On Sep 23 2018, "Garreau, Alexandre" <galex-713@galex-713.eu> wrote:
>>> Le 23/09/2018 à 13h36, Andreas Schwab a écrit :
>>>> My guess would be that it was too slow.
>>>
>>> than now? did it change?
>>
>> It changed when the option was introduced (back in 2002).
>
> Why with this default then? to test it?

Out of caution, most likely. Perhaps unwarranted caution, but certainly
caution.