[180558] in North American Network Operators' Group
RE: Verizon FiOS outbound mail TLS problem - Superpages people here?
daemon@ATHENA.MIT.EDU (Ray)
Sat Jun 6 19:13:44 2015
X-Original-To: nanog@nanog.org
From: Ray <sixsigma44@hotmail.com>
To: Blake Hudson <blake@ispn.net>, "nanog@nanog.org" <nanog@nanog.org>
Date: Sat, 6 Jun 2015 19:13:38 -0400
In-Reply-To: <557080EB.30001@ispn.net>
Errors-To: nanog-bounces@nanog.org
We had a similar issue around November last year where an upgrade on our=0A=
PostFix MTA to a current version of OpenSSL=2C which has Mandatory TLS =0A=
enabled for certain recipient domains=2C suddenly started generating the =
=0A=
same errors with just one recipient domain.
We eventually figured=0A=
out that the problem was they were running an outdated version of the =0A=
AsyncOS on their Cisco IronPorts. Firmware versions prior to 8.02 had =0A=
several problems with TLS and one of them was an inability to =0A=
interoperate with senders who used a newer version of OpenSSL. Their =0A=
IronPort logs in fact showed a TLS connection was established when it =0A=
wasn't. (We had switched them to Opportunistic TLS to be able to send =0A=
emails but their logs still showed TLS while a PCAP showed clear text =0A=
SMTP.)
As soon as that company updated their IronPorts to a v8.5 =0A=
variant the problem went away. They would not tell us what version they =0A=
used to run but did confirm it was prior to v8.02.
Interestingly=2C www.checktls.com=0A=
said they were OK. The admins at Check TLS confirmed that=2C at that time=
=0A=
(the end of 2014)=2C they were running a version of OpenSSL on their =0A=
website that was still compatible with the older AsyncOS version.=20
FWIW=2C
Ray
> Date: Thu=2C 4 Jun 2015 11:46:35 -0500
> From: blake@ispn.net
> To: nanog@nanog.org
> Subject: Re: Verizon FiOS outbound mail TLS problem - Superpages people h=
ere?
>=20
> I have no relation=2C but as a mail server operator I can say that I=20
> wouldn't be surprised if this is actually a TLS version mismatch or=20
> intolerance problem. I would suggest ensuring that both ends support TLS=
=20
> 1.0=2C 1.1=2C and 1.2 and use version tolerant TLS implementations. Next =
on=20
> the short list would be not having compatible cyphers between the two=20
> servers.
>=20
> Either way=2C since the error was a 403 error=2C the expected behavior wo=
uld=20
> be to queue and retry in plain text=3B Sounds like a broken MTA=20
> implementation or misconfiguration if the sending servers do not revert=20
> to plain text.
>=20
> --Blake
>=20
> Jay Ashworth wrote on 6/4/2015 11:15 AM:
> > Anyone on the list who does outbound delivery for Verizon (which I thin=
k
> > is actually Superpages)? A client has smart-hosted outbounds to *one*
> > of his customers bouncing suddenly with
> >
> > Deferred: 403 4.7.0 TLS handshake failed.
> >
> > *My* inclination is to think that a cert expired somewhere=2C but his n=
on-tech
> > contact there tells him that the tech people think things are ok.
> >
> > I'm trying to get a mailer log fragment from them.
> >
> > Cheers=2C
> > -- jra
> >
>=20
=
