We've recently suffered large from remote hosts which
(a) won't take no for an answer
ie frequently reattempt after a 550
(b) immediately reattempt after a temporary failure - often provoking the same failure in a tight loop
is it the case that a MTA MUST consider 5xx codes "permanent" ?,
human intervention is _recommended_ in order to reattempt (deliveries) in the face of one,
but the rfcs do give example of reattempts in the same SMTP session, eg "Too Many Recipients Scenario" on pp63 of rfc 821
Obviously, we'd like to have unambiguously temporary and permanent error classes,
but I wonder if we're guilty of some wishful thinking when we see them in the rfc's ?
from rfc821 :
5yz Permanent Negative Completion reply
The command was not accepted and the requested action did
not occur. The sender-SMTP is discouraged from repeating
the exact request (in the same sequence). Even some
"permanent" error conditions can be corrected, so the
human user may want to direct the sender-SMTP to
reinitiate the command sequence by direct action at some
point in the future (e.g., after the spelling has been
changed, or the user has altered the account status).
Too Many Recipients Scenario
-------------------------------------------------------------
R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
S: HELO USC-ISIF.ARPA
R: 250 BERKELEY.ARPA
S: MAIL FROM:<Postel@???>
R: 250 OK
S: RCPT TO:<fabry@???>
R: 250 OK
S: RCPT TO:<eric@???>
R: 552 Recipient storage full, try again in another transaction
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...etc. etc. etc.
S: .
R: 250 OK
S: MAIL FROM:<Postel@???>
R: 250 OK
S: RCPT TO:<eric@???>
R: 250 OK
S: DATA
R: 354 Start mail input; end with <CRLF>.<CRLF>
S: Blah blah blah...
S: ...etc. etc. etc.
S: .
R: 250 OK
S: QUIT
R: 221 BERKELEY.ARPA Service closing transmission channel
[Darren Mackay wrote:]
>So are you are saying that upgrading to exim v3.22 will actually bounce the
> messages rther than attempting delivery on an alternate smarthost? If this
> is the case this would in fact create quite a problem with users
> compalining
> mail is bouncing just because the ISP uses an MTA that does not fully
> conform to the RFCs (it is also very unlikely that the ISP will change
> their
> MTA either - they are using a custom version of sendmail I believe).
--
Jonathan Kyme
jrk@???
