Re: [Mailman-Users] Mailman 2.1.6 slowness...?
Our load averages are definitely quite small -- hovering below 1.0.
Our sendmail configuration hasn't changed since we upgraded to 2.1.6,
which is why we're [initially] thinking that it isn't a sendmail issue.
Our disks are also quite far from full -- we have oodles of disk
space.
Clarifying question, however -- will mailman only make one SMTP
connection at a time (and block all further outgoing processing until
that one SMTP connection is complete)? Is this why you're suggesting
proper tuning of SMTP_MAX_RCPTS?
We didn't change the value of SMTP_MAX_RCPTS between 2.1.5 and 2.1.6
(500). Perhaps this is too high (none of our lists have close to 500
subscribers in a single domain). We routinely see large sendmail
outgoing queues (and did with 2.1.5, too).
A comment in one of the prior e-mails made me go check the other qfiles
directories -- we have a few hundred files in the qfiles/bad directory
(~200) and a few thousand in qfiles/shunt (~4000). What are these
files? (pardon the newbie question)
Thanks for all your suggestions -- we're checking them in the
background, but it takes a little time to check properly. Also, based
on your replies, I think we need to triple check with our sendmail
maintainers and ensure that they really, really didn't change anything
between when we were running 2.1.5 and 2.1.6 (they swear that they
didn't, but we'll ask again).
On Jul 15, 2005, at 6:57 PM, Brad Knowles wrote:
At 2:55 PM -0700 2005-07-15, Carl Zwanzig wrote:
Sendmail used to throttle itself based on load average of the host.
With new mailman code, and possible newer python (was python
replaced?),
you could be hitting one of those thresholds. It was somewhere in the
sendmail.cf file.
Hmm. Actually, I think you may be on the right track, but not
with regards to load average. The more recent versions of sendmail
will also allow only so many simultaneous connections open, and that
can also be a bottleneck. Proper tuning of SMTP_MAX_RCPTS is
definitely something you want to look at -- too large can hurt you,
as can too small.
--
Brad Knowles, [EMAIL PROTECTED]
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.
--
Mailman-Users mailing list
Mailman-Users@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/
jsquyres%40osl.iu.edu
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;
file=faq01.027.htp
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} Post Doctoral Research Associate, Open Systems Lab, Indiana
University
{+} http://www.osl.iu.edu/
--
Mailman-Users mailing list
Mailman-Users@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/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman 2.1.6 slowness...?
At 3:31 AM +0200 2005-07-16, Carl Zwanzig wrote: I was definitly thinking of load averages, sendmail will reject connections if the LA is too high. Yes, I know precisely what you were thinking about. That is certainly one possibility, but it got me thinking about some others. who hasn't actually run sendmail for quite a while and may be spouting complete BS Note that I was the comp.mail.sendmail FAQ maintainer for '95-97, and I started mucking about with it years before then. I haven't done much with it recently, but that doesn't invalidate all the experience that I have accumulated to date. -- Brad Knowles, [EMAIL PROTECTED] 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. -- Mailman-Users mailing list Mailman-Users@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman 2.1.6 slowness...?
At 8:15 AM -0400 2005-07-16, Jeff Squyres wrote: Clarifying question, however -- will mailman only make one SMTP connection at a time (and block all further outgoing processing until that one SMTP connection is complete)? Yup. Is this why you're suggesting proper tuning of SMTP_MAX_RCPTS? Yup. We didn't change the value of SMTP_MAX_RCPTS between 2.1.5 and 2.1.6 (500). Perhaps this is too high (none of our lists have close to 500 subscribers in a single domain). That's not done on a per-domain basis. Let's say you have 1000 subscribers. With SMTP_MAX_RCPTS set to 500, then you will send out one copy of the message to the first 500 recipients, wait for it to be fully accepted by the MTA, and then send out the second copy of the message to 500 recipients. The result can extremely peaky in nature, kind of like taking a car and shifting the gear box directly from 5th gear to 1st, and then from 1st back to 5th. If you break that up into smaller chunks, the system can be processing more of those chunks in parallel, and each chunk can be accepted faster. We routinely see large sendmail outgoing queues (and did with 2.1.5, too). Given your configuration, I'm not at all surprised. A comment in one of the prior e-mails made me go check the other qfiles directories -- we have a few hundred files in the qfiles/bad directory (~200) and a few thousand in qfiles/shunt (~4000). What are these files? (pardon the newbie question) The stuff in the shunt queue are messages that were malformed in some way, and Mailman shoved them off to the side because it couldn't deal with them. Whenever you stop and restart Mailman, it will go through the shunt queue to see if there is anything it can handle now that previously it could not. This can really hurt startup times, and a large shunt queue can hurt you any time you have to move messages into it. You might want to consider turning off Mailman, moving most of the shunt messages to a different directory name (maybe shunt.old, or shunt.2005-07-16, or whatever), and then creating a new shunt queue with the exact same ownership and permissions. Thanks for all your suggestions -- we're checking them in the background, but it takes a little time to check properly. Also, based on your replies, I think we need to triple check with our sendmail maintainers and ensure that they really, really didn't change anything between when we were running 2.1.5 and 2.1.6 (they swear that they didn't, but we'll ask again). You definitely want to learn more about your sendmail configuration, yes. -- Brad Knowles, [EMAIL PROTECTED] 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. -- Mailman-Users mailing list Mailman-Users@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman 2.1.6 slowness...?
On Jul 16, 2005, at 8:27 AM, Brad Knowles wrote:
We didn't change the value of SMTP_MAX_RCPTS between 2.1.5 and 2.1.6
(500). Perhaps this is too high (none of our lists have close to 500
subscribers in a single domain).
That's not done on a per-domain basis. Let's say you have 1000
subscribers. With SMTP_MAX_RCPTS set to 500, then you will send out
one copy of the message to the first 500 recipients, wait for it to be
fully accepted by the MTA, and then send out the second copy of the
message to 500 recipients. The result can extremely peaky in
nature, kind of like taking a car and shifting the gear box directly
from 5th gear to 1st, and then from 1st back to 5th.
Ah -- thanks for clarifying. This is not really what is implied in the
FAQ
(http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq04.012.htp)
-- I read it to imply that mailman is grouping messages to the MTA by
domain in order to boost minimum number of deliveries to a given target
domain. That could simply be my flawed interpretation (I based that
assumption on the bandwidth discussion in the middle), but perhaps it's
worth a few clarifying statements in the FAQ...?
If you break that up into smaller chunks, the system can be
processing more of those chunks in parallel, and each chunk can be
accepted faster.
We have pumped our SMTP_MAX_RCPTS down to 5 (we had never changed it
before -- the mailman default was 500, even though the FAQ suggests
that it should be significantly lower), but we'll have to wait for our
next peak traffic period (likely not until Monday) to see how well it's
actually working out.
We routinely see large sendmail
outgoing queues (and did with 2.1.5, too).
Given your configuration, I'm not at all surprised.
Right -- sorry, I didn't mean to imply otherwise. We were not
surprised by this, either. I was trying to say that we've seen this
behavior for a long time and didn't have any performance issues with
it.
A comment in one of the prior e-mails made me go check the other
qfiles
directories -- we have a few hundred files in the qfiles/bad
directory
(~200) and a few thousand in qfiles/shunt (~4000). What are these
files? (pardon the newbie question)
The stuff in the shunt queue are messages that were malformed in
some way, and Mailman shoved them off to the side because it couldn't
deal with them. Whenever you stop and restart Mailman, it will go
through the shunt queue to see if there is anything it can handle
now that previously it could not. This can really hurt startup times,
and a large shunt queue can hurt you any time you have to move
messages into it.
You might want to consider turning off Mailman, moving most of the
shunt messages to a different directory name (maybe shunt.old, or
shunt.2005-07-16, or whatever), and then creating a new shunt queue
with the exact same ownership and permissions.
Sounds good -- will do. Thanks!
Thanks for all your suggestions -- we're checking them in the
background, but it takes a little time to check properly. Also,
based
on your replies, I think we need to triple check with our sendmail
maintainers and ensure that they really, really didn't change
anything
between when we were running 2.1.5 and 2.1.6 (they swear that they
didn't, but we'll ask again).
You definitely want to learn more about your sendmail configuration,
yes.
The thought occurs to me that perhaps it wasn't our sendmail guys who
changed something, but perhaps the guys in the anti-spam/virus-checking
crew changed something (I believe they also check outgoing mails for
some insundry list of things that they believe indicates spam/viruses).
Hmm. Need to go ping them, too...
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} Post Doctoral Research Associate, Open Systems Lab, Indiana
University
{+} http://www.osl.iu.edu/
--
Mailman-Users mailing list
Mailman-Users@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/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman 2.1.6 slowness...?
At 8:45 AM -0400 2005-07-16, Jeff Squyres wrote: Ah -- thanks for clarifying. This is not really what is implied in the FAQ (http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq04.012.htp) -- I read it to imply that mailman is grouping messages to the MTA by domain in order to boost minimum number of deliveries to a given target domain. No. He's talking about the network bandwidth that will be used by the MTA, once it has accepted all the messages and recipients from Mailman. The MTA is forced to send no more than X recipients to a given target site, because no more than X recipients exist at that site. But Mailman could dump hundreds of thousands of recipients on the local MTA, and not care about what the local MTA does with that. We've been talking about the Mailman-to-MTA interface, not the MTA-to-MTA interface. That could simply be my flawed interpretation (I based that assumption on the bandwidth discussion in the middle), but perhaps it's worth a few clarifying statements in the FAQ...? I'll see if I can come up with something. If you break that up into smaller chunks, the system can be processing more of those chunks in parallel, and each chunk can be accepted faster. We have pumped our SMTP_MAX_RCPTS down to 5 (we had never changed it before -- the mailman default was 500, even though the FAQ suggests that it should be significantly lower), but we'll have to wait for our next peak traffic period (likely not until Monday) to see how well it's actually working out. One thing I would encourage you to do is to change just one thing at a time, and see what the effects are. With regards to reducing SMTP_MAX_RCPTS, I would encourage you to reduce the value by roughly half at each stage. So, go from 500 to 250, 250 to 125, 125 to 62, 62 to 32, etc This way, you should get a better idea of what the real threshold is. Right -- sorry, I didn't mean to imply otherwise. We were not surprised by this, either. I was trying to say that we've seen this behavior for a long time and didn't have any performance issues with it. This sort of thing happens all the time with all sorts of systems. People will notice that their tires seem a little low, and there is some smoking coming out of the tailpipe, but they won't do anything about it until the car blows up or the tires come off the rims, etc That's when they take the car to the mechanic. With computers, people may notice that queues get really long, but they'll think that this is perfectly normal and acceptable, until something bad happens. That's when they go looking for help. They've been seeing all the signs that something bad was likely to happen soon, but they didn't recognize them for what they were. Sometimes it's expensive to fix catastrophic failures, sometimes not. Unfortunately, this is the way that the world tends to work. The thought occurs to me that perhaps it wasn't our sendmail guys who changed something, but perhaps the guys in the anti-spam/virus-checking crew changed something (I believe they also check outgoing mails for some insundry list of things that they believe indicates spam/viruses). Hmm. Need to go ping them, too... Yeah, gotta talk to them, too. The recommended practice for mailing lists is to check messages on input, but don't try to check them on output -- after all, the messages were already demonstrated to be clean on input. You may or may not be able to do this at your site, but you should at least check with them. The problem could also be DNS or reverse DNS. Those kinds of things can really slow down MTAs, as they check their incoming connections. If a DNS server is flaking out, the MTAs could be taking much longer than they used to in order to do all the same sorts of checks that they've always been doing. Another thing to watch out for is tar-pitting SMTP services, such as TarProxy (see http://www.martiansoftware.com/tarproxy/) or OpenBSD's spamd (see http://www.openbsd.org/cgi-bin/man.cgi?query=spamd and http://www.benzedrine.cx/relaydb.html). Note that spamd can also be run on modern versions of FreeBSD that have also implemented the pf firewall package that is also taken from OpenBSD. This wouldn't directly affect Mailman, but could cause messages to become backlogged on the MTA, waiting to be sent. You want to keep a close eye on those MTAs, and you may want to make sure that any tar-pitting is only done on inbound mail as opposed to outbound. -- Brad Knowles, [EMAIL PROTECTED] 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.
Re: [Mailman-Users] Mailman 2.1.6 slowness...?
Short version -- all good tips; many thanks. We're investigating them all, but as you suggested, we're changing one thing at a time. Checking them thoroughly takes a little while, so I probably won't be able to report anything intelligent back on our results for a week or so (gotta wait for peak usage, for one thing). A few more detailed remarks below. On Jul 16, 2005, at 9:51 AM, Brad Knowles wrote: Ah -- thanks for clarifying. This is not really what is implied in the FAQ (http://www.python.org/cgi-bin/faqw-mm.py? req=showfile=faq04.012.htp) -- I read it to imply that mailman is grouping messages to the MTA by domain in order to boost minimum number of deliveries to a given target domain. No. He's talking about the network bandwidth that will be used by the MTA, once it has accepted all the messages and recipients from Mailman. The MTA is forced to send no more than X recipients to a given target site, because no more than X recipients exist at that site. Gotcha -- I understand that. But the inference that I made was that if mailman did not group domains together in the 1000 member list shown in the example, then his numbers are not necessarily accurate. Specifically, mails to @example.com may not be conveniently lumped into 1 or 2 transfers to the MTA -- in a worst case, they may be spread out across 1000/SMTP_MAX_RCPTS transfers to the MTA. In this case, the MTA has no way of knowing that they are, in fact, the same message, and therefore may have to initiate 1000/SMTP_MAX_RCPTS connections to the same remote MTA at example.com. Or, even if the MTA can tell that they are the same message, due to race conditions and/or CPU load, the MTA may be eagerly delivering messages to the remote MTA, and therefore still have to initiate 1000/SMTP_MAX_RCPTS connections to the example.com MTA (e.g., if one message is fully sent to example.com's MTA before the next [identical] one arrives at the local MTA from mailman). Hence, I assumed that he was implicitly saying that mailman was grouping domains when it transferred to the MTA (i.e., packed as many @example.com's into a single MTA transfer as possible [until exhausted] -- repeating for all like domains in the recipient list), and therefore could guarantee that there would only be 1 or 2 transfers to the remote MTA (based on the numbers in his example). However, it's quite possible that my logic is incorrect here... :-) We have pumped our SMTP_MAX_RCPTS down to 5 (we had never changed it [snipped] One thing I would encourage you to do is to change just one thing at a time, and see what the effects are. With regards to reducing SMTP_MAX_RCPTS, I would encourage you to reduce the value by roughly half at each stage. So, go from 500 to 250, 250 to 125, 125 to 62, 62 to 32, etc This way, you should get a better idea of what the real threshold is. Will do. Right -- sorry, I didn't mean to imply otherwise. We were not surprised by this, either. I was trying to say that we've seen this behavior for a long time and didn't have any performance issues with it. This sort of thing happens all the time with all sorts of systems. People will notice that their tires seem a little low, and there is some smoking coming out of the tailpipe, but they won't do anything about it until the car blows up or the tires come off the rims, etc That's when they take the car to the mechanic. With computers, people may notice that queues get really long, but they'll think that this is perfectly normal and acceptable, until something bad happens. That's when they go looking for help. They've been seeing all the signs that something bad was likely to happen soon, but they didn't recognize them for what they were. Indeed. Delivery on our big lists had *always* been [relatively] slow; as you said, we always assumed that that was the way it was supposed to work. But deliver for our small lists had always been fairly quick -- when it changed to be fairly slow, that was an indication that something was wrong. The thought occurs to me that perhaps it wasn't our sendmail guys who changed something, but perhaps the guys in the anti-spam/virus-checking crew changed something (I believe they also check outgoing mails for some insundry list of things that they believe indicates spam/viruses). Hmm. Need to go ping them, too... Yeah, gotta talk to them, too. The recommended practice for mailing lists is to check messages on input, but don't try to check them on output -- after all, the messages were already demonstrated to be clean on input. You may or may not be able to do this at your site, but you should at least check with them. Yes, that's exactly what I was thinking. I'm not sure what our anti-spam/anti-virus stuff is doing, but I won't be able to talk to the guys who run that stuff
Re: [Mailman-Users] closely related lists - using users from adifferent lists
David Cake wrote: Is there a way to allow people who are subscribed to a second list to be accepted as subscribers to the first? Not as subscribers, but see http://sourceforge.net/tracker/index.php?func=detailaid=1220144group_id=103atid=300103 for a patch that allows the subscribers of list2 to post to list1. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] REQ: member list with nomail
Daevid Vincent wrote: There should be a way under the Membership Management... section in the web UI to show all members who are set to 'no mail'. This way I can weed out users that are basically useless on the list. See http://starship.python.net/crew/jwt/mailman/#throughtheweb for a script that automates getting a subscriber list from the Membership Management... section and has a --nomail option. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] footer comes as an attachment
I added a footer to non-digest mailing list but for some reason it comes trough with each message as an attachment. I can't figure out why. Any suggestions? -- Mailman-Users mailing list Mailman-Users@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] footer comes as an attachment
James wrote: I added a footer to non-digest mailing list but for some reason it comes trough with each message as an attachment. I can't figure out why. Any suggestions? See the FAQ Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Article 4.39 -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Problems upgrading to Fedora4
Finn Sindre Eliassen wrote: I've upgraded from Fedora 2 to FC4 and and are using mailman version 2.1.35. It works fine, except for one thing; the old list members are gone. How can I retrieve them? The location of the $prefix/lists/ directory changed from Fedora 2 to FC4. You have to find the old lists/listname/ directories and move them to the new location. You probably have to do the same for archives/ -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Duplicate Unsubscribe Notifications
LifeTrek Coaching wrote: When Mailman automatically removes a name from the list, I (as list owner and moderator) and receiving either 3 or 4 notices for each name that is removed. What is causing these multiple notices? How can I resolve the issue? Let me know. Thanks. Are you listed in both 'owner' and 'moderator'? That could account for two copies. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Scheduled Administrative Option
LifeTrek Coaching wrote: My large list (40,000 names) is announcement only and all posts are held (to prevent the possibility of a spammer hijacking the list). So the Schedule option is the only one that would work. Simply scheduling when I send the post would not resolve the problem. You could post with an Approved: list_password header as suggested in FAQ articles 3.11 and 3.34. Then as Tokio suggests, you could schedule the sending of the post to the list on your own PC. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Mailman 2.1.6 slowness...?
At 11:16 AM -0400 2005-07-16, Jeff Squyres wrote: Specifically, mails to @example.com may not be conveniently lumped into 1 or 2 transfers to the MTA -- in a worst case, they may be spread out across 1000/SMTP_MAX_RCPTS transfers to the MTA. I'd have to check the code, but I'm pretty sure that Mailman will sort the recipient list, which will allow the MTA to optimize delivery to each domain -- at least, within the parameters of the VERP and personalization settings. However, it will only break that list up at the boundaries specified by SMTP_MAX_RCPTS. We checked into that, and seem to have a pretty reliable DNS connection (and its cached locally). Some nameserver caching systems occasionally have problems. Check with your DNS server administrators to make sure that they haven't been having any such problems. We've seen a lot of complaints lately on comp.protocols.dns.bind, but maybe that's just a seasonal thing or something. I don't think we're a victim of tarpit kinds of remote MTAs, but even if we are, lowering the SMTP_MAX_RCPTS should help with that, right? It might help. That is, if a recipient has a slow MTA, then *essentially* only the other (SMTP_MAX_RCPTS-1) other recipients will be penalized (because the others will be occurring in more-or-less parallel). Is that right? If the deliveries to the other recipients are not tar-pitted, then you would definitely see an improvement, yes. That's one of the advantages of higher parallelism -- up until the point where every recipient gets their own unique copy of the message (which would happen if you turned on VERP and personalization for each and every list), you have fewer and fewer other recipients who might potentially be slowed down by the message currently being delivered to a slow site. -- Brad Knowles, [EMAIL PROTECTED] 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. -- Mailman-Users mailing list Mailman-Users@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] Editing rejection notice text when action to takefor postings from non-members is 'Hold'.
James wrote: Is it possible to send rejection notice text to non-members if action to take for postings from non-members is 'Hold'? When generic_nonmember_action is Hold and a non-member posts, the poster receives a notice based on the postheld.txt template. See http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq04.048.htp for editing info. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] How can I change the admin list?
I want to change the admin list on my Mailman site(s) from [EMAIL PROTECTED] to some other address, namely another another Mailman email list (in part because [EMAIL PROTECTED] gets spam, and also because I have a general [EMAIL PROTECTED] that handls all admin email addresses). Is this possible? If so, how can I do this? -matt -- Mailman-Users mailing list Mailman-Users@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] How can I change the admin list?
Matt England wrote: I want to change the admin list on my Mailman site(s) from [EMAIL PROTECTED] to some other address, namely another another Mailman email list (in part because [EMAIL PROTECTED] gets spam, and also because I have a general [EMAIL PROTECTED] that handls all admin email addresses). Is this possible? If so, how can I do this? Put MAILMAN_SITE_LIST = 'site-admin' in mm_cfg.py and restart Mailman. This assumes you want to use the [EMAIL PROTECTED] list. If not, it can be the name of any mailman list, but the list must exist. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- Mailman-Users mailing list Mailman-Users@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/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
