Re: [Mailman-Users] Slow delivery

2007-03-11 Thread John W. Baxter
On 3/8/07 10:44 PM, "Herman Privyhum" <[EMAIL PROTECTED]> wrote: > > --- Brad Knowles <[EMAIL PROTECTED]> wrote: > >> I'd be willing to bet you're waiting on DNS timeouts >> at the remote end for one or more of your users >> -- their MTA is slowing you down, maybe as a >> result of trying to do

Re: [Mailman-Users] Slow delivery

2007-03-10 Thread Christopher X. Candreva
On Sat, 10 Mar 2007, Brad Knowles wrote: > > This is a common misconception of what IDENT is/was for. IDENT was not > I know what the purpose of IDENT is. I wrote the original sendmail FAQ entry > on this subject back in 1995. Sorry, automatic response of the fingers, usually reserved for IRC

Re: [Mailman-Users] Slow delivery

2007-03-10 Thread Brad Knowles
At 9:48 AM -0500 3/9/07, Christopher X. Candreva wrote: > This is a common misconception of what IDENT is/was for. IDENT was not > intended to provide reliable authentication, as to who owned a connection. I know what the purpose of IDENT is. I wrote the original sendmail FAQ entry on this s

Re: [Mailman-Users] Slow delivery

2007-03-10 Thread Brad Knowles
At 5:15 AM -0800 3/9/07, Herman Privyhum wrote: > If disabling IDENT is so crucial, as both you and my > experience with a triflingly small list seem to argue, > it must be important to amend the Mailman-Exim Howto, > no? Well, it's their HowTo, so I don't see that this is something that we

Re: [Mailman-Users] Slow delivery

2007-03-09 Thread vancleef
The esteemed Brad Knowles has said: > > At 8:46 PM -0700 3/8/07, [EMAIL PROTECTED] wrote: > > > Maybe this is a good time to ask just how DNS-intensive the > > non-sendmail MTA's are. I am finishing off the basics on installing > > sendmail with Mailman, and am including some discussion of th

Re: [Mailman-Users] Slow delivery

2007-03-09 Thread Christopher X. Candreva
On Fri, 9 Mar 2007, Brad Knowles wrote: > So Phil says that he runs a trustworthy IDENT server on his box. > Fine. But plenty of spammers, phishers, and other nefarious types > out there will try to use IDENT as another vector to exploit for use > in breaking into your system, or for tricking

Re: [Mailman-Users] Slow delivery

2007-03-09 Thread Herman Privyhum
--- Brad Knowles <[EMAIL PROTECTED]> wrote: > I'm sorry. I don't see how Phil's views from eight > years ago on this subject are relevant to how > computer systems should be operated in > this modern world. Thanks for the in-depth commentary. Here's the modern FAQ entry, FWIW:

Re: [Mailman-Users] Slow delivery

2007-03-08 Thread Brad Knowles
At 1:04 AM -0600 3/9/07, Brad Knowles quoted Herman Privyhum: > >> http://xrl.us/u8pf (Link to www.exim.org) > > So Phil says that he runs a trustworthy IDENT server on his box. BTW, that article is eight years old now. Eight years in "real" time is over five Internet generations. We were st

Re: [Mailman-Users] Slow delivery

2007-03-08 Thread Brad Knowles
At 10:16 PM -0800 3/8/07, Herman Privyhum wrote: > http://xrl.us/u8pf (Link to www.exim.org) So Phil says that he runs a trustworthy IDENT server on his box. Fine. But plenty of spammers, phishers, and other nefarious types out there will try to use IDENT as another vector to exploit for use

Re: [Mailman-Users] Slow delivery

2007-03-08 Thread Herman Privyhum
--- Brad Knowles <[EMAIL PROTECTED]> wrote: > Ahh, yes. You should definitely disable IDENT. I > didn't know that any modern MTAs actually > used it. Here's Philip Hazel's rationale: http://xrl.us/u8pf (Link to www.exim.org) Herman __

Re: [Mailman-Users] Slow delivery

2007-03-08 Thread Brad Knowles
At 9:44 PM -0800 3/8/07, Herman Privyhum wrote: > Thanks to all for the thorough replies. It appears > that the solution actually lies in disabling ident. Ahh, yes. You should definitely disable IDENT. I didn't know that any modern MTAs actually used it. > I may go back and turn it on aga

