The postgrey application inserts a referral URL into transient (451) reject messages which identifies the recipient domain (%r) to the URL basename postgrey.schweikert.ch. This is an undocumented privacy issue. How-To-Repeat: cd /usr/ports/mail/postgrey make install
Responsible Changed From-To: freebsd-ports-bugs->itetcu Fix synonpsis and take.
State Changed From-To: open->feedback Wait for maintainer. I tend to agree with the submitter, but the fix is wrong (confusing), IMHO.
Maintainer of mail/postgrey, Please note that PR ports/123468 has just been submitted. If it contains a patch for an upgrade, an enhancement or a bug fix you agree on, reply to this email stating that you approve the patch and a committer will take care of it. The full text of the PR can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/123468 -- Edwin Groothuis via the GNATS Auto Assign Tool edwin@FreeBSD.org
You are right, this does leak information. A sender might inadvertently tell the postgrey developer that he'd sent an email to a given domain - connecting a sender IP address with a recipient domain. Also, it tells the postgrey developer that a given domain uses postgrey. I guess the former leak is the one to be concerned about, and it's really not much of a leak. Still. Hmm. Maybe it would be more appropriate to bring this up on the Postgrey list? Maybe in a post-install message from the port to make it a documented privacy issue? It's actually 1) a neat feature and 2) I'd feel bad if I send a bunch of FreeBSD users to the postgrey list with confusing questions because our port is so different from the default. - H
State Changed From-To: feedback->analyzed
Is this PR still relevant?
Created attachment 147093 [details] Privacy patch
The privacy leak still exists as the underlying code has not changed and the previously submitted patch was not applied.
Back to pool! Somebody should take care of this now.
I submitted a patch which upgrades postgrey, and includes this patch too: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194019
This is a non-issue for the following reasons: - If the operator of %r uses the default response string from postgrey, they are making it public they're using postgrey. If they didn't want to disclose that, they'd override the string and remove the URI entirely. - Network information about the server receiving for %r is not disclosed to postgrey.schweikert.ch. - The URI works for nearly-arbitrary strings. It is not even subject to FQDN validation. For example, http://postgrey.schweikert.ch/help/_.html - The IP address disclosed to the postgrey.schweikert.ch is that of the browser going to the site, not the mail server relaying to %r. - The sending email address is not disclosed. - The same information is disclosed to the entire path of networks between the sender and receiving server. The information disclosure is that a browser appearing at a given IP address is emitting unencrypted HTTP requests which may or may not be associated with an email sent to %r. The lack of SSL and minimal level of information provided means this is effectively a disclosure of information already widely disclosed. Given the insignificant nature of the disclosure, there is greater utility in not deviating from upstream.
> - If the operator of %r uses the default response string from postgrey It appears that you're mistaking %r with the localhost (running freebsd and postgrey). %r is generated on the mailserver running postgrey and is sent A) to the originating MTA via SMTP handshake and B) if the message is timed-out it is normally sent back to the originating user in the bounce message text. > they are making it public they're using postgrey. If they didn't want to > disclose that, they'd override the string and remove the URI entirely. It's not clear what you are referring to here. First the postgrey advertisement is not at issue. WRT removing it, the only way to do so is by editing the postgrey script on the recipient MTA. The installation Makefile does not provide any mechanism for "override"ing %r nor does the sender or sending MTA have any way to do this. More importantly, none of these parties has expressed an interest in providing the owner of postgrey.schweikert.ch with this information. > - Network information about the server receiving for %r is not disclosed to > postgrey.schweikert.ch. True in some cases but not relevant to the patch. If the recipient of a bounced message or the reader of a mail log follows the URL, for information on greylisting for example, the operator of postgrey.schweikert.ch is informed of the sender's domain. This is what the patch prevents. The owner of schweikert.ch does not need to know what remote MTAs are being greylisted by other's MTAs nor is the disclosed domain name in any way helpful in researching the cause of a bounced or delayed email. The bottom line is this: neither the mail sender nor the intermediate MTA operators have an interest in disclosing this information to a third party (postgrey.schweikert.ch). > - The IP address disclosed to the postgrey.schweikert.ch is that of the browser > going to the site, not the mail server relaying to %r. This is incorrect. The %r string in question is the providing the sender's domainname. It has nothing to do with web browsers. > The information disclosure is that a browser appearing at a given IP address is > emitting unencrypted HTTP requests which may or may not be associated with an > email sent to %r. The lack of SSL and minimal level of information provided > means this is effectively a disclosure of information already widely disclosed. I respect your opinion that the information disclosed is "minimal", however, it is nevertheless just your opinion. Many of us believe that privacy does matter (as the popularity of Edward Snowden has revealed much less the work of groups from the EFF to EPIC). The patch would not have been submitted if everyone held the same opinion. > Given the insignificant nature of the disclosure, there is greater utility > in not deviating from upstream. An opinion of what constitutes privacy and a mistaken evaluation of what postgrey's %r string resolves to are not valid criteria for rejecting the patch. This patch should be evaluated on more factual and policy-based criteria.
(In reply to marquis from comment #12) >> - If the operator of %r uses the default response string from postgrey > > It appears that you're mistaking %r with the localhost (running freebsd > and postgrey). I'm referring to the operator of the recipient domain, using postgrey's placeholder notation as shorthand. >> they are making it public they're using postgrey. If they didn't want to >> disclose that, they'd override the string and remove the URI entirely. > > It's not clear what you are referring to here. First the postgrey > advertisement is not at issue. The suggested change was the change the default text from http://postgrey.schweikert.ch/help/%r.html to http://postgrey.schweikert.ch/help/ The only reduction in information is the receiving domain. However, Comment 4 mentions informing the developer that a given domain uses postgrey, thereby raising the advertisement aspect as part of this issue. > WRT removing it, the only way to do so is > by editing the postgrey script on the recipient MTA.The installation > Makefile does not provide any mechanism for "override"ing %r nor does the > sender or sending MTA have any way to do this. If you want to override the string, set the --greylist-text command-line parameter to the string you want postgrey to use. For example, my systems have "--greylist-text='4.7.1 greylisted.'" among the parameters added to postgrey_flags in /etc/rc.conf. This makes postfix respond with a string like: 450 4.7.1 <user@example.com>: Recipient address rejected: greylisted. The --greylist-text is mentioned in the postgrey man page. >> - Network information about the server receiving for %r is not disclosed >> to postgrey.schweikert.ch. > > True in some cases but not relevant to the patch. If the recipient of a > bounced message or the reader of a mail log follows the URL, for > information on greylisting for example, the operator of > postgrey.schweikert.ch is informed of the sender's domain. No, the operator of postgrey.schweikert.ch is informed that a browser at a given IP address asked for the help page customized for %r. >> - The IP address disclosed to the postgrey.schweikert.ch is that of the >> browser going to the site, not the mail server relaying to %r. > > This is incorrect. The %r string in question is the providing the > sender's domainname. It has nothing to do with web browsers. From the "Greylist Text" subsection of the postgrey man page: %r Mail-domain of the recipient (example.com). No part of the MAIL FROM address is ever disclosed to postgrey.schweikert.ch. The only other information disclosed is the IP address from which the web request came from. That is not the sender domain's mail server, that is the browser someone used to go to the URI. The reason I mention browser IP address at all is because, in Comment 4, haroldp@internal.org said, "A sender might inadvertently tell the postgrey developer that he'd sent an email to a given domain - connecting a sender IP address with a recipient domain." This is false, hence my addressing that point. > I respect your opinion that the information disclosed is "minimal", > however, it is nevertheless just your opinion. Many of us believe that > privacy does matter (as the popularity of Edward Snowden has revealed > much less the work of groups from the EFF to EPIC). Please refrain from ad hominems. I don't appreciation your insinuation that I don't believe privacy matters. > An opinion of what constitutes privacy and a mistaken evaluation of what > postgrey's %r string resolves to are not valid criteria for rejecting the > patch. > > This patch should be evaluated on more factual and policy-based criteria. Hopefully I've clarified the points where you raised factual concerns. As for policy-based criteria, that's the bailiwick of the operator.
In the interest of not continuing what is already an overblown debate: I would support adding a message alerting the installer to the default values of --greylist-text and --greylist-header and mentioning the ability to override the defaults using postgrey_flags. Is that a reasonable compromise?
I support the alert message. Eventually a simple --greylist-text parameter could be added to default postgrey_flags, and the message could mention that is not the default value. But this is my private suggest only, I think both solutions are almost the same.
I'll work up a patch to add a package message. It will be part of the patch for bug 194019.
Sounds good. A configure option and patch for the port would also be ideal.
The finalized patch for bug 194019 includes the discussed warning message as part of pkg-message. I think we can finally close this bug now.
Fixed with https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194019