[Mailman-Developers] Change to acceptable_aliases

Barry Warsaw bwarsaw@python.org
Tue, 11 Apr 2000 14:51:31 -0400 (EDT)


Hi folks,

I want to make a change to the semantics for the privacy option
`acceptable_aliases' for beta 3.  Harald recently (and rightfully)
backed out a change I'd made between 1.1 and 2.0b1, which caused me to
re-examine how this option is used.

The purpose of acceptable_aliases is to be able to specify a list of
aliases for your mailing list that are acceptable as recipients if
require_explicit_destination is set to true (which it is by default).
The example I like to use is if I have a mailing list

    foo@python.org

I might want to allow `foofriends@alterpost.com' to be a valid
forwarder to the mailing list.

The trouble comes in that the regexps in acceptable_aliases are only
matched against the localpart of the recipient address.  This means
that if I were to put `foofriends@alterpost.com' in this field, it
would actually fail to match a To: header with this address in it.
I'd instead have to put `foofriends' in this field, but then this
would allow `foofriends@evil.com' to post to the list too without
trigger the spam detector.

My proposal is to change the semantics of acceptable_aliases, so that
matching is done against the entire recipient address, not just the
localpart.  To support backwards compatibility, I'm willing to use the
following rules for 2.0:

1) if the regexp does not contain an `@', then match only against the
   localpart as before.

2) if the regexp contains an `@', match against the entire recip
   address.

3) deprecate #1 so that a future release will only match against the
   entire address.

Thoughts?  Is anybody using acceptable_aliases?

-Barry