Mailman 3 April 2001 - Mailman-Users

Configuration questions
by Michael Neel April 25, 2001

April 25, 2001

Hi all, I'm currently installing Mailman for announcement only "Newsletter" style lists, and it will be used across several virt domains. I have a few questions that I haven't yet found the answer too... Where/Can you change the from/to address to display the name of the list, rather than email address (i.e. have mailman build the from line in the form of From: The List <list(a)list.org>)? I have it set to hide the sender, but I'd like to display a more "user-friendly" from … [View More]

1 0

How many messages in an envelope?
by Erik Parker April 25, 2001

April 25, 2001

Is there a way to bump this down to say.. 2 people per envelope? Vs.. The 20 or 30 it seems to put in now? Erik Parker Mind Security "If you think technology can solve your security problems, then you don't understand the problems and you don't understand the technology."

2 3

Re: [Mailman-Users] How many messages in an envelope?
by J C Lawrence April 25, 2001

April 25, 2001

On Tue, 24 Apr 2001 20:20:35 -0700 (PDT) alex wetmore <alex(a)phred.org> wrote: > On Tue, 24 Apr 2001, J C Lawrence wrote: >> Codswhallop. Intelligent MTAs upon successfully connecting to an >> MX will fork multiple queue runners to that target attempting to >> deliver N parallel streams to the MX until the queue for that MX >> is dry. Even sendmail (finally) does this. > Yes, but if there are many recipients on the one message then > there is no … [View More]reason to send many parallel streams to the final > server. True. This assumes that your MX distribution is very globby (ie your have very large numbers of messages all being delivered to the same domain). In the general case this is true for AOL, Hotmail, Yahoo, MSN, and a couple other domains, with the rest of the target space being forms of large numbers of very small populations. Once you get past the point of those large globs being delivered you're back to lock contention and reduced parallelism as each spool entry now represents an increasingly large distribution of target MXes. Note: This happens to not be true for me. AOL+MSN+HotMail+Yahoo form less than 5% of my subscriber base. > The system can send one stream with all of the recipients, rather > then many identical streams with a couple of recipients each. Which is not necessarily faster, and in AOL's case in particular will tend to cause AOL to silently delete your messages as suspected SPAM without every delivering them to the recipients. There are three variables here: NumberOfTransactions, Parallelism, and Bandwidth. The three of them rest on two variables: TotalNumberOfRecipients and MessageSize. Where the sweet spot on that graph is for you is very dependant on your load, setup, etc as previously discussed. > It also depends on strongly on which MTA you are using. Yup, massively. > I am very familiar with the Windows 2000 SMTP Server, and not as > familiar with sendmail or postfix (I've used them for many years, > but I haven't dug into them). I can't comment on the Windows side of things, or SMTP Server's spool handling/locking characteristics as I've never looked at or used it. I'm only passingly familiar with Sendmail (last used it in any heat over 6 years ago). Since then I've been using primarily Exim, and more recently Postfix. I don't feel that I have a full grap on Postfix'es queue handling yet. -- J C Lawrence claw(a)kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- [View Less]

1 0

Re: [Mailman-Users] How many messages in an envelope?
by J C Lawrence April 25, 2001

April 25, 2001

