On 02/08/05, Proinnsias Breathnach <proinnsias at linux.ie> wrote:
> On Tue, Aug 02, 2005 at 01:09:05PM +0100, Stephen Reilly wrote:
> > In my experience
> > "Within most organisations network fileservers exist. Generally
> > employees have access to some portion of that service."
> Until your organisation has dozens of offices and thousands of
> employees. Those with whom you correspond do not always have access to
> the same file-shares (including read-only access).
Granted and I have worked in such an environment in the past. In that
case though we had FTP servers made available and instructions sent to
parties wishing to transfer large files internationally. We had
written "easy to use"(tm) front end clients to facilitate this.
(Server backbone was Redhat at the time) I'm aware of the limitations
involved in implementing this solution however. John's suggestion in
another thread to strip the attachment and replace with a link to a
central repository is still the most practical to come from this
discussion. There are software packages available which use email
attachment caching to this end.
I would prefer if when large files were being sent that it became a
pull rather than push mechanism. As an email recipient I would rather
have the choice whether or not to receive such a file. Of course the
easy way for me to do this is to use a web based mail client :) Email
can often form quite an important role in an organisation's
communications. Therefore having it slowed dramatically or in extreme
cases rendered unusable because someone attached a large file to a
mail is not acceptable. On the other hand most employees with email
access will have the ability and knowledge to attach files to their
mails. This makes it currently the easiest method for a non technical
user to transfer files, nobody is disputing that fact. Unfortunately
in my own experience on a standard corporate network email attachments
form a large portion of network traffic. If left unchecked this could
greatly increase necessary expenditure on infrastructure to support
such a resource. Large file attachments are a bad thing from the
network's point of view. In that sense every other possible method of
transferring large files, except the extremes that I'm sure someone is
currently racking their brains to come up with ;), is preferable. Even
to the point of burning a cd and posting it. The network
provider/maintainer must decide based on analysis of his/her network
what size restrictions to apply to email attachments because they are
and will remain a necessary evil. It may be that they can support
email attachments over 100Mbs in which case more power to them. If
however certain groups of employees were identified as being the
minority that require this resource they could have alternate methods
made available to them (with relevant training).
> and there's no way of uploading stuff to external ones (even if the
> practice wouldn't get you fired in seconds !).
>From a purely technical perspective there are a number of ways to
> That said, it is both painful, and wrong, to attach anything greater
> than (approx) 1MB to an email without it either being requested or
> warning the recipient in advance.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!