[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