Loading ...
Sorry, an error occurred while loading the content.

Patch: mime.types lookup for received application/octet-stream attachments

Expand Messages
  • Ulf Erikson
    Hello again, Some time ago I sent mutt-users (cc: mutt-dev) a suggestion on how one could handle received application/octet-stream attachments. The idea is
    Message 1 of 7 , May 1, 2001
    • 0 Attachment
      Hello again,

      Some time ago I sent mutt-users (cc: mutt-dev) a suggestion on how one
      could handle received "application/octet-stream" attachments. The idea
      is to search the mime.types for a match on the file extension and use
      this content type instead. The patch implements this scheme and
      includes the suggested boolean variable, named $lookup-octetstream. It
      is also extended to deal with auto-views now.

      Still not sure if this is the right way to handle it, but it works..
      Perhaps someone else can find it useful, but just drop it in the trashes
      if you have a better way to do it or think that this is not Mutt's job

      /Ulf
    • Sam Roberts
      ... What does this mean? Does this mean octet-streams are autoviewed differently than parts with correct mime types? ... =========== pitch for the patch to be
      Message 2 of 7 , May 2, 2001
      • 0 Attachment
        Quoting Ulf Erikson <Ulf.Erikson@...>, who wrote:
        > Hello again,
        >
        > Some time ago I sent mutt-users (cc: mutt-dev) a suggestion on how one
        > could handle received "application/octet-stream" attachments. The idea
        > is to search the mime.types for a match on the file extension and use
        > this content type instead. The patch implements this scheme and
        > includes the suggested boolean variable, named $lookup-octetstream. It
        > is also extended to deal with auto-views now.

        What does this mean? Does this mean octet-streams are autoviewed
        differently than parts with correct mime types?

        > Still not sure if this is the right way to handle it, but it works..
        > Perhaps someone else can find it useful, but just drop it in the trashes
        > if you have a better way to do it or think that this is not Mutt's job

        =========== pitch for the patch to be included ============

        I think it has to be mutt's job, because there isn't a good way to do
        this using any other technique.

        procmail may be able to fill out mime types based on file extension if
        the type is octet-stream, but I can't run procmail on our server.

        I can use the Dave Pearson's mutt.octet.filter, but there are two problems
        with that:
        1 - It doesn't use the mailcap to determine how to deal with a file
        once it's made a guess as to its type, so you have to duplicate
        the information in mailcap inside the script. This could be fixed,
        but...
        2 - It bypasses my ability in my muttrc to determine which mime-types
        to autoview, and which to only view when I select them in the
        attachment menu. It means that all octet-stream data is handled
        identically, which sucks.

        If I get a word or html file I have copious output set in my mailcap
        on the entries that convert them to text. I barely even notice that
        people are sending me this kind of lame stuff, I can just read it. I
        don't want a jpeg image to be autoviewed though. However, if I go to
        the attachment menu, I want to be able to view it my selecting it.

        I know that this patch is something of a lame workaround for broken MUAs,
        but I work in a company where most people use Lotus Notes, and it labels
        all attachments as application/octet-stream. This is ****ed, but I can't
        exactly change it.


        ============ comment about the patch =============

        I track the head of CVS, not whatever this patch was against. I had to
        manually integrate some of the patch.

        Attached is what I did, but it didn't work for me. I have
        "set lookup_octetstream" in my muttrc.

        I have a mailbox with two copies of the same message, identical except
        I edited one so the word file has the right mime type, the other has
        octet-stream type.

        The one with the right type is autoviewed, the other isn't. Any suggestions?

        Also, I think the option name should reflect what it does, which is map
        filename extensions to mime types. Perhaps "fake_mimetype_using_ext"?

        --
        Sam Roberts <sroberts@...>
      • Sam Roberts
        And I totally forgot to attach the diff for what I did to get that patch to work, sorry. -- Sam Roberts Index: attach.c
        Message 3 of 7 , May 2, 2001
        • 0 Attachment
          And I totally forgot to attach the diff for what I did to get that patch
          to work, sorry.

          --
          Sam Roberts <sroberts@...>
        • Gary Johnson
          ... There is a solution to this. I took mutt.octet.filter as a starting point and created mutt_octet_view which allows octet-stream data to be handled
          Message 4 of 7 , May 2, 2001
          • 0 Attachment
            On Wed, May 02, 2001 at 12:50:10PM -0400, Sam Roberts wrote:

            > =========== pitch for the patch to be included ============
            >
            > I think it has to be mutt's job, because there isn't a good way to do
            > this using any other technique.
            >
            > procmail may be able to fill out mime types based on file extension if
            > the type is octet-stream, but I can't run procmail on our server.
            >
            > I can use the Dave Pearson's mutt.octet.filter, but there are two problems
            > with that:
            > 1 - It doesn't use the mailcap to determine how to deal with a file
            > once it's made a guess as to its type, so you have to duplicate
            > the information in mailcap inside the script. This could be fixed,
            > but...
            > 2 - It bypasses my ability in my muttrc to determine which mime-types
            > to autoview, and which to only view when I select them in the
            > attachment menu. It means that all octet-stream data is handled
            > identically, which sucks.

            There is a solution to this. I took mutt.octet.filter as a starting
            point and created mutt_octet_view which allows octet-stream data to be
            handled differently depending on whether it is being auto-viewed or
            viewed from the attachment menu and on whether or not X is running. You
            can get it from

            http://www.spocom.com/users/gjohnson/mutt/mutt_octet_view

            That being said, I think putting the capability into mutt is a much
            better solution for all the reasons you mention. These patches are a
            great idea. I'll be trying them as soon as I find the time. B-)

            Gary

            --
            Gary Johnson | Agilent Technologies
            garyjohn@... | RF Communications PGU
            http://www.spocom.com/users/gjohnson/mutt/ | Spokane, Washington, USA
          • Ulf Erikson
            ... No. They are all viewed the same, but octet-streams are handled differently before viewing. The search for an alernative content type depending on file
            Message 5 of 7 , May 6, 2001
            • 0 Attachment
              * Sam Roberts <sroberts@...> [2001-05-02, 12:50 -0400]:
              > Quoting Ulf Erikson <Ulf.Erikson@...>, who wrote:

              > > Some time ago I sent mutt-users (cc: mutt-dev) a suggestion on how one
              > > could handle received "application/octet-stream" attachments. The idea
              > > is to search the mime.types for a match on the file extension and use
              > > this content type instead. The patch implements this scheme and
              > > includes the suggested boolean variable, named $lookup-octetstream. It
              > > is also extended to deal with auto-views now.
              >
              > What does this mean? Does this mean octet-streams are autoviewed
              > differently than parts with correct mime types?

              No. They are all viewed the same, but octet-streams are handled differently
              before viewing. The search for an alernative content type depending on file
              extension is only done for octet-streams.

              My first thought was to do this work when a mailcap entry is searched for
              (by the 'rfc1524_mailcap_lookup'). This is not enough to let you autoview
              octet-stream attachments though. The decision whether the attachment should
              be autoview is done before the mailcap is searched for. Therefor the same
              search is also done then (by the 'mutt_is_autoview').

              If all works you shouldn't need to have octet-streams autoviewed. Those
              attachments tagged as octet-streams but with recognicable extensions are
              handled according to the mailcap entry of their (hopefully) real type.

              > > Still not sure if this is the right way to handle it, but it works..
              > > Perhaps someone else can find it useful, but just drop it in the trashes
              > > if you have a better way to do it or think that this is not Mutt's job

              Maybe one could do without two searches per view. But if you don't mind
              dropping the octet-stream tag you could as well change content type while
              parsing the mailbox..

              > I track the head of CVS, not whatever this patch was against. I had to
              > manually integrate some of the patch.
              >
              > Attached is what I did, but it didn't work for me. I have
              > "set lookup_octetstream" in my muttrc.

              Sorry about that. I only rewrote things for the stable 1.2.5 version since
              that's what I use.. I'll attach a patch towards the newly released 1.3.18.

              > I have a mailbox with two copies of the same message, identical except
              > I edited one so the word file has the right mime type, the other has
              > octet-stream type.
              >
              > The one with the right type is autoviewed, the other isn't. Any suggestions?

              Two things:

              1) The mime.types file that comes with Mutt has no entry to associate .doc
              files with word documents. Adding a line like
              application/msword doc
              to your personal ~/mime.types should help with that.

              2) The patch didn't work for the 1.3.x series since 'lookup_mime_type' had
              changed interface.. Hopefully the new patch help with this. Let me know

              /Ulf
            • Sam Roberts
              ... That s exactly what I want. Good. ... I had to do this, but I don t understand why. I just copied the line out of /etc/mime.types. Isn t this used by mutt,
              Message 6 of 7 , May 9, 2001
              • 0 Attachment
                Quoting Ulf Erikson <Ulf.Erikson@...>, who wrote:
                > If all works you shouldn't need to have octet-streams autoviewed. Those
                > attachments tagged as octet-streams but with recognicable extensions are
                > handled according to the mailcap entry of their (hopefully) real type.

                That's exactly what I want. Good.

                > Sorry about that. I only rewrote things for the stable 1.2.5 version since
                > that's what I use.. I'll attach a patch towards the newly released 1.3.18.

                > Two things:
                >
                > 1) The mime.types file that comes with Mutt has no entry to associate .doc
                > files with word documents. Adding a line like
                > application/msword doc
                > to your personal ~/mime.types should help with that.

                I had to do this, but I don't understand why. I just copied the line out of
                /etc/mime.types. Isn't this used by mutt, or only it's own? That's kind
                of irritating, I'd call it a bug.

                > 2) The patch didn't work for the 1.3.x series since 'lookup_mime_type' had
                > changed interface.. Hopefully the new patch help with this. Let me know

                This patch appears to work for me. I'll work with it for a week, then post
                some feedback.

                Thanks,
                Sam
              • Sam Roberts
                ... Sorry! It means it s worked well enough that I ve forgotten it! It s even survived updating consistently from cvs. I still think the config variables name
                Message 7 of 7 , Jun 18, 2001
                • 0 Attachment
                  Quoting Ulf Erikson <Ulf.Erikson@...>, who wrote:
                  > Hi,
                  > I was recently reminded about this mail as I got asked for an updated
                  > version of the patch for mutt-1.3.19.
                  >
                  > * Sam Roberts <sroberts@...> [2001-05-09, 11:39 -0400]:
                  > > Quoting Ulf Erikson <Ulf.Erikson@...>, who wrote:
                  > > > 2) The patch didn't work for the 1.3.x series since 'lookup_mime_type' had
                  > > > changed interface.. Hopefully the new patch help with this. Let me know
                  > >
                  > > This patch appears to work for me. I'll work with it for a week, then post
                  > > some feedback.
                  >
                  > A week has passed. and an additional month. :) Searching the mutt-dev
                  > archives doesn't give any comments I have missed. I'm curious whether
                  > the silence mean that you removed the patch or if it works well enough
                  > to have you forget it's there.

                  Sorry! It means it's worked well enough that I've forgotten it! It's even
                  survived updating consistently from cvs.

                  I still think the config variables name doesn't really describe what it
                  does, I think "map_filename_to_mimetype" would be way more descriptive.

                  Anyhow, the patch has my vote.

                  > About your comment on how Mutt searches the wrong mime.types file.
                  > The search seems to be hardcoded to, in order, $HOME/.mime.types,
                  > $SYSCONFDIR/mime.types, and $SHAREDIR/mime.types. Where $SYSCONFDIR and
                  > $SHAREDIR are as listed by "mutt -v", and can only be changed by
                  > 'configure' before compiling. Perhaps a ``mimetypes_path'', similar to
                  > ``mailcap_path'', could be useful?

                  I don't think it's necessary, mutt's behaviour is WRONG.

                  Mutt is installed in /usr/local, not the rest of the system. The SYSCONF
                  and SHAREDIR are the directories for mutt's config. It should at
                  least search /etc/mime.types by default.

                  Sam.

                  --
                  Sam Roberts <sroberts@...>
                Your message has been successfully submitted and would be delivered to recipients shortly.