On 2014/11/19 07:09, Stephane Tougard wrote: > I do not even imagine my life without procmail, I use it since 20 years, > it's kind of basic Unix tool, documented and used everywhere ... > > Is it not possible to find a new upstream maintainer for such an > important piece of art than just try to bury it ?
The internet is a very different place now than when procmail was being actively developed. Coding practices have changed too. If someone like Philip who is very familiar with the codebase says it has rotten, I for one would not want it processing the amount of crap that arrives on port 25 today. I'm generally in favour of removing it from ports, it can come back if a new upstream maintainer steps up, but seriously, if there was someone with enough interest in procmail to take it on, why haven't they already done so? *but*... this will hurt people using it for lockfile (somewhat common for shell scripts) - this could be split off easily - and formail - I suspect this may be subject to some of the same problems. Alternatives to procmail(1): sieve has been mentioned, and the implementation that I'm familiar with is good, but it does need admin setup and, for some, a change of MTA. fdm can run in the same "process mail from stdin" role as procmail (as well as pulling from pop3/imap) so that might be a good option. Is there an alternative to formail(1)? I'm not aware of one. If someone wants to step up to tackle this codebase (audit/update or rewrite), I think formail is the best place to start.
