New email address

On Tue, Nov 24, 2015 at 3:41 AM, Kevin Grittner <kgrittn@gmail.com> wrote:

Yahoo recently changed their DMARC policy, and after some
investigation and a support case with Yahoo, it is now clear that
their email systems can no longer be used with the postgresql.org
lists. I've migrated from kgrittn@ymail.com to kgrittn@gmail.com.

Something to be aware of as well: I noticed that sometimes your emails
coming from @ymail.com were flagged as spam by gmail. People be
careful of that if you use it.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Le 24 nov. 2015 01:05, "Michael Paquier" <michael.paquier@gmail.com> a
écrit :

On Tue, Nov 24, 2015 at 3:41 AM, Kevin Grittner <kgrittn@gmail.com> wrote:

Yahoo recently changed their DMARC policy, and after some
investigation and a support case with Yahoo, it is now clear that
their email systems can no longer be used with the postgresql.org
lists. I've migrated from kgrittn@ymail.com to kgrittn@gmail.com.

Something to be aware of as well: I noticed that sometimes your emails
coming from @ymail.com were flagged as spam by gmail. People be
careful of that if you use it.

+1, happened a lot actually.

On Nov 24, 2015 01:05, "Michael Paquier" <michael.paquier@gmail.com> wrote:

On Tue, Nov 24, 2015 at 3:41 AM, Kevin Grittner <kgrittn@gmail.com> wrote:

Yahoo recently changed their DMARC policy, and after some
investigation and a support case with Yahoo, it is now clear that
their email systems can no longer be used with the postgresql.org
lists. I've migrated from kgrittn@ymail.com to kgrittn@gmail.com.

Something to be aware of as well: I noticed that sometimes your emails
coming from @ymail.com were flagged as spam by gmail. People be
careful of that if you use it.

That's a direct effect of the dmarc policy change. Yahoo no longer supports
their customers using mailing lists. They changed their policies for such
emails to hard reject, which makes Gmail (and presumably others) stick them
in spam.. It would happen to all the emails except the ones where you are
on direct cc.

/Magnus

Magnus Hagander wrote:

That's a direct effect of the dmarc policy change. Yahoo no longer supports
their customers using mailing lists. They changed their policies for such
emails to hard reject, which makes Gmail (and presumably others) stick them
in spam.. It would happen to all the emails except the ones where you are
on direct cc.

FWIW we've been rejecting posts coming from @yahoo.com addresses for a
long time now, since DMARC was first introduced. We didn't get around
to blocking other domains owned by Yahoo such as ymail.com or national
yahoo subdomains, but I assume (without checking) that those will cause
trouble too and we will have to block them out in order not to fill our
queues with useless bounces.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Nov 24, 2015 at 12:58 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
wrote:

Magnus Hagander wrote:

That's a direct effect of the dmarc policy change. Yahoo no longer

supports

their customers using mailing lists. They changed their policies for such
emails to hard reject, which makes Gmail (and presumably others) stick

them

in spam.. It would happen to all the emails except the ones where you are
on direct cc.

FWIW we've been rejecting posts coming from @yahoo.com addresses for a
long time now, since DMARC was first introduced. We didn't get around
to blocking other domains owned by Yahoo such as ymail.com or national
yahoo subdomains, but I assume (without checking) that those will cause
trouble too and we will have to block them out in order not to fill our
queues with useless bounces.

Yes. The difference is they changed it from a soft fail to a hard reject,
AIUI. From all of their domains (Kevin forwarded me the responses from
Yahoo support). So the problem got worse, but it's the same basic one.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Magnus Hagander wrote:

That's a direct effect of the dmarc policy change. Yahoo no longer supports
their customers using mailing lists. They changed their policies for such
emails to hard reject, which makes Gmail (and presumably others) stick them
in spam.. It would happen to all the emails except the ones where you are
on direct cc.

FWIW we've been rejecting posts coming from @yahoo.com addresses for a
long time now, since DMARC was first introduced. We didn't get around
to blocking other domains owned by Yahoo such as ymail.com or national
yahoo subdomains, but I assume (without checking) that those will cause
trouble too and we will have to block them out in order not to fill our
queues with useless bounces.

FWIW, my neighborhood's mailing list just recently implemented some
changes that were supposed to allow the list to work again for Yahoo
and other DMARC-affected users, after quite some time without service.
I don't know how successful they were at that, nor how difficult the
changes were ... but I do know the list server was offline for more
than a day while the changes went in, so it was less than trivial.
The only real change I can detect from looking at mail headers is that
it seems the list may now be attaching its own DKIM-Signature header
to emails that had one upon arrival.

