brian moore wrote: > > On Thu, Dec 21, 2000 at 03:08:15PM -0800, Erik Steffl wrote: > > brian moore wrote: > > > > well, the confusing thing is that the address that I tried to > > unsubscribe by explicitly listing it in the subject (I have the same > > problem) is exactly the same as the one listed as similar. And since I > > explicitly asked for specific address to be unsubscribed I see no reason > > for SmartList to try to figure out what the address is from headers. > > Sure there is. For the simple reason that someone -changed- the defaults > so that your name would not match.
I almost understand what you are saying (here and below) but I would think that it would be a fallback behaviour when EXACT match is not found. I guess that's why I am so puzzled because in my case the EXACTLY EXACT match is found. what defaults can change so that [EMAIL PROTECTED] would not match [EMAIL PROTECTED] > > one way or another, I cannot send email from subscribed address (so > > that all from/reply-to match) and I cannot unsubscribe (not sure if > > there is causal relationship between the two). > > There is. > > Again, this is how it works: SmartList sees a name to remove and looks it > up against the list. It -always- has a certain fuzziness it allows (to > allow for things like capitalization oddities: [EMAIL PROTECTED] and > [EMAIL PROTECTED] are almost certainly the same address and making people > play guessing games to get case right is stupid). > > So it gets your request and goes through the subscriber list to find who > it could be. If there is one match with a value > the 'off_threshold', > which is, by default, 24476, then that address is assumed to be correctly > matched and it is removed. If there is more than one or none, there's a > problem: either the person simply isn't on the list with an address at > all like they're mailing from, or they may need to insert or remove a > hostname to make it closer. > > In the post I responded to, there -was- one and precisely one address > with a 'closeness' of more than 24476. It should have removed that > person happily then.... but it didn't. > > Now, add in a bit more info: it used to work for some people, and then > 'something changed somewhere' and now they can't get off any of the lists > at debian. The only thing that matches that behavior is that someone has > either changed ~list/.bin/unsubscribe and broken it completely or they > have changed the 'match_threshold' values in a misguided effort to 'fix' > something. (The per-list settings are hardlinked to ~list/.etc/rc.init, > so changing the 'master' file will affect all the lists.) > > SmartList is working fine. smartlist as a program (or set of program) probably yes. smartlist as a mailing list system (or as particular installation of smartlist) does not. > It is doing -exactly- what it was supposed to. In this case, it's being > asked to either be so picky about 'exactness' of the match that it isn't > possible ("which is greater, 0.999999.. or 1?" -- ask a mathemetician > and ask a floating point chip.... heck, ask a fpu what '1/3 + 2/3' is, > and it won't be 1) or so loose that damned-near-anything matches, and it > doesn't know who to remove when it could be any of a thousand people. > (The 'do you mean..?' mail only lists the top contenders... it > deliberately does not list all potential matches.) > > The problem is simply that someone has changed these settings and needs > to change them back. still, why is it that exact match does not take priority over all other approximate ones? I haven't thought much about mailservers but generaly the idea is to use deterministic algorithm first, if that fails try heuristics... or is it not exact match? why wouldn't [EMAIL PROTECTED] (that I want to unsubscribe) be an exact match for [EMAIL PROTECTED] (in the list of subscribers)? erik