• Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>:

Bary Warsaw or Brad Knowles. According to my knowledge they haven't married. I might be wrong though.

Barry, Brad, I apologize. No offense intended. Lack of coffee.

Cheers Stefan

On Aug 4, 2009, at 7:43 AM, Ralf Hildebrandt wrote:

• Stefan Förster <cite+mailman-users@incertum.net>:

...

• Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>:

...

Bary Warsaw or Brad Knowles. According to my knowledge they haven't married. I might be wrong though.

Barry, Brad, I apologize. No offense intended. Lack of coffee.

Same here. I apologize for the cheesy joke.

It's okay, I'm lactose intolerant.

-Barry

• Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>:

• Stefan Förster <cite+mailman-users@incertum.net>:

...

| smtp_mx_session_limit (default: 2)

While I can certainly imagine larger sites having somewhere between five to ten MXs, 100 seems a bit... oversized.

maybe it tries to set a very hight threshold, thus ALWAYS using ALL MXes?

You don't have an infinite amount of smtp(8) delivery agents, and you don't want to keep them all busy trying the 14th MX of a destination which is most probably dead.

What you actually want to do is ensure that you try at least

floor($num_mx / 2) + 1

different hosts (hello, greylisting!). Mailman can help you in solving this:

list_lists | awk '(NR > 1){print $1}' |
while read list; do list_members $list done | cut -d@ -f2 | sort -u > /tmp/domains

num_mx=0; while read domain; do num_tmp=$(dig $domain mx +short | wc -l) if [ $num_tmp -gt $num_mx ]; then num_mx=$num_tmp fi done < /tmp/domains echo "Maximum number of MX entries: $num_mx" echo "smtp_mx_session_limit should be: $((num_mx/2+1))"

In my case, this script returns "7", so smtp_mx_session_limit should be "4". The problem with this script is, however, that it relies on "list_lists" and "list_members" being available to a user with shell access.

I'm running a Debian package of Mailman and I know that it is modified, I just don't know to which extent. Perhaps someone with more knowledge could comment on the availability of those two helper commands in a standard Mailman installation? Perhaps they must be executed as the Mailman user, or with some special environment.

Cheers Stefan

Stefan Förster wrote:

list_lists | awk '(NR > 1){print $1}' | \

or

list_lists --bare | \

I'm running a Debian package of Mailman and I know that it is modified, I just don't know to which extent. Perhaps someone with more knowledge could comment on the availability of those two helper commands in a standard Mailman installation? Perhaps they must be executed as the Mailman user, or with some special environment.

In the standard source distribution, all the command line commands including list_lists and list_members are available in Mailman's bin/ directory and run from there without any special environment.

They do need to be run directly or via sudo by root or some user in Mailman's group.

Is it the case in Debian that any user on a shared system can run say list_members on any list?

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Stefan Förster wrote:

Since Mailman's "bin" directory has 755 permissions on Debian, every user can attempt to run these commands. Most directories (except private archives) in /var/lib/mailman have world read/execute permissions, but it seems that the actual data is owned by group "list" and only readable by group/owner. So running either "list_lists" or "list_members <listname>" result in a EPERM traceback.

It's the same in the source install. The only difference appears to be Debian's addition of symlinks in /usr/sbin/.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

• Brad Knowles <brad@shub-internet.org>:

The way I read this, it has nothing to do with the number of MXes you have. It has to do with how many SMTP delivery sessions you'll attempt over the same connection before you drop the connection and re-connect (if you have more than this number of deliveries left), and that re-connection may well end up going to a different MX.

No. That's controlled elsewhere, based on time:

smtp_connection_cache_destinations = smtp_connection_cache_on_demand = yes

smtp_connection_cache_time_limit = 2s When SMTP connection caching is enabled, the amount of time that an unused SMTP client socket is kept open before it is closed. Do not specify larger values without permission from the remote sites.

smtp_connection_reuse_time_limit = 300s The amount of time during which Postfix will use an SMTP connection repeatedly. The timer starts when the connection is initiated (i.e. it includes the connect, greeting and helo latency, in addition to the latencies of subsequent mail delivery transactions).

This helps avoid conditions where you get locked into a particular MX that is slow, and that slows down all your delivery to that site, for as long as you have mail for that site.

smtp_connection_reuse_time_limit does that:

The problem starts when one of a set of MX hosts becomes slower than the rest. Even though SMTP clients connect to fast and slow MX hosts with equal probability, the slow MX host ends up with more simultaneous inbound connections than the faster MX hosts, because the slow MX host needs more time to serve each client request.

-- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebrandt@charite.de | http://www.charite.de