If anyone thinks we might be motivated to become DMARC compliant,
I can inquire for more details. But I won't bother unless there's
real interest.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Nov 24, 2015 at 4:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Magnus Hagander wrote:

That's a direct effect of the dmarc policy change. Yahoo no longer

supports

their customers using mailing lists. They changed their policies for

such

emails to hard reject, which makes Gmail (and presumably others) stick

them

in spam.. It would happen to all the emails except the ones where you

are

on direct cc.

FWIW we've been rejecting posts coming from @yahoo.com addresses for a
long time now, since DMARC was first introduced. We didn't get around
to blocking other domains owned by Yahoo such as ymail.com or national
yahoo subdomains, but I assume (without checking) that those will cause
trouble too and we will have to block them out in order not to fill our
queues with useless bounces.

FWIW, my neighborhood's mailing list just recently implemented some
changes that were supposed to allow the list to work again for Yahoo
and other DMARC-affected users, after quite some time without service.
I don't know how successful they were at that, nor how difficult the
changes were ... but I do know the list server was offline for more
than a day while the changes went in, so it was less than trivial.
The only real change I can detect from looking at mail headers is that
it seems the list may now be attaching its own DKIM-Signature header
to emails that had one upon arrival.

If anyone thinks we might be motivated to become DMARC compliant,
I can inquire for more details. But I won't bother unless there's
real interest.

I'd definitely be interested at least in what they're doing. Whether we'd
actually implement it would depend on the implications of course, but if
they've actually figured out how to do it, it could be useful.

We've discussed just forcibly stripping the DKIM headers of those emails,
but that's unlikely to help - I'm sure large mail providers will "know"
that yahoo mail is supposed to carry DKIM and thus fail. The whole point of
DKIM is to prevent changing the headers after all - and we do change the
headers.

