[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] post now asking for a password, even when it doesn't h

From: Ken Hornstein
Subject: Re: [Nmh-workers] post now asking for a password, even when it doesn't have to
Date: Tue, 15 Apr 2014 09:55:12 -0400

>> 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

>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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]