Re: Surprising MIME Type from Android.

[Ralph Corderoy]

Hi Paul,

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

    References: <20220722115151.80A8221517@orac.inputplus.co.uk>
        <20220725092852.E055E2017C@orac.inputplus.co.uk>
        (sfid-20220725_052923_626513_424143A1)
        <20220725102256.65C6C2E01EB@grass.foxharp.boston.ma.us>

> >    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; 
boundary="===============2295464778554599938=="
    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.