Save the Bandwidth -smarter way to send the same file attachment to N users?

[KK]

Hi, my program can send mails to several people (nothing to do with
SPAM) with an attachment. However, in that process, everytime I send a
mail to a new user, I need to upload the attachment. I have access to
store files at the host & wondering if I can exploit this in saving
bandwidth ? (to be precise, I have access to store files with login&
passwd at cs.college.edu & its mail server is mail.cs.college.edu).
I'm a newbie to perl programming, detailed explaination is highly
appreciated.

Secondly, in this process of sending mails (using mail::sender
package) to N (say 3000) users, do I choke the mail server? If yes,
how to introduce delay in between sending mails?
regards,
KK

 

[Mina Naguib]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, my program can send mails to several people (nothing to do with
SPAM) with an attachment. However, in that process, everytime I send a
mail to a new user, I need to upload the attachment. I have access to
store files at the host & wondering if I can exploit this in saving
bandwidth ? (to be precise, I have access to store files with login&
passwd at cs.college.edu & its mail server is mail.cs.college.edu).
I'm a newbie to perl programming, detailed explaination is highly
appreciated.

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.

In your case of multi-recipients, it's also a lot of space on the mail
server.

HTTP and FTP are good ways to send files. Put your file on such a
server and include a simple link to it in your e-mail.

Secondly, in this process of sending mails (using mail::sender
package) to N (say 3000) users, do I choke the mail server? If yes,
how to introduce delay in between sending mails?

To introduce delays between anything in perl, see `perldoc -f sleep`

Regarding choking the mailserver, it depends on the mailserver setup.
Hotmail-style server farms will handle 3000 messages without a hitch, an
old 386 sitting under someone's desk may choke.

If your email content is static (does not change from recipient to
recipient) and all your recipients are on the same mail server, SMTP
might not be the best way to go. Talk to your email server
administrator to see if (s)he can setup the "hard-link" trick for you,
or if the mail software in use has any specific multi-recipient
features. This will cause the space requirements on the server to be
the message size, and not the message size X number of recipients. It
will also alleviate the CPU and network load involved in talking SMTP
for that many recipients.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFALqi0eS99pGMif6wRAhYzAJ0aLRZ7mk3l2LrG3HosGG6Rra8KZACeLjzv
WZC1plFBAWjhH++ZyNPQI0I=
=XWb8
-----END PGP SIGNATURE-----

 

[Kirk Strauser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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-----

 

[KK]

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