OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: RE: Some questions on postfix, SUMMARY
From: Karimov, Rashid (NBC, CNBC) (Rashid.Karimovnbc.com)
Date: Thu Mar 02 2000 - 15:31:45 CST

Thank you all for timely responses.

Here's the summary of what I've gathered from the replies:

A. The fastest/easiest way to generate the messages (see the original
post)
        is to use SMTP to inject messages into postfix and let it handle the
rest.
        Here is the logic (I am a bit rusty here):

        for all recepients {
                generate message
                fork or new thread
                        SMTP into postfix (enable it to relay)
                end
        }
        
        The benefits are clear: very simple, clean, no maintenance required
        as postfix changes/improves, fast (?).

        Possible problems:
        
        1. Too many recepients and long enough messages can potentially lead
                to many (and I mean many!) threads/processes doing SMTP at
the
                same time into a single (having a few would help) postfix
relay.
                One might even have to throttle .

        2. If the SMTP server (postfix(es) you're realying to) are down, you
                wouldn't be able to generate the messages (there is no way
to
                spool them, unless you code for it).

B. Another way is to link your app against the same routines that
sendmail
        uses to generate a message in the maildrop (enqueue() in
sendmail.c).

                for all recepients {
                generate message
                enqueue(.......)
        }

        This one I am getting a mixed feeling about.

        I am being told (by a whole buncha people, including Wietse) that
SMTP would
        be faster here, and w/o having test data I can not disagree with
that :)

        Possible problems with that:
        
        1. Inner working of postfix might change, and some1 has to maintain
the
                custom code.

        2. (??) It is no faster (slower ?) than the SMTP version

C. Is modification of B, when instead of directly using the same
routines
        as sendmail uses, one just fork()s and exec*() sendmail program to
drop
        the message into the maildrop.

        Possible problems with that:

        1. On a slow system, fork()/exec() pair will be slow :)

D. Using NFS to let message generators to populate the maildrop is
        not a good idea due to usual problems with NFS. How about NFS V3
        on a fast NFS server, say Net App toaster ?

E. Can some1 provide some data as to how many messages are generated
locally
        in what time (we're looking to 50K - 1Mil in a HURRY !), size is
under 4K.
        
        How long would it take to fan them out to Internet, assuming regular
client
        mix (AOL/Hotmail/etc) ? What do folx use in terms setting on postfix
systems ?

F. We have quite different setup here, as compared to an ISP/.edu - we
do not
        send mail on behalf/for regular subs, which is usually pretty
random.

        We _generate_ the messages in large batches and we always have to
deliver
        it in timely fashion ... ASAP that is :)

        Any suggestions are appreciated :)

        Once again, thank you for the responses.

Rashid
        

        Because e-mail can be altered electronically,
        the integrity of this communication cannot be guaranteed.