Re: [Mailman-Users] Slow delivery

2007-03-08 Thread Herman Privyhum
--- Brad Knowles <[EMAIL PROTECTED]> wrote: > I'd be willing to bet you're waiting on DNS timeouts > at the remote end for one or more of your users > -- their MTA is slowing you down, maybe as a > result of trying to do a reverse DNS lookup on > your IP address. Thanks to all for the thorou

Re: [Mailman-Users] Slow delivery

2007-03-08 Thread Brad Knowles
At 8:46 PM -0700 3/8/07, [EMAIL PROTECTED] wrote: > Maybe this is a good time to ask just how DNS-intensive the > non-sendmail MTA's are. I am finishing off the basics on installing > sendmail with Mailman, and am including some discussion of the need to > install a good fast-response caching

Re: [Mailman-Users] Slow delivery

2007-03-08 Thread vancleef
The esteemed Dragon has said: > > This may just be the time needed to resolve the dns lookups for the > outgoing mail. > > You may want to consider using a caching dns resolver to cache the > sddresses for some reasonable period. Getting the resolved addresses > out of cache will be much faste

Re: [Mailman-Users] Slow delivery

2007-03-08 Thread Mark Sapiro
Herman Privyhum wrote: > >All >messages have been taking just over 105 seconds to >deliver, according to /usr/local/mailman/log/smtp. > >After searching through the archives to this list, I >found that a garbage line in /etc/hosts was >responsible for 75 seconds worth of that. Now we're >down to

Re: [Mailman-Users] Slow delivery

2007-03-08 Thread Brad Knowles
At 3:14 PM -0800 3/8/07, Herman Privyhum wrote: > Where else should I look for things that could be > causing this? Exim only has problems with mail routed > through Mailman. Look at your MTA logs. They should show you when a given message comes in for a given user, and when that is success

Re: [Mailman-Users] Slow delivery

2007-03-08 Thread Dragon
Herman Privyhum sent the message below at 15:14 3/8/2007: >I'm using Mailman in conjunction with Exim on FreeBSD >5.3 to support a small mailing list (60 members). All >messages have been taking just over 105 seconds to >deliver, according to /usr/local/mailman/log/smtp. > >After searching throug

[Mailman-Users] Slow delivery

2007-03-08 Thread Herman Privyhum
Hello, I'm using Mailman in conjunction with Exim on FreeBSD 5.3 to support a small mailing list (60 members). All messages have been taking just over 105 seconds to deliver, according to /usr/local/mailman/log/smtp. After searching through the archives to this list, I found that a garbage lin

Re: [Mailman-Users] slow delivery times

2005-05-06 Thread Brad Knowles
At 1:02 PM +0100 2005-05-06, Paul Key wrote: > I am having a problem of delayed or slow delivery of emails of a list > with around 1600 subscribers. Have you read through the FAQ, or searched the FAQ for terms like "performance"? > Below is an Exim log

[Mailman-Users] slow delivery times

2005-05-06 Thread Paul Key
Using Mailman version: 2.1.3 Solaris 9 Hi I am having a problem of delayed or slow delivery of emails of a list with around 1600 subscribers. Below is an Exim log for a small testlist. Where does the <= [EMAIL PROTECTED] come from? I assume mailman sends this - what is it for? can it be tur

Re: [Mailman-Users] Slow delivery

2004-10-10 Thread Richard Barrett
On 7 Oct 2004, at 03:32, AE Somerville wrote: I am currently experiencing a very slow delivery of email from mailman to our smart relay server. The job of mailman in our system is to accept the list message expand it and inject it directly back to our mail router for it to decide where the messa

[Mailman-Users] Slow delivery

2004-10-06 Thread AE Somerville
I am currently experiencing a very slow delivery of email from mailman to our smart relay server. The job of mailman in our system is to accept the list message expand it and inject it directly back to our mail router for it to decide where the messages are to go. At no time will the mailman server

[Mailman-Users] slow delivery

2004-02-06 Thread Rob Ruth
I have scoured the archives and google for answer to my problem but none of the fixes I have found seem to work. I have mailman 2-1.1-91 installed w/ postfix 1.1.12-12 on a Suse 8.2 box and qrunner/python is eating the cpu. Most of the posts I read describe this as a postfix problem and to chan