procmail
[Top] [All Lists]

extracting attachments

2001-04-01 13:10:58

After getting one too many enormous GIFs by someone who is digital camera
happy...
...after all the virii going around...
...after hearing about all the different buffer overflows and other exploits
related to HTML emails and whatnot...
...after getting 15 copies of a large executable by someone who claimed I "GOTTA
SEE THIS"...

I have sworn off email attachments for the rest of my life.

Now the problem is that some of them are necessary, and most people (that I deal
with) don't have a clue how to put something on a web page rather than emailing
it.

And I'd rather not have to login to the server and manually extract it anytime I
get an email either

So I came up with an idea:

        Use metamail to extract the attachment to a directory accessible via 
the web.

        Add the URL to the attachment so that if I want to download it, I can 
just
click the link



CONCERN:

        Could some mean person muck with the Content-Type and 
Content-Disposition
definitions, ie instead of this:

Content-Type: application/octet-stream; name="1-Logos Mid Highs.xls"
Content-Disposition: inline; filename="1-Logos Mid Highs.xls"

could someone write an attachment that has

Content-Disposition: inline; filename="../../../../../../../../../../.rhosts"

and try to overwrite a system file?  In my tests, metamail seemed not to be
fooled by that, but I suppose it is a risk unless someone knows metamail's
behavior



RECIPE

:0
*   ^Mime-Version: 1.0
* ! ^Content-Type:[     ]Text/Plain
*   ^Content-type: *\/[^ ].*
{
        #       change UMASK to chmod 644 for the files that metamail creates
        UMASK=022

        # Use metamail to filter the body -- this gets rid of a lot of useless 
HTML
emails too!
        :0 w fb
        | metamail -q -x -b -c "${MATCH}"  2>&1 | fgrep -v 'metamail: Ignoring 
invalid
mailcap'

        #       Change the UMASK back to chmod 600
        UMASK=077

        #       Check for the existence of a message which is given
        #       by metamail when it decodes an attachment
        #       and if found, change the message to point to the URL
        :0 fb w
        * B ?? ^This message contains (raw digital data|data in an unrecognized 
format)
        * B ?? ^which is being decoded and written to the file named
        * B ?? ^If you do not want this data, you probably should delete that 
file.
        * B ?? ^Wrote file
        | sed "/^This message contains/,/Wrote file/ {  /This message/,/If you 
do not
want/d; s/ /%20/g ; s#.*/#ATTACHMENT:\n\t$METAMAILURL/#g}"

# NOTE: the 'sed' line above should be all one long line


        # Remove the MIME headers to make sure we don't confuse any mailers
        :0 w fh
        | formail -I"Content-Type:" -I"MIME-Version:" -A"X-Note: mime altered"
}


NOTE that $METAMAILURL is defined in .procmailrc as is $METAMAIL_TMPDIR... for
example if your system uses $HOME/www/ for web files, then

METAMAIL_TMPDIR=$HOME/www/metamail_temp

METAMAILURL=http://yourisp.com/~yourusername/metamail_temp


Since these files will be visible to anyone who finds them, I would suggest not
broadcasting the URL, and password protect the directory as well


I'd welcome feedback and enhancement/bug fixes.... This works for me thus far in
the limited testing I have done.  ALWAYS BACKUP INCOMING EMAIL BEFORE TESTING A
NEW RECIPE.

Consider it Alpha but "it works for me."


TjL

_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>