On Thu, 15 Nov 2007, Odhiambo Washington wrote:
> > Speaking of which, does anyone have any good tips to share on how to
> > write an ACL for incoming Mailman traffic, which (say) rejects
> > post-DATA for messages which are not from list members? (Obviously
> > only for listname@domain; not for -owner nor -request, for example).
>
> Mailman should do that if properly configured, no? There must be
> information from the Mailman FAQ (and even tips on the net) on how to
> properly configure Mailman lists to prevent abuse.
It doesn't reject at SMTP-time, but if a list is configured appropriately,
messages not from list members can be automatically accepted, discarded,
rejected with message, or held for moderation. In the latter case, the
moderator can choose to accept, discard or reject. So what happens is
down to how the list server manager and list owner have configured and
operate the list.
Back to the original question, Mailman stores its list memberships in
python pickles, but I suppose you could periodically dump a text file out
of them and consult on a per-list basis at SMTP time before accepting a
message. If the list membership changes rapidly, you'd need to dump out
text file correspondingly. Or I imagine you could interface something to
Exim that will read the pck file directly, but you'd need to be aware that
you are bypassing the mechanisms built into Mailman itself.
Of course all this has the fundamental flaw that authentication to send to
the list is done by sending email address, which of course is trivially
forgeable. Certain members of this list will testify to this, having
suffered the indignity of seeing fraudelent messages 'from' them on the
list.
There are a few other potential mechanisms if you are determined to let
list members be able to post to a list without moderation oversight; a
'secret' list posting address known only to members, a 'secret' list
password which must be used when posting, or each member has their own
'secret' address which they must use to post to the list. None are
implemented widely, probably mostly because it just makes list posting
more tedious, and apart from occasional incidents, we mostly get along
fine without the obstructions.
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks
Computing Officer, IT Services
University Of Strathclyde, Glasgow, UK
