I'm more confused then ever.
On the IMAP side of my Mailsystem is use
PORT 993
SSL/TLS with Encrypted password
user@machine:~$ openssl s_client -connect myserver.de:993 -showcerts
CONNECTED(00000003)
**** SSl stuff ****
---
* OK [CAPABILITY IMAP4rev1 CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT
THREAD=REFERENCES SORT AUTH=CRAM-MD5 AUTH=CRAM-SHA1 IDLE ACL ACL2=UNION]
Courier-IMAP ready. Copyright 1998-2011 Double Precision, Inc. See
COPYING for distribution information.
^C
I want to use the same on SMTP/Exim side of my Mailsystem.
Which technique do you prefer for:
port 25/465 or 587
SSL/TLS with Encrypted password
Regards,
Basti
On 23.01.2014 09:05, Phil Pennock wrote:
> 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
>
