Wietse Venema:
> In summary, there are two orthogonal features that should not be
> mixed up:
>
> - routine logging, which currently does not exist for permit actions.
> This requires one-time infrastructure code for "permit" logging,
> and calls to that infrastructure from a half-dozen strategic places
> (number of calls proportional to number of features).
This is now implemented, documented, and tested.
> - warn-if logging, which one uses to test a feature before deployment.
> This takes a few lines of one-time infrastructure code.
After an initial attempt, it became clear that more is needed to
make a new warn_if_permit feature equally useful as the existing
warn_if_reject feature (not to mention a general warn_if feature
than can be used with any action).
warn_if_reject will not only log a "reject_warning" message for a
reject action. When a reject action fails due to a temporary error,
warn_if_reject also logs a "reject_warning" for any implicit
defer_if_permit actions that would prevent the mail from being
accepted.
Likewise, warn_if_permit should not only log a "permit_warning" for
a permit action. When a permit action fails due to a temporary
error, warn_if_permit should also log a "permit_warning" message
for any implicit defer_if_reject actions that would prevent the
mail from being rejected.
There is no time for designing and testing all the necessary changes,
so this will have to wait.
Wietse
