On Tue, Jun 13, 2017 at 09:11:24AM +0200, Vincent Lefevre wrote: > On 2017-06-12 18:13:58 -0500, Derek Martin wrote: > > I'm not opposed to using libmagic for this, but I actually think > > the heueristic code should be removed entirely from Mutt. Message > > bodies should be assumed to be text, and attachments are assumed > > to be NOT text, by virtue of them not being message bodies. Their > > types should be determined via the standard MIME mechanisms. If > > those mechanisms fail--for whatever reason--assume > > application/octet-stream and move on. > > I disagree: those mechanisms will typically fail on what is > actually arbitrary text, because text does not correspond to > a file format.
Which matters exactly zero if you use application/octet-stream. > Very often it does not have a file extension. "Arbitrary text" has a MIME type and associated file extension; The choice to not use it is the user's choice, but like all choices that has consequences. Whatever Mutt does is just a guess, even if it's a good guess, and we know some mail systems translate end-of-line chars, and we know they won't when an application/octet-stream attachment is used. So if you want to send text attachments, and you want them to be properly identified as such automatically, you should use the associated file extension; or else be prepared to set them manually. If you still choose not to, then application/octet-stream is fine, and you can change it manually if not. Small price to pay for your stubborn refusal to adhere to existing standards. Your recipients may need to save the file to view it--a minor annoyance caused by YOU for not following established norms--but the content will arrive unmolested. > Even if binary data is sent as valid text (BTW, any binary data > can be regarded as valid text in some user-defined character set), If it's user-defined, it's not standards-compliant, and needs to be treated specially regardless; i.e. the recipient won't be able to display it without some special effort, such as sending it to a display filter (which will require a suitable MIME type to work automatically). This case isn't interesting. > it should not arrive as unmolested. I mean that in any case, the > user should be able to choose text/plain for "Content-Type" and > be sure that no corruption occurs. It is up to Mutt to choose an > adequate "Content-Transfer-Encoding". A reasonable point, but Mutt should not have to jump through hoops to make that happen, and it should be fast--i.e. take negligible time, so that the user does not have to wait perceptibly for the file to be attached. I think the existing heueristics do that just fine, so long as the user doesn't try something unreasonable. Although, perhaps Mutt should resort to quoted printable more readily, to reduce the chances of producing incorrect messages... However, the case that sparked this thread was someone attaching IMAGE FILES, which are not text, and REQUIRE a suitable MIME type. If the user won't name them properly, or if they truly are a non-standard type that has no established MIME type, then the user will need to do what I described before: either define a fake type with a uniform extension and add it to mime.types, or manually set it in Mutt's attachment menu to something that won't get molested by the mail system. Mutt should encourage following standards, and should not cater to those who refuse. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgpBJ1dGcUbeG.pgp
Description: PGP signature
