🚀 go-pugleaf

According to Tyler Yip - UnixWeenie(tm) <davros@ecst.csuchico.edu>:
:Anyway we could find out how much mail is backlogged on gangrene?

Not in general.  At the time you sent this message, I happened to be
looking at gangrene's queue, so I know that there were a little over 11,000
messages waiting to be sent out.  By a few hours later, it appeared that
they had all been sent out.  At the time of this writing, there are 1,288
messages in the queue.

As best as I can tell, the main problem is that the combination of HP-UX
and HP hardware just can't handle the volume of email we receive any
faster.  Basically, the I/O system is going just as fast as it can, but it
isn't nearly fast enough for our needs.  I hope to get this resolved over
intersession.

As always, suggestions are welcome.

-- 
Py -- 3.141592653589793238462643383279502884197169399375105...
Pythagoras Watson -- "Live long and may all your kernels pop."
INET: py@ecst.csuchico.edu === COMPUSERVE: cspy@compuserve.com

In article <732441$sf2$1@hubble.csuchico.edu>,
Pythagoras Watson <py@ecst.csuchico.edu> wrote:
>According to Tyler Yip - UnixWeenie(tm) <davros@ecst.csuchico.edu>:
>:Anyway we could find out how much mail is backlogged on gangrene?
>
>
>As always, suggestions are welcome.
>

Dump qmail.

Get sendmail 8.9.1 or whatever is current and configure it for cached
connections to spam for delivery,

in your .mc file, add:
define(`confCON_EXPENSIVE', `true')
define(`SMTP_MAILER_FLAGS', `emDFMUX')
define(`confSAFE_QUEUE')
define(`confMCI_CACHE_SIZE', 1)
define(`confMCI_CACHE_TIMEOUT', 30s)
define(`confSINGLE_THREAD_DELIVERY', `true')
define(`confHOST_STATUS_DIRECTORY', `/etc/mail/hoststatus')

build your .cf file, create the /etc/mail/hoststatus directory, and
start sendmail.  This will get sendmail to cache up to 8 connections and keep
them open for 30 seconds, thus reducing connection cost overhead between
gangrene and spam.

CON_EXPENSIVE says that all mail for expensive mailers is queued rather
than handled immediately.

the SMTP_MAILER_FLAGS tags adds the expensive flag to SMTP mailer.

SAFE_QUEUE causes all mail to be committed to disk before further processing
(this keeps messages from being lost in the event of a crash)

MCI_CACHE_SIZE and MCI_CACHE_TIMEOUT set the number of connections and idle
timeout for each of the connections on over-the-network mailers.

SINGLE_THREAD_DELIVERY causes sendmail to limit itself to only one connection
to any single remote host.

HOST_STATUS_DIRECTORY is a directory tree that stores the status of cached
connections.

The results of this is that it allows the maximal throughput between two
MTA's where the receiving MTA may not be able to handle as much I/O as the
sending MTA can send.  This reduces the system impact on the receiving MTA
caused by the sending MTA initiating a new connection for every message that
arrives.  Instead, gangrene would immediately queue all inbound mail, and then
line them all up in single line heading for only one door to spam.  Every
message runs through the door to spam as fast as they can single file.
Be sure to set the queue time in the command line invokation of sendmail
to something short so as to provide reasonably prompt processing of the
queued mail.
-- 
Tyler Yip            : @Home Network        : http://www.home.net
System Administrator : 425 Broadway         :
tyler@corp.home.net  : Redwood City, Calif. : @Home - Unreasonably Fast

In article <732441$sf2$1@hubble.csuchico.edu>,
Pythagoras Watson <py@ecst.csuchico.edu> wrote:
>I hope to get this resolved over intersession.

Just say when.  I keep getting dropped off the GTK+ mailing list due to
excessive failures.  :-(

-Beej

According to Tyler Yip - UnixWeenie(tm) <davros@ecst.csuchico.edu>:
:In article <732441$sf2$1@hubble.csuchico.edu>,
:Pythagoras Watson <py@ecst.csuchico.edu> wrote:
:>According to Tyler Yip - UnixWeenie(tm) <davros@ecst.csuchico.edu>:
:>:Anyway we could find out how much mail is backlogged on gangrene?
:>
:>As always, suggestions are welcome.
:
:Dump qmail.
:
:Get sendmail 8.9.1 or whatever is current and configure it for cached
:connections to spam for delivery,

For various reasons, this is what I was thinking of doing, although the
specifics you provided will surely prove useful.  If VMailer isn't
officially released by January, then sendmail should make its way onto our
machines again before the start of next semester.

I did throw a quick hack into a piece of qmail today that brought the queue
from 5000+ and growing down to 133 in about three hours.  It looks
promising, but I don't like to get too excited until it proves itself for a
few days.

-- 
Py -- 3.141592653589793238462643383279502884197169399375105...
Pythagoras Watson -- "Live long and may all your kernels pop."
INET: py@ecst.csuchico.edu === COMPUSERVE: cspy@compuserve.com

According to Brian 'Beej' Hall <beej@ecst.csuchico.edu>:
:In article <732441$sf2$1@hubble.csuchico.edu>,
:Pythagoras Watson <py@ecst.csuchico.edu> wrote:
:>I hope to get this resolved over intersession.
:
:Just say when.  I keep getting dropped off the GTK+ mailing list due to
:excessive failures.  :-(

Well, I did throw a quick hack into a piece of qmail today that brought the
queue from 5000+ and growing down to 133 in about three hours.  It looks
promising, but I don't like to get too excited until it proves itself for a
few days.

That said, I am a little confused as to what failures have been occurring.
Mail shouldn't have failed in any way.  Instead, it should have been merely
a lot slower.  Queuing up during the day, and getting delivered at night.
Can you provide me with more specifics? This could be indicative of a
different problem.

-- 
Py -- 3.141592653589793238462643383279502884197169399375105...
Pythagoras Watson -- "Live long and may all your kernels pop."
INET: py@ecst.csuchico.edu === COMPUSERVE: cspy@compuserve.com

In article <73313q$ch$1@hubble.csuchico.edu>,
Pythagoras Watson <py@ecst.csuchico.edu> wrote:
>That said, I am a little confused as to what failures have been occurring.
>Mail shouldn't have failed in any way.  Instead, it should have been merely
>a lot slower.  Queuing up during the day, and getting delivered at night.
>Can you provide me with more specifics? This could be indicative of a
>different problem.

I deleted their memo, but I'll resubscribe and tell you if it happens
again.

-Beej