RE: [Exim] Access denied error and retries

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Jonnie
日付:  
To: exim-list
題目: RE: [Exim] Access denied error and retries
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@???