I think that the nmh_get_credentials() call needs to move back to
sm_get_pass(). We might want to do that with inc and msgchk, too.
I think in 1.7 we need to deprecate the POP support. And in 1.8
deprecate the submission SASL support.
POP has been handled by external programs for ages.
Since I'm using it every day, obviously I'm -1 on that. All of the
alternatives I looked at were inferior to the native support for my
workflow. Also, clearly the original MH authors did not think POP was
unreasonable to implement in inc, since it's been in there approximately
forever.
As for submission, it's time to teach the MSAs to accept mail on named
pipes. No need for SASL, or networks, or ... I thought I taught
sendmail to listen for mail submission on UNIX:/var/mail/submission
circa 1999?
I think literally every other MUA on the planet (even Unix-based ones)
have the ability to do direct SMTP submission, and most of them can
authenticate via SASL (even if it's just CRAM-MD5 or PLAIN over TLS);
removing that ability would be a step backwards. I had a reason to
setup postfix recently to do a simple email submission, and it was
actually a huge pain in the ass ... it took several hours to get it
right. I've done sendmail configurations in my day as well; it wasn't
so bad once you figured out the sendmail configuration language, but I
cannot think it's reasonable to require users to have to understand
how to configure postfix or sendmail to making sending email via nmh
(perhaps it's most basic functionality) work properly. If you want
to set up nmh to deliver email that way, that's fine; we're always
going to support that. But it's not reasonable to make it the only
way. (Also, you lose some functionality when submitting email via
a pipe, but it may not be functionality you care about).
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers