On 22 Jan 2018, at 15:31, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> On Jan 22, 2018, at 2:43 AM, DTNX Postmaster <postmas...@dtnx.net> wrote: > >>> A "real" certificate is useful if you have customers connecting to >>> your server as a submission service. While self-signed certs work >>> fine for that purpose too, sometimes it's easier to avoid talking >>> folks into how to import your self-signed cert. >> >> Sadly, there are folks who think that a certificate they cannot verify >> all the way up to a trusted root means that they should fall back to >> plain text. Mailgun is an example of this, and they are quite widely >> used despite this and several other problems. > > My view is that if mailgun chooses to shoot itself in the foot and > considers sending in the clear more secure than unauthenticated TLS > then so be it, their problem, not mine... > > Have you seen any traffic via mailgun that warrants protection from > passive monitoring? > > It would be great to compile a list of systems that are broken in > this manner, and shame them all (politely) in a suitable public > forum. > > Some senders still don't support TLS at all, even with a CA/B forum > CA (WebPKI) certificate on the receiving end. The problem is that Mailgun is used to send transactional email, which might contain sensitive data in ways that is not immediately obvious to the user. Slack used to use them, for example, including for notifications from private channels which might contain things people consider protected. We talked to Slack at the time, explained what the problem was, difference between HTTPS and opportunistic TLS, got all the way up to the CTO, and he still got snookered by whatever Mailgun fielded as a counterargument, refused to adjust policy expect as a per-domain exception, which isn't very useful unless you're spotting it in the logs and open a ticket for it. Which meant that using a public CA for the MTA certificate was the cheaper option, versus having to pick fights. There's simply too many startups out there that submit their transactional messages over some HTTPS API, never looking at what their deliverability looks like, or think they can 'optimise' SMTP, so if spending a little removes the problem entirely, well ... sorted. Add to that the various pitfalls involved in managing a private CA, which we do for other purposes, and the ROI just never happens. Mvg, Joni
