content-transfer-encoding: base64

Hi,

I regularly get traffic form a bugzilla in the following form:

Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: base64
<other headers>

aHR0cDovL2J1Z3MuZnJlZWRlc2t0b3Aub3JnL3Nob3dfYnVnLmNnaT9pZD0xNDY4NwoKCk1hcnRp
bi3DiXJpYyBSYWNpbmUgPHEtZnVua0Bpa2kuZmk+IGNoYW5nZWQ6CgogICAgICAgICAgIFdoYXQg
ICAgfFJlbW92ZWQgICAgICAgICAgICAgICAgICAgICB8QWRkZWQKLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQogICAgICAgICAgQ29tcG9uZW50fERyaXZlci9BTUQgICAgICAgICAgICAgICAgICB8RHJpdmVy
L3JhZGVvbmhkCgoKCgotLSAKQ29uZmlndXJlIGJ1Z21haWw6IGh0dHA6Ly9idWdzLmZyZWVkZXNr
dG9wLm9yZy91c2VycHJlZnMuY2dpP3RhYj1lbWFpbAotLS0tLS0tIFlvdSBhcmUgcmVjZWl2aW5n
IHRoaXMgbWFpbCBiZWNhdXNlOiAtLS0tLS0tCllvdSBhcmUgdGhlIFFBIGNvbnRhY3QgZm9yIHRo
ZSBidWcuCllvdSBhcmUgdGhlIGFzc2lnbmVlIGZvciB0aGUgYnVnLgpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwp4b3JnLXRlYW0gbWFpbGluZyBsaXN0Cnhv
cmctdGVhbUBsaXN0cy54Lm9yZwpodHRwOi8vbGlzdHMueC5vcmcvbWFpbG1hbi9saXN0aW5mby94
b3JnLXRlYW0K
--

-- 
To unsubscribe, e-mail: radeonhd+unsubscribe <at> opensuse.org
For additional commands, e-mail: radeonhd+help <at> opensuse.org

show erros out with:

(Message lists/radeonhd:646)
mhshow: invalid BASE64 encoding -- continuing
        (content text/plain in message 646)

Re: content-transfer-encoding: base64

Anders Eriksson <aeriksson <at> fastmail.fm> wrote on Mar 8, 2008:

>I regularly get traffic form a bugzilla in the following form:

(a bunch of lines deleted here)

>b3JnLXRlYW0K
--

-- 
>To unsubscribe, e-mail: radeonhd+unsubscribe <at> opensuse.org
>For additional commands, e-mail: radeonhd+help <at> opensuse.org

The problem is that the "unsubscribe" footer has been appended to the
base64 data.  Whoever added that footer should have done it as a
separate attachment.

 -NWR

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

Re: content-transfer-encoding: base64

On Sat, 08 Mar 2008 11:31:22 +0100, Anders Eriksson said:

> Content-type: text/plain; charset="utf-8"
> Content-transfer-encoding: base64
> <other headers>

> Seems familiar? Is cte:base64 legal, or is nmh missing something? Judging from 
> the bugzilla list, others can read the messages fine.

It's legal.  I started chasing a similar bug in exmh, which I tracked down to
the fact that some encoders leave a trailing blank  on the last line.  I didn't
get as far as figuring out if the error was in exmh's tcl code, or down in nhm.

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

problem with long field names

This is cut-and-pasted from 
https://bugzilla.redhat.com/show_bug.cgi?id=437652

Description of problem:
Recently (in the last month or so), linkedin.com has started sending very long From fields.  As a result,
pick fails with messages like this:

pick: field name "From
notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0xnV-CG_gSQxxjCdsSEs56P_1MmEv5E0PNMxxjQFo <at> bounce.linkedin.com
 Mon Mar " exceeds 127 bytes
pick: format error in message 169

Here's the start of the message:

From
notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0xnV-CG_gSQxxjCdsSEs56P_1MmEv5E0PNMxxjQFo <at> bounce.linkedin.com
 Mon Mar  3 02:03:01 2008
Return-Path: <notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0xnV-CG_gSQxxjCdsSEs56P_1MmEv5E0PNMxxjQFo <at> bounce.linkedin.com>
...

Version-Release number of selected component (if applicable):
nmh-1.2-20070115cvs.4.fc8 

How reproducible:
Always

Steps to Reproduce:
1. generate a message with a too-long From line
2. scan +inbox

Re: problem with long field names

> 
> This is cut-and-pasted from=20
> https://bugzilla.redhat.com/show_bug.cgi?id=437652
> 
> Description of problem:
> Recently (in the last month or so), linkedin.com has started sending very l=
> ong From fields.  As a result, pick fails with messages like this:
> 
> 
> 
> pick: field name "From notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0=
> xnV-CG_gSQxxjCdsSEs56P_1MmEv5E0PNMxxjQFo <at> bounce.linkedin.com  Mon Mar " exc=
> eeds 127 bytes
> pick: format error in message 169
> 
> Here's the start of the message:
> 
> From
notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0xnV-CG_gSQxxjCdsSEs56P_1MmEv5E0PNMxxjQFo <at> bounce.linkedin.com
> Mon Mar  3 02:03:01 2008
> Return-Path: <notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0xnV-CG_gSQxxjCdsSEs56P_1MmEv5E0PNMxxjQFo <at> bounce.linkedin.com>
> ...

Ah ha, I now see the problem!

It looks like you're trying to view an mbox as a mh message.  the From is
missing a :, and the line doesn't look like a normal From header.

Try to inc that file into your inbox, and you should be OK.  The
question now becomes, how did it get there.

Re: problem with long field names

On Mon, 17 Mar 2008 09:41:27 EDT, Josh Bressers wrote: 
>> 
>> This is cut-and-pasted from=20
>> https://bugzilla.redhat.com/show_bug.cgi?id=437652
>> 
>> Description of problem:
>> Recently (in the last month or so), linkedin.com has started sending very l=
>> ong From fields.  As a result, pick fails with messages like this:
>> 
>> 
>> 
>> pick: field name "From notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0=
>> xnV-CG_gSQxxjCdsSEs56P_1MmEv5E0PNMxxjQFo <at> bounce.linkedin.com  Mon Mar " exc=
>> eeds 127 bytes
>> pick: format error in message 169
>> 
>> Here's the start of the message:
>> 
>> From
notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0xnV-CG_gSQxxjCdsSEs56P_1MmEv5E0PNMxxjQFo <at> bounce.linkedin.com
> Mon Mar  3 02:03:01 2008
>> Return-Path: <notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0xnV-CG_gSQxxjCdsSEs56P_1MmEv5E0PNMxxjQFo <at> bounce.linkedin.com>
>> ...
>
>Ah ha, I now see the problem!
>
>It looks like you're trying to view an mbox as a mh message.  the From is
>missing a :, and the line doesn't look like a normal From header.
>
>Try to inc that file into your inbox, and you should be OK.  The

Re: problem with long field names

John Heidemann wrote:
>I will try and follow up this bug with procmail.  (If you want to make
>mh robust to this incorrectness of someone else, it looks like a 2-line
>change to m_getfld.c will do so.  Please let me know if you're
>interested.)

I'd be interested in seeing the patch, yes. (A similar issue has come
up before; see http://savannah.nongnu.org/bugs/?14975 )

-- PMM

_______________________________________________
Nmh-workers mailing list
Nmh-workers <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers