From: Michael Tokarev (no email)
Date: Thu Nov 01 2001 - 10:12:46 EST
Wietse Venema wrote:
>
> Michael Tokarev:
> > Wietse Venema wrote:
> > >
> > > But why have new code that only works for lookup table restrictions
> > > and nowhere else? Soft_bounce at least has a general scope.
> >
> > Where else can it be useful? In fact, the only real usage I see
> > is in cleanup with header/body checks. Smtpd code as added by
>
> 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
First variant can be applied to a whole dict lookup too, and it is
simpler to implement (only a few code changes required), while second
is easier to read/use. Which variant is preferable?
Notes:
o other "permits" can be made "tuneable" too either by prefixing
a permit with "warn_if_permit" (or more general, warn_if_applicable")
o new WARN dict lookup result can be rewritten with
warn_if_reject, reject
instead (i.e. no new result code can be introduced), but
this is true only for smtpd_*_restrictions -- cleanup with
header/body checks can't be implemented this way. At my
first view, that was the only cleanup with header checks
that really needs this "ability to warn".
o with variant "warn_if_reject, reject", it is better to be able
to use something like "warn_if_reject, 554 xxx" instead
Which variant is more clean?
Regards,
Michael.
-
To unsubscribe, send mail to with content
(not subject): unsubscribe postfix-users
|
|
|