Bas van Schaik:
> >> Eventually, all mail from the internal server gets through and other
> >> mail traveling through the public mailserver does not get affected by
> >> large delays. However, I think the internal mailserver should stop
> >> processing the large batch of mail as soon as it notices that the public
> >> mailserver started tempfailing on it. That would save both mailservers a
> >> lot of work and would speed up retrying other queued mail.
> >>
> > Server overload is not the only reason for 4xx replies. An SMTP
> > server mail respond with 4XX for all kinds of reasons. If the client
> > were to stop delivering mail for any series of 4XX replies then
> > mail would never get delivered.
> >
> I'm sorry, I did not mean "stop delivering" but more some kind of
> mechanism to detect a server which is not willing to accept anymore. I
> do realize this is quite a vague criterium, clearly this is not easy to
> implement.
As mentioned by Victor, a connection rate limit will cause Postfix
to abandon deliveries to the site that rejects the mail, but you
will not like the result. It will take forever to get mail delivered.
> >> Furthermore I'm wondering if it is possible to tell Postfix to start
> >> tempfailing incoming messages when the server load exceeds some value?
> >> Of course it is possible to implement a hard-limit on the number of
> >> smtpd-processes, but that could cause the server to start idling.
> >>
> > Postfix has always had smtpd process count limits. This is because
> > Sendmail's load average limits did not work.
> >
> Maybe a stupid question: why did the load average limits fail? Surely
> the smtpd process count limit is a beautiful feature, but couldn't they
> be used together?
This is a standard example that I used to give in talks about
Postfix. It is not made up.
1) Server is down (for maintenance or whatever). Mail queues up
on the Internet elsewhere.
2) Server starts accepting mail. Mail starts pouring in from the Internet.
3) Server load AVERAGE increases. By the time the AVERAGE reaches
the limit it is already too late (remember it is an AVERAGE).
4) Server crashes (runs out of swap or whatever).
5) Server reboots, spends some time fsck-ing itself, meanwhile
more mail is queuing up elsewhere on the Internet.
6) Go to 2.
The smtpd process limit provides graceful degradation, instead of
overload/crash/reboot/fsck/overload/crash/reboot...
Wietse
