One thing you might check is the cipher set you're using. I can connect to https://tpg.com.au with TLS1.2 just fine.
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256 bit keys, TLS1.2 Output of following can usually highlight problems: openssl s_client -connect mx1.tpgi.com.au:465 or curl -v smtps://mx1.tpgi.com.au:465 Kind regards On 24 July 2018 at 14:45, Bradley Silverman <bsilver...@staff.ventraip.com> wrote: > I think I am still doing a poor job of explaining the scenario clearly, > which is making everyone go off track with this. > > We can receive emails from MTAs and the like, without any authentication, > without TLS. That is perfectly fine and PCI compliant. > IF authentication is required (like users sending email with us as *their* > outgoing > server), then TLSv1.1 or higher is required. That's because confidential > credentials are being sent, the username and password specifically. > > It isn't possible to set TLSv1.0 for un-authenticated email, and TLSv1.1 > for authenticated, though that would fix the problem. > If TPG were using TLS1.1 OR sending without TLS at all, everything would > be perfectly fine. > > While I agree that TPG aren't doing the 'wrong' thing, they are using a > protocol that is almost 20 years old and generally considered not secure. > > We got some great details to get in touch with them (thanks for that) and > we are working towards a solution. Thanks to everyone for responding and > have a great day! > > Regards, > > Bradley Silverman | VentraIP Australia > *Technical Operations* > > mobile. +61 418 641 103 > phone. +61 3 9013 8464 > > On Tue, Jul 24, 2018 at 1:59 PM, Scott Howard <sc...@doc.net.au> wrote: > >> My take would be that for a general service provider, like TPG, you >> should be as accepting as possible. That would including accepting clear >> text and TLS 1.0 (although possibly not SSLv3). Any specific sender or >> recipient can enforce stronger limitations if they choose to do so. >> >> For a provider that has any focus on security it's potentially a >> different story. In that case enforcing TLS1.2 potentially makes sense, >> although it the raises the question around what you do with servers that >> don't support TLS at all, or like TPG at the moment, don't support TLS >> higher than 1.0 (is cleartext better than TLS1.0?) >> >> Then there's the elephant in the room when it comes to SMTP around >> certificate verification, and if/how you determine your talking to the >> correct mail server (at which point you have to move the conversation over >> to things like DNSSEC) >> >> Scott >> >> >> >> On Tue, Jul 24, 2018, 09:48 Paul Wilkins <paulwilkins...@gmail.com> >> wrote: >> >>> Should TLS 1.0 be acceptable? >>> >>> I don't claim to be a crypto geek. >>> >>> Curiously the ISM standards make TLS 1.2 only advisory: >>> >>> >>> - Control: 1447; Revision: 0; Updated: Apr-15; Applicability: UD, P, >>> C, S, TS; Compliance: must; Authority: AA >>> - Agencies *must use TLS*. >>> - >>> - Control: 1139; Revision: 3; Updated: Apr-15; Applicability: UD, >>> P, C, S, TS; Compliance: should; Authority: AA >>> - Agencies *should use the latest version of TLS* >>> >>> Kind regards >>> >>> Paul Wilkins >>> >>> On 24 July 2018 at 11:10, Scott Howard <sc...@doc.net.au> wrote: >>> >>>> On Mon, Jul 23, 2018 at 6:00 PM, Noel Butler <noel.but...@ausics.net> >>>> wrote: >>>>> >>>>> You are the one choosing to use cpanel/plesk, lazy webhost solutions >>>>> that puts all your customers eggs in the one single basket (though I heard >>>>> plesk may soon be changing that), sorry, but that is not TPG's fault your >>>>> chosen hosting software lives in the 90s. >>>>> >>>> >>>> Perhaps not, but it IS TPG's fault that their mail server is only >>>> supporting encryption algorithms that live in the 90's... >>>> >>>> Irrespective of the PCI argument or not, TPG supporting TLS 1.0 but not >>>> higher in 2018 simply shouldn't be seen as acceptable. >>>> >>>> Scott >>>> >>>> >>>> _______________________________________________ >>>> AusNOG mailing list >>>> AusNOG@lists.ausnog.net >>>> http://lists.ausnog.net/mailman/listinfo/ausnog >>>> >>>> >>> _______________________________________________ >>> AusNOG mailing list >>> AusNOG@lists.ausnog.net >>> http://lists.ausnog.net/mailman/listinfo/ausnog >>> >> >> _______________________________________________ >> AusNOG mailing list >> AusNOG@lists.ausnog.net >> http://lists.ausnog.net/mailman/listinfo/ausnog >> >> >
_______________________________________________ AusNOG mailing list AusNOG@lists.ausnog.net http://lists.ausnog.net/mailman/listinfo/ausnog