On 2014-01-22 at 15:09 +0100, basti wrote:
> telnet myserver.de 25
> Trying 1.1.1.1...
> Connected to unix-solution.de.
> Escape character is '^]'.
> 220 mail.myserver.de ESMTP Exim 4.80 Wed, 22 Jan 2014 14:39:54 +0100
> ehlo localhost
> 250-mail.myserver.de Hello p578a6f5e.dip0.t-ipconnect.de [1.1.1.2]
> 250-SIZE 209715200
> 250-8BITMIME
> 250-PIPELINING
> 250-STARTTLS
> 250 HELP
> quit
> 221 mail.myserver.de closing connection
> Connection closed by foreign host.
>
> did this mean that fist of all the connection is encrypt by starttls?
That session means that Exim is not offering authentication when TLS is
not enabled (but says nothing about what Exim provides when TLS is
enabled).
The `gnutls-cli` tool is useful here. I have this shell function:
starttls () {
gnutls-cli --x509cafile "$SSL_CERT_FILE" --starttls --crlf "$@"
}
Point SSL_CERT_FILE in environ to a "cert.pem" of the trust anchors you
want to support. Use like:
$ starttls --port 25 example.org
At the prompt for a command, type `STARTTLS`; when you receive the
response telling you to go ahead, type Ctrl-D to send an EOF to
gnutls-cli, which will trigger TLS negotiation. Once that is complete,
type `EHLO my.host.example.org` once more, to get the post-TLS
capability list, which should now include an AUTH line.
> no one of received or digest are stored in database.
> the password in the db is saved as md5 hash with a salt.
This is not usable with CRAM-MD5. CRAM-MD5 requires access to the
cleartext password. If you use DIGEST-MD5 instead, then you can use a
stored form which is a particular MD5-transformation of the password,
but still not the current scheme. If you're going down this path, then
look to see if the clients support SCRAM auth and how you might store
multiple hash transforms of the password in your database.
Ideally, SCRAM-SHA-1-PLUS (for channel-binding) else SCRAM-SHA-1.
But if you have chosen to only store a particular hash transform of your
password, and that transform was not chosen for compatibility with wire
authentication protocols, then you can only support mechanisms where the
password is disclosed to the server during authentication, so you're
stuck with PLAIN/LOGIN.
-Phil
