From: Luc Pardon (lucpskopos.be)
Date: Wed Feb 08 2006 - 03:18:10 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Victor Duchovni wrote:
> On Tue, Feb 07, 2006 at 06:49:25PM +0100, Luc Pardon wrote:
>
>>
>> * blacklist lookup failure: default 'dunno', override with '-d'
>>to return 'defer_if_permit' instead.
>>
>> * whitelist lookup failure: default 'defer_if_reject', override
>>with '-nd' to return 'dunno' instead.
>>
> Yes, this is the right approach, modulo careful choice of the switch
> letters, and appropriate documentation.
>
> The use of short (single "-") multi-letter (e.g. "nd") options is not
> consistent with Unix option processing standards (getopt(3)) and is best
> avoided. Short options should be single letter or digit, with support
> for the usual shorthand: "-nd" == "-n -d". GNU-style long options should
> use two leading "-" characters, e.g. "--no-defer".
>
> I have no specific naming recommendations (which letters or long option
> names to choose), other than the general advice to avoid inventing your
> own conventions.

     OK, fair enough. I originally tried to avoid clutter in main.cf
with single-letter options and then feature creep got in.

    I guess I'll try to come up with sensible long options first and
then add (possibly cryptic) short options for people with short fingers.

    A few alternatives for the pair of -d and -nd switches described in
the quote above:

    1) --defer-untried-junkmail and --no-defer-untried-realmail

    2) --defer-unconvicted-junkmail and --no-defer-unacquitted-realmail

    3) --no-ignore-blacklist-failure and --ignore-whitelist-failure

    The 'ignore' version (#3) is probably more intuitive, but OTOH the
'defer' versions describe more precisely what is going on from Postfix's
point of view. And the meaning of #2 might not be obvious for non-native
English speakers. Therefore I'm tempted to pick #1, with appropriate
docs to clarify 'untried' as 'trial could not be held because the judge
could not be reached'.

    Of course nobody reads docs ... so maybe #3 after all?

    Anybody has other ideas?

    I will also add the two complementary switches for those who want to
make the defaults explicit (i.e. two sets of --defer../--no-defer...).

>
> Finally, a scalable policy service should run as a listening daemon.
> Per request fork/exec of a Perl script is too expensive for high volume
> mail traffic (tens to hundreds of miliseconds of CPU per invocation).
>

    Hmm. Should be easy enough to implement, but I'd prefer to wait and
see if anybody needs/wants it.

    Actually, I'm not sure if I'd want this on a Very High Volume server
myself. Wouldn't the cost of all these DNS lookups (even with a local
DNS cache) dwarf the exec/fork cycles (smoothed out over $max_use
requests by Postfix)? Also, a weighting policy server might be a better
solution here.

    Luc Pardon
    Skopos Consulting
    Belgium

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]