4 ms·

Aside of the fact that I doubt your "most people" assertion here, it's beside the point that I was trying to make which is that a CVE affecting a feature of Pos

by pilif 7y ago

Aside of the fact that I doubt your "most people" assertion here, it's beside the point that I was trying to make which is that a CVE affecting a feature of Postfix that qmail doesn't have to begin with is not a fair mark against postfix. Because if you disable a feature you don't use, you won't be affected by the vulnerability. If you use smtp authentication, you're not running djb's code and all advantages of djb's code are moot. If you don't use smtp authentication then that CVE is inconsequential and you can't count it as a black mark against Postfix with regards to the security of your specific setup.

geocar 7y ago
> it's beside the point that I was trying to make which is that a CVE affecting a feature of Postfix that qmail doesn't have to begin with is not a fair mark against postfix. I disagree. It is a fair mark against postfix if (as I claim) most users really don't need it. Here's my reasoning to that point: I think most email end-users either use their ISPs mail settings (who know who they are and don't need authentication), or webmail (which doesn't use SMTP for relaying anyway), or outlook (which doesn't need SMTP at all). Fastmail is becoming more popular and it doesn't need SMTP either. The end-users who remain are either business users (who could use a VPN which is better than SMTP AUTH in every way), and nutters with vanity domains. If that's contended, and note I do believe there are probably end users who are actually still manually entering SMTP AUTH settings into email clients, but I would struggle to believe they're the majority and would need evidence. Meanwhile on the enterprise, pretty much every machine in every enterprise environment I've ever worked in has been set up for local relay. Again, if you think they're all using SMTP AUTH I'd need to see evidence. > If you use smtp authentication, you're not running djb's code and all advantages of djb's code are moot Do you actually believe that if you apt-get install postfix that you don't have any of the advantages of postfix's development processes? I'm not sure I can engage with that. It's like saying running linux invalidates "all advantages of djb's code" simply because you're (sometimes) not running his code (e.g. when you're in a syscall). Madness runs down that way. For what it's worth, most of the qmail smtpd patches I've seen to add SMTP AUTH (including the one I wrote nearly twenty years ago) are sensible, integrate well with the rest of qmail. You might not get djb's warrantee, but I can't believe you gain nothing by starting from a solid foundation.
- 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

by pilif 7y ago

geocar 7y ago

> it's beside the point that I was trying to make which is that a CVE affecting a feature of Postfix that qmail doesn't have to begin with is not a fair mark against postfix. I disagree. It is a fair mark against postfix if (as I claim) most users really don't need it. Here's my reasoning to that point: I think most email end-users either use their ISPs mail settings (who know who they are and don't need authentication), or webmail (which doesn't use SMTP for relaying anyway), or outlook (which doesn't need SMTP at all). Fastmail is becoming more popular and it doesn't need SMTP either. The end-users who remain are either business users (who could use a VPN which is better than SMTP AUTH in every way), and nutters with vanity domains. If that's contended, and note I do believe there are probably end users who are actually still manually entering SMTP AUTH settings into email clients, but I would struggle to believe they're the majority and would need evidence. Meanwhile on the enterprise, pretty much every machine in every enterprise environment I've ever worked in has been set up for local relay. Again, if you think they're all using SMTP AUTH I'd need to see evidence. > If you use smtp authentication, you're not running djb's code and all advantages of djb's code are moot Do you actually believe that if you apt-get install postfix that you don't have any of the advantages of postfix's development processes? I'm not sure I can engage with that. It's like saying running linux invalidates "all advantages of djb's code" simply because you're (sometimes) not running his code (e.g. when you're in a syscall). Madness runs down that way. For what it's worth, most of the qmail smtpd patches I've seen to add SMTP AUTH (including the one I wrote nearly twenty years ago) are sensible, integrate well with the rest of qmail. You might not get djb's warrantee, but I can't believe you gain nothing by starting from a solid foundation.

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