• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 192
  • Last Modified:

Help with Mass Mailing System

A client of mine wants to setup a mailing list of about 80000 addresses (N.B this is for legitimate reasons and not for spam!!)

Each user will be sent an html email. Users will have to be able to unsubscribe from the list by either following a link or sending an email.

the server is a pIII/256M Ram on a 4M connection and the OS will be freeBSD or LINUX

Does anybody know:

A. how to go about sending 80000 emails in the firstplace?
(will the server i have hack it ??)
B. how to run the automated unsubscription?

i have thought about using majordomo but i'm not sure if this is the right application for this.?

your help would be most appreciated.

regards

mike
0
mikeee12
Asked:
mikeee12
1 Solution
 
jlevieCommented:
Whether to use majordomo, Mailman, etc. depends in part of what you are trying to accomplish. Those applications implement mail lists which, by their definition are intended to be a two-way exchange, meaning that anyone on the list can submit a message for distribution to the list members. If what you want is simply a mass mailer that recipents cannot submit messages to, then they may not be the best solution. BTW: Mailman (http://www.list.org/) is considered by lots of folks that I've talked to to be the logical successor to majordomo.

On the assumption that you are talking about a mass mailer, the basic problem with a list that big is controlling the rate of message submission so that you don't overwhelm the server and drive the load average up to the point that sendmail stops accepting transactions. Ideally that should be done in an intelligent manner by monitoring the load average of the number of sendmail processes active and adusting the rate of submission accordingly. I haven't looked carefully to see, but I assume that real mail list packages include this sort of throttling mechanism. I know that I've had to include an 'intelligent throttle" in mass mailers for much smaller lists (~1K addresses).

And to some degree the amount of memory on the box will influence how many simultaneous sendmail processes is reasonable. I suspect that you may be really, really, shy of memory for that sized list and Internet link. Just as a guess I suspect that 2GB or more wouldn't be too much memory. Remember, when delivering to Internet mail servers that some will be more responsive than others and some of the sendmail processes will have a "longer life" than others. One thing that you don't want the system to do is to start swapping sendmail processes.

I don't know what kind of disks the system has, but I suspect IDE. You probably need to consider changing to SCSI and placing /var/spool on a separate disk. Each and every email that is sent will cause files to be created and deleted by sendmail. IDE disks are not known for their ability to handle lots of I/O request and they disks are likely to limit the server's ability to process email transactions.

Given enough memory and fast disks, you probably will want to tune sendmail to  raise the load average limit. It's probably also a good idea to look at deferring DNS lookups until actual message delivery (sendmail will normally try to verify the deliverability via a DNS lookup when handed the message... see the Sendmail book).

Subscribe/Unsubscribe mechanisms can be handled via email piped to a program or script or via a web page. If you are "rolling your own" I suspect that a web interface is probably silghtly easier to implement. And I'm pretty sure that it is more "user friendly" than a mail mechanism.
0
 
psimationCommented:
also listening here, have a similar question in Linux topic area...
0
 
mikeee12Author Commented:
Thanks,

Definatly going to upgrade the ram!!
Now all it need to figure is the mechanism for sending the email.
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now