From owner-freebsd-ports-bugs@FreeBSD.ORG Thu Oct 9 05:18:38 2014 Return-Path: Delivered-To: freebsd-ports-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B317D44D for ; Thu, 9 Oct 2014 05:18:38 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 999B42E6 for ; Thu, 9 Oct 2014 05:18:38 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s995Ic2b013699 for ; Thu, 9 Oct 2014 05:18:38 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 123468] mail/postgrey: information leak, privacy issue Date: Thu, 09 Oct 2014 05:18:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports Tree X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ports.maintainer@evilphi.com X-Bugzilla-Status: In Discussion X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 05:18:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=123468 --- Comment #13 from Darren Pilgrim --- (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 : 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.