Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > On Mon, Jan 28, 2019 at 7:26 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > > Stephen Frost <sfr...@snowman.net> writes: > > >> On Sun, Jan 27, 2019 at 2:28 AM Noah Misch <n...@leadboat.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-b...@postgresql.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-b...@lists.postgresql.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
signature.asc
Description: PGP signature
