On Wed, Oct 08, 2014 at 11:53:57PM -0500, Noel Jones wrote:
> > That delay, in and of itself is not really a problem for me. What
> > _is_ a bit of a problem is the fact that smtpd_delay_reject doesn't
> > merely cause anything listed under smtpd_sender_restrictions to be
> > delayed until such time as the _first_ RCPT TO is seen, but rather
> > it causes each of the things listed under smtpd_sender_restrictions
> > to be reevaluated, once for each RCPT TO.
>
> Yes, this is an implementation artifact. I don't know if it's worth
> fixing since it rarely causes an issue.
Actually, it is a design feature. It allows those restriction
classes to also look at the recipient. There is nothing to fix.
Long ago I proposed generalizing the model to allow users to specify
a list of top-level restriction classes that apply to each protocol
stage. Wietse adopted just "smtpd_relay_restrictions", and deemed
the rest needlessly complex, but the basic design is that whatever
set of restriction classes apply to the first recipient at RCPT TO
time also apply equally to the rest.
--
Viktor.
