[mailop] Not-in-dane/mta-sts mx for tls fallback
Hello mailops, At StartMail we've recently changed our incoming MXes to only allow TLSv1.2 and 1.3 on incoming connections - but because there are still some legitimate sources of mail that only support TLSv1 or 1.1 we've set up a fallback mx that also supports TLSv1 and TLSv1.1. The idea here is that an outdated (or misconfigured) server tries to connect to our regular MXes, fails to negotiate in the starttls phase and then retries with a lower priority server which does allow a successful starttls negotiation. This fallback MX however is not listed in our MTA-STS thing nor does it have DANE records, so sending parties that care about that should not connect to it and are not exposed to the dangers of downgrade attacks. Parties that don't care about DANE/MTA-STS but do support modern TLS may be tricked into connecting to the backup mx and be at risk of a downgrade attack, but if you ask me, that is a small price to pay for allowing people with outdated stacks to use any form of TLS instead of having to fall back to plaintext. However, both the Internet.nl checker (see https://www.internet.nl/mail/startmail.com/871658 for the latest report), hardenize, and the monitoring by SSLMate claim that this is not a great setup. Staring at the rfcs I can't find any reason why though. Did we miss something or should I start chasing down folks to improve their tools? Best regards, Jasper Spaans ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Should mailing list messages be DKIM signed? (ARC / DKIM)
Alessandro Vesely via mailop skrev den 2023-02-20 08:47: The point of ARC is to report authentication results. A post having only spf=pass becomes unauthenticated after the first hop. inccorect, nexthop can use spf aswell, or not Right. Ditto for DMARC rejects/ quarantine, which I don't think many ML receivers honor. DMARC is greedy, if DKIM is breaked, to avoid DKIM problems if needed to post to ml could be to configure dkim to be in test mode, ensureing mails are not rejected based just on dkim fails, mailman can do this policy to not accept non testing mode in dkim, its design fails that dkim should be used as a reject factor :( back to DMARC, it should imho use ARC results to know if original sender did have dkim pass and spf pass, and make results based on it, then its no matter if mailman breaks dkim or not, since it would not matter for dmarc testing downstream, we can all raise the flag when developpers of mailman know this :=) i use dmarc policy none to protect maillist receivers to not reject maillists senders, more or less this is what bad software try to solve, hmmp ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
