Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
TLS library problem - SSL routines:SSL3_GET_RECORD - wrong version number
2,041 views
Skip to first unread message
Michael Büker
Oct 14, 2013, 9:20:13 PM10/14/13
to
Hi people,
I'm running postfix 2.9.6 and openssl 1.0.1 stock from Ubuntu 12.04 LTS.
postfix is generally working fine as a relay to several SMTP servers (using a
relayhost_map). However, there is one server that is causing trouble so that I
cannot use it with postfix (while directly addressing it with e.g. kmail
works). That server is run by a large organization, so I can't change its
configuration.
The errors I see are these:
> […] postfix/smtp[9689]: warning: TLS library problem: 9689:error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
> […] postfix/smtp[9689]: 033661A108A: to=<f...@bar.com>,
relay=server[X.X.X.X]:587, delay=0.51, delays=0.09/0.03/0.39/0, dsn=4.4.2,
status=deferred (lost connection with server[X.X.X.X] while performing the
EHLO handshake)
In diagnosing the problem, I found that I can connect correctly to the server
on the command line by issuing:
$ openssl s_client -connect server:587 -starttls smtp -tls1
which gives (among many other things):
> Secure Renegotiation IS supported
> […]
> Protocol : TLSv1
but NOT if I say:
$ openssl s_client -connect server:587 -starttls smtp -tls1_1
which gives these errors:
> 3078101192:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:337:
> […]
> Secure Renegotiation IS NOT supported
> […]
> Protocol : TLSv1.1
(This error was the same with a self-compiled version of the latest openssl
1.0.1e.)
So, I thought I should try to force postfix to use tls1 instead of tls1_1 or
1_2. I set up a tls_policy map that I know is working (because it complains on
typos or if I forbid all the protocols):
[server]:587 encrypt protocols=!SSLv2:!TLSv1.1:!TLSv1.2
However, this does not help, and I still get the same error. Giving
"protocols=TLSv1" fails just the same.
What can I do?
Thanks in advance!
Michael
I'm running postfix 2.9.6 and openssl 1.0.1 stock from Ubuntu 12.04 LTS.
postfix is generally working fine as a relay to several SMTP servers (using a
relayhost_map). However, there is one server that is causing trouble so that I
cannot use it with postfix (while directly addressing it with e.g. kmail
works). That server is run by a large organization, so I can't change its
configuration.
The errors I see are these:
> […] postfix/smtp[9689]: warning: TLS library problem: 9689:error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
> […] postfix/smtp[9689]: 033661A108A: to=<f...@bar.com>,
relay=server[X.X.X.X]:587, delay=0.51, delays=0.09/0.03/0.39/0, dsn=4.4.2,
status=deferred (lost connection with server[X.X.X.X] while performing the
EHLO handshake)
In diagnosing the problem, I found that I can connect correctly to the server
on the command line by issuing:
$ openssl s_client -connect server:587 -starttls smtp -tls1
which gives (among many other things):
> Secure Renegotiation IS supported
> […]
> Protocol : TLSv1
but NOT if I say:
$ openssl s_client -connect server:587 -starttls smtp -tls1_1
which gives these errors:
> 3078101192:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:337:
> […]
> Secure Renegotiation IS NOT supported
> […]
> Protocol : TLSv1.1
(This error was the same with a self-compiled version of the latest openssl
1.0.1e.)
So, I thought I should try to force postfix to use tls1 instead of tls1_1 or
1_2. I set up a tls_policy map that I know is working (because it complains on
typos or if I forbid all the protocols):
[server]:587 encrypt protocols=!SSLv2:!TLSv1.1:!TLSv1.2
However, this does not help, and I still get the same error. Giving
"protocols=TLSv1" fails just the same.
What can I do?
Thanks in advance!
Michael
Viktor Dukhovni
Oct 14, 2013, 9:48:57 PM10/14/13
to
On Tue, Oct 15, 2013 at 03:20:13AM +0200, Michael B?ker wrote:
> > postfix/smtp[9689]: warning: TLS library problem: 9689:error:1408F10B:SSL
> > routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
> > postfix/smtp[9689]: 033661A108A: to=<f...@bar.com>,
> > relay=server[X.X.X.X]:587, delay=0.51, delays=0.09/0.03/0.39/0, dsn=4.4.2,
> > status=deferred (lost connection with server[X.X.X.X] while performing the
> > EHLO handshake)
Obfuscating the target domain and IP address makes it much harder
> > postfix/smtp[9689]: warning: TLS library problem: 9689:error:1408F10B:SSL
> > routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
> > postfix/smtp[9689]: 033661A108A: to=<f...@bar.com>,
> > relay=server[X.X.X.X]:587, delay=0.51, delays=0.09/0.03/0.39/0, dsn=4.4.2,
> > status=deferred (lost connection with server[X.X.X.X] while performing the
> > EHLO handshake)
to help you. At the very least you MUST obfuscate using a 1-to-1
function, so that each distinct domain or IP address is mapped to
a distinct obfuscated value.
You must post the relevant entries (unmangled except for any 1-to-1
mapping) from your transport table that direct mail for the recipients
in question via the problem relay.
> $ openssl s_client -connect server:587 -starttls smtp -tls1
>
> but NOT if I say:
>
> $ openssl s_client -connect server:587 -starttls smtp -tls1_1
>
> which gives these errors:
>
>
> $ openssl s_client -connect server:587 -starttls smtp -tls1_1
>
> which gives these errors:
>
> [server]:587 encrypt protocols=!SSLv2:!TLSv1.1:!TLSv1.2
The obfuscation is again most unfortunate. Most likely said
"[server]:587" lookup key in not fact the literal nexthop from
the transport table.
> However, this does not help, and I still get the same error. Giving
> "protocols=TLSv1" fails just the same.
2.7.9, 2.8.10, 2.9.2 and 2.10. If you're using 2.9.6 you should
be covered if you correctly specify the policy table lookup key
and enable SMTP tls policy lookups.
Showing "postconf -n" output would also be helpful.
--
Viktor.
Michael Büker
Oct 15, 2013, 6:21:28 AM10/15/13
to
On Tue 15.10.13 01:48:57 Viktor Dukhovni wrote:
> Obfuscating the target domain and IP address makes it much harder
> to help you. At the very least you MUST obfuscate using a 1-to-1
> function, so that each distinct domain or IP address is mapped to
> a distinct obfuscated value.
I see the problem. Here, I just replace the domain name of the organization
> Obfuscating the target domain and IP address makes it much harder
> to help you. At the very least you MUST obfuscate using a 1-to-1
> function, so that each distinct domain or IP address is mapped to
> a distinct obfuscated value.
fom [organization].de to foo.de and replace the first IP block with 999 (it's
always the same actual value).
> You must post the relevant entries (unmangled except for any 1-to-1
> mapping) from your transport table that direct mail for the recipients
> in question via the problem relay.
First, here is my postconf -n:
> alias_database = hash:/etc/aliases
> alias_maps = hash:/etc/aliases
> append_dot_mydomain = no
> biff = no
> config_directory = /etc/postfix
> home_mailbox = Maildir/
> inet_interfaces = all
> inet_protocols = ipv4
> mailbox_command =
> mailbox_size_limit = 0
> message_size_limit = 104857600
> mydestination = localhost, asterix, asterix.home, myself.dyndns.net
> myhostname = myself.dyndns.net
> mynetworks = 127.0.0.0/8
> readme_directory = no
> recipient_delimiter =
> sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_map
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
> smtp_sasl_security_options = noanonymous
> smtp_sasl_type = cyrus
> smtp_sender_dependent_authentication = yes
> smtp_tls_mandatory_ciphers = high
> smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
> smtp_tls_security_level = encrypt
> smtpd_banner = postfix on asterix
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_path = private/auth
> smtpd_sasl_type = dovecot
> smtpd_tls_cert_file = /etc/ssl/certs/my.crt
> smtpd_tls_key_file = /etc/ssl/private/my.key
> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
Then, this is the relevant line from /etc/postfix/relayhost_map:
> michael...@foo.de [smtp-auth.foo.de]:587
Which of course has an entry in /etc/postfix/sasl_passwd (win.foo.de belongs in
the username):
> michael...@foo.de mbu...@win.foo.de:password
This is the line for that server in /etc/postfix/tls_policy:
> [smtp-auth.foo.de]:587 encrypt protocols=!TLSv1.1:!TLSv1.2
Now, sending mail from michael...@foo.de gives the following postfix
errors:
> Oct 15 02:30:04 asterix postfix/qmgr[4428]: 42E021A0F44:
> from=<michael...@foo.de>, size=551, nrcpt=1 (queue active)
>
> Oct 15 02:30:04 asterix postfix/smtp[4458]: warning: TLS library problem:
> 4458:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
> number:s3_pkt.c:337:
>
> Oct 15 02:30:04 asterix postfix/smtp[4458]: 42E021A0F44: to=<mb@michael-
> bueker.de>, relay=smtp-auth.foo.de[999.169.5.134]:587, delay=0.51,
> delays=0.08/0.03/0.4/0, dsn=4.4.2, status=deferred (lost connection with
> smtp-auth.foo.de[999.169.5.134] while performing the EHLO handshake)
Now, I _think_ the tls_policy entry is correct, because if I set if to
something absurd like "protocols=SSLv2", the connection fails predictably:
> Oct 15 11:55:20 asterix postfix/qmgr[15283]: 659DA1A11E1:
> from=<michael...@foo.de>, size=550, nrcpt=1 (queue active)
>
> Oct 15 11:55:20 asterix postfix/smtp[15334]: SSL_connect error to
> smtp-auth.foo.de[999.169.5.134]:587: lost connection
>
> Oct 15 11:55:20
> asterix postfix/smtp[15334]: 659DA1A11E1: to=<m...@michael-bueker.de>,
> relay=smtp-auth.foo.de[999.169.5.134]:587, delay=0.29,
> delays=0.08/0.03/0.17/0, dsn=4.7.5, stat us=deferred (Cannot start TLS:
> handshake failure)
However, when I set "protocols=TLSv1", it gives the same error as above
("warning: TLS library problem: 18064:error:1408F10B:SSL
routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:" and "lost
connection with smtp-auth.foo.de[999.169.5.134] while performing the EHLO
handshake").
Even the seemingly absurd values "protocols=!TLSv1:!TLSv1.1:!TLSv1.2" and
"protocols=SSLv3" give that error ("warning: TLS library problem:
18064:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:337:" and "lost connection with smtp-
auth.foo.de[999.169.5.134] while performing the EHLO handshake"), so I'm not
sure about the tls_policy line anymore. I made sure to "postmap tls_policy"
and restart the server after every change.
Now, for command line openssl, first with -tls1_1:
> $ openssl s_client -connect smtp-auth.foo.de:587 -starttls smtp -tls1_1
> CONNECTED(00000003)
> 3077581000:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
> number:s3_pkt.c:337: ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 440 bytes and written 7 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1.1
> Cipher : 0000
> Session-ID:
> Session-ID-ctx:
> Master-Key:
> Key-Arg : None
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1381831404
> Timeout : 7200 (sec)
> Verify return code: 0 (ok)
> ---
The error is different for -tls1_2:
> $ openssl s_client -connect smtp-auth.foo.de:587 -starttls smtp -tls1_2
> CONNECTED(00000003)
> 3077904584:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
> failure:s3_pkt.c:596: ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 435 bytes and written 0 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1.2
> Cipher : 0000
> Session-ID:
> Session-ID-ctx:
> Master-Key:
> Key-Arg : None
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1381831448
> Timeout : 7200 (sec)
> Verify return code: 0 (ok)
> ---
However, connecting works fine with -tls1:
> $ openssl s_client -connect smtp-auth.foo.de:587 -starttls smtp -tls1
> CONNECTED(00000003)
> depth=2 C = DE, O = DFN-Verein, OU = DFN-PKI, CN = foo-cert -
> G01 verify error:num=20:unable to get local issuer certificate
> verify return:0
> ---
> Certificate chain
>
> [ … skipping lots of certificate info … ]
> ---
> SSL handshake has read 4414 bytes and written 570 bytes
> ---
> New, TLSv1/SSLv3, Cipher is RC4-MD5
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
>
> SSL-Session:
> Protocol : TLSv1
> Cipher : RC4-MD5
> Session-ID:
> C80700004DDE0E3E27FD4082227D82FBF991A97FABF3674E29C2FAA3B3CD5797
> Session-ID-ctx:
> Master-Key:
> 349E696910AD644B583ED97EA7FBE5B30251F681607A2E65E05DD02025FFC5ED31D03E6
> 397813BF8898581306536F0F7 Key-Arg : None
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1381831489
> Timeout : 7200 (sec)
> Verify return code: 20 (unable to get local issuer certificate)
>
> ---
> 250 OK
Again, also setting smth-auth.foo.de as the outgoing server in my MUA (kmail)
with the same credentials works fine for sending mails ("TLS" set for
security), but trying to relay with postfix fails.
I hope this was more useful now.
Cheers,
Michael
Viktor Dukhovni
Oct 15, 2013, 11:18:06 AM10/15/13
to
On Tue, Oct 15, 2013 at 12:21:28PM +0200, Michael B?ker wrote:
> > Oct 15 02:30:04 asterix postfix/smtp[4458]: warning: TLS library problem:
> > 4458:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
> > number:s3_pkt.c:337:
> >
> > Oct 15 02:30:04 asterix postfix/smtp[4458]: 42E021A0F44: to=<mb@michael-
> > bueker.de>, relay=smtp-auth.foo.de[999.169.5.134]:587, delay=0.51,
> > delays=0.08/0.03/0.4/0, dsn=4.4.2, status=deferred (lost connection with
> > smtp-auth.foo.de[999.169.5.134] while performing the EHLO handshake)
>
> Now, I _think_ the tls_policy entry is correct, because if I set if to
> something absurd like "protocols=SSLv2", the connection fails predictably:
Note the "while performing the EHLO handshake" detail. This means
> > Oct 15 02:30:04 asterix postfix/smtp[4458]: warning: TLS library problem:
> > 4458:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
> > number:s3_pkt.c:337:
> >
> > Oct 15 02:30:04 asterix postfix/smtp[4458]: 42E021A0F44: to=<mb@michael-
> > bueker.de>, relay=smtp-auth.foo.de[999.169.5.134]:587, delay=0.51,
> > delays=0.08/0.03/0.4/0, dsn=4.4.2, status=deferred (lost connection with
> > smtp-auth.foo.de[999.169.5.134] while performing the EHLO handshake)
>
> Now, I _think_ the tls_policy entry is correct, because if I set if to
> something absurd like "protocols=SSLv2", the connection fails predictably:
the TLS handshake succeeded, but the subsequent SMTP commands failed
inside the encrypted channel. Fortunately, your over-obfuscation
of the target server left me with only 224 choices of the target
IP address. The server in question is a Microsoft Exchange server
with buggy 3DES ciphersuites (IIRC found in Windows XP, and
perhaps Windows Server 2003).
Add "exclude=3DES" to the entry table for this server, and you'll likely
be fine. You probably don't need to tweak the protocols.
$ posttls-finger -o 'tls_medium_cipherlist=aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:!3DES:@STRENGTH' "[smtp-auth.foo.de]:587"
posttls-finger: Connected to smtp-auth.foo.de[999.169.5.134]:587
posttls-finger: < 220 adxf3.win.foo.de Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at Tue, 15 Oct 2013 16:43:11 +0200
posttls-finger: > EHLO central-dogma.lan
posttls-finger: < 250-adxf3.win.foo.de Hello [999.169.40.26]
posttls-finger: < 250-TURN
posttls-finger: < 250-SIZE
posttls-finger: < 250-ETRN
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-DSN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8bitmime
posttls-finger: < 250-BINARYMIME
posttls-finger: < 250-CHUNKING
posttls-finger: < 250-VRFY
posttls-finger: < 250-TLS
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-X-EXPS GSSAPI NTLM
posttls-finger: < 250-AUTH GSSAPI NTLM
posttls-finger: < 250-X-LINK2STATE
posttls-finger: < 250-XEXCH50
posttls-finger: < 250 OK
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 SMTP server ready
posttls-finger: smtp-auth.foo.de[999.169.5.134]:587: Matched subjectAltName: smtp-auth.foo.de
posttls-finger: smtp-auth.foo.de[999.169.5.134]:587 CommonName smtp-auth.foo.de
posttls-finger: certificate verification failed for smtp-auth.foo.de[999.169.5.134]:587: untrusted issuer /C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
posttls-finger: smtp-auth.foo.de[999.169.5.134]:587: subject_CN=smtp-auth.foo.de, issuer_CN=FOO CA - G02, fingerprint=21:B2:6F:D3:19:96:C7:DE:73:A4:0B:70:FA:6B:4C:B1:BC:F1:97:CE, pkey_fingerprint=CC:50:03:5F:14:AA:4B:AC:46:B4:C0:0A:D2:9C:B1:77:E8:DD:0F:10
posttls-finger: Untrusted TLS connection established to smtp-auth.foo.de[999.169.5.134]:587: TLSv1 with cipher RC4-MD5 (128/128 bits)
posttls-finger: > EHLO central-dogma.lan
posttls-finger: < 250-adxf3.win.foo.de Hello [999.169.40.26]
posttls-finger: < 250-TURN
posttls-finger: < 250-SIZE
posttls-finger: < 250-ETRN
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-DSN
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-8bitmime
posttls-finger: < 250-BINARYMIME
posttls-finger: < 250-CHUNKING
posttls-finger: < 250-VRFY
posttls-finger: < 250-X-EXPS GSSAPI NTLM LOGIN
posttls-finger: < 250-X-EXPS=LOGIN
posttls-finger: < 250-AUTH GSSAPI NTLM LOGIN
posttls-finger: < 250-AUTH=LOGIN
posttls-finger: < 250-X-LINK2STATE
posttls-finger: < 250-XEXCH50
posttls-finger: < 250 OK
posttls-finger: > QUIT
posttls-finger: < 221 2.0.0 adxf3.win.foo.de Service closing transmission channel
I'd like to suggest that you find a less broken email provider.
--
Viktor.
DTNX Postmaster
Oct 15, 2013, 11:33:50 AM10/15/13
to
On Oct 15, 2013, at 17:18, Viktor Dukhovni <postfi...@dukhovni.org> wrote:
> On Tue, Oct 15, 2013 at 12:21:28PM +0200, Michael B?ker wrote:
>
>>> Oct 15 02:30:04 asterix postfix/smtp[4458]: warning: TLS library problem:
>>> 4458:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
>>> number:s3_pkt.c:337:
>>>
>>> Oct 15 02:30:04 asterix postfix/smtp[4458]: 42E021A0F44: to=<mb@michael-
>>> bueker.de>, relay=smtp-auth.foo.de[999.169.5.134]:587, delay=0.51,
>>> delays=0.08/0.03/0.4/0, dsn=4.4.2, status=deferred (lost connection with
>>> smtp-auth.foo.de[999.169.5.134] while performing the EHLO handshake)
>>
>> Now, I _think_ the tls_policy entry is correct, because if I set if to
>> something absurd like "protocols=SSLv2", the connection fails predictably:
>
> Note the "while performing the EHLO handshake" detail. This means
> the TLS handshake succeeded, but the subsequent SMTP commands failed
> inside the encrypted channel. Fortunately, your over-obfuscation
> of the target server left me with only 224 choices of the target
> IP address. The server in question is a Microsoft Exchange server
> with buggy 3DES ciphersuites (IIRC found in Windows XP, and
> perhaps Windows Server 2003).
Yes on Windows 2003 Server. It's possible to add the AES ciphersuites
> On Tue, Oct 15, 2013 at 12:21:28PM +0200, Michael B?ker wrote:
>
>>> Oct 15 02:30:04 asterix postfix/smtp[4458]: warning: TLS library problem:
>>> 4458:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
>>> number:s3_pkt.c:337:
>>>
>>> Oct 15 02:30:04 asterix postfix/smtp[4458]: 42E021A0F44: to=<mb@michael-
>>> bueker.de>, relay=smtp-auth.foo.de[999.169.5.134]:587, delay=0.51,
>>> delays=0.08/0.03/0.4/0, dsn=4.4.2, status=deferred (lost connection with
>>> smtp-auth.foo.de[999.169.5.134] while performing the EHLO handshake)
>>
>> Now, I _think_ the tls_policy entry is correct, because if I set if to
>> something absurd like "protocols=SSLv2", the connection fails predictably:
>
> Note the "while performing the EHLO handshake" detail. This means
> the TLS handshake succeeded, but the subsequent SMTP commands failed
> inside the encrypted channel. Fortunately, your over-obfuscation
> of the target server left me with only 224 choices of the target
> IP address. The server in question is a Microsoft Exchange server
> with buggy 3DES ciphersuites (IIRC found in Windows XP, and
> perhaps Windows Server 2003).
to Window 2003 in theory, but it's one of them 'not really supported
hotfix' type things. When we last tried to get it working for a client
it simply did not work.
For our particular situation, this provides a workaround for the few
more months we'll need to support Exchange 2003 on the backend;
smtp_tls_exclude_ciphers = DES-CBC3-SHA
YMMV, of course.
Mvg,
Joni
Michael Büker
Oct 16, 2013, 4:29:21 AM10/16/13
to
On Tue 15.10.13 15:18:06 Viktor Dukhovni wrote:
> The server in question is a Microsoft Exchange server with buggy 3DES
> ciphersuites (IIRC found in Windows XP, and perhaps Windows Server 2003).
>
> The server in question is a Microsoft Exchange server with buggy 3DES
> ciphersuites (IIRC found in Windows XP, and perhaps Windows Server 2003).
>
> Add "exclude=3DES" to the entry table for this server, and you'll likely
> be fine. You probably don't need to tweak the protocols.
Adding "exclude=3DES" or "exclude=DES-CBC3-SHA" to the smtp_tls_policy_maps
> be fine. You probably don't need to tweak the protocols.
file didn't quite do it, maybe because I have "smtp_tls_mandatory_ciphers=high"
set globally. So I used this line, which works for this server:
> [smtp-auth.foo.de]:587 encrypt ciphers=medium
The next problem was the error: "5.7.3 Authentication unsuccessful", which
appears to be unique for Exchange servers. Google suggested a broken GSSAPI
implementation on the server side that should be excluded. That leaves only
LOGIN in this case, which my config doesn't seem to allow for ciphers=medium.
Globally allowing LOGIN with smtp_sasl_mechanism_filter worked, but I didn't
want that. So I defined a new transport in master.cf:
> exchangerelay unix - - n - - smtp -o smtp_sasl_mechanism_filter=!gssapi,login
and configured postfix to use a sender_dependent_default_transport_maps that
contains this line:
> michael...@foo.de exchangerelay:
Now, everything works. Phew.
I might still combine the sender_dependent_default_transport_maps with my
sender_dependent_relayhost_maps so I don't have to maintain both files. Come to
think of it: Couldn't I combine the single line in smtp_tls_policy_maps into
the transport definition and save one more file?
> Fortunately, your over-obfuscation of the target server left me with only
> 224 choices of the target IP address.
avoid angering the admin overlords at foo by publicly discussing their mail
server.
> I'd like to suggest that you find a less broken email provider.
accelerators in much better shape than their mail servers.
Cheers,
Michael
Michael Büker
Oct 16, 2013, 5:05:40 AM10/16/13
to
On Wed 16.10.13 10:29:21 Michael Büker wrote:
> I might still combine the sender_dependent_default_transport_maps with my
> sender_dependent_relayhost_maps so I don't have to maintain both files. Come
> to think of it: Couldn't I combine the single line in smtp_tls_policy_maps
> into the transport definition and save one more file?
Just for the record: I did, and it works. The line in my
> I might still combine the sender_dependent_default_transport_maps with my
> sender_dependent_relayhost_maps so I don't have to maintain both files. Come
> to think of it: Couldn't I combine the single line in smtp_tls_policy_maps
> into the transport definition and save one more file?
sender_dependent_default_transport_maps is now:
> michael...@foo.de exchangerelay:[smtp-auth.foo.de]:587
and the corresponding transport in master.cf looks like this:
> exchangerelay unix - - n - - smtp
> -o smtp_sasl_mechanism_filter=!gssapi,login
Thanks again everyone!
Michael
DTNX Postmaster
Oct 16, 2013, 5:06:16 AM10/16/13
to
On Oct 16, 2013, at 10:29, Michael Büker <m...@michael-bueker.de> wrote:
> Now, everything works. Phew.
Premature optimization is the root of all evil, after all ;-)
Mvg,
Joni
> Now, everything works. Phew.
>
> I might still combine the sender_dependent_default_transport_maps with my
> sender_dependent_relayhost_maps so I don't have to maintain both files. Come to
> think of it: Couldn't I combine the single line in smtp_tls_policy_maps into
> the transport definition and save one more file?
Document the setup in all relevant files, and be done with it.
> I might still combine the sender_dependent_default_transport_maps with my
> sender_dependent_relayhost_maps so I don't have to maintain both files. Come to
> think of it: Couldn't I combine the single line in smtp_tls_policy_maps into
> the transport definition and save one more file?
Premature optimization is the root of all evil, after all ;-)
Mvg,
Joni
Viktor Dukhovni
Oct 16, 2013, 9:59:51 AM10/16/13
to
On Wed, Oct 16, 2013 at 10:29:21AM +0200, Michael B?ker wrote:
> > Add "exclude=3DES" to the entry table for this server, and you'll likely
> > be fine. You probably don't need to tweak the protocols.
>
> Adding "exclude=3DES" or "exclude=DES-CBC3-SHA" to the smtp_tls_policy_maps
> file didn't quite do it, maybe because I have "smtp_tls_mandatory_ciphers=high"
> set globally. So I used this line, which works for this server:
Yes, of course, the *only* "high" grade cipher supported by Windows
> > Add "exclude=3DES" to the entry table for this server, and you'll likely
> > be fine. You probably don't need to tweak the protocols.
>
> Adding "exclude=3DES" or "exclude=DES-CBC3-SHA" to the smtp_tls_policy_maps
> file didn't quite do it, maybe because I have "smtp_tls_mandatory_ciphers=high"
> set globally. So I used this line, which works for this server:
2003 (sans hot-fixes, ...) is 3DES, but it is unusable (buggy).
The strongest working cipher-suite is RC4-SHA, which is "medium".
> > [smtp-auth.foo.de]:587 encrypt ciphers=medium
You should still exclude 3DES, I found that even with RC4-SHA
offered by the client, depending on the exact mix of client protocol
versions, sometimes the server picks 3DES and breaks.
So for this server (de-obfuscated) I'd specify:
[smtp-auth.foo.de]:587 encrypt ciphers=medium exclude=3DES
or with suitable content in "smtp_tls_CAfile" and/or "smtp_tls_CApath"
[smtp-auth.foo.de]:587 secure ciphers=medium exclude=3DES
since one really ought to verify the SSL certificate of a submission
service.
> > exchangerelay unix - - n - - smtp
To support Exchange MSAs on Windows 2003 generically (less critical
state in per-relay policy entries):
exchangerelay unix - - n - - smtp
-o smtp_tls_security_level=secure
-o smtp_tls_mandatory_ciphers=medium
-o smtp_tls_mandatory_exclude_ciphers=3DES
There's no need to explicitly exclude "gssapi" when you've only
included "login". The "!gssapi" syntax is only useful with:
!gssapi, static:all
> > I'd like to suggest that you find a less broken email provider.
>
> Nah, I like my employer. And I know for a fact that they keep their particle
> accelerators in much better shape than their mail servers.
captive users of a museum-grade legacy infrastructure. :-) In that
case, since it is Oktober, perhaps over a Bier or two suggest that
they consider upgrading their MSAs to something less ancient when
they get a chance.
Postfix is easy to integrate with Active-Directory LDAP for user
validation, and you can enable PLAIN or LOGIN via saslauthd with
PAM as a backend, and a kerberos entry in the PAM entry for SMTP.
Together with a keytab on the server with "host/<fqdn>@REALM"
keys issued from AD it just works.
--
Viktor.
0 new messages