Stefan Förster put forth on 12/5/2009 8:51 AM:
> * Stan Hoeppner <s...@hardwarefreak.com>:
>> Two classes before smtpd_helo_restrictions should have triggered
>> accepting the email.  The message should have never made it to the HELO
>> checks.  It should have been accepted in smtpd_client_restrictions or
>> smtpd_sender_restrictions.  Both classes come before
>> smtpd_helo_restrictions in my main.cf.
> 
> The order in which checks are evaluated is the one in which the
> criterion to be checkd is made available to Postfix:
> 
> 1. client IP address
> 2. HELO hostname
> 3. MAIL FROM aka "sender"
> 4. RCPT TO, aka "recipient(s)"
> 5. DATA
> 6. .
> 
> 
>> How is everyone missing this?  You're fixated on the darn error message.
>>  We all know what caused the error, a DNS lookup failure.  That's not
>> rocket science and has nothing to do with the problem.  The problem is
>> that the restriction processing order isn't being followed for some
>> reason.  Why isn't it?  _THAT_ is the problem I'm asking for help with.
>>  That was clear in my first email, was it not?
> 
> Postfix behaves according to the documentation. The documentation
> doesn't say that an OK from a check_client_access results in an OK for
> the HELO restrictions.
> 
> And no, it was not clear from your first posting that you had a
> serious misunderstanding of how Postfix access control works. Your
> first posting simply suggested that you worked a whole night, couldn't
> barely keep your eyes open (5:46am) and therefore mixed
> "check_recipient_access" with "check_client_access" in your
> smtpd_helo_restrictions.

Nah, as I said to mouss, I was under the assumption that "first match
wins" meant all other class checks were ignored.  Given that, you can
understand why I was pulling my hair out trying to identify the problem.

Thanks for your patience.

--
Stan

Reply via email to