It appears that I caused a ruckus with my suggestion. It hasn't helped that
I have, I think, encouraged a rather different discussion. This message is
intended to disambiguate the various threads of this discussion, lay to rest
at least one, and to make a promise about others.
A. What I asked for
What I actually asked for was that we reject mail From:
<listname(at)postgresql(dot)org> destined for <listname(at)postgresql(dot)org>. I
suggested this, because the spammers have obviously figured out that they
can send mail with the From: and To: headers the same, and evade many spam
traps. Since lists should _never_ send mail to themselves (it'd be a loop),
this is an obvious optimisation. Marc says he can do this; I dunno whether
it's been done, but I think his suggestion should be implemented.
B. What else came out
As it turns out, this discussion raised several other issues. I think they
are the following:
1. SMTP Auth
Everyone agrees this should be and is happening, so we don't need to discuss
2. SMTP Submit vs. "Classic" SMTP
While it is possible to authenticate SMTP while relaying, there is a current
push in the Internet operator community to end the practice of MUA->MTA
submission on port 25. The reasons for this are somewhat complicated. I'd
like to propose that we not be distracted by this conversation while the
current release is happening. Therefore, I propose that we postpone that
discussion until some time in January.
In order to allow people to prepare for any such discussion, there are some
sub-questions that arise:
a. Do we allow email that is unauthenticated with SMTP Auth from
any domain to go to any list without moderation (irrespective of
b. Do we allow email that is unauthenticated with SMTP Auth from
postgresql.org domains to go to any list without moderation
(irrespective of subscription)?
c. Do we reject email that is unauthenticated with SMTP Auth with a
To: to the lists?
d. Do we regard email with a From: address in the postgresql.org
domain that is unauthenticated (by any server) to be legitimate (and
therefore in or out of spam-control attempts)?
e. Do we regard email with a From: address in the postgresql.org
domain that is not SMTP-Auth authenticated _at all_ to be
f. Do we regard email with a From: address in the postgresql.org
domain that is not authenticated _at the postgresql.org mail
servers_ to be legitimate? (Consider SMTP Auth at
non-postgresql.org mail servers, such as hub.org or
g. Do we regard email with a From: address in the postgresql.org
domain that is not authenticated by the postgresql.org submit
service at the time of MUA->MTA delivery to be legitimate?
h. What do our answers to the above mean for various email signing
systems (such as SPF and DKIM)?
Every one of the above may be answered in different ways, and the union of
them entails various listmail policies that we may or may not like. Since
the possible set of policies is so large, I offer to put together a proposed
set of policies, with justifications, some time in January (after the
release is behind us); that ought to eliminate the number of options that
need to be included (I think some of the above questions have obvious
Is this ok with others?
Old sigs will return after re-constitution of blue smoke
In response to
pgsql-www by date
|Next:||From: Magnus Hagander||Date: 2007-11-29 22:41:05|
|Subject: Re: Can we please refuse mail to the list from list addresses?|
|Previous:||From: Raymond O'Donnell||Date: 2007-11-29 20:15:15|
|Subject: Re: [pgsql-www] Republic of Ireland Press Contact|