From: Thor Bols (thorbols@hotmail.com)
Date: 05/05/00-12:12:33 PM Z
Regarding Rod's statement: "SO you figure out how I can send to 20 or so
different clients, all using different operating systems, software, some
using ISDN, some on modems, some on non-capi 2 ISDN ta's, some, it's true,
still using 14.4 modems, without being there all day?"
Wayde is totally correct in his statements concerning ftp. But, even though
it is less efficient, I do things Rod's way. Depending upon one's business
and the technical prowess of the client contacts, there can be DINSTINCT
ADVANTAGES to using e-mail attachments to send software, etc. Some people
just glaze over when you mention ftp, or even when you furnish them, via
e-mail, a url. They want it served to them the only way they know: e-mail.
E-mail allows them the advantage of being able to readily find an
attachement in the future. And, perhaps more importantly, it affords the
sender the comfort in knowing that the recipient DID receive the attachment.
>From: Wayde Allen <wallen@boulder.nist.gov>
>Reply-To: Wayde Allen <wallen@boulder.nist.gov>
>To: alt-photo-process-l@sask.usask.ca
>Subject: Re: course of true love
>Date: Fri, 05 May 2000 10:00:33 -0600 (MDT)
>
>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)
>
>
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
This archive was generated by hypermail 2b29 : 06/13/00-03:10:17 PM Z CST