Re: [EFM] Re: May we please eliminate file attachments from this reflector?-Re: VirusAlert
All,
In the interest of saving bits and lessening the virus threat, what if the reflector would refuse any attachments that aren't zipfiles? This would allow legitimate posters to send a compressed attachment, while also fighting off most virus attacks.
-=Scott
"O'Mahony, Barry" wrote:
>
> Howard,
>
> I'd like to support this position.
>
> Looking over the past several months activity on the EFM reflector, the
> percentage of messages with attachments is very small. And despite the
> recent spate of viruses (which the IEEE reflector dealt with), the vast
> majority of them have been relevent to the work of 802.3ah. Typically, they
> are not very large, and are things like minutes of conference calls,
> strawman (logo-less) presentation proposals, etc. It would impede the work
> of the group to lose them. And it does not appear that there is any other
> mechanism available: does 802.3ah have a web site where anyone can post
> material, anytime? It appears not. So someone wishing to do this would
> need to devise their own, outside of any corporate firewalls.
>
> One can always do dialup downloads while at dinner. For me, the biggest
> problem I have is the marketing guy that send me the 10 Meg presentation
> while I'm on the road, not the 802.3ah reflectors.
>
> ~~~~~~~~~~~~~~~~~~~~~~~
> Barry O'Mahony
> Intel Labs
> Hillsboro, OR, USA
> tel: +1 (503) 264-8579
> barry.omahony@xxxxxxxxx
> barry.omahony@xxxxxxxxxxxx
> ~~~~~~~~~~~~~~~~~~~~~~~
>
> -----Original Message-----
> From: Howard Frazier [mailto:millardo@xxxxxxxxxxxxxxxxxx]
> Sent: Friday, May 17, 2002 10:03 AM
> To: stds-802-3@ieee.org; stds-802-3-efm@ieee.org
> Subject: [EFM] 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.
> > >