Re: default MTA
On Wednesday, June 05, 2013 15:35:14, Marc Haber wrote:
> On Sun, 2 Jun 2013 19:53:59 -0400, Chris Knadle
>
> <Chris.Knadle@coredump.us> wrote:
> >On Sunday, June 02, 2013 17:10:02, Marc Haber wrote:
> >> Exim's default in the packages is not to send authentication data over
> >> a non-encrypted connection. The debconf code could try to check
> >> whether the smarthost allowes TLS, and if not, query the user whether
> >> it is ok to send the password over a non-encrypted connection.
> >
> >Yeah I see why this test could be useful; gnutls-bin is listed as a
> >Suggests by exim4-base, so the TLS libraries may not be locally
> >available.
>
> The TLS libraries are not in gnutls-bin. gnutls-bin contains debugging
> tools. Exim can, of course, use encryption by default.
Ah... okay.
> >The normal way I know to check for TLS availability is to telnet to the
> >SMTP port, give an "EHLO <FQDN>" (and it must be an EHLO) or "EHLO
> >[<IP_address>]", and then look for a "STARTTLS" advertisement in the
> >response from the server. Unfortunately this isn't always possible; some
> >systems filter telnet from reaching the MTA.
>
> Selinux? or how do they do that?
I'm glad you asked this, because it prompted me to investigate further. This
was something I was told was commonly done, but it looks now like it might be
a misnomer. I'm not able to find a concrete example of a system that allows
SMTP MTA transfers but doesn't allow telnet to the SMTP port. [The instances
that seemed to fit the symptoms look like they have more "normal" root causes,
such as ISP port 25 filtering.]
Because I had repeatedly been told that telnet to the MTA was a security
problem, prior to now I had suspected that blocking telnet to SMTP might be
possible via firewall filtering that distinguished the "type of service"
somehow, but after doing some packet sniffing and examining the resulting
packet internals I'm starting to doubt this is possible.
> >Attempting to use an FQDN is also troublesome, because Exim tries to use
> >DNS to look up the FQDN, and falls back to using 'uname -n' which returns
> >the local hostname without a domain name. The SMTP RFCs require the
> >HELO/HELO information to contain an FQDN or an IP address in [] brackets,
> >and some mail systems reject connections containing non-conforming
> >HELO/EHLO greetings.
>
> Smarthosts are usually a lot more forgiving in that regard.
Maybe so, but the smarthosts I run aren't, so I don't have the expectation
that others are. ACL rules for both Exim and Postfix for blocking
noncompliant EHLO/HELO greetings are commonly suggested.
> >> > In this example, the FQDN of the local machine is orac.example.com
> >> > and the smarthost machine is smtp.example.com
> >> >
> >> > Create new file /etc/exim4/exim4.conf.localmacros containing:
> >> > MAIN_TLS_ENABLE = true
> >> > primary_hostname = orac.example.com
> >>
> >> I don't think you need MAIN_TLS_ENABLE to to TLS as a client.
> >
> >Tested this... looks like this is true. :-) Cool. [I'm pretty sure this
> >wasn't always the case, but I'm glad it is now.]
>
> Afair, it was always the case.
Okay -- I'll take your word for it. ;-)
> >> You can set sc_smarthost to hostname::587 without having to change the
> >> transport, see update-exim4.conf(8) or the debconf template for
> >> dc_smarthost.
> >
> >Sweet. Thanks! This really helps because it means I can avoid having to
> >modify exim4.conf.template altogether, which will simplify upgrades
>
> Indeed. The configuration was carefully crafted to allow this.
Cool. Somehow I missed this particular setting.
> >> > On the mail server machine (i.e. smtp.example.com), make an MD5
> >> >
> >> > passowrd hash of the password used on the client machine via command:
> >> > #mkpasswd -H md5 SillyPassword
> >> > $1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1
> >> >
> >> > Then modify /etc/exim4/passwd on the server to add a
> >> >
> >> > username:hashed_passwd:passwd triplet for the client:
> >> > Orac:$1$fUJ2RJ3J$1JvM9dutQs3dbM8DXts1H1:SillyPassword
> >>
> >> You also can a more modern hash if the server is Debian exim as well.
> >
> >The exim4_files(5) man page recommends MD5, which is why I was using it,
> >and thee README.Debian.gz document simply refers to this man page.
> >However crypt(3) indicates that sha-256 is supported too, so I tried it
> >with Exim's passwd file... sure enough, that works. ;-)
>
> I have committed a fix for the manpage that hasn't been touched in
> years. I hope that I pushed to the correct repository.
That's cool. Thanks!
-- Chris
--
Chris Knadle
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74
Reply to: