[Mailman-Users] Spam backscatter: Which aliases to remove

Rich Kulawiec rsk at gsp.org
Wed Mar 19 22:56:16 CET 2008


On Mon, Mar 17, 2008 at 07:10:30PM -0700, Kenneth Porter wrote:
> Ok, thanks. It sounds like I can safely prune admin, subscribe, 
> unsubscribe, join, and leave. That leaves bounces, confirm, owner, and 
> request, which I can tolerate dealing with manually.

I certainly agree with keeping -request, especially because
of RFC 2142 Section 6:

	Mailing lists have an administrative mailbox name to which add/drop
	requests and other meta-queries can be sent.

	For a mailing list whose submission mailbox name is:

		<LIST at DOMAIN>

	there MUST be the administrative mailbox name:

		<LIST-REQUEST at DOMAIN>

	Distribution List management software, such as MajorDomo and
	Listserv, also have a single mailbox name associated with the
	software on that system -- usually the name of the software -- rather
	than a particular list on that system.  Use of such mailbox names
	requires participants to know the type of list software employed at
	the site.  This is problematic.  Consequently:

		LIST-SPECIFIC (-REQUEST) MAILBOX NAMES ARE REQUIRED,
		INDEPENDENT OF THE AVAILABILITY OF GENERIC LIST SOFTWARE
		MAILBOX NAMES.


RFC 1211 discusses the use of "owner" -- except that it's owner-list,
not list-owner.  I've seen both used over the years, and tend to favor
the latter as it keeps the list name first, which is handy when
searching or sorting alias or virtusertable files.  I think it's
also less confusing to users: my experience has been that just
getting the -request convention firmly established can often take
considerable effort, so it seems to me that if we get that far,
then keeping the form consistent is a win.

There's been all kinds of discussion on this point, some of which
has to do with the vagaries of particular MTAs or MLM programs
(like majordomo) and some of which has to do with the nuances of
how people are running their lists.  If we ever get around to
updating RFC 2142, I think I'd like to argue for including the
trailing -owner form instead of the leading owner- form.

What I do locally: list-owner is fed to mailman just like -request
or anything else.  Inside mailman, I use "owner-list" as the value
of the relevant field.  Then I have an alias owner-list which actually
expands to the list of people who run the list.  This lets me
change that list of people without getting into the mailman config:
it's just an alias update.  It also lets me send messages directly
to those people (via owner-list) without routing them through mailman.
And it means that something reasonable will probably happen to incoming
mail from outside addressed to owner-list or list-owner.

Summarizing that last paragraph of unintelligble gibberish:

	Inside mailman:

	the foo-list owner field value is "owner-foo".

	In the aliases file:

	foo-owner:	"|/usr/local/mailman/mail/mailman owner foo"
	owner-foo:	bozo at example.com, clown at example.com

so the last entry is the only thing that needs to be touched if
the keepers of the list change.


While I'm blabbing about this, I'd like to float another idea
related to RFC 2142.  We have postmaster (mail), webmaster (web)
and quite often hostmaster (DNS).  How about listmaster, which
would expand to "the person or persons responsible for the overall
care and feeding of mailing lists associated with this domain"?

Why have such as thing?  Because there are many sites (like one
that I run) where the keeper of the mail system, mailman, and
everything else isn't one of the people responsible for any lists,
and vice versa.  So asking a random list-owner, or even asking
all list-owners, to effect a site-side change doesn't work because
none of them can do it.  Hence...the listmaster, who *can* do it
and is thus the right person to be contacting.   Thoughts?

(...produces pocket-watch, swings it slowly...yes...yesssss...you
are all concurring that it is positively the most brilliant thing
you have ever read...goooood...sleeeeeeep now...)

---Rsk


More information about the Mailman-Users mailing list