Re: what is up with the PG mailing lists?
От | Magnus Hagander |
---|---|
Тема | Re: what is up with the PG mailing lists? |
Дата | |
Msg-id | 4729F105.30704@hagander.net обсуждение исходный текст |
Ответ на | Re: what is up with the PG mailing lists? (Andrew Sullivan <ajs@crankycanuck.ca>) |
Ответы |
Re: what is up with the PG mailing lists?
("Joshua D. Drake" <jd@commandprompt.com>)
Re: what is up with the PG mailing lists? ("Marc G. Fournier" <scrappy@hub.org>) Re: what is up with the PG mailing lists? (Andrew Sullivan <ajs@crankycanuck.ca>) |
Список | pgsql-www |
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
В списке pgsql-www по дате отправления: