July 9, 2024 4:16 PM, "Tassilo Philipp" <[email protected]> wrote:
>>> 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. > > Mh... sounds like a good idea, however, smtpd.conf(5) itself would still just > be a binary option, > no? > nope, it could be a binary option to match the fact that tls was specified, or it could be an option with suboptions (tls cipher ..., tls version ...) to match a more specific criteria. if you implement the more general feature, you still want to put the data for the more specific ones in the envelope to avoid having to many envelope format changes for foreseen features. >> 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. > > I might not follow... what would be the flag "day"? > I can look at it, but... > it means that we have to tell everyone "sorry, the new envelopes are incompatible, you need to empty the queue and reload smtpd", it's painful for users so you really want to avoid it at all cost. It's not always avoidable, so if you HAVE to provoke one, we want to make sure it contains all changes we will need for upcoming features too. >> 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 think I have to study the code a bit more thoroughly, first, and do > play around with it, to > not miss anything. This might take a little bit longer, life's unfortunately > not that easy, lately. > :-/ > no rush >> I'd suggest you move forward with your diff, including envelope > changes, >> and we can discuss with >> the full diff. > > Sounds good! Will try to make it happen! > > Thanks for the helpful feedback, glad I asked, first :)
