On Thu, Sep 27, 2012 at 05:38:20PM -0400, Wietse Venema wrote:
> Victor discussed smtpd_relay_restrictions 6 years, see
> http://archives.neohapsis.com/archives/postfix/2006-05/0598.html.
>
> The article also discussed a number of other ideas that have potential
> to increase the Postfix learning curve. I'll leave those for now.
> My current goal is to make Postfix easier to use by eliminating one
> opportunity for human error.
Nice to see the general idea moving forward, thanks. I'd like to make
another attempt to sell the complete package.
Apart from a possibly tricky interaction with the existing
smtpd_delay_reject, adding explicit:
smtpd_client_restriction_classes = ...
smtpd_helo_restriction_classes = ...
smtpd_mail_restriction_classes = ...
smtpd_rcpt_restriction_classes = ...
smtpd_data_restriction_classes = ...
smtpd_dot_restriction_classes = ...
can I think be backwards compatible since all of these can default
empty, and then exhibit legacy behaviour. So the proposal for
smtpd_delay_reject is to do away with it when the new parameters
are in force. In other words as an example:
# Empty? Use legacy behaviour controlled by smtpd_delay_reject
#
smtpd_rcpt_restriction_classes =
# Non-empty, do exactly what the user said:
#
smtpd_rcpt_restriction_classes =
smtpd_relay_restrictions,
smtpd_recipient_restrictions
This implements the new feature, but makes it completely optional,
and gives the user control over ordering and the option to add more
classes.
--
Viktor.
