[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Surprising MIME Type from Android.

From: Ralph Corderoy
Subject: Re: Surprising MIME Type from Android.
Date: Mon, 25 Jul 2022 14:07:47 +0100

Hi Paul,

Haven't noticed a comment in a References field before:

    References: <20220722115151.80A8221517@orac.inputplus.co.uk>

> >    pick -sea 'content-type.*\*'
> I have one.  Message came from a hotmail user, via outlook.com.
> $ mhlist
>  msg part  type/subtype              size description
> 2122       multipart/mixed           968K
>      1     multipart/alternative      859
>      1.1   text/html                  342
>      1.2   text/plain                  69
>      2     image/*                   715K 20220609_075908_resized.jpg

The email which triggered it here is from a user who typically uses
Outlook, though all the ‘android’ bits of this particular email pushed
me away from that.  I also noticed its Message-ID field was created on
my machine when it arrived.

Thanks to Bob too for checking.

I followed my own suggestion with interesting, in a bad way, results.

In my +inbox, there are no culprits according to grep(1) as all the hits
are false positives.

    $ LC_ALL=C grep -i 'content-type.*\*' [0-9]*
    6105:      document-response = Content-Type [ Status ] *other-field NL
    81708: >     pick -sea 'content-type.*\*'
    81714:> >     Content-Type: image/*; name=3D"20220721_180552.jpg"
    81714:>     pick -sea 'content-type.*\*'

But if I use pick(1) to do the same search:

    $ pick -sea 'content-type.*\*'
    4 hits
    $ scan lp
     6105  13-12-08  me                The Common Gateway Interface (CGI) 
     8717  20-02-19  Mark Sapiro       Re: [Mailman-Announce] I18n for Mai
    81708  22-07-25  Paul Fox          Re: Surprising MIME Type from Andro
    81714+ 22-07-25  Bob Carragher     Re: Surprising MIME Type from Andro

Message 8717 is a hit, but it shouldn't be:

    $ LC_ALL=C grep -i content-type 8717
     'content-type:multipart/signed': 0.07; 'bay': 0.09; 'content-
    Content-Type: multipart/mixed; 
    Content-Type: multipart/signed; micalg=pgp-sha1;
    Content-Type: multipart/mixed; boundary="ttQpQgr8FL6th88C6FQswkN3KhxwqEQFl"
    Content-Type: text/plain; charset=utf-8
    Content-Type: application/pgp-signature; name="signature.asc"
    Content-Type: text/plain; charset="us-ascii"

Either it's some nmh corruption of the input as it's buffering it, or a
fault in -search's regexp processing.  I'd guess the former.

See, this is why it's worth not glossing over these RFC violations!  :-)

Cheers, Ralph.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]