On Wed, Sep 09, 2026 at 12:10:17PM +0100, Mark Hills wrote: > On Wed, 9 Sep 2026, Crystal Kolipe wrote: > > > On Tue, Sep 08, 2026 at 08:42:18PM +0100, Mark Hills wrote: > > > Here's an example: I would like our outbound SMTP servers to strip > > > "Received" headers, to avoid exposing some gnarly details of our internal > > > network (eg. prototype script below) > > > > > > There needs quite a lot of code to sit between smtpd and this script. > > > > About 300 lines of C. Possibly less. > [...] > > all that is required is field-splitting the lines that you receive via > > the filter API, session management, and error handling. > > This is "all"(!) > > A bunch of state, a persistent process, and due care around field > splitting, escaping and buffer handling. > > This is "and now draw the rest of the owl" > > That ~15 line example requires ~2,000% overhead with no discernable upside > (but corresponding exponential increase in bugs)
Well, adding a second filter API to smtpd wouldn't be 'free'. It would just shift the burden of potential new bugs away from your code and towards the smtpd code. > > Written like that, it might sound ominous, but about 98% of this has > > already been done for you, (we published a guide to writing smtpd > > filters which includes examples of such logic). > > Please link to this guide? It does not appear to be in the docs. https://research.exoticsilicon.com/articles/mail_filters > If it exists then the project would be well placed to deploy this -- a > "wrapper" filter which forks scripts on stdin/stdout, maintaned and > installed as part of OpenSMTPd, bug-free. I guess you're looking for something equivalent to slowcgi for httpd. Well, it could be done. Patches are welcome :-).
