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