Yahoo has a page on it (can't find the ref this moment) where they simply
say "there is no mailinglist software supporting this. There are some
experimental patches for an old version of mailman that people will perhaps
consider merging at some time in the future."

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus@hagander.net> writes:

On Tue, Nov 24, 2015 at 4:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

If anyone thinks we might be motivated to become DMARC compliant,
I can inquire for more details. But I won't bother unless there's
real interest.

I'd definitely be interested at least in what they're doing. Whether we'd
actually implement it would depend on the implications of course, but if
they've actually figured out how to do it, it could be useful.

OK, will ask.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Magnus Hagander <magnus@hagander.net> writes:

On Tue, Nov 24, 2015 at 4:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

If anyone thinks we might be motivated to become DMARC compliant,
I can inquire for more details. But I won't bother unless there's
real interest.

I'd definitely be interested at least in what they're doing. Whether we'd
actually implement it would depend on the implications of course, but if
they've actually figured out how to do it, it could be useful.

Forwarded with Rudy's permission ...

regards, tom lane

------- Forwarded Message

Date: Tue, 24 Nov 2015 10:34:45 -0500
From: "Rudolph T. Maceyko" <rm55@pobox.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: How did you fix HP list for DMARC compliance, exactly?

Hi Tom,

The basic changes since Yahoo implemented their p=reject DMARC policy
last year (and others followed) were:
* make NO CHANGES to the body of the message--no headers, footers, etc.

* make NO CHANGES to the subject header of the message--no more
"[Highland Park]"

* when mail comes to the list from a domain that uses a p=reject DMARC
policy, CHANGE THE FROM HEADER so that it comes from the list.
Otherwise, when that message would be verified by any site that checks
DMARC, it would fail (and probably would not be delivered, or would be
considered spam).

That last point was the big one, and is something that Mailman supports
(in recent versions). It provides the option either to wrap the
"offending" message in an attachment, or to do what we do now, which is
to change the From header (and add a Reply-To, so replies still work).
You could also elect to change *every* message that way, which seems
like overkill (at least it does today).

All of that is necessary in order to avoid DMARC problems. Of course,
you CAN ban subscribers from these domains, but the list of p=reject
DMARC policy sites will only grow. I read that Google is considering
implementing it next year.

Anyway, in addition to all of that, I've implemented DKIM
verification/signing and our own DMARC policy (but NOT p=reject), as
well as greylisting. These are just ways to elevate our anti-spam
profile (and reputation). I've also set up feedback loops for AOL and
Yahoo (and I'm trying for Comcast) so they don't ding us just because
one of their subscribers "accidentally" marks a message that came
through the list as spam. Running a mail server is hard these days...

-Rudy

On 2015-11-24 10:19, Tom Lane wrote:

I'm curious about what changes you made for this. And, of course: did
it work?

I'm inquiring on behalf of an open-source project I'm involved in,
who might be interested in fixing their lists similarly:
/messages/by-id/CACjxUsPCjAFU81izZ0VcmK78EtEQ4_EjgCJK402WwwXvEZRhZA@mail.gmail.com [1]

I don't believe they run the same list software you do, so exact
instructions probably aren't useful, but a functional spec for what
needs to happen would be very valuable.

Thanks!

regards, tom lane

------- End of Forwarded Message

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

I wrote:

"Rudolph T. Maceyko" <rm55@pobox.com> writes:

The basic changes since Yahoo implemented their p=reject DMARC policy
last year (and others followed) were:
* make NO CHANGES to the body of the message--no headers, footers, etc.
* make NO CHANGES to the subject header of the message--no more
"[Highland Park]"
* when mail comes to the list from a domain that uses a p=reject DMARC
policy, CHANGE THE FROM HEADER so that it comes from the list.

After further off-list discussion with Rudy, I'm not entirely convinced
by his reasoning for dropping Subject-munging and footer-addition; it
seems like that might be at least in part a limitation of his
mailman-based infrastructure.

The clearly critical thing, though, is that when forwarding a message from
a person at a DMARC-using domain, we would have to replace the From: line
with something @postgresql.org. This is what gets it out from under the
original domain's DMARC policy.

The other stuff Rudy did, including adding the list's own DKIM-Signatures
and publishing DMARC and SPF policy for the list domain, is not
technically necessary (yet) but it makes the list traffic less likely to
get tagged as spam by antispam heuristics. And, as he noted, there are
feedback loops that mean once some traffic gets tagged as spam it becomes
more likely that future traffic will be.

If Rudy's right that Gmail is likely to start using p=reject DMARC policy,
we are going to have to do something about this before that; we have too
many people on gmail. I'm not exactly in love with replacing From:
headers but there may be little alternative. We could do something like
From: Persons Real Name <nobody@postgresql.org>
Reply-To: ...
so that at least the person's name would still be readable in MUA
displays.

We'd have to figure out whether we want the Reply-To: to be the original
author or the list; as I recall, neither of those are fully satisfactory.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Nov 24, 2015 at 11:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Forwarded with Rudy's permission ...
From: "Rudolph T. Maceyko" <rm55@pobox.com>

* when mail comes to the list from a domain that uses a p=reject DMARC
policy, CHANGE THE FROM HEADER so that it comes from the list.
Otherwise, when that message would be verified by any site that checks
DMARC, it would fail (and probably would not be delivered, or would be
considered spam).

change the From header (and add a Reply-To, so replies still work).

If this were done, would the other steps (not changing the subject
or body of the email) be necessary?

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Kevin Grittner <kgrittn@gmail.com> writes:

On Tue, Nov 24, 2015 at 11:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

change the From header (and add a Reply-To, so replies still work).

If this were done, would the other steps (not changing the subject
or body of the email) be necessary?

See my followup: I think it's probably true that we could skip those
changes. But Rudy commented that there's a lot of underdocumented
subtlety here. There might be reasons I'm missing why we'd need to
stop doing those things. It doesn't seem like DMARC as such would
force that, but perhaps those things trigger some popular antispam
heuristics.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-11-24 13:11, Tom Lane wrote:

Kevin Grittner <kgrittn@gmail.com> writes:

On Tue, Nov 24, 2015 at 11:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

change the From header (and add a Reply-To, so replies still work).

If this were done, would the other steps (not changing the subject
or body of the email) be necessary?

See my followup: I think it's probably true that we could skip those
changes. But Rudy commented that there's a lot of underdocumented
subtlety here. There might be reasons I'm missing why we'd need to
stop doing those things. It doesn't seem like DMARC as such would
force that, but perhaps those things trigger some popular antispam
heuristics.

regards, tom lane

Any Header or Body changes will invalidate most, if not all, DKIM
signatures. Since DKIM is used as part
of DMARC, it's a problem.

Not sure what MajorDomo2 will allow you to do.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: ler@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Larry Rosenman wrote:

On 2015-11-24 13:11, Tom Lane wrote:

Kevin Grittner <kgrittn@gmail.com> writes:

On Tue, Nov 24, 2015 at 11:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

change the From header (and add a Reply-To, so replies still work).

If this were done, would the other steps (not changing the subject
or body of the email) be necessary?

See my followup: I think it's probably true that we could skip those
changes. But Rudy commented that there's a lot of underdocumented
subtlety here. There might be reasons I'm missing why we'd need to
stop doing those things. It doesn't seem like DMARC as such would
force that, but perhaps those things trigger some popular antispam
heuristics.

Any Header or Body changes will invalidate most, if not all, DKIM
signatures. Since DKIM is used as part
of DMARC, it's a problem.

Not sure what MajorDomo2 will allow you to do.

We can turn off header and body changes easily enough, but changing the
"From:" address requires patching the Majordomo2 source code; and, as
you may already be aware, the maintainers gave up on Mj2 a decade ago,
so we'd be on our own for that. I cannot promise any sort of timeline
for getting that done; and since that's an essential part of the recipe,
I don't see any point in doing the other changes either for the time
being.

I think the breakage of DKIM signatures is already causing some pain
(though nowhere near the level of DMARC).

Of course, removing all the "List-" headers *and* our custom footers is
a huge step backwards in terms of mailing list functionality :-( Also,
removing the [HACKERS] etc tags will annoy some people, for sure.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-11-24 13:43, Alvaro Herrera wrote:

Larry Rosenman wrote:

On 2015-11-24 13:11, Tom Lane wrote:

Kevin Grittner <kgrittn@gmail.com> writes:

On Tue, Nov 24, 2015 at 11:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

change the From header (and add a Reply-To, so replies still work).

If this were done, would the other steps (not changing the subject
or body of the email) be necessary?

See my followup: I think it's probably true that we could skip those
changes. But Rudy commented that there's a lot of underdocumented
subtlety here. There might be reasons I'm missing why we'd need to
stop doing those things. It doesn't seem like DMARC as such would
force that, but perhaps those things trigger some popular antispam
heuristics.

Any Header or Body changes will invalidate most, if not all, DKIM
signatures. Since DKIM is used as part
of DMARC, it's a problem.

Not sure what MajorDomo2 will allow you to do.

We can turn off header and body changes easily enough, but changing the
"From:" address requires patching the Majordomo2 source code; and, as
you may already be aware, the maintainers gave up on Mj2 a decade ago,
so we'd be on our own for that. I cannot promise any sort of timeline
for getting that done; and since that's an essential part of the
recipe,
I don't see any point in doing the other changes either for the time
being.

I think the breakage of DKIM signatures is already causing some pain
(though nowhere near the level of DMARC).

Of course, removing all the "List-" headers *and* our custom footers is
a huge step backwards in terms of mailing list functionality :-( Also,
removing the [HACKERS] etc tags will annoy some people, for sure.

You don't have to remove the List- headers. DKIM says what headers it's
using.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: ler@lerctr.org
US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Larry Rosenman <ler@lerctr.org> writes:

On 2015-11-24 13:11, Tom Lane wrote:

Kevin Grittner <kgrittn@gmail.com> writes:

If this were done, would the other steps (not changing the subject
or body of the email) be necessary?

See my followup: I think it's probably true that we could skip those
changes.

Any Header or Body changes will invalidate most, if not all, DKIM
signatures. Since DKIM is used as part of DMARC, it's a problem.

Yeah, but SPF is also used as part of DMARC, which means that merely
forwarding somebody's email out of our listserv is probably going to look
like spam, even if we didn't change anything at all about the message
contents. Also, some sources sign Reply-To: and/or Sender: (Yahoo,
at least, does the former) which means you can't replace those headers
either without breaking the DKIM signature. The only fix for that is to
rewrite From:, and once you do that I don't see a convincing argument why
you can't also rewrite Subject: and add a footer if you feel like it.

(For context, Rudy had implemented the no-header-change and no-footers
changes on our neighborhood list quite some time ago; the From: changes
and local DKIM-Signature: were the things that went in last week. I'm of
the opinion that he could revert the former now that he's done the latter;
but he seems to think not, for reasons he was not able to explain to me
convincingly. It seems to me that the first two changes were meant to
allow the source's DKIM-Signature to still apply, and now that he's given
up on that strategy, I don't see what they're buying.)

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Larry Rosenman <ler@lerctr.org> writes:

On 2015-11-24 13:43, Alvaro Herrera wrote:

Of course, removing all the "List-" headers *and* our custom footers is
a huge step backwards in terms of mailing list functionality :-( Also,
removing the [HACKERS] etc tags will annoy some people, for sure.

You don't have to remove the List- headers. DKIM says what headers it's
using.

Yeah. RFC 6376 is worth a quick look if you want to opine knowledgeably
about this. Basically, the DKIM crypto hash covers the message body plus
those header fields enumerated in the DKIM-Signature header, and 6376
gives this advice:

The From header field MUST be signed (that is, included in the "h="
tag of the resulting DKIM-Signature header field). Signers SHOULD
NOT sign an existing header field likely to be legitimately modified
or removed in transit. In particular, [RFC5321] explicitly permits
modification or removal of the Return-Path header field in transit.
Signers MAY include any other header fields present at the time of
signing at the discretion of the Signer.

INFORMATIVE OPERATIONS NOTE: The choice of which header fields to
sign is non-obvious. One strategy is to sign all existing, non-
repeatable header fields. An alternative strategy is to sign only
header fields that are likely to be displayed to or otherwise be
likely to affect the processing of the message at the receiver. A
third strategy is to sign only "well-known" headers. Note that
Verifiers may treat unsigned header fields with extreme
skepticism, including refusing to display them to the end user or
even ignoring the signature if it does not cover certain header
fields. For this reason, signing fields present in the message
such as Date, Subject, Reply-To, Sender, and all MIME header
fields are highly advised.

I think the advice to sign Reply-To and Sender is rather ill-advised,
particularly the latter, as signing that absolutely would break mailing
list forwarding.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 11/24/2015 07:55 PM, Tom Lane wrote:

I wrote:

"Rudolph T. Maceyko" <rm55@pobox.com> writes:

The basic changes since Yahoo implemented their p=reject DMARC policy
last year (and others followed) were:
* make NO CHANGES to the body of the message--no headers, footers, etc.
* make NO CHANGES to the subject header of the message--no more
"[Highland Park]"
* when mail comes to the list from a domain that uses a p=reject DMARC
policy, CHANGE THE FROM HEADER so that it comes from the list.

After further off-list discussion with Rudy, I'm not entirely convinced
by his reasoning for dropping Subject-munging and footer-addition; it
seems like that might be at least in part a limitation of his
mailman-based infrastructure.

The clearly critical thing, though, is that when forwarding a message from
a person at a DMARC-using domain, we would have to replace the From: line
with something @postgresql.org. This is what gets it out from under the
original domain's DMARC policy.

exactly

The other stuff Rudy did, including adding the list's own DKIM-Signatures
and publishing DMARC and SPF policy for the list domain, is not
technically necessary (yet) but it makes the list traffic less likely to
get tagged as spam by antispam heuristics. And, as he noted, there are
feedback loops that mean once some traffic gets tagged as spam it becomes
more likely that future traffic will be.

well the purpose of the feedback loops is for the receiving ISP to feed
back information about (mostly) user tagged "I dont want this email"
(which is what the work on - not actual heuristics triggering) stuff -
from historical experience that works very very poor for a mailing list
like ours because in almost all cases subscribers are simply using the
"this is spam" feature to declare an email as "unwanted" and using it as
a shortcut to actually unsubscribing (and not thinking about any further
impact).

If Rudy's right that Gmail is likely to start using p=reject DMARC policy,
we are going to have to do something about this before that; we have too
many people on gmail. I'm not exactly in love with replacing From:
headers but there may be little alternative. We could do something like
From: Persons Real Name <nobody@postgresql.org>
Reply-To: ...
so that at least the person's name would still be readable in MUA
displays.

We'd have to figure out whether we want the Reply-To: to be the original
author or the list; as I recall, neither of those are fully satisfactory.

well this is basically what it boils down to - we will absolutely have
to do is replacing "From:" (assuming the gmail rumour is true which I'm
not entirely convinced though) but what are we prepared to replace the
current system with and are we accepting that the lists are going to
work differently.

Stefan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 11/24/2015 07:55 PM, Tom Lane wrote:

[snip]
The clearly critical thing, though, is that when forwarding a message from
a person at a DMARC-using domain, we would have to replace the From: line
with something @postgresql.org. This is what gets it out from under the
original domain's DMARC policy.

One possibility that comes to mind:

- Remove the sender's DMARC headers+signature **after thoroughly
checking it** (to minimize the amount of UBE/UCE/junk going in)
- Replace the sender's (i.e. 'From:' header) with
list-sender+munched-email@postgresql.org (VERP-ified address)

- Add the required headers, footers, change the subject line, etc

- DKIM-sign the resulting message with postgresql.org's keys before
sending it

[snip]

If Rudy's right that Gmail is likely to start using p=reject DMARC policy,
we are going to have to do something about this before that; we have too
many people on gmail. I'm not exactly in love with replacing From:
headers but there may be little alternative. We could do something like
From: Persons Real Name <nobody@postgresql.org>
Reply-To: ...
so that at least the person's name would still be readable in MUA
displays.

Yup

We'd have to figure out whether we want the Reply-To: to be the original
author or the list; as I recall, neither of those are fully satisfactory.

Or just strip it, though that trump the sender's explicit preference
(expressed by setting the header)

I might be able to help a bit with implementation if needed.

/ J.L.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers