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

Discussion in 'Perl Misc' started by KK, Feb 14, 2004.

  1. KK

    KK Guest

    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
     
    KK, Feb 14, 2004
    #1
    1. Advertising

  2. KK

    Mina Naguib Guest

    Re: Save the Bandwidth -smarter way to send the same file attachmentto N users?

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



    KK wrote:
    > 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-----
     
    Mina Naguib, Feb 14, 2004
    #2
    1. Advertising

  3. Re: Save the Bandwidth -smarter way to send the same fileattachment to N users?

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

    At 2004-02-14T23:01:03Z, Mina Naguib <> 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-----
     
    Kirk Strauser, Feb 15, 2004
    #3
  4. KK

    KK Guest

    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 <> wrote in message news:<>...
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > At 2004-02-14T23:01:03Z, Mina Naguib <> 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-----
     
    KK, Feb 15, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. DanB
    Replies:
    8
    Views:
    534
  2. Shawn
    Replies:
    2
    Views:
    376
    =?Utf-8?B?RWx0b24gVw==?=
    Feb 19, 2006
  3. Max M

    Smarter way of doing this?

    Max M, Feb 2, 2004, in forum: Python
    Replies:
    13
    Views:
    444
    Anton Vredegoor
    Feb 5, 2004
  4. BenjaMinster
    Replies:
    1
    Views:
    325
    =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
    Dec 17, 2006
  5. id10t error
    Replies:
    3
    Views:
    733
    Alexey Smirnov
    Aug 31, 2009
Loading...

Share This Page