Date: Thu, 09 Oct 2014 05:18:37 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 123468] mail/postgrey: information leak, privacy issue Message-ID: <bug-123468-13-pGPfZeEk6n@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-123468-13@https.bugs.freebsd.org/bugzilla/> References: <bug-123468-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=123468 --- Comment #13 from Darren Pilgrim <ports.maintainer@evilphi.com> --- (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. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-123468-13-pGPfZeEk6n>