Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: mig (mig1984.cz)
Date: Sat Mar 28 2009 - 18:02:32 CDT
Thanks for reply,
But I'm still a bit confused about the SMTPD_ACCESS_README.html:
"Restriction lists are still evaluated in the proper order of (client, helo,
etrn) or (client, helo, sender, recipient, data, or end-of-data)
I agree, all restriction lists are evaluated on the RCPT TO (because of the
delayed reject), but not just after the first RCPT TO. It looks they evaluate
again on each RCPT TO. So this is a feature?
Do all items behave like this or is it only the check_policy_service? I mean,
if everything is evaluated again on each RCPT TO, then if I place
reject_rbl_client into smtpd_client_restrictions, the rbl check will run
needlessly more times?
Dne Saturday 28 of March 2009 23:46:18 Sahil Tandon napsal(a):
> On Sat, 28 Mar 2009, mig wrote:
> > I wrote a policy server (that do RBL checks and dynamically disable slow
> > RBL servers). I supposed the right place is the
> > smptd_client_restrictions:
> > smtpd_client_restrictions =
> > check_policy_service unix:/opt/mailfilter/client_restrictions
> > smtpd_helo_required = yes
> > smtpd_recipient_restrictions =
> > reject_invalid_hostname,
> > reject_unauth_pipelining,
> > reject_non_fqdn_sender,
> > reject_unknown_sender_domain,
> > reject_non_fqdn_recipient,
> > reject_unknown_recipient_domain,
> > permit_sasl_authenticated,
> > permit_mynetworks
> > Unfortunatelly it doesn't work as expected. The policy is not executed
> > when a client connects, but on each RCPT TO. It behaves the same way as
> > if the policy was under the smtpd_recipient_restrictions. In my case, it
> > means that the RBL checks will be done again for each RCPT TO...
> > I tried to put the check_policy_service under different restrictions
> > (smtpd_helo_restrictions, smtpd_sender_restrictions), but with the same
> > result - it worked, but as if it was in the RCPT state.
> > smtpd_data_restrictions is the only state where it works well, so the
> > protocol_state=DATA.
> > Is this a bug or a feature?
> By default, smtpd_delay_reject = yes, which means smtpd(8) will wait until
> the RCPT TO stage of the SMTP conversation before evaluating the
> $smtpd_client_restrictions, $smtpd_helo_restrictions and
> $smtpd_sender_restrictions. This is a feature documented in postconf(5).