On Sun, 17 May 2020 at 12:04, Adam D. Barratt via mailop <mailop@mailop.org> wrote:
> On Sun, 2020-05-17 at 12:30 +0200, ml+mailop--- via mailop wrote: > > On Sun, May 17, 2020, Alessio Cecchi via mailop wrote: > > > > > the domain name is stefanoboschi.it and after the transfer from one > > > > dig stefanoboschi.it. mx > > stefanoboschi.it. 3500 IN MX 10 mx01.cbsolt.net. > > stefanoboschi.it. 3500 IN MX 20 mx02.cbsolt.net. > > > > connecting to mx01.cbsolt.net > > ... > > RCPT TO:<postmas...@stefanoboschi.it.> > > 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) > > > > Looks like the MX record is wrong or the server is misconfigured. > > It works fine without the trailing dot, which is what I'd expect: > > adam@kotick:~$ telnet mx01.cbsolt.net 25 > Trying 185.97.217.85... > Connected to mx01.cbsolt.net. > Escape character is '^]'. > ma220 mail02.cbsolt.net ESMTP > mail from:<> > 250 ok > rcpt to:<postmas...@stefanoboschi.it> > 250 ok > rcpt to:<postmas...@stefanoboschi.it.> > 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) > > Hi Alessio, I agree with Ken's comments about confirming DNS is OK. I did my own checks from a couple of servers and my home connection, and they seem to reliably report the correct MXes, but WeTransfer and Facebook *might* be caching stale records. Try making a trivial update (a dummy TXT record) to increment the SOA's serial, then check the response through public resolvers after it's propagated. If that all looks OK, I'd suspect your MTA. Is it just the one customer affected, or all served by that MX? I've seen this kind of problem with selective refusal of mail when cipher suites have been incompatible or supported TLS versions are too strict. To make sure you're not just erroneously blocking subnets, here's a sample from earlier of hosts delivering for Facebook and WeTransfer from my logs o3.email.wetransfer.com[192.254.123.42]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) o6.email.wetransfer.com[167.89.35.32]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) o5.email.wetransfer.com[167.89.35.243]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) 69-171-232-142.mail-mail.facebook.com[69.171.232.142]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) 69-171-232-140.mail-mail.facebook.com[69.171.232.140]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) 66-220-144-144.mail-mail.facebook.com[66.220.144.144]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits) Enable verbose logging to check for cipher negotiation problems and handshake failure during receipt. Testing to mx01/02.cbsolt.net, testssl.sh was only able to negotiate AES128-GCM-SHA256 to your server, you should be aiming for something like DHE-RSA-AES256-SHA256 via TLSv1.2. Your MXes appear to accept >=SSLv3, so I suspect cipher mismatch. - testssl.sh (https://testssl.sh) indicates your MXes offer almost no ciphers supporting Forward Secrecy, and are nearly all SHA1 (and so is possibly vulnerable to the ROBOT attack). - Your server offers RC4 ciphers, not good. The only other offered ciphers are all TLS_RSA_* SHA-1, except a couple of stronger ciphers (but still not great) via TLSv1.2. - With TLS_RSA ciphers, your servers cannot negotiate Forward Secrecy and that may be preventing delivery. - The _SHA ciphers are all SHA-1, no certs have been issued as SHA-1 for years. It's inadvisable to offer them without some more modern DHE/ECDHE, RSA/ECDSA ciphers. + You absolutely do not need to offer RC4 any more, but you do absolutely need to offer DHE and ECDHE. - After last year's CBC padding oracles exploits, consider all CBC ciphers potentially vulnerable ( https://www.tripwire.com/state-of-security/vert/tls-cbc-padding-oracles/). - I still offer CBC ciphers as I still see incoming connections trying to negotiate a CBC cipher. I suggest you update your cipher suites. Always offer a handful of fallback ciphers (despite known issues with CBC), but primarily offer DHE and ECDHE ciphers. Elliptical Curve Diffie Hellman Ephemeral encryption (ECDHE) is more efficient than DHE, but both will offer Forward Secrecy. Anything is better than TLS_RSA. Note that Facebook and WeTransfer both negotiate an ECDHE cipher. I only offer TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_CAMELLIA_128_CBC_SHA as fallbacks for badly configured senders; the rest of my ciphers are mostly ECDHE and DHE, SHA256 or SHA384. For incoming encrypted negotiation to my servers I unfortunately still need to permit SSLv3 and up. Some senders still insist on using SSLv3 or TLSv1 and nothing more recent. Realistically, so many senders are still using obsolete settings we cannot restrict to only TLSv1.2 or 1.3 and ECDHE. Even some of the big senders are using poor TLS configurations, but likewise some have already dropped support for old ciphers. Hopefully updating your settings will fix delivery problems. The cipher suite below will enable 2048 bit key pair DHE, 128/256 bit encryption, and drop support for the weakest, obsolete ciphers. I believe you're running qmail? I don't use qmail, but if it's of any use, here's an excerpts from my 'standard deploy' Postfix config (apologies to all Exim users), most options should be self-explanatory: ################################################## # smtpd = incoming to this server # smtp = outgoing from this server smtpd_tls_mandatory_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, DES, ADH, RC2, RC4, RC5, PSD, SRP, 3DES, eNULL, aNULL smtp_tls_mandatory_exclude_ciphers = MD5, aDSS, kECDH, kDH, SEED, IDEA, DES, ADH, RC2, RC4, RC5, PSD, SRP, 3DES, eNULL, aNULL smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA smtp_tls_exclude_ciphers = ${smtpd_tls_exclude_ciphers} tls_high_cipherlist = EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA) broken_sasl_auth_clients = yes smtpd_tls_received_header = yes tls_random_source = dev:/dev/urandom smtp_tls_ciphers = high smtpd_tls_ciphers = high smtp_tls_mandatory_ciphers = high smtpd_tls_mandatory_ciphers = high smtpd_tls_auth_only = yes smtp_use_tls = yes smtpd_use_tls = yes smtp_tls_security_level = may smtpd_tls_security_level = may smtp_tls_loglevel = 2 smtpd_tls_loglevel = 2 smtp_tls_protocols = !TLSv1, !SSLv2, !SSLv3 smtpd_tls_protocols = !TLSv1, !SSLv2, ## relax these to permit SSLv3 and above ## pre-Postfix 2.6 # smtp_tls_mandatory_protocols = !TLSv1, !SSLv2, !SSLv3 # smtpd_tls_mandatory_protocols = !TLSv1, !SSLv2, !SSLv3 # stricter, only >=TLSv1.2 inbound: # smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 ################################################## During handshake, Postfix logs the presented cipher suite as "EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA256:EECDH:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA128-SHA:AES128-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES:!CBC3-SHA" I can explain the reasons behind these choices if anyone wants, however Postfix documentation is quite useful for these settings. Also, ServerFault/StackExchange has discussion around most of these options. I spent a while refining these to suit my requirements but, as always, any suggestions for improving the cipher suites or altering the configuration is welcome. Other things I noticed: - ab...@stefanoboschi.it is not a valid recipient (RFC 2142) - no SPF - no DMARC - no DANE, no DNSSEC (https://ns.tools/stefanoboschi.it) Interested to hear how you get on Alessio, please let us know how you get on. Cheers Chris A few other useful test tools and references from my bookmarks + https://bettercrypto.org/#_tls_usage_in_mail_server_protocols + https://tribut.de/blog/secure-your-services-using-sane-cipher-ordering + https://serverfault.com/questions/670348/how-to-force-a-own-set-of-ciphers-in-postfix-2-11 + https://serverfault.com/questions/829874/disabling-a-cipher-cipher-suite-in-postfix-tls-for-specific-recipient + https://tools.ietf.org/id/draft-sheffer-uta-bcp195bis-00.html + https://testssl.sh (https://kruyt.org/postfix-and-tls-encryption/) - what I used to test your MXes + https://www.checktls.com/TestReceiver + https://tls.imirhil.fr/smtp/stefanoboschi.it + https://ssl-tools.net/mailservers/stefanoboschi.it + https://gf.dev/ + https://dnssec-analyzer.verisignlabs.com/ + https://dane-test.had.dnsops.gov/ and https://email-test.had.dnsops.gov/ + https://www.cyphercraft.io/tls (only useful for web sites, doesn't support SMTP/STARTTLS) + https://www.sslshopper.com/ssl-checker.html (only useful for web, again no :25 support) + https://discussions.qualys.com/thread/17971-tlsrsawithaes256cbcsha-comes-to-be-weak-cipher + https://blog.cloudflare.com/staying-on-top-of-tls-attacks/ + https://developers.cloudflare.com/ssl/ssl-tls/cipher-suites/ "openssl s_client -connect host:25 -starttls smtp" and "openssl s_client -connect host:25 -starttls smtp -showcerts | openssl x509 -text" are often useful
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
