Issues delivering mail from GMX to my postfix
Hi,
I've got a report from a user that tries to send an mail from GMX to my private mail account.
The mail-account is secured by DANE/TLSA and running on Postfix. "dane.sys4.de" does not report any issues, but GMX refuses to deliver mail with this message:
----------------------------schnipp---------------------------- This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:
cas@strotmann.de: remote MX does not support STARTTLS ----------------------------schnipp----------------------------
Has anyone seen a similar issue? Any ideas how to troubleshoot?
Best regards
Carsten
Looks like two different issues.
The certificate name on smtp3.strotmann.de doesn't match, it is mail.tidelock.de instead.
When using smtp2.strotmann.de, the TLS/DANE part works fine, but after this, and you attempt to send an email, it fails. posttls-finger: Verified TLS connection established to smtp2.strotmann.de[5.45.109.212]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) posttls-finger: > EHLO mx3.grsi.com posttls-finger: < 500 5.5.1 Command unrecognized posttls-finger: EHLO rejected: 500 5.5.1 Command unrecognized posttls-finger: > QUIT
I am not sure what is talking here, but it's not postfix and it's not allowing the ehlo to be processed.
Quoting "Carsten Strotmann (sys4)" cs@sys4.de:
Hi,
I've got a report from a user that tries to send an mail from GMX to my private mail account.
The mail-account is secured by DANE/TLSA and running on Postfix. "dane.sys4.de" does not report any issues, but GMX refuses to deliver mail with this message:
----------------------------schnipp---------------------------- This message was created automatically by mail delivery software.
A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:
cas@strotmann.de: remote MX does not support STARTTLS ----------------------------schnipp----------------------------
Has anyone seen a similar issue? Any ideas how to troubleshoot?
Best regards
Carsten
Hello Patrick,
Patrick Domack wrote:
Looks like two different issues.
The certificate name on smtp3.strotmann.de doesn't match, it is mail.tidelock.de instead.
Yes, true, but that should not be an issue when using DANE-EE(3)
From https://tools.ietf.org/html/rfc7671#section-5.1
In particular, the binding of the server public key to its name is based entirely on the TLSA record association. The server MUST be considered authenticated even if none of the names in the certificate match the client's reference identity for the server.
When using smtp2.strotmann.de, the TLS/DANE part works fine, but after this, and you attempt to send an email, it fails. posttls-finger: Verified TLS connection established to smtp2.strotmann.de[5.45.109.212]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) posttls-finger: > EHLO mx3.grsi.com posttls-finger: < 500 5.5.1 Command unrecognized posttls-finger: EHLO rejected: 500 5.5.1 Command unrecognized posttls-finger: > QUIT
I am not sure what is talking here, but it's not postfix and it's not allowing the ehlo to be processed.
This is OpenBSDs "spamd" intercepting. I need to check why it is intercepting here, and not transparent piping towards the Postfix.
Thanks for the pointers, I will check that.
-- Carsten
On Thu, May 19, 2016 at 05:02:59PM +0200, Carsten Strotmann (sys4) wrote:
posttls-finger: Verified TLS connection established to smtp2.strotmann.de[5.45.109.212]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) posttls-finger: > EHLO mx3.grsi.com posttls-finger: < 500 5.5.1 Command unrecognized posttls-finger: EHLO rejected: 500 5.5.1 Command unrecognized posttls-finger: > QUIT
I am not sure what is talking here, but it's not postfix and it's not allowing the ehlo to be processed.
This is OpenBSDs "spamd" intercepting. I need to check why it is intercepting here, and not transparent piping towards the Postfix.
Thanks for the pointers, I will check that.
I was going to guess that spamd or similar is the most likely culprit, even before you said you're running it.
https://dane.sys4.de/common_mistakes#8
It might be enabling TLS only for cached "known good" clients, but that is not compatible with DANE.
Hello Viktor,
On 05/19/16 18:04, Viktor Dukhovni wrote:
On Thu, May 19, 2016 at 05:02:59PM +0200, Carsten Strotmann (sys4) wrote:
posttls-finger: Verified TLS connection established to smtp2.strotmann.de[5.45.109.212]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) posttls-finger: > EHLO mx3.grsi.com posttls-finger: < 500 5.5.1 Command unrecognized posttls-finger: EHLO rejected: 500 5.5.1 Command unrecognized posttls-finger: > QUIT
I am not sure what is talking here, but it's not postfix and it's not allowing the ehlo to be processed.
This is OpenBSDs "spamd" intercepting. I need to check why it is intercepting here, and not transparent piping towards the Postfix.
Thanks for the pointers, I will check that.
I was going to guess that spamd or similar is the most likely culprit, even before you said you're running it.
https://dane.sys4.de/common_mistakes#8It might be enabling TLS only for cached "known good" clients, but that is not compatible with DANE.
this seems to be the issue, Although "spamd" in its latest version does support TLS, *my* installation has stopped to offer STARTTLS. I need to check why that is.
It also might be this issue: https://groups.google.com/forum/#!topic/mailing.openbsd.bugs/dK22QW-fWCk
I will try the patch and check again.
My 2nd MX (smtp3.strotmann.de) is a plain postfix on Debian doing STARTTLS and having DANE TLSA. If the first MX does not offer STARTTLS, shouldn't a sender try the 2nd MX (TLSA authenticated) mail-destination in case the first fails because of missing STARTTLS?
If scanned RFC 7672, but couldn't find this case mentioned.
On Thu, May 19, 2016, Carsten Strotmann (sys4) wrote:
this seems to be the issue, Although "spamd" in its latest version does support TLS, *my* installation has stopped to offer STARTTLS. I need to
Really?
read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 32 2 read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 32 2 read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 30 0 read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0001 - <SPACES/NULS> read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 6d m read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 61 a read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 69 i read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 6c l read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 2e . read from 0x1003ee420 [0x1003f1270] (4096 bytes => 1 (0x1)) 0000 - 73 s read from 0x1003ee420 [0x1003f1270] (4096 bytes => 73 (0x49)) 0000 - 74 72 6f 74 6d 61 6e 6e-2e 64 65 20 45 53 4d 54 trotmann.de ESMT 0010 - 50 20 73 70 61 6d 64 20-49 50 2d 62 61 73 65 64 P spamd IP-based 0020 - 20 53 50 41 4d 20 62 6c-6f 63 6b 65 72 3b 20 54 SPAM blocker; T 0030 - 68 75 20 4d 61 79 20 31-39 20 31 39 3a 33 38 3a hu May 19 19:38: 0040 - 33 36 20 32 30 31 36 0d-0a 36 2016.. write to 0x1003ee420 [0x1003f2280] (25 bytes => 25 (0x19)) 0000 - 45 48 4c 4f 20 6f 70 65-6e 73 73 6c 2e 63 6c 69 EHLO openssl.cli 0010 - 65 6e 74 2e 6e 65 74 0d-0a ent.net.. read from 0x1003ee420 [0x1003f1270] (4096 bytes => 14 (0xE)) 0000 - 32 35 30 20 53 54 41 52-54 54 4c 53 0d 0a 250 STARTTLS.. write to 0x1003ee420 [-0x80005eb0] (10 bytes => 10 (0xA)) 0000 - 53 54 41 52 54 54 4c 53-0d 0a STARTTLS.. read from 0x1003ee420 [0x1003e3730] (8192 bytes => 56 (0x38)) 0000 - 32 32 30 20 67 6c 61 64-20 79 6f 75 20 77 61 6e 220 glad you wan 0010 - 74 20 74 6f 20 62 75 72-6e 20 6d 6f 72 65 20 43 t to burn more C 0020 - 50 55 20 63 79 63 6c 65-73 20 6f 6e 20 79 6f 75 PU cycles on you 0030 - 72 20 73 70 61 6d 0d 0a- r spam.. SSL_connect:before/connect initialization ... Server certificate subject=/CN=mail.strotmann.de issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X1 --- No client certificate CA names sent --- SSL handshake has read 3576 bytes and written 538 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2560 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 4DE94964346F99C2798593C6A16A37CC03CFBFEB1B12218A7D647D9CC5521666 Session-ID-ctx: Master-Key: 89C06D81DEA6438E523840D8854C07D4AD7D8CB5DADAE878F218E0E085BB3D483886E79D7CB336A4EEB78411C4E4CEAB Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 97 2f 4b 2b 96 1f 0c 6f-f9 7b fb b0 79 2c af 3e ./K+...o.{..y,.> 0010 - 61 9a 27 21 e7 0f 8f 33-8c 0b ab 37 09 34 ed c1 a.'!...3...7.4.. 0020 - e3 c2 f8 a7 bf 4c 41 e3-d4 2a f7 37 6f e7 28 fd .....LA..*.7o.(. 0030 - 50 b0 ab 69 a4 67 78 89-38 27 32 55 62 13 b9 5d P..i.gx.8'2Ub..] 0040 - 14 2e 4d ee 83 57 57 2c-45 23 91 b8 e4 a9 7e 89 ..M..WW,E#....~. 0050 - 8f bd 43 7d 67 9b e7 7a-96 bc d4 ae 21 0e 29 34 ..C}g..z....!.)4 0060 - 3f 42 92 76 25 00 9e 98-56 6d 90 16 70 50 d6 d9 ?B.v%...Vm..pP.. 0070 - ea 81 30 b4 e4 62 1e d0-eb 01 fb 1d b2 ed d0 48 ..0..b.........H 0080 - f1 d7 83 32 2d 16 3e c0-06 6f ed f5 21 e6 e4 ed ...2-.>..o..!... 0090 - 3d e8 29 ae 69 9e 4b 5f-31 1b 65 0d 89 69 e9 b5 =.).i.K_1.e..i.. 00a0 - 6d 8e ce ba 14 35 64 7b-4b cb b4 d3 4e f5 fb d8 m....5d{K...N... 00b0 - 26 e9 9c 7f f2 d3 dd d4-5c 2c 71 bb f3 36 46 3d &.......,q..6F=
Start Time: 1463679529 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- 250 STARTTLS EHLO o write to 0x1003ee420 [0x1003fad43] (37 bytes => 37 (0x25)) 0000 - 17 03 03 00 20 38 8b 1c-03 e7 00 4b 6e e0 f4 14 .... 8.....Kn... 0010 - 0b 62 7f 8e 04 c5 d0 f6-5e 53 92 25 9e 3d 5b 0c .b......^S.%.=[. 0020 - 44 6f 70 ad fe Dop.. read from 0x1003ee420 [0x1003f67e3] (5 bytes => 5 (0x5)) 0000 - 17 03 03 00 38 ....8 read from 0x1003ee420 [0x1003f67e8] (56 bytes => 56 (0x38)) 0000 - 00 00 00 00 00 00 00 01-23 3e ab e4 d8 d5 fb 4c ........#>.....L 0010 - 62 72 85 da 80 aa f2 c1-6c 02 ae 3f 08 de 1a 66 br......l..?...f 0020 - 71 d2 72 b7 e8 88 4d af-56 22 82 4d 07 95 71 88 q.r...M.V".M..q. 0030 - 47 af 04 df 0f ec 28 60- G.....(` 500 5.5.1 Command unrecognized quit
Seems STARTTLS is offered and "kind of" working... but then EHLO fails.
Maybe you should just use a real MTA... (or figure out why spamd behaves this way and fix it?)
On Thu, May 19, 2016 at 07:26:46PM +0200, Carsten Strotmann (sys4) wrote:
My 2nd MX (smtp3.strotmann.de) is a plain postfix on Debian doing STARTTLS and having DANE TLSA. If the first MX does not offer STARTTLS, shouldn't a sender try the 2nd MX (TLSA authenticated) mail-destination in case the first fails because of missing STARTTLS?
It definitely should. DANE clients should not impose a single point of failure at the primary MX host.
However, your primary MX host has both an IPv4 and an IPv6 address, and if GMX is using Postfix as their outbound, perhaps they've set
http://www.postfix.org/postconf.5.html#smtp_mx_address_limit
to 2? This would preclude ever connecting to your backup MX. Failure to complete TLS handshakes does not count against the
http://www.postfix.org/postconf.5.html#smtp_mx_session_limit
However, the above is a rather improbable wild guess, no idea why they don't try the backup.
I scanned RFC 7672, but couldn't find this case mentioned.
Section 2.2:
A "secure" TLSA RRset with at least one usable record: Any connection to the MTA MUST employ TLS encryption and MUST authenticate the SMTP server using the techniques discussed in the rest of this document. Failure to establish an authenticated TLS connection MUST result in falling back to the next SMTP server or delayed delivery.
I think you know some the GMX staff in person. In which case, reach out to them, they may be able to look into what the problem looks like on their end. If you don't, drop me a note, and I'll forward the contact info I have. They should be interested in ironing out any implementation limitations on their end.
Hello Viktor, Hello List-Participants,
On Thu, 19 May 2016 16:04:19 +0000 Viktor Dukhovni ietf-dane@dukhovni.org wrote:
I was going to guess that spamd or similar is the most likely culprit, even before you said you're running it.
https://dane.sys4.de/common_mistakes#8It might be enabling TLS only for cached "known good" clients, but that is not compatible with DANE.
I've found the issue, it was a configuration error on my behalf on the IPv4 side of "smtp2.strotmann.de" that causes STARTTLS to be denied (for all clients).
The IPv6 side of the configuration was always working and most mail-sender preferred IPv6, that is the reason why the configuration issue was not seen immediatly. Lesson learned: monitoring needs to cover IPv4 and IPv6 separatly.
The GMX people have contacted me and were very helpful in debugging this issue.
This now seems to be fixed, mail from GMX is coming in again.
Have a good week!
Carsten
participants (5)
-
Carsten Strotmann -
Carsten Strotmann (sys4)
-
ml+dane-users＠esmtp.org -
Patrick Domack -
Viktor Dukhovni