From: Wayde Allen (wallen@boulder.nist.gov)
Date: 05/05/00-10:00:33 AM Z
On Fri, 5 May 2000, Rod Fleming wrote:
> The KAKWORM virus, on the other hand, which was
> distributed through the list recently, was of a type which does NOT require
> that anyone executes it or opens the attachment- simply reading the message
> in the viewing pane is enough to relase the worm.
Care to provide a reference for this? I don't know of any viri that can
propagate without being executed.
> Further, it is axiomatic that viri are loose in the wild BEFORE the
> designers of anti-virus software can design the cure- so sooner or later
> you're going to get bit.
Very true!
> In view of that I don't think there is any doubt at all that it would be a
> Very Good Thing if all attachments were blocked.
OK, I usually don't like to get involved in these discussions, but I think
that perhaps a few words are in order. First of all, simply blocking
e-mail attachments isn't that simple. Everyone needs to remember that the
e-mail systems were never designed to carry attachments. They are only
really designed to process relatively short ASCII data streams. That
means, that e-mail attachments are not just binary files that are sent
along with your e-mail. To send a binary file via e-mail it has
to be processed to encode it using transmittable ASCII characters (you
can't use escape codes for security reasons). The resulting stream of
ASCII characters is then simply appended to the end of your e-mail, before
being sent. This is all done by your mailer client (Eudora, Pine, etc.)
before being delivered to the mail transport agent (Sendmail, Qmail,
Smail, etc.). As a result, your e-mail with an attachment really is just
a single big e-mail, and the internet mail protocol makes no distinction
between a message with an attachment versus one without. Separating out
the attachment is either done manually by the recipient, or by their mail
client.
Listservers, are really just an extension of the mail transport mechanism
(usually Sendmail). What they really do is map a single address to a
group of addresses. On a Unix or Linux box, which is the typical place
where listservers reside you can create a mailing list by creating a mail
alias such as:
altphoto: address_file
where the address_file looks something like:
address1
address2
address3
A mailing list created in this way, is not secure or convenient however,
since only a person with access to the mail server can add or delete
subscribers and anyone in the world can post to the address (altphoto in
this case). Listserver software simply provides a mechanism for remotely
administering the subscriber database and checks to verify that someone is
a subscriber or not. Indeed, if you wanted to create this list using
majordomo you'd have an alias file that reads something like:
altphoto: "|/usr/lib/majordomo/wrapper resend -l altphoto altphoto-list"
altphoto-list: :include:/var/lib/majordomo/lists/altphoto
altphoto-request: "|/usr/lib/majordomo/wrapper majordomo -l altphoto"
altphoto-approval: thelistowner@somewhere.net
owner-altphoto: thelistowner@somewhere.net
altphoto-owner: thelistowner@somewhere.net
The point is, that the Listserver software really doesn't know anything
about attachments, since the servers job is simply to route the e-mail to
the appropriate place. I have used majordomo, mailman, and smartlist, and
to the best of my knowledge none of these lists have a specific provision
for scanning the message internals to determine whether they contain
attachments or not. They do have is a limit that the administrator
can set that restricts the length of all posts. The normal limit is 40000
characters. Most of the time, this length restriction causes binary files
to bounce since they are typically quite long. It isn't a foolproof
solution though. The other option I could think of would be to setup
a regular expression trap for attachment markers. That could be a tad
tricky though since lots of people send html attachments and vcards.
You'd want to except those kinds of attachments or you'll get lots of
complaints.
> Finally- and I hope it is- my company sends a lot of attachments. I would
> appreciate it if anyone who wants to send me an attachment adopts a
> procedure similar to ours. (Well they'll have to if they want it to be
> opened.)
>
> Our system is as follows; normally we are in touch with the client either by
> email or phone before we send. When we send, we send TWO emails;
Of course if you are going to go to this trouble, why not use a file
transport mechanism designed for the job? The net was designed to allow
people to exchange binary files directly, and the e-mail system isn't it.
I can ftp anything I want to you, and don't have all the headaches
involved with converting to mail and back again.
- Wayde
(wallen@boulder.nist.gov)
This archive was generated by hypermail 2b29 : 06/13/00-03:10:17 PM Z CST