Re: pgsql: Remove references to Majordomo

Greetings,

* Magnus Hagander (magnus(at)hagander(dot)net) wrote:
> On Mon, Jan 28, 2019 at 7:26 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > >> On Sun, Jan 27, 2019 at 2:28 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > >>> What are those blocked infrastructure improvements?
> >
> > > The specific improvements we're talking about are DKIM/DMARC/SPF, which
> > > is becoming more and more important to making sure that the email from
> > > our lists can actually get through to the subscribers.
> >
> > Certainly those are pretty critical. But can you give us a quick
> > refresher on why dropping the @postgresql.org list aliases is
> > necessary for that? I thought we'd already managed to make the
> > lists compliant with those specs.
>
> I believe it doesn't, as Stephen also agreed with upthread.
>
> We needed to move our *sending* out of the postgresql.org domain in order
> to be able to treat them differently. But there is nothing preventing us
> from receiving to e.g. pgsql-bugs(at)postgresql(dot)org and internally forward it
> to @lists.postgresql.org, where we then deliver from.

Yes, I *think* this will work, as long as we are sending it back out
from pgsql-bugs(at)lists(dot)postgresql(dot)org then we should be able to have SPF
records for lists.postgresql.org and downstream mail servers should be
happy with that, though I still want to actually test it out in our test
instance of PGLister.

This is the main thing- we want to have lists.postgresql.org (and
friends) have SPF (and maybe DKIM..) records which basically say that
malur is allowed to send mail out from those lists (or with those lists
in the From: of the email in the case of DKIM), but we don't want to
make everyone who is sending email from a @postgresql.org have to relay
through our mail servers (well, at least not today.. we may get to a
point in the spam wars where we *have* to do that or their email ends up
not going through, but we aren't quite there yet).

> I believe we *can* do the same for all lists, but that part is more a
> matter of cleaning up our infrastructure, which has a fair amount of cruft
> to deal with those things. We have an easy workaround for a couple of lists
> which owuld take only a fairly small amount of traffic over it, but we'd
> like to get rid of the cruft to deal with the large batch of them.

Yes, there's this aspect of it also.

Thanks!

Stephen