Re: [Exim] Access denied error and retries

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Philip Hazel
Dátum:  
Címzett: Darren Mackay - Lists
CC: exim-users
Tárgy: Re: [Exim] Access denied error and retries
On Fri, 23 Mar 2001, Darren Mackay - Lists wrote:

>    SMTP error from remote mailer after initial connection:
>    host XXX.XXX.XXX.XXX [XXX.XXX.XXX.XXX]:
>    500 access denied; too many concurrent connections

>
> I know this error is pretty self explanatory, however the time stamps on the
> log indicate that exim it attempting delivery every 10 to 20 secs until
> delivery is complete. The logs indicate that usually 3 to 5 attempts are
> needed during peak periods, which is around lunchtime. This particular is
> the first of 2 smarthost we send outbound mail to.


It is possible that you are hitting a bug that was fixed in release
3.20. Here are the ChangeLog extracts:

5. If there were several messages queued for the same host, and at every
attempt to deliver, all the addresses got 4xx errors, Exim could get into a
loop trying to deliver the messages over the same SMTP channel, and cycling
round the messages as it did so. Now, it won't pass the channel to another
message unless at least one address was either successfully delivered, or
rejected with a hard (5xx) error. In other words, unless there was some
progress in delivering to that host.

6. As another safety precaution against the problem encountered in 5, the
default value of the batch_max option in the SMTP transport has been changed
from zero (unlimited) to 500.

The behaviour on receiving a 500 message on connection would be the same
as every address getting 4xx in the release you are running.

However, if you upgrade to 3.22 (the latest release) you will find also
that another change has been applied:

9. Exim was treating a 5xx response on connection to an SMTP server, or in
response to HELO, in the same way as a connection failure - that is, as a
temporary error, causing the message to be tried again later. It now bounces
all the addresses in these situations.

This will cause your messages to bounce. The problem is in the remote
server. It should not be giving a 5xx error for a temporary problem. It
should be giving a 4xx error. The RFCs are quite clear that a 5xx error
means "permanent error; do not try again".

Philip

--
Philip Hazel            University of Cambridge Computing Service,
ph10@???      Cambridge, England. Phone: +44 1223 334714.