Re: New email address - Mailing list pgsql-hackers

From José Luis Tallón
Subject Re: New email address
Date
Msg-id 56579229.6030306@adv-solutions.net
Whole thread Raw
In response to Re: New email address  (Greg Stark <stark@mit.edu>)
Responses Re: New email address
List pgsql-hackers
<div class="moz-cite-prefix">On 11/26/2015 09:12 PM, Greg Stark wrote:<br /></div><blockquote
cite="mid:CAM-w4HPNfQFAxYQhA=T7DJDoiyWEB+jwx1y2VCEvuvmk6dX7kA@mail.gmail.com"type="cite"><pre wrap="">On Wed, Nov 25,
2015at 6:55 PM, Tom Lane <a class="moz-txt-link-rfc2396E" href="mailto:tgl@sss.pgh.pa.us"><tgl@sss.pgh.pa.us></a>
wrote:
</pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">But my point was that while the RFC says what to put
therethere's
 
absolutely no reference anywhere for when the information should cause
any MUA or MTA to behave differently.
</pre></blockquote><pre wrap="">
Agreed.  To my mind that's a reason why Sender should not be DKIM-signed.
Unfortunately, RFC 6376 explicitly suggests doing so ... and it looks like
some people are taking that advice.
</pre></blockquote><pre wrap="">
Hm, I see it as a reason why signing Sender is reasonable. If it were
a functional header then there might be a reason it would have to be
changed. But if it's purely informational and the receiving MUA is
going to display to the user (which is a bad idea imho but Gmail and
Exchange both do it) then it makes sense to expect some authentication
for it. I think the thinking is basically "sign everything we're going
to present to the user phishers can't claim to be someone they're
not". In which case it's fairly important that things like Sender be
signed. Or that everyone agree it's just a useless header and stop
sending or displaying it.</pre></blockquote><br /> From DMARC.org's Wiki:<br /><span class="comment"><span
class="c00"><<<2 Add an "Original Authentication Results" header to indicate you have <br /> performed the
authenticationand you are validating it <br /> 3 Take ownership of the email, by removing the DKIM signature and
puttingyour own <br /> as well as changing the from header in the email to contain an email address <br /> within your
mailinglist domain.</span></span> >>><br /><br /><br /> Read elsewhere: "To allow for forwarding scenarios,
DMARCalso allows the <strong>Display From</strong> to be cryptographically signed by DKIM, and if any unauthorized
spammeror phisher were to attempt to assume that identity, the encryption would fail."<br /><br /><blockquote
cite="mid:CAM-w4HPNfQFAxYQhA=T7DJDoiyWEB+jwx1y2VCEvuvmk6dX7kA@mail.gmail.com"type="cite"><pre wrap="">I don't think we
shouldbase any action on guesses of what Gmail does.
 
Google may do something we don't expect that's more complex to work
around the problem. For one thing you can have email addresses at
Google from a number of domains so they may well be able to have more
than one policy for different users.</pre></blockquote> Yep<br /><blockquote
cite="mid:CAM-w4HPNfQFAxYQhA=T7DJDoiyWEB+jwx1y2VCEvuvmk6dX7kA@mail.gmail.com"type="cite"><pre wrap="">I would suggest
westop doing things that are obviously incompatible
 
with DKIM -- header and body munging for example. And I suspect we can
stop touching Sender without any ill effects too.

One idea might be to add a script to check a user's domain for
p=reject and send them a warning when subscribing (or sending mail to
the list?) warning them of the problem.
</pre></blockquote> Definitively worth the effort, unless an almost perfect solution is found :S<br /><br /><br />    
/J.L.<br /><br /> 

pgsql-hackers by date:

Previous
From: Euler Taveira
Date:
Subject: Re: WIP: About CMake v2
Next
From: Greg Stark
Date:
Subject: Re: New email address