"allow only if set" is much more complicated then the linked "deny if
set" example; the "deny if set" simply rejects the message when the
header has a particular value. The "allow only if set" must instead mark
appropriate messages as allowed, but then also somewhere else deny all
other messages. Another complication for the "allow only if set" is the
possibility of system messages (e.g. those from cron) that may also need
to be allowed, in which case a blanket deny will not suffice. Yet
another concern is whether your systems allow remote relay; if so and if
the ruleset is crafted incorrectly you could turn your servers into open
relays for anyone who sets the header field in question. That could be
bad, and unless you strip out the test header somewhere, it will be
visible to anyone who can read messages from your system.
One method would be to check at the end of headers whether X-Test has
been seen; if not, reject the message. This will fail system messages
that do not have the header set, but should not turn the system into an
open relay as various other rulesets should still apply to detemine
relaying rights. Thus in sendmail.mc add something like:
LOCAL_RULESETS
Kstorage macro
HX-Test: $>CheckTestHeader
SCheckTestHeader
R$* $: $(storage {xtestsetp} $@ OK $) $1
Scheck_eoh
R$* $: < $&{xtestsetp} >
R$* $: $(storage {xtestsetp} $) $1
R< $+ > $@ OK
R$* $#error $: 553 Missing Header
and rebuild sendmail.cf, restart sendmail, send test messages with
and without the test header.
Those runs of "lots of spaces" must be replaced one or more tab
characters, as Sendmail is one of those unfortunate softwares that
mandates the use of significant whitespace (crazy, I know, but
here we are).
For more information on this example see section 5.1.4.6 in the Sendmail
op.pdf manual, from which the above is more or less cribbed.
Note also that the above should only be used on outgoing mail server
configurations, as it will reject incoming mail that does not have
the required header.
