Re: what is up with the PG mailing lists?

Andrew Sullivan wrote:
> On Thu, Nov 01, 2007 at 08:09:59AM -0700, Joshua D. Drake wrote:
>> However the "mailing list" problem is a constant. Sometimes they work,
>> sometimes I don't get messages for hours. This is not the first time I
>> or others have brought up the mailing list issues.
>
> There are indeed sometimes mailing list latency issues. But I
> caution everyone in being too glib about some of this:
>
> 1. All the mail RFCs are totally clear that latency is to be
> expected in the mail system. Every time I hear complaints about mail
> latency that entails delays of merely hours, I worry that people are
> treating SMTP as though it's XMPP. It ain't, and it's designed _not_
> to be.

There's a difference between acceptable delay and what we're often
getting. Sure, SMTP should have latency. But a modern SMTP system
shouldn't take hours to deliver an email.

> 2. There are plenty of individual relays involved here, and
> saying "it's slow" without mail headers is no more helpful in
> demystifying mail issues than are posts to -performance without
> EXPLAIN ANALYSE output.

Sure. But I can tell you that *every single time* I've looked at
latencies, the problem has been at postgresql.org or hub.org. And in my
own case, there is just one relay on the way, usually with a latency of
<5 seconds.

> 3. We know that sometimes, moderation _does_ cost. This is
> especially true because we've already cranked up a lot of rules to
> capture common abuses (spam, common admin keywords) that are far from
> free to run on lists with the volume of mail the postgres lists get.
> So we're really paying for two moderations: humans, and machines.

That's very true.

>> It would be great if the actual sysadmin team had management ability on
>> the mail servers.
>
> This seems true to me. More important,
>
>> Note we still don't have documentation on this stuff
>
> I think this is a very serious problem. Some of the issues have been
> perplexing to diagnose because of the poor documentation. We talked
> about this most recently with respect to MX records and
> higher-preference-number MXes having the user list from the final
> destination, so that we could generate rejects consistently, IIRC.

Can't agree more.

//Magnus