Re: New email address - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: New email address
Date
Msg-id CABUevEywFSg5kvixg9f62F9QVyYR+zbCP6fA-=vjBYbPuFoKjA@mail.gmail.com
Whole thread Raw
In response to Re: New email address  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Fri, Nov 27, 2015 at 10:36 AM, Greg Stark <stark@mit.edu> wrote:
On Thu, Nov 26, 2015 at 11:26 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> I don't think that's going to be anything but unwelcome noise.  What
> would they do if they became aware of the issue?  They could switch
> providers, but that only works for so long.  As soon as Gmail switches
> to p=reject, we've lost.  We got away with doing it for Yahoo because
> there's not a lot of people using that -- not on these lists anyway.

On further thought I think Gmail going p=reject is the wrong thing to
worry about. The thing we need to check is how major mail providers
like Gmail and Yahoo handle SPF failures *today*. There are plenty of
domains we probably don't want to miss emails from that *already* have
p=reject. For example if a Google employee mails us from @google.com
[*] today that domain has p=reject so will everyone reading the list
on Gmail or Yahoo miss the email? I bet other major companies have
p=reject on their corporate domains as well.

Google doesn't actually reject, but it increases the likelyhood of it hitting spam significantly. However, they put a fairly low value on the SPF records. In my experience, it seems they put a much higher value on DKIM (failed or not).

Of course, Google also only actually *supports* email if both sender and receiver is on gmail. Anything else is "we hope it works". (Yes, I have official responses from google paid support saying they only support scenarios where both sender and receiver is on gmail)

--

pgsql-hackers by date:

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