July 9, 2024 2:32 PM, "Tassilo Philipp" <tphil...@potion-studios.com> wrote:
> 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.
>
Unsure I understand, it might help to share some config.
> 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?
>
No, not really complex, it just was a bad timing when I wrote this code.
> 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?
>
You won't be opening a can of worms, no, but this diff is not enough:
What we want is to record not only that there was TLS but also what TLS version
and ciphers were
used, so just a binary flag isn't enough.
Furthermore, since this will require adding one or two fields to envelopes,
there will be a bump
in envelope version and _possibly_ a flag day unless old envelopes missing
fields can be updated
transparently by a new smtpd expecting the field.
Back then we had just released the new action-based envelopes so I didn't want
to impose another
flag day on users so soon after, it's been years now so it's acceptable if
needed. If needed, we
need to check if other features might need to ride it so we can unlock multiple
features at once
even if we just provision the envelope but don't expose the features yet.
I'd suggest you move forward with your diff, including envelope changes, and we
can discuss with
the full diff.
> 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).
