On Wed, Sep 09, 2026 at 01:44:06PM +0100, Mark Hills wrote: > On Wed, 9 Sep 2026, Crystal Kolipe wrote: > > 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. > > I agree, but this is exactly the benefit though. > > I (and others) are not smtpd developers and therefore this is _absolutely_ > the best place place to shift the burden of bugs. > > And the closer to the core, the more there is a single implementation > rather than repeating the burdern on each author/filter.
But some people want to do things with filters that can't be achieved with your simple model. In that case, the current API is a benefit, (and it really isn't _that_ hard to work with), whereas the model you described would make it more difficult to implement more advanced types of filters. One more alternative might not seem like too much. But then more requests would likely come along afterwards, for a filter API that's a bit more than yours but still less than the existing one. The current API does, at first glance, look a bit over-engineered for a simple application. But nobody has yet written shim to make the existing API talk to a simple script. One possible reason for that could be because once you start using it, it quickly becomes obvious that it's not actually that complex. > A user with C skills akin to demo_filter.c (pasted below, formatting > preserved) and the time to code like this would be better patching a > feature into smtpd itself. Apart from the fact that telling other people how their time is best spent is a bit dubious, I can't imagine what makes you think that the person who wrote it is automatically interested in contributing to the 'official' project, with all of the beaurocracy that goes along with that, or that the project would be interested in a particular feature that they had coded. Or even that writing a feature for smtpd rather than writing a programming tutorial would be a justifyable use of work time. > I may like to think I'm a C ninja, but I code in C to get me to high level > constructs like awk where I can do my work quickly (and still without > "bloated third-party dependencies") > > The truth here is that example shows enormous scope for fragility or bugs > (at a glance, malloc() and write() results are unchecked, so at best the > example is incomplete; and it omits bounds checking on parts of the > protocol with smtpd) You seem to miss the point of the article, which is to explain the smtpd API in a language-independent way. Nobody is expected to run the quoted code verbatim on a production server. C code is something of a universal lanugage amongst programmers. Even if somebody is not a C programmer, they can usually understand the higher level logic. Various RFCs have sample code in C, for example. For the target audience, mostly writing their own filter in a higher level scripting language, adding the malloc() and write() checks you mention would make it harder to follow the core logic because it doesn't have an equivalent in their language of choice. For anyone who _is_ a C programmer, this should be obvious.
