Hello Ralph,
Ralph Corderoy <ra...@inputplus.co.uk> wrote:
|Hi Peter,
|
|>> http://lists.gnu.org/archive/html/groff/2014-06/bin14bGZPiUPU.bin
|>> which
|>
|> The .bin extension issue for attachments in archived email has come up
|> before. Does anyone know why lists.gnu.org is doing this and whether
|> there'd be any point trying to get it fixed?
|
|It's to protect users on systems that might execute it as a program
|willy-nilly, e.g. Microsoft.
|http://wiki.list.org/pages/viewpage.action?pageId=4030603
|
|https://mail.python.org/pipermail/mailman-users/2008-October/063693.html
|says how Mailman looks up the MIME part's content-type to see if it's
|known. The email used
|
| Content-Type: application/x-tar-gz
| Content-Disposition: attachment; filename="distribute.tgz"
| Content-Transfer-Encoding: base64
|
|and application/x-tar-gz isn't in
|http://www.iana.org/assignments/media-types/application/ The closest is
|http://www.iana.org/assignments/media-types/application/gzip which
|leaves the tar for the user to fathom out if left to MIME types alone.
I found that [1] is a good place to look for "a complete list" of
IANA registered and unregistered MIME types but which are used in
practice (i use that for the mailer i maintain), and it lists the
extension tgz regulary thereunder
<mime-type type="application/gzip">
<_comment>Gzip Compressed Archive</_comment>
<alias type="application/x-gzip"/>
<alias type="application/x-gunzip"/>
<alias type="application/gzip-compressed"/>
<alias type="application/gzipped"/>
<alias type="application/gzip-compressed"/>
<alias type="application/x-gzip-compressed"/>
<alias type="gzip/document"/>
<magic priority="45">
<match value="\037\213" type="string" offset="0" />
<match value="\x1f\x8b" type="string" offset="0" />
</magic>
<glob pattern="*.tgz" />
<glob pattern="*.gz" />
<glob pattern="*-gz" />
<glob pattern="*.emz" />
</mime-type>
[1] <http://svn.apache.org/viewvc/tika/trunk/tika-core/src/main/\
resources/org/apache/tika/mime/tika-mimetypes.xml>
--steffen
