OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Wietse Venema (wietseporcupine.org)
Date: Thu Nov 01 2001 - 08:48:51 CST

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

    Michael Tokarev:
    > > You're using WARN for debugging REJECT actions. A debugging warning
    > > can be generally useful to alert that a restriction of some sort
    > > would cause mail to be rejected. That is not limited to table lookup.
    > >
    > > And it's not difficult to implement either: the routine that
    > > processes the "warn_if_reject" token has to manipulate a flag, and
    > > there needs to be some code that maintains the flag appropriately
    > > as code recurses and returns. Maybe the flag can be implemented
    > > as a counter.
    >
    > Looking to this further, and having in mind several threads ("proper
    > place for UCE restrictions", "Another interesting spam trick" with
    > HELO argument validatio etc), I see a good reason(s) to have this
    > sort of debugging very useful now... ;) And I see two variants for
    > the usage. Dictinary lookup is unaffected by this, but other
    > reject primitives are affected:
    >
    > a) smtpd_xxx_restrictions = warn_if_reject, reject_unknown_hostname
    > b) smtpd_xxx_restrictions = warn_unknown_hostname

    Something along the lines of a) is preferable, because functionality
    is implemented in one place, while b) is a maintenance nightmare.

    > o other "permits" can be made "tuneable" too either by prefixing
    > a permit with "warn_if_permit" (or more general, warn_if_applicable")

    And we would need a separate mailing list for discussions on how to
    use this.

    > o [what about header/body checks]

    They need a WARN token; the present architecture allows us no choice.

    If we had a bright moment then we could turn the whole UCE architecture
    inside out, and change the existing test+reject code that is spread out
    over smtpd+cleanup into a bunch of sensors for a policy daemon.

    That is different from designs that copy the entire message stream
    through some Kremlin-style censoring daemon, or that require that
    all the test+reject be concentrated in the Postfix SMTP server.

    > o with variant "warn_if_reject, reject", it is better to be able
    > to use something like "warn_if_reject, 554 xxx" instead

    The Postfix access control little language was not designed to
    contain raw SMTP commands.

            Wietse
    -
    To unsubscribe, send mail to majordomopostfix.org with content
    (not subject): unsubscribe postfix-users