Hello ML,
I tried to make use of the "tls" option of match rules, and got confused
that whenever that option is specified, the server tries to expand the
"RCPT TO", address, no matter what action is specified. This results in
a 451 Tempfail, when it cannot expand that address.
Puzzled by this I looked into the code, and came across this
implementation in ruleset.c:
static int
ruleset_match_smtp_starttls(struct rule *r, const struct envelope *evp)
{
if (!r->flag_smtp_starttls)
return 1;
/* XXX - not until TLS flag is added to envelope */
return -1;
}
The retval of -1 will always trigger a tempfail in ruleset_match().
So basically it's simply not implemented, so far so good. The fact that
it's documented in the man page, makes me wonder if there was anything
more complex that blocked the implementation?
Would it be enough to introduce a new flag in enum envelope_flags, and
set it when the session flag SF_SECURE is set, e.g. in smtp_tx()? E.g.
some addition like (given EF_TLS would be the new envelope flag):
if (s->flags & SF_SECURE)
tx->evp.flags |= EF_TLS;
I would be open to work on a patch, or do I risk opening a can of worms,
b/c there is something I don't foresee?
Thanks!
PS: my use case, just in case: in some company intranet we try to get
every machine to mail via TLS, either implicit or via STARTTLS. However,
some crappy UPS have severely outdated crypto stacks and there are no
more firmware updates. Given that their status mails aren't security
issues, I wanted to basically whitelist those few devices, explicitly,
so a "!tls" would have come in handy (only other option I see is to
provide a dedicated port, or making starttls optional for any client).