On Tue, 24 Apr 2001 15:53:47 -0700 (PDT) alex wetmore <alex(a)phred.org> wrote: > On Tue, 24 Apr 2001, Erik Parker wrote: >> > Is there a way to bump this down to say.. 2 people per >> envelope? Vs.. The > 20 or 30 it seems to put in now? >> >> Sorry to waste your bandwidth, I found what I was looking for in >> the Defaults.py .. Default was 500, I bumped it down to 2.. What >> do you know, sending messages to 25000 people at a time now, … [View More]goes >> quite fast. > Increasing this number should result in lower bandwidth usage and > higher performance. This is not necessarily true, and depends heavily on the total number of spool entries and the level of contention among queue runners for deliveries as it reduces the total level of parallelism possible in the delivery process. It also depends on the average load on your mail spool. If your spool is constantly busy then lock contention will be consequently lower as the spool never drains and there are always other entries to process. Consider the simple case for your 1K count envelope. The gain is that due to the low number of transactions the handoff to the MTA is rapid. The problem is that without a constantly active mail server, the delivery rate by the MTA will tend to be low. For a list with 25K members there are now 25 spool entries. This means that there can be at most 25 queue runners. Problem is, some number of those queue runners are going to be locked at any given instant dealing with slow/unresponsive MXes, leaving your total "live" count of actively delivering queue runners as a much smaller (and rapidly decreasing as the situation becomes more pessimal across the queue lifetime). Conversely, setting the max envelope size to a small value, say 10, will result in 2.5K queued entries for the same list post. Given an MTA configured for say 50 queue runners (depending on system I typically run between 20 - 80 with a max of 10 per target MX) you'll likely find that you can maintain queue runner saturation across the majority of the queue run time (depends on the distribution of your targets). Less contention over queue entries equals greater parallelism equals faster delivery times. ObExample: With a 2K member list with envelope seize set to 500 on my main test system under Postfix it takes roughly 14 minutes to drain the queue of responsive MXes. After reducing the envelope size of 5, the drain time is now just over 3 minutes before the spool becomes quiescant (only slow MXes left). Tha gating factor on that 3 minutes is transactional overhead on the deliveries, not disk IO or bandwidth. Further, values above ~20 will tend to result in your mail being silently dropped/deleted by AOL. Its not clear what the exact trigger value is for AOL, and of course they don't publish it, but empirical testing suggests that it is currently 17. > As an example, assume that your list has 1000 users on > hotmail.com. If you are sending messages with 2 recipients then > the best that your MTA can do is to batch two hotmail.com > recipients together. Codswhallop. Intelligent MTAs upon successfully connecting to an MX will fork multiple queue runners to that target attempting to deliver N parallel streams to the MX until the queue for that MX is dry. Even sendmail (finally) does this. > If you are sending with 500 envelope recipients then it might be > able to batch half of the hotmail.com recipients together in one > shot. What the greater number of entries in the envelope gains you is: -- Faster handoff to MTA time -- Lower transaction rate -- Lower bandwidth requirements -- Lower disk IO -- Generally lower system load (outside of MTA configuration) What is costs you: -- Lower parallelism opportunities -- Greater spool entry contention What works best for you will depend on your cost structure, your mail load, and the distribution (and responsiveness) of your target MXes. You are trading off parallelism against bandwidth in the end, with a second order trade of diskIO against transaction rate behind that. Where your sweet spot is will depend on your load. For my setup ( a generally idle system doing ~200K outbound deliveries per day a small envelope size under postfix (used to be Exim) works well as I can effectively maintain a high level of parallelisation (50 queue runners, 10 per MX) during the deliver period. With an envelope size of 10 (versus 5) my queue runtime increases by almost 60%. Moving to 100 almost trebles the queue run time (the graph seems to flatten after about 70 as lock contention becomes the binding factor). ObExcuse: I previously reported that I averaged in the small millions for delivery rate. I was wrong. My stat tool (a little script foo under UCD-SNMP) was, umm, buggy, and was reporting wrongly high values. My actual load averages between 110K - 500K deliveries per day, with occassional bursts/rare bursts up to the 0.8M - 1.1M range. On very busy days (I get bursts like this about once a month) my main box will ship between 0.8M - 1.1M messages a day. That summates to 160K - 220K spool entries per day, which maps out to an average transaction rate of 110 - 152 spool entries per minute. At that point the system is compleatly saturated and disk IO is the gating factor (killing syslog helps a LOT, as does doing some level of domain routing to smarthosts). Were that condition a regular occurance AND Mailman did domain sorting and grouping, then increasing envelope size would make sense as it would decrease the disk IO rate, allowing me to start getting to the point where outbound bandwidth AND diskIO were equally gating factors. My sense, and this is a guesstimate, is that an envelope size of around 30 - 50 would be the sweet spot for that condition (I have a very heavily spread MX base). > As far as I know Mailman doesn't try to batch recipients by domain > though... IIRC (I can't check right now) Mailman does do domain sorting, but does not yet do domain grouping. -- J C Lawrence claw(a)kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as sane as he is dangerous to his environment |=-- [View Less]

2 1

subscribe/unsubscribe
by Steve Lee April 25, 2001

April 25, 2001

I have finally installed and setup mailman. I can subscribe and unsubscribe using the web interface. This part ask for a password when one does subscribe. When I subscribe using the email form by mailling listname-request(a)somedomain.com with the subject line containing subscribe, i recieve a message from mailman and am able to subribe by a reply. Then when i want to unsubscribe using an email with the same address with the subject line containing unsubscribe, it ask for a password and … [View More]

1 0

Re: [Mailman-Users] How many messages in an envelope?
by J C Lawrence April 25, 2001

April 25, 2001

On Tue, 24 Apr 2001 14:16:30 -0700 (PDT) Erik Parker <eparker(a)mindsec.com> wrote: > Is there a way to bump this down to say.. 2 people per envelope? > Vs.. The 20 or 30 it seems to put in now? MAX_RCPT_TO in mm_cfg.py. Depending on your setup the sweet value will vary. I find somewhere between 5 and 10 is my sweet spot. -- J C Lawrence claw(a)kanga.nu ---------(*) http://www.kanga.nu/~claw/ --=| A man is as … [View More]

1 0

Re: [Mailman-Users] hard-resetting list admin passwords?
by Dan Mick April 25, 2001

April 25, 2001

log in using the site password (or have the site owner do it). > Any suggestion on how to hard-reset a list admin password?

1 0

hard-resetting list admin passwords?
by Bill Bradford April 25, 2001

April 25, 2001

Any suggestion on how to hard-reset a list admin password? Since upgrading to python 2.1 / mailman 2.0.4, mailman wont authenticate my admin password for any of the lists that existed before the upgrade... This is *rather important* that I be able to fix soon. 8-) Bill -- Bill Bradford mrbill(a)mrbill.net Austin, TX

1 0

mailman 3.0
by Elshair, Ferras April 24, 2001

April 24, 2001

Hello Do you have a time estimate on when mailman 3.0 will be out? Ferras Elshair

1 0

Re: Mailman-Users digest, Vol 1 #1161 - 8 msgs
by louis stafford April 24, 2001

April 24, 2001

thank you ----- Original Message ----- From: mailman-users-request(a)python.org Sent: Tuesday, April 24, 2001 9:06 AM To: mailman-users(a)python.org Subject: Mailman-Users digest, Vol 1 #1161 - 8 msgs Send Mailman-Users mailing list submissions to mailman-users(a)python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/mailman-users or, via email, send a message with subject or body 'help' to mailman-users-request(a)python.org You can … [View More]

1 0