FAQ
I changed the domain on my mail list. When I log into the admin site all
the links still show the old domain. Anybody know what i need to do to
change this.

Thanks
Troy

Search Discussions

  • Ross Anderson at Mar 25, 2005 at 6:35 pm
    I've been struggling with a delivery error on mailman that I could
    use some help with. I'm using postfix w/ amavis-new and cyrus for local
    users. The trouble I'm having is when a local users have exceeded thier
    quota, the messages sent by mailman gets stuck in a temporary delivery
    error. Does anyone have suggestions as to what I need to focus on? I've
    read cyrus, postfix, and mailman lists and haven't had much luck
    locating this error. Any suggestions appreciated. Conf files avail on
    request.


    Ross
  • John W. Baxter at Mar 25, 2005 at 7:00 pm

    On 3/25/2005 10:35, "Ross Anderson" wrote:

    I've been struggling with a delivery error on mailman that I could
    use some help with. I'm using postfix w/ amavis-new and cyrus for local
    users. The trouble I'm having is when a local users have exceeded thier
    quota, the messages sent by mailman gets stuck in a temporary delivery
    error. Does anyone have suggestions as to what I need to focus on? I've
    read cyrus, postfix, and mailman lists and haven't had much luck
    locating this error. Any suggestions appreciated. Conf files avail on
    request.
    Well, you're seeing basically reasonable behavior. A site which imposes
    quotas can either reject temporarily when a user is over quote, or reject
    permanently the first time the message is offered.

    The former assumes that users are reasonable, and will clear out their quota
    problem fairly soon. The latter assumes that users are ignoring their mail.

    If you want to change the behavior, the Postfix configuration (about which I
    know nothing) would be the place to look. Interestingly, the O'Reilly book
    "Postfix, The Definitive Guide" (my copy was printed in Dec 2003...first
    edition) does not mention "quota" in its index.

    --John
  • Brad Knowles at Mar 25, 2005 at 7:42 pm

    At 11:00 AM -0800 2005-03-25, John W. Baxter wrote:

    Interestingly, the O'Reilly book
    "Postfix, The Definitive Guide" (my copy was printed in Dec 2003...first
    edition) does not mention "quota" in its index.
    That's because quotas like this don't actually have anything to
    do with postfix. Any mailbox quotas that are applied come from the
    Local Delivery Agent, or the operating system and filtered up through
    through the LDA.

    From the LDA, these errors are filtered up through to postfix,
    which then issues either a permanent or a temporary error code to the
    sending machine, depending on how you have configured it to react to
    that kind of error from the LDA.


    So, when trying to debug problems like this, start with postfix,
    and follow through from there to the LDA.

    --
    Brad Knowles, <brad at stop.mail-abuse.org>

    "Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

    SAGE member since 1995. See <http://www.sage.org/> for more info.
  • Ross Anderson at Mar 25, 2005 at 7:46 pm

    John W. Baxter wrote:
    On 3/25/2005 10:35, "Ross Anderson" wrote:


    I've been struggling with a delivery error on mailman that I could
    use some help with. I'm using postfix w/ amavis-new and cyrus for local
    users. The trouble I'm having is when a local users have exceeded thier
    quota, the messages sent by mailman gets stuck in a temporary delivery
    error. Does anyone have suggestions as to what I need to focus on? I've
    read cyrus, postfix, and mailman lists and haven't had much luck
    locating this error. Any suggestions appreciated. Conf files avail on
    request.

    Well, you're seeing basically reasonable behavior. A site which imposes
    quotas can either reject temporarily when a user is over quote, or reject
    permanently the first time the message is offered.

    The former assumes that users are reasonable, and will clear out their quota
    problem fairly soon. The latter assumes that users are ignoring their mail.

    If you want to change the behavior, the Postfix configuration (about which I
    know nothing) would be the place to look. Interestingly, the O'Reilly book
    "Postfix, The Definitive Guide" (my copy was printed in Dec 2003...first
    edition) does not mention "quota" in its index.

    --John

    ------------------------------------------------------
    Mailman-Users mailing list
    Mailman-Users at python.org
    http://mail.python.org/mailman/listinfo/mailman-users
    Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
    Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
    Unsubscribe: http://mail.python.org/mailman/options/mailman-users/rosander%40owbn.org

    Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&amp;file=faq01.027.htp

    Well the confusion I seem to be having here is cyrus-mailman related
    since it is the program handling local quota's. Cyrus bounces mail when
    single mail is recieved from local or outside mail accounts. This odd
    behaviour only occurs with mailman which is why I'm a bit puzzled. I'd
    like to get the message bouncing back to mailman right away like it does
    with users that are not locally hosted.
  • Brad Knowles at Mar 25, 2005 at 8:32 pm

    At 1:46 PM -0600 2005-03-25, Ross Anderson wrote:

    Well the confusion I seem to be having here is cyrus-mailman related
    since it is the program handling local quota's. Cyrus bounces mail when
    single mail is recieved from local or outside mail accounts.
    What LDA do you have configured for use with Cyrus?
    This
    odd behaviour only occurs with mailman which is why I'm a bit puzzled.
    I'd like to get the message bouncing back to mailman right away like
    it does with users that are not locally hosted.
    I think that this is a difference in the way that the LDA is
    called, or perhaps using different Cyrus-compatible LDAs. At the
    very least, you need a lot more information about how your MTA is
    configured to talk to your LDA, and how your LDA is configured to
    handle certain situations.

    --
    Brad Knowles, <brad at stop.mail-abuse.org>

    "Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

    SAGE member since 1995. See <http://www.sage.org/> for more info.
  • Heather Madrone at Mar 25, 2005 at 7:55 pm
    I've been using Mailman with exim on Mac OSX. I started with
    sendmail (because it comes with OSX and I'm somewhat familiar
    with it), but soon got tired of having to wrestle it into submission
    all the time and switched to exim. I've been very pleased with exim's
    performance and integration with Mailman.

    The OSX setup, however, is only a stopgap while I get my permanent
    server set up. I've been looking for an open source operating system
    that will run well on our Ultra 5 (sparc). We were going with Debian,
    which then announced that it's dropping sparc support, so we've switched
    to OpenBSD.

    The time has come to start seriously thinking about the MTA. OpenBSD
    comes with sendmail, but I'm not going down that road again. I've heard
    good things about postfix, but I've never used it. It seems somewhat more
    complex to set up than exim, and its integration with Mailman does not
    seem to be as seamless.

    My previous service provider used postfix, and we had recurrent problems
    with Mailman's queues getting silently hung up. A friend of mine who
    runs a Mailman/postfix site also has the same problem. I wrote a perl
    script to check for this problem and restart Mailman's qrunner if necessary,
    and my Mailman/exim installation hasn't had this problem once. Is this
    problem related to postfix or have I just been lucky?

    Things I like about exim:

    * Exim's ability to directly poke the Mailman installation and
    determine legitimate delivery addresses.
    * Exim's ability to handle VERP processing through the MTA
    rather than having Mailman have to do it.
    * Exim's fine degree of control of transient and permanent
    delivery errors (by host, by address, by error type).
    * Exim's informative logs.
    * Ease of configuration and administration.
    * Reliability.

    I don't have a huge Mailman installation. There's one main list with 300
    subscribers that gets 50-200 messages a day. There are two digest-only
    lists with 100 and 500 subscribers that get 2-10 messages daily. There
    are a handful of other lists that get a few posts a month. Everything's in
    the same domain.

    What are some reasons that I would consider postfix instead of exim?

    --
    Heather Madrone (heather at madrone.com) http://www.madrone.com

    A rolling stone gathers no mass.
  • Brad Knowles at Mar 25, 2005 at 9:08 pm

    At 11:55 AM -0800 2005-03-25, Heather Madrone wrote:

    The OSX setup, however, is only a stopgap while I get my permanent
    server set up. I've been looking for an open source operating system
    that will run well on our Ultra 5 (sparc). We were going with Debian,
    which then announced that it's dropping sparc support, so we've switched
    to OpenBSD.
    In terms of providing good support for UltraSPARC, Solaris is
    going to be best, and I believe that Solaris 10 is freely available
    from Sun. But that's not what I would consider an "open source"
    operating system.

    In terms of Open Source operating systems for UltraSPARC, NetBSD
    is probably going to be the best, with OpenBSD close behind (they
    split off from NetBSD not too long ago), and FreeBSD catching up very
    quickly. There may be some Linux distributions which also support
    UltraSPARC, and they might have been decent in the past, but I think
    they're tending to drop it in the same way that Debian has done.
    The time has come to start seriously thinking about the MTA. OpenBSD
    comes with sendmail, but I'm not going down that road again. I've heard
    good things about postfix, but I've never used it. It seems somewhat more
    complex to set up than exim, and its integration with Mailman does not
    seem to be as seamless.
    Postfix is a good MTA for use with mailing lists. It does a lot
    of things out-of-the-box that you want in this kind of environment,
    and which take more work to do if you want to use sendmail instead.
    I have run large sites with both sendmail and postfix, and depending
    on what you're trying to do and how much care & feeding you're
    willing/able to give it, either sendmail or postfix should be
    perfectly suitable.

    I know a lot less about Exim, but it does seem to be reasonably
    capable, and I have spoken to the author of Exim a fair amount. Phil
    Hazel is a good guy. Based more on that than anything else, I
    consider Exim to be the only other MTA that I can recommend that
    people use.


    In terms of integration with Mailman, I think postfix is about as
    good as anything else I've seen, and the hacks to improve the
    integration with sendmail basically amount to lying to Mailman and
    instead telling it that it's using postfix.
    My previous service provider used postfix, and we had recurrent problems
    with Mailman's queues getting silently hung up. A friend of mine who
    runs a Mailman/postfix site also has the same problem.
    Hung up? In what way?
    I wrote a perl
    script to check for this problem and restart Mailman's qrunner if necessary,
    and my Mailman/exim installation hasn't had this problem once. Is this
    problem related to postfix or have I just been lucky?
    I've never heard of a problem like this being able to be
    attributed to postfix and not be generally applicable to other MTAs
    as well.
    * Exim's ability to directly poke the Mailman installation and
    determine legitimate delivery addresses.
    If you use the postfix integration scripts, then the aliases are
    automatically generated when you create and delete mailing lists, and
    this shouldn't be a problem.
    * Exim's ability to handle VERP processing through the MTA
    rather than having Mailman have to do it.
    Postfix has support for XVERP, and there have been patches posted
    which allow Mailman to take advantage of that. I don't personally
    like that option, as I don't think it really saves you anything, and
    it certainly takes a lot of the control away from Mailman that I
    would normally want to maintain. But if you want this, you can do it
    with postfix.
    * Exim's fine degree of control of transient and permanent
    delivery errors (by host, by address, by error type).
    I'm not sure I understand what you're talking about. Can you be
    more specific? I know that postfix gives you a lot of control in
    these areas, but without knowing more about how Exim does them, it's
    hard to compare.
    * Exim's informative logs.
    I've seen Exim's logs. I was never able to make much of any
    sense out of them. I've also seen postfix's logs, and they seem to
    me to be the model of readability and understandability.

    Is there something in specific you don't like?
    * Ease of configuration and administration.
    Postfix is the only MTA on the planet that can have a truly
    useful two-line configuration file. Moreover, it has the most
    intelligible configuration file that I have ever seen. Better still,
    it comes up "default secure", unlike every other MTA I've ever seen.

    I've seen Exim configuration files, and it's hard to tell what
    goes where, what is a router versus all the other ways that certain
    things could be handled, etc....


    When looking at Exim and Mailman, there is a distinct issue that
    has to be kept in mind. The instructions for integrating Mailman
    2.0.x are oriented exclusively towards Exim 3.x, and the instructions
    for integrating Mailman 2.1.x are oriented exclusively towards Exim
    4.x. If you've got Exim 3.x and you want to use Mailman 2.1.x,
    you're screwed.

    Been there, done that. Not knowing Exim very well, I had to be
    the one to try to patch together something that would
    kinda-semi-sorta work with Mailman 2.1.x and Exim 3.x. Not fun. I
    might wish this kind of experience on my worst enemies, but not
    anyone else.


    This is at least one area where postfix does not share the same
    kind of problem -- the instructions and scripts provided with Mailman
    2.0.x and 2.1.x work with pretty much any version of postfix that has
    shipped within the last few years.
    * Reliability.
    All I can say is that the largest Mailman installations in the
    world (that I know of) exclusively use postfix. You'd have to ask
    them why they went this route, but my personal belief is that postfix
    is more powerful, flexible, and scalable than Exim, or most anything
    else available.
    What are some reasons that I would consider postfix instead of exim?
    Well, for a small site, it mostly comes down to personal
    preference. Regardless of whether I think that postfix is
    head-and-shoulders above Exim or not, if you're familiar with Exim
    and you feel comfortable administering it, then you should seriously
    consider continuing to go that route. Of course, your hosting
    provider might also fit into this picture -- if they're not familiar
    with Exim, then if you have any problems you may not be able to rely
    on their help.

    We use postfix on python.org for mailman-users and the other
    mailing lists we host, the freebsd.org folks use it for their mail
    servers, and lists.apple.com use it for theirs. However, just
    because we use postfix does not necessarily mean that you have to.

    --
    Brad Knowles, <brad at stop.mail-abuse.org>

    "Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

    SAGE member since 1995. See <http://www.sage.org/> for more info.
  • John W. Baxter at Mar 25, 2005 at 9:48 pm

    On 3/25/2005 13:08, "Brad Knowles" wrote:

    If you've got Exim 3.x and you want to use Mailman 2.1.x,
    you're screwed.
    Debian woody notwithstanding, no one should be installing and running Exim 3
    these days. There is essentially no one readily available (eg, on the
    exim-users mailing list) who remembers much about it.

    (After 10 years of reading Exim logs, and a few minutes reading Postfix
    logs, I would reverse Brad's characterization (I don't know how configurable
    Postfix's logging is...Exim can add or drop many aspects of the log
    entries). Actually, the Postfix logs look quite reasonable.)

    --John
  • Brad Knowles at Mar 25, 2005 at 10:14 pm

    At 1:48 PM -0800 2005-03-25, John W. Baxter wrote:

    Debian woody notwithstanding, no one should be installing and running Exim 3
    these days. There is essentially no one readily available (eg, on the
    exim-users mailing list) who remembers much about it.
    Think someone who already has Exim 3 on their legacy machine, and
    wants to upgrade Mailman but not anything else. You'd be surprised
    how many people out there are in this position.
    (After 10 years of reading Exim logs, and a few minutes reading Postfix
    logs, I would reverse Brad's characterization (I don't know how configurable
    Postfix's logging is...Exim can add or drop many aspects of the log
    entries). Actually, the Postfix logs look quite reasonable.)
    Indeed, that's one of the aspects I find most confusing about
    Exim's log information. Trying to help out this one site, I ended up
    having to turn on all possible logging in order to get some clue as
    to what was going on, because it was totally unclear as to which
    particular little fiddly bit I needed to tweak in order to see the
    information I needed.

    Log configuration is an area where I consider Exim to be the
    weakest. Conversely, this is an area where I think postfix shines.

    --
    Brad Knowles, <brad at stop.mail-abuse.org>

    "Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

    SAGE member since 1995. See <http://www.sage.org/> for more info.
  • John W. Baxter at Mar 26, 2005 at 12:02 am

    On 3/25/2005 14:14, "Brad Knowles" wrote:

    Debian woody notwithstanding, no one should be installing and running Exim 3
    these days. There is essentially no one readily available (eg, on the
    exim-users mailing list) who remembers much about it.
    Think someone who already has Exim 3 on their legacy machine, and
    wants to upgrade Mailman but not anything else. You'd be surprised
    how many people out there are in this position.
    Very likely, they can't, taking that problem statement literally. Because
    very likely, they have an ancient Python as well, and Mailman won't run with
    it.

    And I have no way to help them. I could probably manage to configure the
    old Exim to work with the new Mailman, but I have no interest in doing so.

    On the other hand, the Python adjustment (if one is careful on an ancient
    RedHat installation, where much breaks if one removes Python 1.5.2, or
    points the name python at anything newer) is easier than the Exim upgrade,
    since there is a large canyon between Exim 3 and Exim 4.

    It may very well be best to try switching such a setup to Postfix (where I
    also can't help), if one has a Postfix guru available. That should be about
    the same magnitude of change as Exim 3 to Exim 4.

    --John
  • Brad Knowles at Mar 26, 2005 at 1:12 am

    At 4:02 PM -0800 2005-03-25, John W. Baxter wrote:

    And I have no way to help them. I could probably manage to configure the
    old Exim to work with the new Mailman, but I have no interest in doing so.
    Therein lies a big part of the problem. If you're not willing to
    help, and the rest of the Exim community feels the same way, then the
    people who are in this situation are doomed unless they switch to
    other software.
    On the other hand, the Python adjustment (if one is careful on an ancient
    RedHat installation, where much breaks if one removes Python 1.5.2, or
    points the name python at anything newer) is easier than the Exim upgrade,
    since there is a large canyon between Exim 3 and Exim 4.
    This whole Exim 3/Exim 4 thing is not a problem with postfix.
    Don't get me wrong, postfix isn't perfect. But what flaws it has
    tend to be less visible than this, and the issue of upgrading from
    one version to another usually has more to do with whether or not a
    binary package with the new version has yet been prepared, or whether
    they're willing to take the risk of going straight to the original
    source.

    --
    Brad Knowles, <brad at stop.mail-abuse.org>

    "Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

    SAGE member since 1995. See <http://www.sage.org/> for more info.
  • Jim Tittsler at Mar 26, 2005 at 2:08 am

    On Mar 26, 2005, at 10:12, Brad Knowles wrote:
    At 4:02 PM -0800 2005-03-25, John W. Baxter wrote:

    And I have no way to help them. I could probably manage to
    configure the
    old Exim to work with the new Mailman, but I have no interest in
    doing so.
    Therein lies a big part of the problem. If you're not willing to
    help, and the rest of the Exim community feels the same way, then the
    people who are in this situation are doomed unless they switch to
    other software.
    I've not had any problem using Exim 3 with Mailman 2.1. If there are
    some specific problems you are having, I'm willing to try to help.
    (But Exim 4's flexibility makes it a worthwhile upgrade. :-)

    python.net uses Exim.
    --
    Jim Tittsler http://www.OnJapan.net/ GPG: 0x01159DB6
    Python Starship http://Starship.Python.net/
    Mailman IRC irc://irc.freenode.net/#mailman
  • John W. Baxter at Mar 26, 2005 at 2:31 am

    On 3/25/2005 17:12, "Brad Knowles" wrote:

    This whole Exim 3/Exim 4 thing is not a problem with postfix.
    Don't get me wrong, postfix isn't perfect. But what flaws it has
    tend to be less visible than this, and the issue of upgrading from
    one version to another usually has more to do with whether or not a
    binary package with the new version has yet been prepared, or whether
    they're willing to take the risk of going straight to the original
    source.
    Philip is very conscious of backwards compatibility, and very consciously
    broke it in the Exim 3 to Exim 4 transition, because the old configuration
    system and the old way of managing messages had been outgrown by reality.

    There are several configuration defaults which are suboptimal in today's
    world, but are not being changed because they would break backwards
    compatibility.

    Most Exim version upgrades are a matter of making the change, then deciding
    what new features to use and adding them to the config (and perhaps removing
    workarounds for feature lacks and bugs which have been fixed).

    But at any rate, Exim 3 to ?? Is a very good opportunity to consider Postfix
    rather than Exim 4 as the ??. Mailman 2.x to 3.0 will likely present a
    similar opportunity to look around at what else there is. (The seemingly
    never-ending lack of Majordomo 2 was what moved us to Mailman from
    Majordomo.)

    --John
  • Brad Knowles at Mar 26, 2005 at 3:05 am

    At 6:31 PM -0800 2005-03-25, John W. Baxter wrote:

    But at any rate, Exim 3 to ?? Is a very good opportunity to consider Postfix
    rather than Exim 4 as the ??. Mailman 2.x to 3.0 will likely present a
    similar opportunity to look around at what else there is.
    I suspect that Mailman 2.x to 3.x will not be that rough. Yes,
    the architectural changes internally are quite massive, but I see no
    reason that a "make upgrade" process shouldn't be able to read the
    old pickle format data and rewrite that into whatever the new format
    is. I don't think that Mailman is as complex a program as either
    postfix or Exim, and I don't think the changes are going to be that
    painful.

    Of course, I wasn't around for the 2.0.x to 2.1.x conversion, so
    I can't speak for how this has worked in the past.
    (The seemingly
    never-ending lack of Majordomo 2 was what moved us to Mailman from
    Majordomo.)
    What drove me to Mailman was not the lack of Majordomo2 per se,
    but was that there were so many additional things I had to add to the
    system to get it working the way I wanted, and adding Majorcool plus
    MHonArc to our existing Majordomo installation was likely to be about
    as painful as switching everything over to Mailman instead.

    Mailman is certainly not perfect, but I think it's a lot more
    scalable and certainly more easily managed than Majordomo, and that's
    good enough for me.

    --
    Brad Knowles, <brad at stop.mail-abuse.org>

    "Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

    SAGE member since 1995. See <http://www.sage.org/> for more info.
  • Terry Allen at Mar 26, 2005 at 3:32 am
    I suspect that Mailman 2.x to 3.x will not be that rough. Yes, the
    Hi again,
    Just out of interest, on Postfix, there is a simple option to
    upgrade a running system like so (as most here will know):

    make
    stop postfix
    make upgrade
    start postfix

    I have never had to upgrade Mailman, as I started out using
    it on 2.1.5 - is the upgrade procedure for Mailman anything like
    Postfix? It's been foolproof thus far for me, so I'm hoping it works
    as well on Mailman when the time comes.
    --

    Bye for now, Terry Allen
    ___________________________________________________________________
    hEARd

    Postal Address:
    hEARd, 26B Glenning Rd, Glenning Valley, NSW 2261, Australia
    Internet -
    WWW: http://heard.com.au http://itavservices.com
    EMAIL: hmag at ozemail.com.au
    Phone: Australia - 02 4388 1400 / International - + 61 2 43881400
    Mobile: Australia - 04 28881400 / International - 61 4 28881400
    -----------------------------------------------
    Non profit promotion for new music - since 1994
    -----------------------------------------------
  • John W. Baxter at Mar 26, 2005 at 6:03 am

    On 3/25/2005 19:32, "Terry Allen" wrote:

    I suspect that Mailman 2.x to 3.x will not be that rough. Yes, the
    Hi again,
    Just out of interest, on Postfix, there is a simple option to
    upgrade a running system like so (as most here will know):

    make
    stop postfix
    make upgrade
    start postfix

    I have never had to upgrade Mailman, as I started out using
    it on 2.1.5 - is the upgrade procedure for Mailman anything like
    Postfix? It's been foolproof thus far for me, so I'm hoping it works
    as well on Mailman when the time comes.
    Well, it's basically that. (The 2.0x to 2.1x jump for us involved a change
    of servers, and server locations, and a huge jump in Linux version, so we
    couldn't do the straighforward install the new over the old and turn it on.)

    Unless one uses RedHat's RPMs...which will soon move things Mailman around
    considerably.

    That's probably a good thing...having configuration mixed with code mixed
    with data is not really a good idea. RedHat's new arrangement looks a lot
    better to me--I might well copy it even if I don't use the RPMs. And even
    with all the changes, the process will essentially involve copying the stuff
    in $prefix/lists and $prefix/archives (and maybe something else) to the
    right new places.

    Having configuration *be* code, while a nice use of Python's capabilities,
    also presents problems to those who believe that code and configuration
    should be disjoint...RedHat has managed it without bending *too* much.

    --John
  • John W. Baxter at Mar 26, 2005 at 5:35 am
    On 3/25/2005 19:05, "Brad Knowles" wrote:
    At 6:31 PM -0800 2005-03-25, John W. Baxter wrote:

    But at any rate, Exim 3 to ?? Is a very good opportunity to consider Postfix
    rather than Exim 4 as the ??. Mailman 2.x to 3.0 will likely present a
    similar opportunity to look around at what else there is.
    I suspect that Mailman 2.x to 3.x will not be that rough. Yes,
    the architectural changes internally are quite massive, but I see no
    reason that a "make upgrade" process shouldn't be able to read the
    old pickle format data and rewrite that into whatever the new format
    is. I don't think that Mailman is as complex a program as either
    postfix or Exim, and I don't think the changes are going to be that
    painful.

    Of course, I wasn't around for the 2.0.x to 2.1.x conversion, so
    I can't speak for how this has worked in the past.
    (The seemingly
    never-ending lack of Majordomo 2 was what moved us to Mailman from
    Majordomo.)
    What drove me to Mailman was not the lack of Majordomo2 per se,
    but was that there were so many additional things I had to add to the
    system to get it working the way I wanted, and adding Majorcool plus
    MHonArc to our existing Majordomo installation was likely to be about
    as painful as switching everything over to Mailman instead.

    Mailman is certainly not perfect, but I think it's a lot more
    scalable and certainly more easily managed than Majordomo, and that's
    good enough for me.
  • Derrick Hudson at Mar 26, 2005 at 1:56 pm

    On Fri, Mar 25, 2005 at 06:31:58PM -0800, John W. Baxter wrote: | On 3/25/2005 17:12, "Brad Knowles" wrote:
    This whole Exim 3/Exim 4 thing is not a problem with postfix.
    Don't get me wrong, postfix isn't perfect. But what flaws it has
    tend to be less visible than this, and the issue of upgrading from
    one version to another usually has more to do with whether or not a
    binary package with the new version has yet been prepared, or whether
    they're willing to take the risk of going straight to the original
    source.
    Philip is very conscious of backwards compatibility, and very consciously
    broke it in the Exim 3 to Exim 4 transition, because the old configuration
    system and the old way of managing messages had been outgrown by reality.
    Indeed. Don't think of exim3->exim4 as a version upgrade, but rather
    replacing a worn-out tool with a fresh one. Kind of like the zope2 ->
    zope3 change, if you're familiar with the zope world. Or, perhaps,
    compare it to Win3.1->Win95 or Win9x->NT/2k/XP. Same basic
    concepts, but new implementation and configuration.

    -D

    --
    A mouse is a device used to point at the xterm you want to type in.
    --Kim Alm, a.s.r

    www: http://dman13.dyndns.org/~dman/ jabber: dman at dman13.dyndns.org
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: Digital signature
    Url : http://mail.python.org/pipermail/mailman-users/attachments/20050326/73ea35c4/attachment.pgp
  • Heather Madrone at Mar 25, 2005 at 10:25 pm
    Thanks for your detailed answer, Brad. I appreciate your
    opinion on this subject. If Postfix will do a better job than
    exim, I don't mind switching at all.
    At 10:08 PM +0100 3/25/05, Brad Knowles wrote:
    In terms of providing good support for UltraSPARC, Solaris is
    going to be best, and I believe that Solaris 10 is freely available
    from Sun. But that's not what I would consider an "open source"
    operating system.
    That's our fallback plan.
    In terms of Open Source operating systems for UltraSPARC,
    NetBSD is probably going to be the best, with OpenBSD close behind
    (they split off from NetBSD not too long ago), and FreeBSD catching
    up very quickly. There may be some Linux distributions which also
    support UltraSPARC, and they might have been decent in the past, but
    I think they're tending to drop it in the same way that Debian has
    done.
    FreeBSD works great if you don't need a keyboard, a mouse, or a monitor.
    Not an insurmountable problem for a server, but the FreeBSD hardware
    support of the sparcs is a lot spottier than NetBSD or OpenBSD. The
    guy who started OpenBSD was responsible for the sparc ports for
    NetBSD.
    My previous service provider used postfix, and we had recurrent problems
    with Mailman's queues getting silently hung up. A friend of mine who
    runs a Mailman/postfix site also has the same problem.
    Hung up? In what way?
    All mailing lists on the server silently stop sending posts. No errors in the
    logs, no console messages, no nothing. Qrunners still appear to be
    functioning normally. A mail loopback test diagnoses the problem and
    restarting Mailman clears it.

    As I said, I haven't been able to see this problem since I started running
    my own server. It was happening at least once a week before that.
    * Exim's ability to handle VERP processing through the MTA
    rather than having Mailman have to do it.
    Postfix has support for XVERP, and there have been patches
    posted which allow Mailman to take advantage of that. I don't
    personally like that option, as I don't think it really saves you
    anything, and it certainly takes a lot of the control away from
    Mailman that I would normally want to maintain. But if you want
    this, you can do it with postfix.
    With exim, trying to do VERP processing on the digest runs caused Mailman
    to flood exim, even when I turned the number of sessions and connections
    way down. It also brought my poor Mac, which was not meant to be a server,
    to its knees. I'm hoping that the sparc will be able to handle peak loads more
    gracefully than a Powerbook.

    One of the reasons that I'm considering Postfix is that I wonder whether
    it might be more efficient than exim. I have a hunch that exim might do
    more work than it needs to to get the job done.
    * Exim's fine degree of control of transient and permanent
    delivery errors (by host, by address, by error type).
    I'm not sure I understand what you're talking about. Can you
    be more specific? I know that postfix gives you a lot of control in
    these areas, but without knowing more about how Exim does them, it's
    hard to compare.
    It's described in excruciating detail in section 32 of the exim specification.

    http://www.exim.org/exim-html-4.50/doc/html/spec.html

    Basically, you can have a set of retry rules that go like this:

    host (or regexp) error (or regexp) retry strategy

    the.host.name rcpt_452 F,1h,10m
    * quota F,4d,6h
    * * F,2h,20m; G,16h,1h,1.5; F,4d,6h

    The first rule tells exim to retry rcpt_452 errors for host the.host.name every
    ten minutes for an hour and then fail. The second tells exim to retry all quota
    overruns every six hours for four days. The third rule says that all other errors
    should be retried every 20 minutes for two hours, then at increasingly longer intervals
    for the next 14 hours, then every six hours until 4 days have elapsed.

    Okay, so it's not simple. Easy enough to figure out, though, and it does give
    you the ability to tune exim to deal with the kinds of errors that you run into.
    It pains me to see endless retries of errors that aren't going to go away in minutes.
    * Ease of configuration and administration.
    Postfix is the only MTA on the planet that can have a truly
    useful two-line configuration file. Moreover, it has the most
    intelligible configuration file that I have ever seen. Better
    still, it comes up "default secure", unlike every other MTA I've
    ever seen.

    I've seen Exim configuration files, and it's hard to tell
    what goes where, what is a router versus all the other ways that
    certain things could be handled, etc....
    As I said, I've never tried Postfix, so my only point of comparison is
    sendmail. I am fairly confident that any MTA would look simple and
    friendly next to sendmail.
    When looking at Exim and Mailman, there is a distinct issue
    that has to be kept in mind. The instructions for integrating
    Mailman 2.0.x are oriented exclusively towards Exim 3.x, and the
    instructions for integrating Mailman 2.1.x are oriented exclusively
    towards Exim 4.x. If you've got Exim 3.x and you want to use
    Mailman 2.1.x, you're screwed.
    Fortunately, the documentation makes that abundantly clear.
    * Reliability.
    All I can say is that the largest Mailman installations in
    the world (that I know of) exclusively use postfix. You'd have to
    ask them why they went this route, but my personal belief is that
    postfix is more powerful, flexible, and scalable than Exim, or most
    anything else available.
    How would you rate Postfix's efficiency? Is it fast? Does it limit
    network traffic to the necessary and keep its disk reads and writes
    down to a dull roar?

    Bandwidth is a consideration, since this will all be flowing on a fairly
    slow DSL line (speed in this case limited by geography).
    What are some reasons that I would consider postfix instead of exim?
    Well, for a small site, it mostly comes down to personal
    preference. Regardless of whether I think that postfix is
    head-and-shoulders above Exim or not, if you're familiar with Exim
    and you feel comfortable administering it, then you should seriously
    consider continuing to go that route. Of course, your hosting
    provider might also fit into this picture -- if they're not familiar
    with Exim, then if you have any problems you may not be able to rely
    on their help.
    My ISP is just doing bandwidth and DNS entries, so they don't enter
    into the picture at all. At this point, I'm my own service provider.
    We use postfix on python.org for mailman-users and the other
    mailing lists we host, the freebsd.org folks use it for their mail
    servers, and lists.apple.com use it for theirs. However, just
    because we use postfix does not necessarily mean that you have to.
    Do you know why the choice was made to use Postfix on any of those
    sites?

    --
    Heather Madrone (heather at madrone.com) http://www.madrone.com

    A rolling stone gathers no mass.
  • John W. Baxter at Mar 25, 2005 at 10:34 pm

    On 3/25/2005 14:25, "Heather Madrone" wrote:

    As I said, I've never tried Postfix, so my only point of comparison is
    sendmail. I am fairly confident that any MTA would look simple and
    friendly next to sendmail.
    You probably shouldn't say "any" in that context. Exchange lurks out there.
    (Not part of your universe, or ours, but it is out there.)

    --John
  • Brad Knowles at Mar 26, 2005 at 12:37 am

    At 2:25 PM -0800 2005-03-25, Heather Madrone wrote:

    FreeBSD works great if you don't need a keyboard, a mouse, or a monitor.
    They are oriented towards the serial console at the moment, but
    I'm sure that the rest will come along. I've got four UltraSPARC 10
    clones that I plan on using under FreeBSD (perhaps turning them into
    a small package build cluster), and I'll make myself a guinea pig.
    Not an insurmountable problem for a server, but the FreeBSD hardware
    support of the sparcs is a lot spottier than NetBSD or OpenBSD.
    It's not as good for FreeBSD as it should be, no.
    All mailing lists on the server silently stop sending posts. No
    errors in the
    logs, no console messages, no nothing. Qrunners still appear to be
    functioning normally. A mail loopback test diagnoses the problem and
    restarting Mailman clears it.
    Huh. Weird. I've never heard of anything like that.
    With exim, trying to do VERP processing on the digest runs caused Mailman
    to flood exim, even when I turned the number of sessions and connections
    way down. It also brought my poor Mac, which was not meant to be a server,
    to its knees. I'm hoping that the sparc will be able to handle peak
    loads more gracefully than a Powerbook.
    Depends on the powerbook, the UltraSPARC configuration, etc....


    Generally speaking, for things like this, assuming you have
    enough RAM and network I/O capacity, the principal limiting factor
    becomes synchronous meta-data I/O. Every time you create a file,
    delete a file, move a file from one directory to another, or rename a
    file, you're doing synchronous meta-data I/O. This means that the
    entire directory has to be locked while the operation is taking place.

    Now, locking the entire directory, doing the operationg, and
    unlocking the entire directory, is something that usually happens
    pretty quickly. However, try doing that thousands of times per
    second, and you run into very serious bottleneck issues.

    Of course, one thing an MTA does more than anything else is
    create lots and lots of little files, which don't live for very long.


    In this situation, *BSD with softupdates will be your best bet on
    the filesystem side. The cool thing about softupdates is that it
    re-orders the disk I/O operations in a safe manner, and if the file
    is created and goes away quickly enough, then the I/O is never pushed
    to disk at all.

    All the *BSD implementations should be capable of enabling softupdates.

    If you do end up having to go with Solaris, make sure that you
    enable filesystem logging. It's not as good as softupdates (although
    Sun did buy the rights to softupdates from Kirk, and is incorporating
    them into a future version of Solaris), but filesystem logging is
    better than nothing.

    Note that Apple doesn't have anything like softupdates for MacOS
    X, although more recent versions have introduced a type of journaling
    for the filesystem. Unfortunately, in this case it actually slows
    things down a bit, but it does improve robustness in a crash, so
    overall it's still a win.
    One of the reasons that I'm considering Postfix is that I wonder whether
    it might be more efficient than exim. I have a hunch that exim might do
    more work than it needs to to get the job done.
    In all my testing, when it comes to the basic operations of a
    mail server, postfix has been the most efficient MTA that I've ever
    found. I've tried very, very hard to push sendmail to be faster and
    more efficient, and I still believe that can be done, although I
    haven't managed it -- and I consider myself to be a specialist in
    this area.

    I haven't been able to do much testing with Exim towards this
    end. However, Phil Hazel has said some very complimentary things
    about postfix in this regard, and I have a very hard time believing
    that Exim can compete.
    Okay, so it's not simple. Easy enough to figure out, though, and it
    does give you the ability to tune exim to deal with the kinds of errors
    that you run into. It pains me to see endless retries of errors that
    aren't going to go away in minutes.
    Postfix tries to be smarter about these sorts of things without
    requiring any kind of complex configuration. It uses a bounded
    exponential backoff scheme, the same type of scheme that has been
    proven over time throughout TCP/IP, Ethernet, and other network
    protocols.

    Postfix does include some pretty advanced tools for diagnosing
    queueing problems (see <http://www.postfix.org/QSHAPE_README.html>),
    and once you've identified any particular problem domains you can
    then create separate queues dedicated to them so that everything else
    is unaffected. There's also some pretty extensive performance tuning
    tips at <http://www.postfix.org/TUNING_README.html>.
    How would you rate Postfix's efficiency? Is it fast? Does it limit
    network traffic to the necessary and keep its disk reads and writes
    down to a dull roar?
    Postfix is the fastest MTA I've ever tested. It's smart about
    trying parallelism to remote sites, and using backing off when it
    detects that the remote site can't handle the load. If you like,
    you're able to configure higher amounts of parallelism for given
    remote sites.

    Pretty much everything in postfix is table driven, and those
    tables can be in most any form of database you like -- Berkeley DB,
    *dbm, MySQL, LDAP, plain text files, or whatever. In some areas, it
    uses regular expressions, and you typically have options of
    Unix-style regular expressions or Perl-compatible REs, etc....
    Bandwidth is a consideration, since this will all be flowing on a fairly
    slow DSL line (speed in this case limited by geography).
    Personally, I can't think of an MTA that would be better suited
    for this environment, but then I have been involved in postfix since
    '97, back before it was officially announced and it was still called
    VMailer. I'm a bit biased. ;)
    Do you know why the choice was made to use Postfix on any of those
    sites?
    I can't speak for lists.apple.com or freebsd.org, but on
    python.org it was a combination of the people who were going to be
    managing the system feeling more comfortable with postfix than
    anything else, plus our view that postfix would probably outperform
    anything else we could throw at it.

    The previous mail server for python.org used Exim, and it was not
    well-maintained. Only one person really understood much of anything
    about it, and he wasn't around very much. The machine itself was
    also pretty old and slow, and not well-maintained. The new machine
    is much faster and better maintained, but I don't know how we would
    have done if we would have used Exim on the same box.

    --
    Brad Knowles, <brad at stop.mail-abuse.org>

    "Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

    SAGE member since 1995. See <http://www.sage.org/> for more info.
  • John W. Baxter at Mar 26, 2005 at 2:21 am

    On 3/25/2005 16:37, "Brad Knowles" wrote:

    In this situation, *BSD with softupdates will be your best bet on
    the filesystem side. The cool thing about softupdates is that it
    re-orders the disk I/O operations in a safe manner, and if the file
    is created and goes away quickly enough, then the I/O is never pushed
    to disk at all.

    All the *BSD implementations should be capable of enabling softupdates.
    That's all very well, but the reason that all those little files are created
    and destroyed is that it isn't safe to hold the data in RAM, and once an MTA
    has accepted a message, a mere power outage isn't supposed to cause it to
    drop the message on the floor. (There are even words in the mail RFCs about
    it.)

    Unless softupdates "sees" power outages and hustles the data onto disk
    (which is probably feasible) it would not be considered MTA-suitable (and
    Exim does what it can to prevent it, using whatever force to disk calls are
    available to it).

    --John
  • Brad Knowles at Mar 26, 2005 at 2:58 am

    At 6:21 PM -0800 2005-03-25, John W. Baxter wrote:

    Unless softupdates "sees" power outages and hustles the data onto disk
    (which is probably feasible) it would not be considered MTA-suitable (and
    Exim does what it can to prevent it, using whatever force to disk calls are
    available to it).
    The problem is that with modern disks not flushing cache data
    even when they're told to do so, it's virtually impossible to
    guarantee that the data is written before you've lost power. You're
    completely at the mercy of the hardware, and modern caches these days
    are easily large enough to hold a large number of small files.


    The typical Linux method of using async mounts fairly frequently
    results in filesystem corruption which needs to be corrected with
    fsck, and that can take a long time with a large filesystem. Yes,
    journaling can ameliorate that problem to a degree, but you still
    need to turn off the async mount if you want as much as they can give
    you in terms of "full protection".

    Softupdates makes sure that the filesystem on disk is always in a
    consistent state, and while a few files/messages may be lost in a
    power outage, the filesystem itself is okay and shouldn't ever need
    to fsck. Given the modern world we live in and the realities we have
    to deal with, I think that's a pretty good trade-off.

    --
    Brad Knowles, <brad at stop.mail-abuse.org>

    "Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

    SAGE member since 1995. See <http://www.sage.org/> for more info.
  • Derrick Hudson at Mar 26, 2005 at 1:53 pm
    On Fri, Mar 25, 2005 at 11:55:46AM -0800, Heather Madrone wrote:
    [...]
    We were going with Debian,
    which then announced that it's dropping sparc support,
    Hold up. Debian hasn't announced any such thing. Don't pay attention
    to the rumors. Some of the project's leadership *proposed* (notice
    that it's just a proposal) and different way of supporting 11+
    architectures and making releases manageable.

    Even if the proposal is accepted, it doesn't say anything about
    *dropping* any architectures. Rather, it proposes that the less
    popular arches be managed independent from the most popular ones.
    Sparc would still be supported, as long as anyone cares to use it.
    so we've switched
    to OpenBSD.

    The time has come to start seriously thinking about the MTA.
    I recommend either postfix or exim. I use postfix now, and it is
    rather easy to setup, has good performance, and can be instructed not
    to trash the machine its on while under heavy load.
    OpenBSD comes with sendmail, but I'm not going down that road again.
    I've heard good things about postfix, but I've never used it.
    It seems somewhat more complex to set up than exim,
    postfix is simpler because all of the logic is built-in, you merely
    fill in some tables. I had quite a bit of experience with exim before
    I started using postfix. postfix has better rate- and resource-
    limiting controls.
    and its integration with Mailman does not
    seem to be as seamless.
    Its integration is nearly perfect -- see README.POSTFIX. All you
    really have to do is put an entry in $alias_maps (and one in
    $virtual_alias_maps if mailman will serve virtual domains) and you're
    set.

    There is one hitch, depending on your setup, which is discussed here:

    http://mail.python.org/pipermail/mailman-developers/2005-March/017979.html

    Grr. pipermail needs much better MIME support =p. You'll have to
    read the message from me from the mbox archives instead:
    http://mail.python.org/pipermail/mailman-developers/2005-March.txt
    but it won't matter to you unless the domain you specify in $mydomain
    is in $virtual_mailbox_domains.


    I'll comment on a few items from other posts in this, since I happen to
    have a bit of knowledge in this area:


    Brad wrote:
    I've seen Exim's logs. I was never able to make much of any sense
    out of them. I've also seen postfix's logs, and they seem to me to
    be the model of readability and understandability.
    As a former expert on exim, exim's logs are extremely informative, but
    they're also quite terse. You have to know how exim organizes things
    before they'll make any sense, and then you have to know what the
    single-character codes mean before you know what data you are seeing.
    postfix logs everything very well. Each step of the process is
    logged, and isn't anywhere near as terse as exim's logs. Both provide
    adequate information to identify and correct any situations that will
    arise.

    Heather wrote:
    * Ease of configuration and administration.
    Brad wrote:
    Postfix is the only MTA on the planet that can have a truly useful
    two-line configuration file. Moreover, it has the most intelligible
    configuration file that I have ever seen. Better still, it comes up
    "default secure", unlike every other MTA I've ever seen.

    I've seen Exim configuration files, and it's hard to tell what goes
    where, what is a router versus all the other ways that certain
    things could be handled, etc...
    exim is only semi-easy to configure and administer. postfix is
    easier. exim's model requires you, the administrator, to put together
    all the pieces needed for mail handling (access control, routing,
    transports) and then it requires you to put the logic in place so that
    the right components interact the way you want them to. The biggest
    drawback is the verbosity in the configuration file. The second
    biggest drawback is the trickiness in correctly setting all the
    conditions to handle very unusual and strange situations.

    I would say that exim is actually more flexible than postfix, since
    the admin controls so much of the logic. However, postfix is simpler
    because Wietse already put all the logic in the code and the only
    responsibility of the admin is to fill in the tables correctly.


    Brad wrote:
    When looking at Exim and Mailman, there is a distinct issue that has
    to be kept in mind. The instructions for integrating Mailman 2.0.x
    are oriented exclusively towards Exim 3.x, and the instructions for
    integrating Mailman 2.1.x are oriented exclusively towards Exim 4.x.
    If you've got Exim 3.x and you want to use Mailman 2.1.x, you're
    screwed.
    John wrote:
    no one should be installing and running Exim 3 these days.
    I agree -- exim 3 is extremely old, no longer maintained, and exim 4
    greatly simplified the configuration. I think it has been three or
    four years, now, since exim 3 passed the torch on to exim 4, and I
    can't think of any -good- reason to use it other than perhaps "if it
    ain't broke, don't fix it" (but that includes not upgrading or
    installing a new mailman on the exim3 server).


    Heather wrote:
    With exim, trying to do VERP processing on the digest runs caused
    Mailman to flood exim, even when I turned the number of sessions and
    connections way down. It also brought my poor Mac, which was not
    meant to be a server, to its knees. I'm hoping that the sparc will
    be able to handle peak loads more gracefully than a Powerbook.
    Have I got a story for you! I'll try to keep it succint. Basically I
    moved from NY to IL for a co-op job a few years ago. While I was
    moving, my computer was offline and so I couldn't receive any mail.
    Due to circumstances, I couldn't get a public IP for a total of about
    4 days. As an interim solution, I tried setting the router at my
    parents' house as my backup MX. That router is a 25MHz 486 that had
    8MB RAM at the time. The problem came when mail servers around the
    world (ie lists.debian.org and others) noticed an accessible MX for my
    domain. The ensuing load literally killed the machine. exim forked
    too many processes causing extreme thrashing and the linux kernel's
    OOM killer killed everything including init. I couldn't do anything
    until I went back to NY and even then only a hard reboot was possible
    (no init -> no ctl-alt-del).

    Fast-forward a couple years to another time I moved, and didn't have
    any network for a week or two. I again made that router my backup MX.
    This time it was running postfix, and I told postfix to accept at most
    2 simultaneous smtp connections. During that time the machine had no
    problems, and I was even able to read my mail remotely while I was at
    a conference (albeit slowly).

    The difference is this: exim is wholly decentralized, and so it
    didn't even know it was trashing the machine. It does have a
    load-based limiter, however the problem on that router wasn't load
    (cpu), it was memory. postfix has a central "master" process that
    oversees all the other processes. With this mechanism it is capable
    of limiting each component, such as incoming connections or the
    various deliveries. For example, I now limit both the junk-scanning
    and local deliveries to 2 (each) simultaneous processes. This
    prevents bogging down the CPU when the network is restored after being
    down for a time (eg a few hours or a day). I just let the messages
    sit on the queue a bit longer, which isn't a problem since the machine
    remains usable (it's my desktop/workstation too).


    Heather wrote:
    How would you rate Postfix's efficiency? Is it fast?
    Rather outdated now, but here is an empirical comparison:

    http://www.dt.e-technik.uni-dortmund.de/~ma/postfix/vsqmail.html
    http://www.dt.e-technik.uni-dortmund.de/~ma/postfix/bench2.html
    Does it limit network traffic to the necessary and keep its disk
    reads and writes down to a dull roar?
    See the above narrative on how a woefully underpowered machine fared
    when bombarded with mail running exim vs. postfix. (actually, that
    was precisely the reason I started using postfix -- because it was
    better suited on that machine _as a server_; then I learned how much
    easier it is to use and have stuck with it)

    My preference of MTAs is postfix, but exim is a good second choice,
    IMO. Also, both Phil and Wietse (the authors) are quite respectable
    -- they help users while providing quality software and addressing
    real concerns.

    HTH,
    -D

    --
    "...the word HACK is used as a verb to indicate a massive amount
    of nerd-like effort." -Harley Hahn, A Student's Guide to Unix

    www: http://dman13.dyndns.org/~dman/ jabber: dman at dman13.dyndns.org
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: Digital signature
    Url : http://mail.python.org/pipermail/mailman-users/attachments/20050326/42d26159/attachment.pgp
  • John W. Baxter at Mar 26, 2005 at 3:10 pm

    On 3/26/2005 5:53, "Derrick Hudson" wrote:

    Fast-forward a couple years to another time I moved, and didn't have
    any network for a week or two. I again made that router my backup MX.
    This time it was running postfix, and I told postfix to accept at most
    2 simultaneous smtp connections. During that time the machine had no
    problems, and I was even able to read my mail remotely while I was at
    a conference (albeit slowly).
    You could have told Exim to do that (Exim 2 or 3 or 4...I don't remember
    Exim 1 well enough to say...we didn't use it long). I don't think it can
    limit the number of things injected via command line calls to
    "sendmail"...but that wasn't the problem (Mailman can make it the problem).

    Thank you very much for jumping in. It was very useful to hear from someone
    with solid knowledge of both Postfix and Exim.

    --John
  • Heather Madrone at Mar 26, 2005 at 8:18 pm
    Thank you so much, Derrick. This is exactly the sort of information
    I was looking for. Of particular interest was the discussion of exim's
    and postfix's configuration, the performance benchmarks, and your
    story of running the two MTAs through an underpowered router.
    At 8:53 AM -0500 3/26/05, Derrick Hudson wrote:
    On Fri, Mar 25, 2005 at 11:55:46AM -0800, Heather Madrone wrote:
    [...]
    We were going with Debian,
    which then announced that it's dropping sparc support,
    Hold up. Debian hasn't announced any such thing. Don't pay attention
    to the rumors. Some of the project's leadership *proposed* (notice
    that it's just a proposal) and different way of supporting 11+
    architectures and making releases manageable.
    You're right. I was trying to gloss over the details of a long search for
    an adequate OS. Suffice to say that the linuces have been dropping sparc
    support left and right, and it looked like Debian might follow suit.
    exim is only semi-easy to configure and administer. postfix is
    easier. exim's model requires you, the administrator, to put together
    all the pieces needed for mail handling (access control, routing,
    transports) and then it requires you to put the logic in place so that
    the right components interact the way you want them to. The biggest
    drawback is the verbosity in the configuration file. The second
    biggest drawback is the trickiness in correctly setting all the
    conditions to handle very unusual and strange situations.
    Yes, this is true. It took me a few weeks to fine-tune exim so that it
    correctly handled all the usual occurrences in my mail world.

    It's pretty easy to configure if you can read and think, however, something
    that has not always been true in the Unix world. I had it up and running
    and working with Mailman in a few hours, and was marveling at how
    smoothly it all went.
    I would say that exim is actually more flexible than postfix, since
    the admin controls so much of the logic. However, postfix is simpler
    because Wietse already put all the logic in the code and the only
    responsibility of the admin is to fill in the tables correctly.
    Are there any configuration options in exim that you miss (or missed)
    in Postfix? I like the ability to control retries, because I don't want more
    network traffic than I need to keep my lists running smoothly. Have you
    ever wished for more control in that area, or does Postfix handle it all
    so intelligently that you're glad to have it use its brain instead of yours?
    I agree -- exim 3 is extremely old, no longer maintained, and exim 4
    greatly simplified the configuration. I think it has been three or
    four years, now, since exim 3 passed the torch on to exim 4, and I
    can't think of any -good- reason to use it other than perhaps "if it
    ain't broke, don't fix it" (but that includes not upgrading or
    installing a new mailman on the exim3 server).
    One of my concerns with Debian is that Python programs tend to be
    closely coupled with Python versions. I was concerned that I might
    be in a position where I'd be stuck in a version of Debian that wouldn't
    work with a new version of Python (and hence Mailman).
    Heather wrote:
    With exim, trying to do VERP processing on the digest runs caused
    Mailman to flood exim, even when I turned the number of sessions and
    connections way down. It also brought my poor Mac, which was not
    meant to be a server, to its knees. I'm hoping that the sparc will
    be able to handle peak loads more gracefully than a Powerbook.
    (To be fair to the Powerbook, I was also asking it to be a laptop at the
    time. It could not handle heavy-duty web browsing at the same time
    it was handling peak Mailman loads. Moving VERP from Mailman
    to exim and setting up a caching name server solved the problem.)

    --
    Heather Madrone (heather at madrone.com) http://www.madrone.com

    A rolling stone gathers no mass.
  • Brad Knowles at Mar 26, 2005 at 8:25 pm

    At 12:18 PM -0800 2005-03-26, Heather Madrone wrote:

    One of my concerns with Debian is that Python programs tend to be
    closely coupled with Python versions. I was concerned that I might
    be in a position where I'd be stuck in a version of Debian that wouldn't
    work with a new version of Python (and hence Mailman).
    If you need to keep an old version of Python on the system, you
    can always install a newer version somewhere else, and configure
    Mailman to use that instead of the normal one. That shouldn't be too
    much work.
    (To be fair to the Powerbook, I was also asking it to be a laptop at the
    time. It could not handle heavy-duty web browsing at the same time
    it was handling peak Mailman loads. Moving VERP from Mailman
    to exim and setting up a caching name server solved the problem.)
    /me wonders how much of the performance difference was due to letting
    Exim handle the VERP as opposed to setting up a caching nameserver.

    --
    Brad Knowles, <brad at stop.mail-abuse.org>

    "Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

    SAGE member since 1995. See <http://www.sage.org/> for more info.
  • Heather Madrone at Mar 26, 2005 at 9:15 pm
    ...dropping the OS issue, which is not on-topic for this list.
    At 9:25 PM +0100 3/26/05, Brad Knowles wrote:
    (To be fair to the Powerbook, I was also asking it to be a laptop at the
    time. It could not handle heavy-duty web browsing at the same time
    it was handling peak Mailman loads. Moving VERP from Mailman
    to exim and setting up a caching name server solved the problem.)
    /me wonders how much of the performance difference was due to
    letting Exim handle the VERP as opposed to setting up a caching
    nameserver.
    You're right that that caching nameserver made the biggest difference
    in terms of increasing network throughput (and decreasing timeouts).
    That was probably 2/3 of the performance right there, and it came off
    all delivery times, whether the system was busy or not.

    In terms of getting the mail into the users' mailboxes, having exim do
    the VERP processing decreased the elapsed time for digest deliveries
    from a mean of 60 minutes to a mean of 15 minutes. Mailman had
    to make many more connections to exim, and exim was unable to
    batch deliveries to the same host as efficiently as it can do when it does
    its own VERP processing. Turnaround on normal list deliveries was
    improved also, but not as dramatically.

    Exim could certainly be smarter about batching deliveries to the same
    host. It only seems to try for messages that come in on the same queue
    run, so it was better to have Mailman send all its digest runs in one
    lump sum (more or less) and then have exim churn through them than
    to have Mailman dole them out and exim handle them inefficiently.

    When I was having Mailman do its own VERP, I'd see exim do VERP
    checks repeatedly on the same address. When exim is doing the VERP,
    it still does some of this, but much less.

    --
    Heather Madrone (heather at madrone.com) http://www.madrone.com

    A rolling stone gathers no mass.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedMar 24, '05 at 2:41p
activeMar 26, '05 at 9:15p
posts29
users8
websitelist.org

People

Translate

site design / logo © 2022 Grokbase