Re: Save the Bandwidth -smarter way to send the same file attachment to N users?
From: KK (kewlkarun_at_yahoo.com)
Date: 02/15/04
- Previous message: Stoyan Stoyanov: "read/write to a character device"
- In reply to: Kirk Strauser: "Re: Save the Bandwidth -smarter way to send the same file attachment to N users?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 15 Feb 2004 00:17:08 -0800
Kirk & Mina, thank you for throwing light on this topic. There is one
thing that still bothers me. I dont need a password to access the mail
server (mail.cs.college.edu) where as, I 'must' supply a passwd to
access the attachment stored in the server (cs.college.edu). my perl
program does not contain the feature of incorporating the password.
Are you suggesting to incorporate this feature? If yes, How can I
achieve this?
Regards,
-KK
Kirk Strauser <kirk@strauser.com> wrote in message news:<87u11t80ed.fsf@strauser.com>...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> At 2004-02-14T23:01:03Z, Mina Naguib <spam@thecouch.homeip.net> writes:
>
> > Email was not designed with file attachments in mind. Every time you send
> > a binary attachment, it has to be ASCII-armoured which increases it's
> > size, often 2-3 times the original binary file size.
>
> Almost never. Base64 encoding uses a 7-bit ASCII character to represent 6
> bits from the attachment, so it has a 33% overhead. Note that the resulting
> encoding is trivially compressible to nearly the original size; any
> intermediate storage or transfer mechanism that uses compression (such as
> TLS) will use almost no more space than the original file.
>
> > HTTP and FTP are good ways to send files. Put your file on such aq
> > server and include a simple link to it in your e-mail.
>
> I disagree. Why?
>
> 1) When you send email, *you* control when you're going to use your
> bandwidth. If you sent out 10,000 links to a file on your server, and
> everyone decides to follow the link at the same time, then you might be
> in trouble.
>
> 2) Modern MTAs merge transmitions to given domains. If 2500 out of your
> 10,000 emails are to aol.com users, then your mailserver could
> reasonably send exactly one mail to aol.com, and specify that it should
> go to all 2500 recipients. That mitigates the bandwidth factor
> somewhat.
>
> 3) People are lazy. If you're trying to send, say, a monthly newsletter
> in PDF form to your customers, then the odds of them opening an
> attachment are *much* higher than them clicking on a link to open a
> browser and visit a webpage. Plus, if the file is on their mailserver
> or their client, then they don't have to re-download it from you if
> they want to view it again a month from now.
>
> 4) When you sent email, you're making an *outbound* connection. When you
> host the files locally, you have to configure your firewall and
> services to allow access to the files in question but nothing more.
> From a security point of view, I'd much rather establish connections
> than accept them.
>
> FTP and HTTP obviously have their uses, but it's not fair to use the reason
> that "email was not designed" to recommend against doing exactly that. It
> has its place.
> - --
> Kirk Strauser
> The Strauser Group
> Open. Solutions. Simple.
> http://www.strausergroup.com/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFALuz+5sRg+Y0CpvERAowvAJ9nDaPI0SYP4WrxcQTfApR17KJ99QCfed87
> jjR+GguN+F2O6ASi60bSZMI=
> =v42d
> -----END PGP SIGNATURE-----
- Previous message: Stoyan Stoyanov: "read/write to a character device"
- In reply to: Kirk Strauser: "Re: Save the Bandwidth -smarter way to send the same file attachment to N users?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
