public inbox for [email protected]  
help / color / mirror / Atom feed
From: Magnus Hagander <[email protected]>
To: Marc G. Fournier <[email protected]>
Cc: Andrew Sullivan <[email protected]>
Cc: [email protected]
Subject: Re: what is up with the PG mailing lists?
Date: Thu, 01 Nov 2007 21:33:01 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<20071101080959.49f3087b@scratch>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Marc G. Fournier wrote:
>> No. All those cases are reasons for acceptable delays. But how often
>> does say network connectivity go away for an hour? If they do, you need
>> to better hosting provider.
> 
> You really don't have a clue on how an SMTP server works, do you?  If delivery 

Well, it's been a couple of years since I last wrote a code patch for a
SMTP server, but yeah, I have a fair clue on how it works. And I do run
servers that deliver some 100,000 mails a day. I know, it's not much,
but I know enough to keep those working, and I've never seen internal
delays like what we're seeing here.


> fails, it backs up and tries again *later* ... if there is a high volume of 
> email going through said server, *later* could very well be 1 hour ... and, in 
> fact, its an incremental backup, so it actually works out to be something like:
> 
> Try now, fail, try in 5 minutes, fail, try in 10 minutes, fail, try in 20 
> minutes, fail, etc ... I'm not sure if its a simple '2x' algorithm, but the 
> delay between attempts does get progressively greater, so if it fails after 
> trying at '40 minutes', then it will be another hour and a half after *that* 
> beofre it will try again, etc ...

That's an implementation detail, that differs wildly between different
SMTP servers. But you already know that of course. Postfix,
specifically, implements a '2x' algorithm. There's also a minimum
backoff time (configurable in new versions, previously fixed at 1000
seconds) and a maximum backoff time (configurable).


The main question remains. As Tom posted again in this thread, the delay
happens *internally between hub.org machines*. By your reasoning, that
means it's getting multiple failures to move mail internally. To me,
that's a clear indication that something is wrong. I'm sorry to hear you
don't agree.


>> A couple of minutes delay is perfectly acceptable. A couple of hours is
>> an indication that something is wrong.
> 
> Well, when you see a couple of hours delay, then do something *useful* and let 
> me know ... the only *useful* reports I've had in the past 24 hours dealt with 
> a problem that Tom reported yesterday and that I fixed within minutes of him 
> reporting ... the headers that you and Bruce sent me were *from that problem* 
> ...

I have given up. I used to send these, but nothing is fixed. Maybe I
should set up a procmail script to capture them...

Oh, and the headers I sent were because the email was stuck in the
moderation queue.


//Magnus



view thread (59+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: what is up with the PG mailing lists?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox