Please watch your formatting. I've reformatted this message so it's
reasonable. Many people won't take the trouble to reply to you if
you won't take the trouble to format to under 74 columns.
Jonnie <jrk@???> probably said:
> 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
They exist and are annoyingly broken, yes.
> is it the case that a MTA MUST consider 5xx codes "permanent" ?,
In the context that was being discussed, yes.
> 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
> S: RCPT TO:<eric@???>
> R: 552 Recipient storage full, try again in another transaction
Errors are context sensitive. 5xx doesn't always mean "disconnect and
go away". Here it means "I won't take any more 'RCPT TO:'s for this
message, send the rest seperately". The appropriate response here to
this 552 code is, as the example gives, to finish giving RCPT TO:s and
to send the data section of the message.
> 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 ?
We do. 4xx and 5xx. Just because people write bad code and bad
applications doesn't mean they are ambiguously. It just means some
people are incompetent. This is hardly news.
P.
--
pir pir@??? pir@???
