4 ms·

>I disagree. It is a fair mark against postfix if (as I claim) most users really don't need it. if they don't need it, they won't be affected by that vulnerabi

by pilif 7y ago

>I disagree. It is a fair mark against postfix if (as I claim) most users really don't need it. if they don't need it, they won't be affected by that vulnerability because it won't be active. >Meanwhile on the enterprise, pretty much every machine in every enterprise environment I've ever worked in has been set up for local relay. In every enterprise setup I have seen, local relay was still protected using SMTP-AUTH for accounting purposes. Plus in case of end-users, many ISPs still provide SMTP for mail delivery, all of whom need to support SMTP auth. That includes Fastmail and Gmail. >but I can't believe you gain nothing by starting from a solid foundation. Of course you do. But saying "Postfix is worse because it had a security vulnerability in a component that qmail doesn't even support" is unfair to postfix. If you are running qmail with a custom patch then that custom patch will for sure have been exposed to less scrutiny than Postfix proper. It's not valid to extend the scrutiny given to vanilla qmail to all of the custom patches.

geocar 7y ago
> saying "Postfix is worse because it had a security vulnerability in a component that qmail doesn't even support" is unfair to postfix. Ok, well that's your opinion, and hopefully now you at least know why I have mine. I can't imagine forgiving Microsoft for all those AD/SMB and explorer CVE just because Linux doesn't support those things, but it's not really that important to me. > In every enterprise setup I have seen, local relay was still protected using SMTP-AUTH for accounting purposes. I have no idea what you mean by "accounting purposes" -- it sounds like you're talking about users relaying and not machines relaying. There is no way you'd get a SOC2 (or SSAE/SOC1) if you used SMTP auth to protect local relays, so perhaps we are talking about different things when we say "enterprise". > If you are running qmail with a custom patch then that custom patch will for sure have been exposed to less scrutiny than Postfix proper. I'm still not sure you can have it both ways. Why is it when Debian patches postfix that it's still (in your mind) "postfix proper" but when I download a well-distributed and discussed patch from a mailing list, and read it myself, that you somehow think I'm at higher risk?
- pilif 7y ago
  >it sounds like you're talking about users relaying and not machines relaying there is such a thing as machine- or even application-specific accounts that can be terminated or their credentials rotated. Even better; you could use something like Vault (https://www.vaultproject.io/ https://www.vaultproject.io/) to manage such application-specific credentials. All of this is much better than relying on IP addresses never changing and never being reused. >Why is it when Debian patches postfix that it's still (in your mind) "postfix proper" but when I download a well-distributed and discussed patch from a mailing list, and read it myself, that you somehow think I'm at higher risk? I never said it was postfix proper. It really isn't. Debian is known to f'up the security of its packages. But it's my hope that distributors have a better equipped security team and bigger exposure compared to some guy putting a patch on some website. Debian also has a proper security update process that makes sure that patches go out to users quickly and painlessly. And because Debian is big enough, it's usually included in embargoed security vulnerability reports, so usually a patch will be out and sometimes even deployed by the time the vulnerability is known. But the relative security of Debian-maintained postfix vs. Debian-maintained custom-patched qmail is the same as postfix proper vs custom-patched qmail. However, vanilla whatever, in my opinion is superior to custom-patched whatever. And while postfix is usable vanilla, qmail isn't. It was bordering unusable back in the 90ies and it definitely is unusable nowadays. qmail doesn't support TLS, it doesn't support spf, much less domainkeys or dmarc. It doesn't (as we're talking about) support SMTP auth, it doesn't support ipv6. It doesn't support any other common anti spam measures like greylisting or rbl checks, nor does it support a plugin system that would allow for easy plugging them in. Heck, it doesn't even support rejecting mail at SMTP time so it's one of the worst offenders for backscatter which is one of the big annoyances for mail admins. At this point, an unpatched qmail is as useful in fulfilling MTA roles as a closed port 25 is (which would totally be safer than both qmail and postfix) Hence my assertion that everybody is running a patched qmail and none of these patches ever enjoyed the same scrutiny as even the security abominations that are sendmail and exim. And worse: None of these patches were ever reviewed for side-effects of arbitrarily combining them. Nearly every custom patch was made against a vanilla qmail because there is no central project to manage these patches. So every site runs a different version of qmail, none of them vetted at all for security. This is a mess and we should really discourage this rather than dreaming of long-gone times where vanilla qmail at least was useful to a minor degree. Partially-related update: I just looked at the qmail code: This thing is written in K&R style C and sometimes uses single-character variable and function names. I would argue nobody but djb can actually safely make changes to this code-base. This is all from a bygone age. Let it rest.

