Ken Hornstein <k...@pobox.com> writes: > >As for THIS specific feature ... well, mh-format is used in a lot of >places. For example, it can be used on message reception (by rcvtty), >and it's used in inc, repl, and now forw and comp. We'd have to think >carefully about the security implications of allowing callouts to >programs. Also, since there aren't too many true string handling >functions in mh-format the normal ways of santizing input or output >aren't available. It just feels like the wrong approach; I know that's >not a great answer, but I don't have a better one.
I grant that, as you have often said, that the main impediment to nmh usage is its MIME support, and that your planned effort to improve MIME support is important. But one of the the trade offs relevant to the existing or prospective nmh user is the extent to which nmh still supports "All power to the user". mh-format constitutes a real barrier to "All power to the user", for all but the most sophisticated of users. I also agree that any further significant effort on mh-format is probably ill advised. This is why I now suggest a new option to, at least, scan and inc, and anywhere else that it is not deemed to be a security risk. The option would be -exec procedure_name, or if you like, -eval procedure_name. If present, then procedure_name would be invoked for each message. procedure_name's stdout would completely replace each scan line. It would not redirect stderr. A non-zero exit status would be an error. For each component, comp, of a message, it would define an environment variable, NMH_FORMAT_comp, whose value was the content of that component. I don't know anything about Lua. But I do know that most prospective users of nmh won't know much about it either, but that almost all of them will surely know at least a little about either it, Perl, Java, Python, Haskel, Erlang, C, ... . _______________________________________________ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
