Stan Hoeppner a écrit : > 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. >
you need to read the docs :) an OK in an smtpd_foo_restrictions skips further checks in _that_ restriction. so an OK in smtpd_client_restrictions skips further checks and goes to smtpd_helo_restrictions. for mail to be accepted, it needs to get an OK in _each_ restriction. by default, all but smtpd_recipient_restrictions return OK, but since you edited yours... This is why I suggested (in my previous post) that you put all your checks under smtpd_recipient_restrictions. Among other things, this avoids the need to duplicate whitelisting actions. > [snip]
