Issues delivering mail from GMX to my postfix

[Carsten Strotmann (sys4)]

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#8
> 
> It 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.sys4.de/mailman/private/dane-users/attachments/20160519/3511d070/attachment-0001.asc>