Stefan Förster put forth on 12/5/2009 6:16 AM: > Whitelist doesn't trigger because you are performing a check for the > value of the "RCPT TO" parameter, not the "HELO" or "EHLO". > > If this isn't what you were looking for I don't have any idea what > your question is.
You're not seeing the forest for the trees. Look at my original post again. Within /etc/postfix/access there is a class C network listed with "OK" that matches the IP address of the rejected sending host. That should have caused the email to be accepted. Also, in smtpd_sender_restrictions, there is a whitelist entry in /etc/postfix/access that matches the sender address in the mail that was rejected. Once again, smtpd_sender_restrictions comes before smtpd_helo_restrictions in my main.cf, so even if for some unknown reason the client check whitelist entry failed, the sender check whitelist entry should have caused the email to be accepted. 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. 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? -- Stan
