[SGVLUG] Anyone know about Postfix on Linux?

[Stan Schwarz]

> > the mail senidng being slow?  One thing that I would look at 
> > right off the bat is your name resolution settings.

This is a good point. Each of the mail sender machines has a 
caching name server running on it for just this reason. It's a 
local name server that's configured to only respond to queries
from localhost.

> > On Wed, Sep 05, 2007 at 11:34:26AM -0700, Stan Schwarz wrote:
> > > I run the Earthquake Notification System here ...
> > > I'm trying to achieve faster-than-a-speeding-spammer mail 
> > > sends, since everyone wants to know about earthquakes right after
> 
> Gareth's comment brings to mind the thought of pre-sorting your
> addresses: I presume your database of "people who want to know about an
> event" grows slowly over time, with changes being far less common [and
> deletions even more so!] EXCEPT when there is a major event, but they

It's a bit more complicated than that. The people in the database
are in there with rule associated with their addresses. The rules
cover different geographic areas and minimum magnitude limits, as
well as day and night times for their address, so users can set a
higher notification level at night. (This is important for users
with cell phones and pagers.) So the list for any given earthquake
will depend on the magnitude, its location on the earth, and what
time of day it is.

> (*) of course, this raises an interesting dilemma: should you send
> messages to folks you know are physically located near an event first or
> last?  By their proximity alone, they will be the ones most interested

The list of addresses comes out of the database sorted by 'userclass',
which means that people who work in the earthquake research community
and emergency responders come out first.

> You mentioned flow_delay -- In addition to pre-sorting, you might
> consider partitioning the data and building multiple VIRTUAL postfix
> "servers" on a given machine. [or send them to multiple physical

This is already happending. There are five machines. One of them
is designated as the 'primary', and it receives earthquakes and
generates the messages for them. The messages are put into a table
in the database. There is a mail-send process running on each 
machine, and they all dip into that table to get messages to send.
So each machine has something like 140 smtp processes sending
mail in parallel, and there are five machines doing this.

When I was first setting this up, I looked at spam engines just to
get an idea of how fast they claim to be able to send mail. My system
blows the chips off theirs. They think that sending 10 messages/sec
is fast. I do 10 times that.

All that said, I did find the problem. And it was a stupid-simple
one. The machine that had the problem was running RedHat, and it
had been configured to run Postfix. But the guy who set it up
had not changed the link for sendmail:

 /usr/sbin/sendmail -> /etc/alternatives/mta

The file /etc/alterntives/mta is a link that points to the 
actual binary used to send mail. By default, this points to
/usr/sbin/sendmail.sendmail. I changed it to:

 /etc/alternatives/mta -> /usr/sbin/sendmail.postfix

The problem was that the actual Sendmail sendmail is a huge
program, and starting it up takes a long time. The Postfix
sendmail program is much lighter-weight, and it starts much
faster. So my Perl script that's looping through the addresses
it got out of the database could only start one sendmail.sendmail
process per second, but using the sendmail.postfix, it can do
something like 20/sec.

So, problem solved. It was just a matter of my not being all
that familiar yet with how things work in the Linux world.

-- 
-----------------------------------------------------------------
Stan Schwarz              |"Sun likely will have to embrace Linux
stan at iron.gps.caltech.edu | and eat their own children, or watch 
                          | IBM and HP do it instead." - crn.com
- http://pasadena.wr.usgs.gov/stans -----------------------------