Comment 1 for bug 266812

P.S. I realize that I can accomplish what I want by an
appropriate setting of header_filter_rules, but it's not
very convenient, since I can't make use of
acceptable_aliases.

The introduction of header_filter_rules is great, but it
creates confusion by making the existing sender and
recipient filters redundant. I suggest renaming the section
in which header_filter_rules from "spam filters" to
"advanced filter" or something like that. All three
sections can be used to filter spam, so it's misleading to
distinguish a "spam filter" from sender and recipient
filters. The documentation for header_filter_rules /
"advanced filter" section should explain that this filter is
a general mechanism which exists; the sender/recipient
filters are special cases that are common enough to merit a
convenient interface just for them.

Even with this clarification of the header_filter_rules, I
still think require_explicit_destination should be expanded
to offer all four actions. If you're going to go to the
trouble of setting up the special interface to filter a lack
of explicit destination, it really ought to offer complete
options. It won't complicate the interface (really, it will
simplify it to have the familiar four actions offered), and
it seems very awkward to have to recreate this nice
interface in header_filter_rules (acceptable_aliases and so
on) just because the manager wants an action other than
"accept" or "hold".