FAQ
I have a mailing-list, where only I post. And 2000 users are subscribed
on it

I searched on the mailman list archive, FAQ and other places, but I
couldn't find a proper answer, so I'm asking here.

Many users of the mailing-list are on the same domain. I'd like know if
the mailman send the e-mail addresses to sendmail (my MTA) in domain
order, or if it ignore this, sending with no order. Or if sendmail can
do this job (is it the default?), optimizing the transfer of the message
to the list. How this work?

thanks in advance,
Klaubert Herr

Search Discussions

  • Paul Tomblin at Nov 17, 1999 at 2:14 pm

    Quoting Klaubert Herr da Silveira (klaubert at bcb.gov.br):
    Many users of the mailing-list are on the same domain. I'd like know if
    the mailman send the e-mail addresses to sendmail (my MTA) in domain
    order, or if it ignore this, sending with no order. Or if sendmail can
    do this job (is it the default?), optimizing the transfer of the message
    to the list. How this work?
    From looking at my sendmail logs, mailman does the right thing when it splits
    up a message to multiple MTA processes and gives all the messages for people
    @panix.com to the same process, etc. And sendmail *definitely* does the right
    thing and sends only one message to panix.com.

    --
    Paul Tomblin, not speaking for anybody.
    SETI at Home: Finally a *good* way to impress Jodie Foster
    http://www.setiathome.ssl.berkeley.edu/
  • J C Lawrence at Nov 17, 1999 at 7:26 pm

    On Wed, 17 Nov 1999 11:52:23 -0200 Klaubert Herr da Silveira wrote:

    Many users of the mailing-list are on the same domain. I'd like
    know if the mailman send the e-mail addresses to sendmail (my MTA)
    in domain order, or if it ignore this, sending with no order. Or
    if sendmail can do this job (is it the default?), optimizing the
    transfer of the message to the list. How this work?
    Sendmail will not do this for you. MailMan can be persuaded to, but
    I wouldn't bother. A better choice is to use a better MTA than
    Sendmail, which has better (faster and more optimised) delivery and
    queue running functionality than Sendmail. Two good choices are:

    Exim http://www.exim.org/
    Postfix http://www.postfix.org

    Unlike Sendmail, such efficient MTAs will automatically order the
    messages they deliver in the most efficient fashion.

    --
    J C Lawrence Internet: claw at kanga.nu
    ----------(*) Internet: coder at kanga.nu
    ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...
  • Paul Tomblin at Nov 17, 1999 at 7:47 pm

    Quoting J C Lawrence (claw at cp.net):
    Sendmail will not do this for you. MailMan can be persuaded to, but
    Wrong. Sendmail *does* do this for you. If you have a bunch of people on a
    list in random order, sendmail will work through the list in order, but every
    time it connects to a domain, it will send one message to *all* the members of
    the list at that domain. One of my most popular lists has at least 30% of its
    subscribers at panix.com, and another 10% at best.com. When it was on
    majordomo, the entire list was passed off to sendmail in one chunk. Since one
    of the panix.com people is first on the list, all the panixians got their mail
    first, then a few more people, then all the people at best.com, etc. Now that
    I'm using mailman, and it's split into 5 chunks, I've noticed that one of the
    chunks is all panixians, which goes in one message to panix, and one of the
    chunks is almost all bestians, which also goes in one message.

    --
    Paul Tomblin, not speaking for anybody.
    SETI at Home: Finally a *good* way to impress Jodie Foster
    http://www.setiathome.ssl.berkeley.edu/
  • Jerry Adlersfluegel at Nov 17, 1999 at 8:08 pm

    On Wed, 17 Nov 1999, Paul Tomblin wrote:

    Wrong. Sendmail *does* do this for you. If you have a bunch of people on a
    list in random order, sendmail will work through the list in order, but every
    time it connects to a domain, it will send one message to *all* the members of
    the list at that domain. One of my most popular lists has at least 30% of its
    subscribers at panix.com, and another 10% at best.com. When it was on
    majordomo, the entire list was passed off to sendmail in one chunk. Since one
    of the panix.com people is first on the list, all the panixians got their mail
    first, then a few more people, then all the people at best.com, etc. Now that
    I'm using mailman, and it's split into 5 chunks, I've noticed that one of the
    chunks is all panixians, which goes in one message to panix, and one of the
    chunks is almost all bestians, which also goes in one message.
    This is similar to what I see with my mailman/sendmail setup. It seems
    pretty well thought out.

    --
    Jerry Adlersfluegel
  • J C Lawrence at Nov 17, 1999 at 8:41 pm

    On Wed, 17 Nov 1999 14:47:53 -0500 Paul Tomblin wrote:

    Quoting J C Lawrence (claw at cp.net):
    Sendmail will not do this for you. MailMan can be persuaded to...
    Wrong. Sendmail *does* do this for you. If you have a bunch of
    people on a list in random order, sendmail will work through the
    list in order, but every time it connects to a domain, it will
    send one message to *all* the members of the list at that domain.
    Not quite true, but close.
    One of my most popular lists has at least 30% of its subscribers
    at panix.com, and another 10% at best.com. When it was on
    majordomo, the entire list was passed off to sendmail in one
    chunk. Since one of the panix.com people is first on the list,
    all the panixians got their mail first, then a few more people,
    then all the people at best.com, etc. Now that I'm using mailman,
    and it's split into 5 chunks, I've noticed that one of the chunks
    is all panixians, which goes in one message to panix, and one of
    the chunks is almost all bestians, which also goes in one message.
    The chunks you are describing are messages with some number (100 is
    typical) of RCPT TOs tagetting them at a number of recipient
    addresses. Thusly your MTA can have a single message with a long
    list of addresses to which it is to be delivered. (cf VERP which
    does the exact opposite)

    I should be more specific:

    Given N messages in the mail spool where each message has
    (pessimally) a single RCPT TO, and many of those messages are
    targetted at the same domain:

    In that case, when Sendmail succeeds in delivering a single
    message to domain X it will not then immediately attempt to deliver
    the rest of the mesages targeted at domain X, either by the same
    connection, or via other connections under other queue runners.
    Instead it will deliver one, and then move on to the next message in
    the queue and attempt to deliver that, ignoring the fact of what
    domain it is targetted at.

    Your case which you report above is that of a single message with a
    large number of RCPT TOs to the same domain. There is no wonder in
    that message being delivered to the target MX in a single
    transaction. The sadness is that if you had had multiple such
    messages, say for instance under MailMan you had 500 WorldNet users
    subscribed and thus 5 such messages each with 100 RCTP TOs, or
    worse, with the same subscriber base, but the RCPT TOs ordered willy
    nilly across the messages, that those 5 (or more) would not have
    been delivered in a single pass by a single queue runner, but would
    instead have been processed in queue order one at a time, as the
    queue runners encountered them..

    Other MTA's do not share this weakness. Exim for instance, no
    matter how many messages were in the queue, and no matter what the
    distribution of RCTP TOs across those messages, upon successfull
    delivery of _one_ would then immediately attempt to deliver the rest
    to the same MX.

    --
    J C Lawrence Internet: claw at kanga.nu
    ----------(*) Internet: coder at kanga.nu
    ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...
  • Paul Tomblin at Nov 17, 1999 at 8:52 pm

    Quoting J C Lawrence (claw at cp.net):
    Your case which you report above is that of a single message with a
    large number of RCPT TOs to the same domain. There is no wonder in
    that message being delivered to the target MX in a single
    transaction. The sadness is that if you had had multiple such
    You're right, sendmail only does the optimization within a single message, not
    across all the messages in the queue. I've been thinking about another MTA,
    but qmail means dealing with Dan B, which I'd rather not do because he's a
    horrendous jerk in any newsgroup that dares mention qmail in an
    uncomplimentary way, and my only exposure to exim was being yelled at by an
    admin at an ISP who had configured his version of exim in a way that was
    specifically prohibited by RFC822 and refused to fix it because it "stopped
    spam" (at the expense of stopping a great deal of legitimate mail, including
    my mailing list). Is Postfix any better?

    --
    Paul Tomblin, not speaking for anybody.
    SETI at Home: Finally a *good* way to impress Jodie Foster
    http://www.setiathome.ssl.berkeley.edu/
  • J C Lawrence at Nov 17, 1999 at 9:16 pm

    On Wed, 17 Nov 1999 15:52:22 -0500 Paul Tomblin wrote:

    Quoting J C Lawrence (claw at cp.net):
    Your case which you report above is that of a single message with
    a large number of RCPT TOs to the same domain. There is no
    wonder in that message being delivered to the target MX in a
    single transaction.
    You're right, sendmail only does the optimization within a single
    message, not across all the messages in the queue.
    nod>
    I've been thinking about another MTA, but qmail means dealing with
    Dan B, which I'd rather not do because he's a horrendous jerk in
    any newsgroup that dares mention qmail in an uncomplimentary
    way...
    I have similar reservation on Dan Bernstein. While I've been
    impressed with the thru-puts that QMail can accomplish (CP here uses
    a QMail derivative), due to Dan's behaviour it is not one I freely
    recommend.
    ... and my only exposure to exim was being yelled at by an admin
    at an ISP who had configured his version of exim in a way that was
    specifically prohibited by RFC822 and refused to fix it because it
    "stopped spam" (at the expense of stopping a great deal of
    legitimate mail, including my mailing list).
    The behaviour of a single admin hardly reflect on the MTA entire. I
    like Exim. Phillip Hazel (the author) is responsive and active on
    the mailing list that supports it. The config files are human
    readable and easy to understand. The admin controls and logging are
    well developed. Performance is good and often similar to QMail and
    Postfix. And best of all: I don't need a Bat Book.
    Is Postfix any better?
    Postfix is impressive. I've been archiving the Postfix lists at
    Kanga.Nu for a while now, but don't run the MTA myself yet (happy
    with Exim and more more important fish to fry than an MTA change).
    I have a number of friends, some running large sites and large mail
    loads, that are happily running Postfix. I'm encouraged by the
    traffic I see on the lists and by Vietse's behaviour on the lists
    (especially compared to Dan B).

    --
    J C Lawrence Internet: claw at kanga.nu
    ----------(*) Internet: coder at kanga.nu
    ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...
  • Ivan Van Laningham at Nov 17, 1999 at 9:52 pm
    Hi All--

    J C Lawrence wrote:
    >

    [bobbitt]
    J C Lawrence Internet: claw at kanga.nu
    ----------(*) Internet: coder at kanga.nu
    ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...
    Uh, is that Clan McFud as in "I am J C Lawrence of the Clan McFud.
    There can be only one!"

    <try-to-keep-your-head>-ly y'rs,
    Ivan;-)
    ----------------------------------------------
    Ivan Van Laningham
    Callware Technologies, Inc.
    ivanlan at callware.com
    ivanlan at home.com
    http://www.pauahtun.org
    See also:
    http://www.foretec.com/python/workshops/1998-11/proceedings.html
    Army Signal Corps: Cu Chi, Class of '70
    Author: Teach Yourself Python in 24 Hours
    ----------------------------------------------
  • J C Lawrence at Nov 17, 1999 at 11:59 pm

    On Wed, 17 Nov 1999 14:52:05 -0700 Ivan Van Laningham wrote:

    Uh, is that Clan McFud as in "I am J C Lawrence of the Clan McFud.
    There can be only one!"
    Its much closer to the fact that I used to work for IBM...

    --
    J C Lawrence Internet: claw at kanga.nu
    ----------(*) Internet: coder at kanga.nu
    ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...
  • Barry A. Warsaw at Nov 18, 1999 at 2:04 am
    "JCL" == J C Lawrence <claw at cp.net> writes:
    JCL> Postfix is impressive. I've been archiving the Postfix lists
    JCL> at Kanga.Nu for a while now, but don't run the MTA myself yet
    JCL> (happy with Exim and more more important fish to fry than an
    JCL> MTA change). I have a number of friends, some running large
    JCL> sites and large mail loads, that are happily running Postfix.
    JCL> I'm encouraged by the traffic I see on the lists and by
    JCL> Vietse's behaviour on the lists (especially compared to Dan
    JCL> B).

    I looked at a bunch of MTAs when I got our new python.org Ultra2.
    Like almost everyone else, I just can't deal with sendmail's
    atrocious complexity (of which even the bat book only begins to help
    with). Based on all the comments here, I looked at qmail, exim, and
    postfix. My time is limited so I figured I'd only get a chance to
    really dig deeply into one of them, and if that was successful, would
    not actually install and play with the others.

    I dismissed qmail ironically because it wasn't similar enough to
    sendmail in a few key areas (e.g. alias and .forward files). Those
    bits are easy to understand; we have a lot of different people
    potentially maintaing the mail system and I didn't want to have to
    worry about teaching them all the new interfaces. The stuff I'd read
    about dealing with the maintainer of qmail made me think twice too.

    I liked what I saw about exim, but I had some concerns about it's
    security. Maybe I am being overly paranoid (or ignorantly propagating
    unsubstantiated rumor :), but I didn't have time to start down that
    path to have to back out later.

    So that left postfix, and I liked what I read about it's performance
    and security. Obviously Wieste has plenty of credentials in the
    security arena. Postfix was very easy to get configured and installed
    exactly the way I wanted. My sole unresolved issue is the way it
    formats error messages when scripts filters exit with non-zero status
    (it wraps the script's output, which obvious messes with Python
    tracebacks :)

    Anyway, so far so good.
    -Barry
  • J C Lawrence at Nov 18, 1999 at 2:28 am

    On Wed, 17 Nov 1999 21:04:19 -0500 (EST) Barry A Warsaw wrote:

    I liked what I saw about exim, but I had some concerns about it's
    security. Maybe I am being overly paranoid (or ignorantly
    propagating unsubstantiated rumor :), but I didn't have time to
    start down that path to have to back out later.
    To flesh out this statement a little, and hopefully not write
    anything into your fingers (there's a slight imprecation there
    against Exim which I'm sure you didn't intend):

    Postfix and QMail are both built on similar security models where
    the service is provided by a slew of very small programs (small and
    thus easy to debug and secure), none of which trust each other, and
    all of which run with the very lowest possible privilege (ie never
    as root unless absolutely necessary etc on down to running as nobody
    where possible).

    Exim is descended from Smail, best known for its excellent UUCP
    mail capabilities, and shares SMail's (and factually Sendmail's)
    security model: a single large monolithic application which is
    trusted to "do the right thing". Now Sendmail of course has a long
    and hallowed history of "the exploit of the week". This is more the
    fault of Senmail's internal complexity and just crufty code than it
    is of the security model. It does however reveal a weakness in the
    security model: It allows large collections of complex code to
    survive. The highly divided security model used by Postfix et al
    mandate small concise chunks of code by insisting that any
    individual program only do one thing, and nothing but that thing.
    Thus there is the potential in Exim for complexity, and thus
    security concerns, to breed.

    As far as security histories go, few programs, almost encluding MS
    Windows, have as bad a history as Sendmail. However, that said,
    unlike Senmail, Exim has a very good history in this regard with no
    root exploits that I'm aware of, and only a few Denial of Service
    attacks that were very promptly addressed by the author.

    One should also note that neither QMail or Postfix has been totally
    exploit of DoS attack free. Dan Bernstein took great (and
    unpleasant) delight in pointing out a number of weaknesses in
    Wietse's original implementation of Postfix (which Wietse then
    addressed). More importantly they both, like Exim, have a long
    recent history of not having any known exploits, and come with the
    advantage of being built on a well known, well anmalysed, and very
    security concious design model.

    None of which says anything I think you (Barry) don't know, but hey.

    --
    J C Lawrence Internet: claw at kanga.nu
    ----------(*) Internet: coder at kanga.nu
    ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...
  • Barry A. Warsaw at Nov 18, 1999 at 2:39 am
    Very good post JC, thanks for the clarification. I definitely didn't
    mean to disparage Exim in any way.

    -Barry
  • Barry A. Warsaw at Nov 18, 1999 at 1:37 am
    "PT" == Paul Tomblin <ptomblin at xcski.com> writes:
    PT> Wrong. Sendmail *does* do this for you. If you have a bunch
    PT> of people on a list in random order, sendmail will work
    PT> through the list in order, but every time it connects to a
    PT> domain, it will send one message to *all* the members of the
    PT> list at that domain. One of my most popular lists has at
    PT> least 30% of its subscribers at panix.com, and another 10% at
    PT> best.com. When it was on majordomo, the entire list was
    PT> passed off to sendmail in one chunk. Since one of the
    PT> panix.com people is first on the list, all the panixians got
    PT> their mail first, then a few more people, then all the people
    PT> at best.com, etc. Now that I'm using mailman, and it's split
    PT> into 5 chunks, I've noticed that one of the chunks is all
    PT> panixians, which goes in one message to panix, and one of the
    PT> chunks is almost all bestians, which also goes in one message.

    So do you think the Mailman way is better or worse? I'm curious
    because I'm trying to decide whether I should port Mailman 1.0's bulk
    mailer code to the new message pipeline.

    In the current 1.2 code base (available via the anonCVS), I os.popen()
    sendmail[1] passing the entire recipient list on the command line,
    then I pipe the message text to stdin and let the MTA do the rest.
    There's one complication; if the length of the recipients list is
    greater than a certain length (current 3000), I chop it up into
    multiple popens, but I don't do any sorting of the recipient list.

    The advantage I see of this is that sendmail can do it's thing
    asychronously, without keeping the list object locked the entire
    time. The disadvantage is that Mailman is only aware of delivery
    problems if the delivery bounces.

    I could see trying to sort the recips on the domain name if the total
    length is > 3000. I can also see porting the local-smptd delivery
    scheme of the current bulk mailer, but fixing some of the problems in
    the 1.0 code base (and there are quite a few). I'm leary though of
    stepping on too much of the MTA's toes -- a good MTA should just do
    the right thing.

    Another alternative, which would be less work and delegates all
    delivery to the MTA, is to just pump all the recips to the local smtpd
    via smtplib.py. The advantage here is that again we're MTA
    independent, but the disadvantage is that Mailman's delivery is
    synchronous with the smtpd. We'd have to be very sure to unlock the
    list object during this transaction (but watching out for race
    conditions, locking again if failure status's are handled directly,
    etc.) More code, more opportunity for bugs.

    Comments?

    -Barry

    [1] I actually don't use sendmail, I use postfix, but the code is
    easily configured to use anything with a sendmail compatible command
    line interface.
  • Paul Tomblin at Nov 18, 1999 at 1:45 am

    Quoting Barry A. Warsaw (bwarsaw at cnri.reston.va.us):
    So do you think the Mailman way is better or worse? I'm curious
    because I'm trying to decide whether I should port Mailman 1.0's bulk
    mailer code to the new message pipeline.
    Personally, I think you should leave it to the MTA to make the decisions on
    how to deliver the mail more efficiently. Anybody who wants more parallelism
    can find an MTA to do that. And that leaves Mailman to concentrate on doing
    the things it does well, rather than second guessing the MTA.

    --
    Paul Tomblin, not speaking for anybody.
    SETI at Home: Finally a *good* way to impress Jodie Foster
    http://www.setiathome.ssl.berkeley.edu/
  • J C Lawrence at Nov 18, 1999 at 2:04 am

    On Wed, 17 Nov 1999 20:37:58 -0500 (EST) Barry A Warsaw wrote:

    So do you think the Mailman way is better or worse? I'm curious
    because I'm trying to decide whether I should port Mailman 1.0's
    bulk mailer code to the new message pipeline.
    MailMan's current code is definitely in the "good enough"
    category.
    In the current 1.2 code base (available via the anonCVS), I
    os.popen() sendmail[1] passing the entire recipient list on the
    command line, then I pipe the message text to stdin and let the
    MTA do the rest. There's one complication; if the length of the
    recipients list is greater than a certain length (current 3000), I
    chop it up into multiple popens, but I don't do any sorting of the
    recipient list.
    My view is that appropriate and efficient handling of mail for
    delivery is the domain of the MTA, and should not be the domain of
    MUA's (in which camp MailMan sorta falls). As such domain sorting
    is pleasant, it really only acts to further bolster technically
    lagging mail servers which are in need of new life anyways.
    The advantage I see of this is that sendmail can do it's thing
    asychronously, without keeping the list object locked the entire
    time. The disadvantage is that Mailman is only aware of delivery
    problems if the delivery bounces.
    Which of course requires a local MTA, which the current design
    doesn't.

    What actually needs to happen (presuming my current understanding of
    the source is correct) is that the abstraction of MailMan's internal
    mail queue needs to be finished. Then, a mail broadcast attempt
    would only stuff messages (cheaply) into the MailMan queue
    mechanism, and then return, unlocking the list objects. The queue
    object of course can be lock free (lockless DB's aren't difficult)
    and you then merely need to run a could of MailMan queue runners to
    pipe it to the MTA.

    One the messages are stuffed, you can then fork a queue runner,
    which, if there are already sufficient queue runners immediately
    dies. If more queue runners are needed however, it proceeds to grab
    messages and stuff them at the MTA in the normal fashion over SMTP.

    Note: If you do this adding VERP support becomes a doddle.
    I'm leary though of stepping on too much of the MTA's toes -- a
    good MTA should just do the right thing.
    This is perhaps the best point. Spending time to further bolster
    fading technologies when better services are freely available hardly
    seems worth it.
    Another alternative, which would be less work and delegates all
    delivery to the MTA, is to just pump all the recips to the local
    smtpd via smtplib.py. The advantage here is that again we're MTA
    independent, but the disadvantage is that Mailman's delivery is
    synchronous with the smtpd. We'd have to be very sure to unlock
    the list object during this transaction (but watching out for race
    conditions, locking again if failure status's are handled
    directly, etc.) More code, more opportunity for bugs.
    No no no no no no. MailMan oeprates asynchronously of the MTA, and
    because as a list server it generates unusual loads in itself, it
    cannot be subject to the perfoamcen vagaries of the MTA.

    Consider the case I used to commonly run into:

    Message arrives and is delivered to MailMan.

    MailMan explodes that message into a couple thousand more messages
    (100K+ subscribers).

    MailMan attempts to hand off messages to MTA.

    MTA refuses connections as system load is too high.

    MailMan bitches.

    Meanwhile another message arrives at MailMan to be exploded.
    Comments?
    Nope!

    --
    J C Lawrence Internet: claw at kanga.nu
    ----------(*) Internet: coder at kanga.nu
    ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...
  • Gergely Madarasz at Nov 18, 1999 at 2:14 am

    On Wed, 17 Nov 1999, Barry A. Warsaw wrote:

    So do you think the Mailman way is better or worse? I'm curious
    because I'm trying to decide whether I should port Mailman 1.0's bulk
    mailer code to the new message pipeline.
    Actually I kinda like the mailman bulk mailer. Before I switched from
    majordomo, I used an external bulkmail package (called from aliases, what
    mailman doesn't do on delivery so I can't use it with mailman) to help out
    sendmail. Changing MTA's on a high traffic site can be a real PITA, I
    wouldn't like it if I had to change it because mailman can't help it out
    anymore :( So I think it would be nice if you left it as an option.

    --
    Madarasz Gergely gorgo at caesar.elte.hu gorgo at linux.rulez.org
    It's practically impossible to look at a penguin and feel angry.
    Egy pingvinre gyakorlatilag lehetetlen haragosan nezni.
    HuLUG: http://mlf.linux.rulez.org/
  • The Dragon De Monsyne at Nov 18, 1999 at 2:49 pm

    On Wed, 17 Nov 1999, Barry A. Warsaw wrote:
    Another alternative, which would be less work and delegates all
    delivery to the MTA, is to just pump all the recips to the local smtpd
    via smtplib.py. The advantage here is that again we're MTA
    independent, but the disadvantage is that Mailman's delivery is
    synchronous with the smtpd. We'd have to be very sure to unlock the
    list object during this transaction (but watching out for race
    conditions, locking again if failure status's are handled directly,
    etc.) More code, more opportunity for bugs.
    In my own highly-hacked version of mailman that I use, I do this.
    Mailman simply drops outgoing messages into the queue directory. A
    background daemon de-queues the messages and pumps them to the local MTA
    via SMTP. A cronjob checks the daemon periodically, and starts it if is
    falls over. All very simple, and has worked very reliably for me for
    several months.

    -The Dragon De Monsyne
  • Barry A. Warsaw at Nov 26, 1999 at 11:27 pm
    Dragon> In my own highly-hacked version of mailman that I use,
    Dragon> I do this. Mailman simply drops outgoing messages into
    Dragon> the queue directory. A background daemon de-queues the
    Dragon> messages and pumps them to the local MTA via SMTP. A
    Dragon> cronjob checks the daemon periodically, and starts it if
    Dragon> is falls over. All very simple, and has worked very
    Dragon> reliably for me for several months.

    This would make a nice addition to Mailman, and probably wouldn't be
    hard to port to the new message pipeline model. How'd you like to
    look into that?

    -Barry
  • The Dragon De Monsyne at Nov 27, 1999 at 10:36 am

    On Fri, 26 Nov 1999, Barry A. Warsaw wrote:


    Dragon> In my own highly-hacked version of mailman that I use,
    Dragon> I do this. Mailman simply drops outgoing messages into
    Dragon> the queue directory. A background daemon de-queues the
    Dragon> messages and pumps them to the local MTA via SMTP. A
    Dragon> cronjob checks the daemon periodically, and starts it if
    Dragon> is falls over. All very simple, and has worked very
    Dragon> reliably for me for several months.

    This would make a nice addition to Mailman, and probably wouldn't be
    hard to port to the new message pipeline model. How'd you like to
    look into that?
    Sure! I'd be happy to. Probably not today, as I have a rather bad
    case of the flu, and right at the moment sitting upright for any length
    of time is rewarded with nausea and a blinding headache :P, but mebbe on
    sunday I'll be up to it & I'll pull the CVS and see what I can do. It
    should be fairly simple to port.

    PS: good job for doing this cleanup, this is something that's been needed
    for awhile.

    -The Dragon De Monsyne

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedNov 17, '99 at 1:52p
activeNov 27, '99 at 10:36a
posts20
users8
websitelist.org

People

Translate

site design / logo © 2022 Grokbase