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