From: Rémi Guyomarch (no email)
Date: Thu Nov 01 2001 - 04:07:44 EST
On Tue, Oct 30, 2001 at 09:37:14AM -0700, Matt Armstrong wrote:
> Craig Sanders <> writes:
>
> > On Fri, Oct 26, 2001 at 05:07:54AM -0700, Devin L. Ganger wrote:
> >> On Wed, Oct 24, 2001 at 09:33:12PM +0200, Ralf Hildebrandt wrote:
> >>
> >> > And suddenly you understand why it's such a smart idea to put all
> >> > restrictions in the correct order into
> >> > smtpd_recipient_restrictions.
> >>
> >> Ralf, I know you've gone over the logic of this before many times,
> >> but I still don't know that I fully understand why you insist that
> >> this is the best course of action.
> >
> > it's the best way to do it BECAUSE you can explicitly order the
> > sequence of checks in one place.
>
> This is clearly easier for many people to understand. But when you
> use all of the smtpd_*_restrictions, it becomes more clear where you
> need to go if you'd like to, say, make an exception for a given host
> restriction for a given host.
I completely agree with you Matt.
I certainly don't want to loose the hability to white-list servers /
emails / whatever. Sure, as Ralph pointed in his reply, you can have
white-lists when you have every restrictions in
smtpd_recipient_restrictions but it become ten times more ugly and
harder to manage properly than the current system.
Please, do NOT force every restrictions to be put in one
place. Please, keep it simple for us who have to live in not-so-simple
environments !
> >> I personally have my restrictions ordered all throughout the
> >> various smtpd_*_restrictions clauses and have had no problems, as
> >> there are various behaviors I wish to enforce on certain phases but
> >> not others.
Same thing here.
> > yes, that's possible but it's far more difficult to do right, and
> > far more confusing than just putting them all in
> > smtpd_recipient_restrictions.
> >
> > the actual rejection code (if any) will probably be delayed until
> > the RCPT TO stage of the smtp transaction anyway (by default,
> > smtpd_delay_reject = yes), so it makes no difference to how it
> > works.
> >
> > in short, it works the same but is much easier to read and
> > understand.
For me it's exactly the reverse. Maybe I'm twisted but it seems I'm
not alone in that case :)
-- Rémi - To unsubscribe, send mail to with content (not subject): unsubscribe postfix-users
|
|
|