[Top][All Lists]

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

Re: [Nmh-workers] specifying SMTP server in mts.conf broken by TLS certi

From: Ken Hornstein
Subject: Re: [Nmh-workers] specifying SMTP server in mts.conf broken by TLS certificate changes
Date: Thu, 16 Feb 2017 14:42:51 -0500

>New code in smtp_init() is assuming that the server parameter is a string
>containing the SMTP server. It isn't unless you specify -server as a
>switch to post. If you have the server configured in mts.conf, it is
>still NULL at this point. smtp_init goes on to call rclient() which is a
>wrapper around client().

Sigh.  Like many things with nmh, there is always something more complicated
going on.

The client() function is also used by the POP code; having it fall back to
the list of SMTP servers in mts.conf seems wrong.  Right now that can't
happen because the POP code always supplies a hostname, but still ...
that seems weird to put that code in a generic "client" function.

The more subtle thing is apparently you can do something like:

-host "pop1.foo.com pop2.foo.com"

and that will try both of those servers in succession.  Since we need
to know the connecting hostname for both the the SSL certificate code
and the SASL code, this suggests to me that the right solution is:

- Move the MTS "servers" fallback code from client() into rclient()
  (since that's really just for SMTP).
- Add an argument to client() to let you know which server it ended up
  using for the connection, and have the netsec code use that.


(As a side note, I went and looked and I guess the reason for the rclient()/
client() split was because rclient() used to do a lot more, but I can't
really fathom what the old code used to do :-) ).


reply via email to

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