[Mailman-Users] SMART_ADDRESS_MATCH isn't very

[Bob Weissman]

At 01:54 PM 7/15/02, Jerry Stratton wrote:
>>I have a user subscribed as name at eng.sun.com who just posted to a
>>members-only list as name at sun.com. (Because of Sun's email setup,
>>this is out of the user's control.) The posting failed to go through
>>even though SMART_ADDRESS_MATCH was set to 1.
>>
>>Has anyone else hit this problem and found a fix? It seems like it
>>must be a logic error in Utils.FindMatchingAddresses(), but it's not
>>obvious to me where the problem is.
>
>I think we have, and I think the solution was that mailman assumes it has the canonical e-mail address and searches for that domain within the domain of incoming mail. So, if your user was subscribed as name at sun.com, attempts to e-mail from name at eng.sun.com would work, because eng.sun.com contains sun.com. But sun.com does not contain eng.sun.com, so posting as sun.com when subscribed as eng.sun.com does not work.
>
>There is probably some logic to this, as it is not unreasonable to posit a site where multiple subdomains are unrelated. (i.e., name at eng.sun.com and name at mktg@sun.com have their own namespaces). Mailman appears to be assuming that the subscription address is the most general possible, and only more specific addresses will match with SMART_ADDRESS_MATCH turned on.
>
>Anyway, our solution was to resubscribe the user with their "real" address, and I have not heard from that list manager since on that subject.

Yes, I believe your analysis is correct. You can see the logic (or lack thereof? :-) in Utils.GetPossibleMatchingAddrs().

Thanks. I've changed the user's address on the list and it should work now.

For the curious, engineering folks at Sun Microsystems appear at eng.sun.com when at the office, and at sun.com when working from home. So they can't really help it.

- Bob