Earl Hood writes:
> For nmh, my biggest wish is TLS support. And from what I gather, there
> is NO solution that exists for this, either with the nmh core itself
> or via external programs.
Unless I've misunderstood, this is a problem that was discussed and
solved on comp.mail.mh a couple of year
>I think the difficulty may depending on the TLS library to use.
>When I looked at years ago wrt openssl, it appeared to me that the
>work require rewriting I/O stuff in nmh. Of course, I was not an
>expert at the time, but I did not see a quick fix to the problem.
Recently (post-1.3) I made a bu
Ken Hornstein wrote:
>> I'm not going to spend half my day reading RFCs to see just how "MTA" is
>> defined. [...]
>
> Well, I'm sorry ... if you don't understand exactly _what_ am MTA is, then
> how do you expect to participate in a discussion about them? I mean, you're
> the one who changed the
On January 28, 2010 at 15:39, Ken Hornstein wrote:
> I am guessing (I do not know for sure) that the original designers didn't
> want to have to duplicate code and they figured since the -bs mode would
> allow them to reuse the SMTP code, that's what they went with.
That is my assumption.
> Note
On January 28, 2010 at 15:35, Ken Hornstein wrote:
> Why does nmh have SASL support? Because I needed, and I wrote the
> code. Why does nmh _not_ have TLS support? Because no one has written
> the code (in more cynical moments, I might say, "Because I _didn't_
> need it"). Note that anyone is
>can someone remind me why this is so? (i.e., the use of -bs mode?)
I am guessing (I do not know for sure) that the original designers didn't
want to have to duplicate code and they figured since the -bs mode would
allow them to reuse the SMTP code, that's what they went with.
Note that I have n
>The problem, as I see it, is limited resources for maintaining and enhancing
>nmh, as evidenced by the slow pace of development. The question that's being
>posed is where it is best to spend those limited resources. I suggest that
>adding MTA functions into nmh which already exist in external t
earl wrote:
> or via external programs. Neither ssmtp, msmtp, or nullmailer have
> interfaces that nmh expects (from what I gather from documentation).
> They function as drop-in replacements for sendmail and not as SMTP
> proxies. None support the -bs option, which nmh/MH use when in
> send
On January 28, 2010 at 19:15, markus schnalke wrote:
> > Nmh should try to stay in-sync with Internet mail standards,
>
> This needs steady development of nmh in all involved fields (also
> mail retrieval and transfer). By using external tools, only the core
> job of nmh (= reading, organizing, a
> I agree that MIME support should be improved.
Maybe native support for S/MIME signatures and encryption
should be a high priority?
Has anyone cleanly wedged "premail" into their mh setup
for S/MIME signing and signature verification?? It'd be
nice to have a recipe for that.
steve
--
_
[2010-01-28 10:53] Earl Hood
>
> At some point, nmh must be able to read (incorporate) mail to
> do its job. I.e. It must "fetch" the mail from something, somehow.
>
> At the time MH was written, local spool files was all there is, but
> things change. POP came to be a legitimate (standard) d
[2010-01-28 10:37] Earl Hood
> On January 28, 2010 at 11:04, markus schnalke wrote:
>
> > Use a simple forwarding MTA (like nullmailer or ssmtp) instead.
>
> IIRC, ssmtp is a command-line replacement of sendmail vs
> running as a daemon. MH/nmh communicate with sendmail via
> the -bs option, so
In the message dated: Wed, 27 Jan 2010 20:53:46 EST,
The pithy ruminations from Ken Hornstein on
were
:
=> Have we not beaten this subject into the ground yet?
=>
=> >Here's where we differ. For me, it's "easier" to configure sendmail, so that
=> >the nmh configuration remains the same in any
[2010-01-28 10:28] Earl Hood
> On January 28, 2010 at 10:55, markus schnalke wrote:
>
> > Nmh should work on a mailbox in the local filesystem. Incoming mail
> > should enter as plain-text through inc. Outgoing mail should leave as
> > plain-text to an MTA.
>
> Not sure about this statement, esp
[2010-01-28 09:48] Michael Richardson
>
> > "markus" == markus schnalke writes:
> markus> Use a simple forwarding MTA (like nullmailer or ssmtp)
> markus> instead.
>
> okay. That would work for me.
> The work would still be there to essentially:
> a) rip out everything els
[2010-01-28 10:43] Ken Hornstein
> >Instead of having one program inside nmh to forward, use one external
> >program to forward. The external program will surely do the job better
> >than the internal one. (Do you need reasons for this statement?)
>
> Actually, you're going to have to provide som
[2010-01-28 10:39] Ken Hornstein
>
> >> And as for it being _easier_ ... well, literally, configuring the SMTP
> >> MTS is as simple as placing this in your .mh_profile:
> >
> >I personally, don't care much about easy, but I care about right.
> >(Especially, as this is what nmh does better as any
On January 28, 2010 at 10:39, Ken Hornstein wrote:
> >Fetching mail is also the job of a different tool.
>
> So, just so we're clear ... you want to remove the existing support for
> POP in inc as well?
I agree with Ken.
At some point, nmh must be able to read (incorporate) mail to
do its job.
>There are some organizations where all network traffic
>must be encrypted, and if MUAs are to submit to a
>central MTA for delivery, nmh would need TLS support
>to do this.
Minor correction: nmh can do this already, _if_ the SASL mechanism
supports encryption (we have that requirement, and we use
On January 28, 2010 at 11:04, markus schnalke wrote:
> Use a simple forwarding MTA (like nullmailer or ssmtp) instead.
Has anyone got either of these programs to work with nmh?
If so, can they share their configuration?
IIRC, ssmtp is a command-line replacement of sendmail vs
running as a daemon
On January 28, 2010 at 10:55, markus schnalke wrote:
> Nmh should work on a mailbox in the local filesystem. Incoming mail
> should enter as plain-text through inc. Outgoing mail should leave as
> plain-text to an MTA.
Not sure about this statement, especially "plain-text".
MH was written at a t
> We have several graphical MUAs that sit on top of it, and I'd like to
>see more of them, not fewer. I do not want thunderbird and all the like
>to have to reinvent everything.
The problem I see is that if part of your GUI configuration involves
setting up a local email forwarder ... well, kind
>Instead of having one program inside nmh to forward, use one external
>program to forward. The external program will surely do the job better
>than the internal one. (Do you need reasons for this statement?)
Actually, you're going to have to provide some reasons ... I looked at
the examples you p
>History may have been bad. However, it may teach very important
>lessons. One should never ignore it, but one should go new ways if
>appropriate.
Okay ... so, what, you're just dismissing my point here with some vague
"oh, all that stuff people did before, it might be wrong"?
>> And as for it be
> "markus" == markus schnalke writes:
markus> Use a simple forwarding MTA (like nullmailer or ssmtp)
markus> instead.
okay. That would work for me.
The work would still be there to essentially:
a) rip out everything else.
b) adjust packages such that nullmailer/ssmtp
[2010-01-27 18:01] valdis.kletni...@vt.edu
> On Wed, 27 Jan 2010 23:21:10 +0100, markus schnalke said:
> > TLS seems to be already solved. However, why does nmh need TLS?
> > Doesn't it delegate mail transfer to an MTA?
>
> You may need it to talk to a remote MTA that insists on doing TLS. And
>
[2010-01-27 20:53] Ken Hornstein
>
> We've already seen numerous examples of people providing
> legitmate reasons for using the SMTP MTS. The SMTP MTS is not a new
> feature in nmh; it's been there forever. Clearly people thought it was
> useful, even a bazillion years ago.
History may have be
27 matches
Mail list logo
