Over the weekend NAI had to release two whole dat-files. Both worms spread by way of .zip files. This has potentially very bad consequences for the future of attachments in e-mail. Already, certain file-types are banned at the boarder in order to defend against "zero day" worms (worms that start spreading like wildfire before signatures are updated). At OldJob, we managed to dodge many such worms just by blocking certain attachment extensions. If worms start spreading in archive formats like .ZIP and .CAB, the boundary blockers will not catch them.
The archivers introduce a layer between the blockers and the actual content. Unfortunately, most e-mail clients now read ZIP well enough that a double-click is all it takes to open them and get at the buggy insides. Virus scanners can also scan into such archives, but the attachment blockers generally don't. There exist some open-source utilities that can block files deep within zip files, but that generally doesn't help Exchange/LotusNotes/Groupwise environments very much.
The debate has been raging for some time on the topic of executable content in e-mail, and the desirability of e-mail as a file-transfer protocol. Until Outlook 2003 introduced the "convert all to plain-text" option for viewing new e-mail, just plain HTML in the message portion could be used to do Bad Stuff. Part of the problem is defining just what 'executable content' is.
E-mail as a file-transfer protocol is a fairly poor choice. Even today, binary code send in e-mail has to be converted to 7-bit ASCII before being transmitted over the internet by SMTP. Extensions exist to permit 8-bit transfer (and thus savings), but enough weird e-mail systems exist out there that staying with 7-bit is needed. Therefore, you get a size penalty for sending binaries (like Word documents) as attachments. This is the main reason mail administrators put attachment-size limits into place, because that size problem becomes very obvious when mailing 652mb cd-rom images.
Add into that, the fact that different e-mail systems handle the single-attachment/multiple-recipient problem (think of that retirement party notice you got last week, with the Word document containing the bouncing balloons image, and cheery music, sent to the entire department) differently, and you have another issue. Some send the same file to each person individually. Others save the file in one spot and send pointers to that file to the recipients. Both methods have their good and bad points.
And the source of the problem: attachments are very easy for the end-user to figure out, so they use them a lot. Weaning them folk off of attachments and onto another system will take effort. Lots of effort. If it is even possible.
The archivers introduce a layer between the blockers and the actual content. Unfortunately, most e-mail clients now read ZIP well enough that a double-click is all it takes to open them and get at the buggy insides. Virus scanners can also scan into such archives, but the attachment blockers generally don't. There exist some open-source utilities that can block files deep within zip files, but that generally doesn't help Exchange/LotusNotes/Groupwise environments very much.
The debate has been raging for some time on the topic of executable content in e-mail, and the desirability of e-mail as a file-transfer protocol. Until Outlook 2003 introduced the "convert all to plain-text" option for viewing new e-mail, just plain HTML in the message portion could be used to do Bad Stuff. Part of the problem is defining just what 'executable content' is.
E-mail as a file-transfer protocol is a fairly poor choice. Even today, binary code send in e-mail has to be converted to 7-bit ASCII before being transmitted over the internet by SMTP. Extensions exist to permit 8-bit transfer (and thus savings), but enough weird e-mail systems exist out there that staying with 7-bit is needed. Therefore, you get a size penalty for sending binaries (like Word documents) as attachments. This is the main reason mail administrators put attachment-size limits into place, because that size problem becomes very obvious when mailing 652mb cd-rom images.
Add into that, the fact that different e-mail systems handle the single-attachment/multiple-recipient problem (think of that retirement party notice you got last week, with the Word document containing the bouncing balloons image, and cheery music, sent to the entire department) differently, and you have another issue. Some send the same file to each person individually. Others save the file in one spot and send pointers to that file to the recipients. Both methods have their good and bad points.
And the source of the problem: attachments are very easy for the end-user to figure out, so they use them a lot. Weaning them folk off of attachments and onto another system will take effort. Lots of effort. If it is even possible.