Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[802.3] RE: May we please eliminate file attachments from this reflector?-Re: VirusAlert




Bob,

As someone who travels and connects over modem on the road fairly frequentl,
I would rather have small attachments sent with the emails rather than as a
URL. For small files, it takes a lot more time on the modem to go through
finding the emails that require a download, attach to the websites and do
the downloads than it does to just download them in the email stream even if
that means getting a few extra. And downloading from web sites takes my
time. As the file gets large, then it is more convenient to have the choice
of whether to download by going to a web site.  

Regards,
Pat

-----Original Message-----
From: Bob Barrett [mailto:bob.barrett@xxxxxxxxxxxxxxxxxx]
Sent: Saturday, May 18, 2002 8:35 AM
To: stds-802-3@ieee.org; stds-802-3-efm@ieee.org
Subject: RE: May we please eliminate file attachments from this
reflector?-Re: VirusAlert



Frank

I strongly disagree with your comment paraphrased as 'no attachements is
like taking away ink'.

Putting a url link to the material in your email (which is on your own web
site), allows free and open access to the material by those that choose to
view it. I can't see how this can damage the process, and the download time
is roughly the same. The url option gives people the choice to get the
information or not. These seems to fit the rules of an open democratic
process just as well as posting the attachment with an email.

Best regards

Bob


-----Original Message-----
From: owner-stds-802-3@majordomo.ieee.org
[mailto:owner-stds-802-3@majordomo.ieee.org]On Behalf Of Howard Frazier
Sent: 17 May 2002 18:03
To: stds-802-3@ieee.org; stds-802-3-efm@ieee.org
Subject: Re: May we please eliminate file attachments from this
reflector?-Re: VirusAlert





As one who travels frequently, thus having to put up with dial up
access to a POP3 server, and one who can't afford the LUXURY of being
able to filter or delete messages which contain attachments, I
have some sympathy for those who are similarly burdened.  For this
reason, the stds-802-3-efm reflector imposes a limit of 250,000
characters per message, which bounces very long attachments to
the list administrator. If you have any familiarity with PDF
distillers, and you eliminate wasteful things like fancy corporate
logos and useless background patterns, it is easy to constrain
PDF files to this limit.  Believe it or not, the principal reason
for PDF file size bloat is the corporate logo which appears on
so many presentation templates.

That said, I also agree with Frank's point.  The free exchange of
information is essential to our process, and email is just too good
of a medium for information distribution. So, I offer the following
guidelines:

1) Be mindful of file size.  Eliminate ridiculous background fill
patterns from your slides (monochrome backgrounds usually do not
cause problems, but gradient fills do). Eliminate logos which blow
up files.  If you must use a logo (understandable) choose one
that compresses well.  Your corporate marcom department can help
if you ask them.  Choose your PDF distiller options carefully, and
use a high compression (lower quality) setting.

2) Most importantly, check your file size before you fire
off a message.  If the size exceeds a quarter meg, you have done
something wrong.

3) Use a compression utility like PKzip to compact large files. You
might be surprised at how effective this is, but it shouldn't be
a surprise since the bloat is caused by redundant information which
compresses quite nicely, thank you.  The unzip utillities are
freeware, and should not represent a barrier to the message recipients.

4) If all else fails, email a link to your material, rather than
emailing the file itself.

I realize that this sounds like a burden, and I don't want to discourage
the distribution of important material.  Please realize that the few
minutes you spend following the steps above will save alot of time for
the thousands (!) of people on these reflectors.

Howard Frazier
Chair, IEEE 802.3ah EFM Task Force


FEffenberger@xxxxxxxxxxxxxxxxx wrote:
>
> All,
>
> Eliminating file attachments is like stopping people from using ink.
> Attachments are one of the best features of Email.
>
> If you don't like attachments, then it is all to easy to set up your Email
> client to automatically delete them.
>
> As for the basic problem here, I've not noticed a huge volume of
> virus-induced Email coming from IEEE.  I'm assuming that the IEEE
> server has installed filtering software.  Are other peoples'
> experiences different?  If so, the proper solution is to get better
> filtering software, not to turn off the attachment service.
>
> To Hugh's complaint, the slowness you refer to is caused by the
> medium (copper), and not the message (attachments).  (Sorry, I
> couldn't resist.)  As I've said, you can set up your Email
> client to not download large attachments.
>
> Regards,
> Frank Effenberger.
>
> -----Original Message-----
> From: Hugh Barrass
> To: Clay_Hudgins@xxxxxxxxxx
> Cc: stds-802-3@ieee.org
> Sent: 5/17/02 9:50 AM
> Subject: Re: May we please eliminate file attachments from this reflector?
> -Re:  VirusAlert
>
> Clay,
>
> I agree with this. Many people have to access e-mail through slow links
> (because EFM
> hasn't finished yet) and attachments are painful. Anyone who wishes to
> distribute large
> files should post links (as most people do) or ask for interested
> parties to send
> separate e-mail to request the files.
>
> Hugh.
>
> Clay_Hudgins@xxxxxxxxxx wrote:
>
> > Hi, to who it may concern.
> >
> > I have a need for the useful and timely information distributed by the
> IEEE
> > 802.3 Reflectors.
> >
> > Having said that, I have no need whatsoever to receive file
> attachments via
> > these reflectors.  I hope that the administration will consider
> removing
> > the capability to transfer files via these reflectors, in light of the
> fact
> > that junk mail distribution and virus distribution has become the
> > predominate use of the file attachment capability.
> >