Re: Surprising MIME Type from Android.
Ralph wrote: > Fair enough. Either way, I think nmh should baulk at invalid characters > in the MIME type so to avoid creating ‘42.2.*’ as it contains shell > globbing characters. Agreed. If you don't have time in the near future, this would be a great task to introduce someone new to nmh work. It's "balk" in baseball rulebooks. I never knew it's spelled differently on your side of the pond. David
Re: Surprising MIME Type from Android.
Hi David, > > Something for mhfixmsg(1) to correct? > > At this point, I think the trade-off favors manually fixing the > apparently rare offending messages rather than investing effort in > enhancing mhfixmsg. Fair enough. Either way, I think nmh should baulk at invalid characters in the MIME type so to avoid creating ‘42.2.*’ as it contains shell globbing characters. -- Cheers, Ralph.
Re: Surprising MIME Type from Android.
Ralph wrote: > > I haven't checked yet, but I assume it violates the RFCs. > > It does by my reading of > https://datatracker.ietf.org/doc/html/rfc2045#section-5.1 Agreed. > Something for mhfixmsg(1) to correct? At this point, I think the trade-off favors manually fixing the apparently rare offending messages rather than investing effort in enhancing mhfixmsg. David
Re: Surprising MIME Type from Android.
Ralph Corderoy wrote in <20220725092852.e055e20...@orac.inputplus.co.uk>: |> I ran mhstore(1) and was surprised by the ‘81081.2.*’ filename. |... |> 2 image/* 2985K |... |> I haven't checked yet, but I assume it violates the RFCs. | |It does by my reading of |https://datatracker.ietf.org/doc/html/rfc2045#section-5.1 | |Something for mhfixmsg(1) to correct? ... |> Content-Type: image/*; name="20220721_180552.jpg" ... Fwiw, my mailer has a *mime-counter-evidence* variable which tries ... |Has anyone else got an example? | |pick -sea 'content-type.*\*' ... It has become better, but i see that setting adjusting MIME types very often. (Though most often it is overwriting application/octet-stream with something more sensible. Iirc especially elder Apple Mail's where notorious false claimers.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Surprising MIME Type from Android.
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 meThe 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.
Re: Surprising MIME Type from Android.
Hi Ralph, Checking email going back to 2013, I could not find a single occurrence of that pattern. Bob On Mon, 25 Jul 2022 10:28:52 +0100 Ralph Corderoy sez: > Hi again, > > > I ran mhstore(1) and was surprised by the ‘81081.2.*’ filename. > ... > > 2 image/* 2985K > ... > > I haven't checked yet, but I assume it violates the RFCs. > > It does by my reading of > https://datatracker.ietf.org/doc/html/rfc2045#section-5.1 > > Something for mhfixmsg(1) to correct? > > > _com.samsung.android.email_135816585189000 > > Content-Type: image/*; name="20220721_180552.jpg" > ... > > which suggests a Samsung Galaxy S9 took the photo but that doesn't meant > > Has anyone else got an example? > > pick -sea 'content-type.*\*' > > Note, don't use ‘--content-type’ as that only searches the header's > fields. > > -- > Cheers, Ralph.
Re: Surprising MIME Type from Android.
ralph wrote: > > Has anyone else got an example? > > pick -sea 'content-type.*\*' > > Note, don't use ‘--content-type’ as that only searches the header's > fields. 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 There's no metadata in the image to indicate where it originated. Happy to get you a full copy of the message if it's interesting. paul =-- paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 74.8 degrees)
Re: Surprising MIME Type from Android.
Hi again, > I ran mhstore(1) and was surprised by the ‘81081.2.*’ filename. ... >2 image/* 2985K ... > I haven't checked yet, but I assume it violates the RFCs. It does by my reading of https://datatracker.ietf.org/doc/html/rfc2045#section-5.1 Something for mhfixmsg(1) to correct? > _com.samsung.android.email_135816585189000 > Content-Type: image/*; name="20220721_180552.jpg" ... > which suggests a Samsung Galaxy S9 took the photo but that doesn't meant Has anyone else got an example? pick -sea 'content-type.*\*' Note, don't use ‘--content-type’ as that only searches the header's fields. -- Cheers, Ralph.
