Re: [exim] Sender Verification Results

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Marc Perkel
日付:  
To: exim-users
題目: Re: [exim] Sender Verification Results


Graeme Fowler wrote:
> Hi
>
> Marc Perkel wrote:
>
>> When sender verify fails, What veriable contains the result string that
>> is returned. I'm trying to make sebder verification smarter so that the
>> following does mean failed.
>>
>> telnet relay.amcity.com 25
>> Trying 65.213.145.14...
>> Connected to relay.amcity.com (65.213.145.14).
>> Escape character is '^]'.
>> 220 ******************************
>> helo ctyme.com
>> 250 relay.amcity.com
>> mail from:marc@???
>> 250 Ok
>> rcpt to:mveloz@???
>> 450 <mveloz@???>: Recipient address rejected: Service is unavailable
>>
>
> ...but that *doesn't* mean that the message permanently failed, it means
> that the remote server returned an error which was transient:
>
> RFC2821, Section 4.2.1, Page 41
> 4.2.1 Reply Code Severities and Theory
>     The three digits of the reply each have a special significance.  The
>     first digit denotes whether the response is good, bad or incomplete.
> <snip>
>     4yz   Transient Negative Completion reply
>        The command was not accepted, and the requested action did not
>        occur.  However, the error condition is temporary and the action
>        may be requested again.  The sender should return to the beginning
>        of the command sequence (if any).

>
> In your case a 450 as detailed in the RFC is:
>        450 Requested mail action not taken: mailbox unavailable
>           (e.g., mailbox busy)

>
> Which does not indicate a permanent error but a transient one. You
> should either defer acceptance of the message yourself and retry later,
> or take a punt and accept it. What you should not do is try to munge the
> return message and make it mean something it does not.
>
> Rejection at this stage is, strictly speaking, in breach of RFC2821 and
> could render you liable to tar, feathers, and public humiliation ;-)
>
> In any case, a brief peruse of the manual (yes, we're in that rude area
> again) gives us:
>
> http://www.exim.org/exim-html-4.62/doc/html/spec_html/ch39.html#SECTaddressverification
>
> Graeme
>
>


Thanks - I'm going to test /$acl_verify_message to see if that gives me
what I want.


/