On Sep 11, 2013, at 21:52, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> On Wed, Sep 11, 2013 at 09:39:57PM +0200, DTNX Postmaster wrote: > >>> This is more reasonable, provided systems you send mail to all >>> support TLSv1 and up. What fraction of outbound handshakes end up >>> with SSLv3? >> >> Outbound is an even smaller percentage of total TLS connections >> established in August; 0,0002%. Interestingly, they are both banks; >> one Dutch, and one Swiss. Both using SSLv3 with AES256-SHA, wouldn't >> be surprised if that means they are using the same brand of security >> product. > > For many large organizations inbound and outbound email are handled > by completely separate infrastructure. Inbound mail is often first > received by various anti-spam appliances. Outbound mail often > bypasses these, and for bulk transactional mail, may be handled by > other appliances that handle deliverability tracking, ... Ahh, yes. It's the same IP address, but that could just as well be the firewall itself that fronts multiple devices. >> The odd thing is that both banks drop to RC4-MD5 when sending to >> us. I've seen this on another product that we support ourselves as >> well; the Postfix client negotiates a higher protocol level and >> better cipher for outgoing mail than the server does for incoming >> mail. There is probably a good reason for this, but it feels to me >> like they should support the same protocol and cipher level regardless >> of direction? > > I am not surprised. In our own case though this is with current software, a direct connection without firewall tomfoolery and whatnot. I shall see if their support department can explain it to me and satisfy my curiosity as to what causes the difference. >> Re-enabled SSLv3 for incoming connections again, by the way; >> turns out that about half of those incoming connections are from >> an outsourcing firm that handles payment notifications for, yes, >> another Dutch bank. Sigh ;-) > > As I mentioned, at this time, deprecating SSLv3 is most likely > counter-productive. I am hoping that in a couple of years it will > be a practical default for the SMTP client only, where you can > define exceptions for problem destinations via smtp_tls_policy_maps. > > A polite note to their postmaster linking to this thread may > encourage them to start making plans to upgrade to inbound systems > that can support TLSv1 and up (strictly speaking the STARTTLS EHLO > response in SMTP promises support of TLS an IETF standard, not SSLv3). Noted. In our experience however the postmaster account rarely works, and if it does you run into a mess of red tape where even the most simple change requires multiple signatures, several hours of consulting billed and whatnot. Mvg, Joni