by pilif 7y ago

geocar 7y ago

> saying "Postfix is worse because it had a security vulnerability in a component that qmail doesn't even support" is unfair to postfix. Ok, well that's your opinion, and hopefully now you at least know why I have mine. I can't imagine forgiving Microsoft for all those AD/SMB and explorer CVE just because Linux doesn't support those things, but it's not really that important to me. > In every enterprise setup I have seen, local relay was still protected using SMTP-AUTH for accounting purposes. I have no idea what you mean by "accounting purposes" -- it sounds like you're talking about users relaying and not machines relaying. There is no way you'd get a SOC2 (or SSAE/SOC1) if you used SMTP auth to protect local relays, so perhaps we are talking about different things when we say "enterprise". > If you are running qmail with a custom patch then that custom patch will for sure have been exposed to less scrutiny than Postfix proper. I'm still not sure you can have it both ways. Why is it when Debian patches postfix that it's still (in your mind) "postfix proper" but when I download a well-distributed and discussed patch from a mailing list, and read it myself, that you somehow think I'm at higher risk?

pilif 7y ago
>it sounds like you're talking about users relaying and not machines relaying there is such a thing as machine- or even application-specific accounts that can be terminated or their credentials rotated. Even better; you could use something like Vault (https://www.vaultproject.io/ https://www.vaultproject.io/) to manage such application-specific credentials. All of this is much better than relying on IP addresses never changing and never being reused. >Why is it when Debian patches postfix that it's still (in your mind) "postfix proper" but when I download a well-distributed and discussed patch from a mailing list, and read it myself, that you somehow think I'm at higher risk? I never said it was postfix proper. It really isn't. Debian is known to f'up the security of its packages. But it's my hope that distributors have a better equipped security team and bigger exposure compared to some guy putting a patch on some website. Debian also has a proper security update process that makes sure that patches go out to users quickly and painlessly. And because Debian is big enough, it's usually included in embargoed security vulnerability reports, so usually a patch will be out and sometimes even deployed by the time the vulnerability is known. But the relative security of Debian-maintained postfix vs. Debian-maintained custom-patched qmail is the same as postfix proper vs custom-patched qmail. However, vanilla whatever, in my opinion is superior to custom-patched whatever. And while postfix is usable vanilla, qmail isn't. It was bordering unusable back in the 90ies and it definitely is unusable nowadays. qmail doesn't support TLS, it doesn't support spf, much less domainkeys or dmarc. It doesn't (as we're talking about) support SMTP auth, it doesn't support ipv6. It doesn't support any other common anti spam measures like greylisting or rbl checks, nor does it support a plugin system that would allow for easy plugging them in. Heck, it doesn't even support rejecting mail at SMTP time so it's one of the worst offenders for backscatter which is one of the big annoyances for mail admins. At this point, an unpatched qmail is as useful in fulfilling MTA roles as a closed port 25 is (which would totally be safer than both qmail and postfix) Hence my assertion that everybody is running a patched qmail and none of these patches ever enjoyed the same scrutiny as even the security abominations that are sendmail and exim. And worse: None of these patches were ever reviewed for side-effects of arbitrarily combining them. Nearly every custom patch was made against a vanilla qmail because there is no central project to manage these patches. So every site runs a different version of qmail, none of them vetted at all for security. This is a mess and we should really discourage this rather than dreaming of long-gone times where vanilla qmail at least was useful to a minor degree. Partially-related update: I just looked at the qmail code: This thing is written in K&R style C and sometimes uses single-character variable and function names. I would argue nobody but djb can actually safely make changes to this code-base. This is all from a bygone age. Let it rest.