Hi Paul, Haven't noticed a comment in a References field before:
References: <20220722115151.80a8221...@orac.inputplus.co.uk> <20220725092852.e055e20...@orac.inputplus.co.uk> (sfid-20220725_052923_626513_424143A1) <20220725102256.65c6c2e0...@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.