Re: Palyh, *.pi files, and windows

From: Will Day (
Date: Wed 21 May 2003 - 19:24:09 GMT

  • Next message: Henrý Þór Baldursson: "Temporary files [patch]"

    A short time ago, at a computer terminal not so far away, I wrote:
    > +

    Sigh, okay non-signed:

    We're using Anomy here to uvscan and/or defang things like .exe and .pif.
    However, recent reports from campus indicate that Palyh samples aren't
    getting scanned or defanged.

    One sample I found had the following MIME headers on the attachment:

       Content-Type: application/octet-stream;
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment;

    Note the two seperate specifications of a name for the file, and that they
    provide two different extensions.

    Not being very familiar with the intricacies of MIME headers, I don't know
    what the difference is supposed to be, and/or why it can be specified in
    two separate places like that.

    As best I can tell, the disposition/filename is what most clients use, both
    for creating and parsing messages. It's not clear if the type/name is used
    by anything, or indeed if it's valid. However, some reports from users, as
    well as news articles, talk about "*.pi" files; I'm not sure if those are
    messages with a disposition/filename of ".pi", or if it's the same
    mismatch-situation as above, except where the client is in fact using the
    type/name field.

    There also seems to be some confusion whether ".pi" files are executable in
    the same fashion as ".pif" files are. For instance:

       Although the file has a .pi or .pif extension, it is an .exe file. And
       because Windows processes files according to their internal structure
       rather than their extension, Windows runs the file as soon as the
       recipient double-clicks on it.

    This doesn't match any of my experience with Windows, and I have been
    unable to get windows to launch a ".pi" file for me.

    I have, however, observed Windows apparently parsing _some_ files and
    loading them properly despite/regardless of their extension. For instance,
    any Office file renamed to an unknown extension, or to no extension at all,
    is loaded into the proper Office application. That is, renaming
    "meeting.doc" to "meeting.blah" will still launch into Word. However, this
    has only worked for Office documents so far; in particular, renaming
    "notepad.exe" to "notepad.blah" will not run the executable, but instead
    wil prompt for application to read the file.

    So, I guess I'm wondering:
     - Is the Content-Type/name field valid, how does it compare to the
       Content-Disposition/filename field, and/or should we expect clients to
       parse and honor it?
     - Should Anomy parse the type/name field in addition to the
       disposition/filename field?
     - Are ".pi" files executable/launchable in the same manner as ".pif"
     - How/why is windows understanding an Office file without a valid Office
       extension, and does this apply to any other file types? Ie, if it does
       apply to other types, then file extension starts to appear become an
       insufficient basis on which to filter attachments. Should Anomy perhaps
       use /bin/file or the equivalent, and filter based on the file's magic

    Will Day                  Those who would give up essential Liberty, to       purchase a little temporary Safety, deserve neither 
    Georgia Tech / OIT        Liberty nor Safety.
    UNIX System Programmer      - Benjamin Franklin, Penn. Assembly, Nov. 11, 1755
      -> Opinions expressed are mine alone and do not reflect OIT policy <-

    hosted by