[Mailman-Developers] Re: Todo list questions
Thu, 7 May 1998 09:52:19 -0700
On Thu, May 07, 1998 at 12:30:54PM -0400, Ken Manheimer wrote:
> It is there, and it does happen to work for that particular example.
> However, it does not accept some that the original did. In particular,
> the original version was much too accepting on one hand:
> 'firstname.lastname@example.org') => 1
That would be a bug, if so. It was intended to *require* the last two
names to match.
> because of the matching ".org". Likewise:
> 'email@example.com') => 1
I never really cosidered that one, but it should be easy to fix :)
> Of course, this is the right thing when we're talking about the top
> level domain. However, it's open for debate whether we want to accept
> common account names on sibling hosts within a local naming authority
> (second level domain, eg 'python.org') as being the same account.
I would say it should be an option defaulting to yes.
> My read of the situation is that matching there might typically be
> correct for small domains (like python.org or cnri.reston.va.us) and
> *not* correct for moderate or large ones (eg, sun.com or reston.va.us or
> ukraine.ru). So i opted for the conservative approach - accept matches
> for domain containment, but not sibling hosts within a domain.
Well, take advantage of the info you know. In foreign addresses,
require 3 matches. In .us addresses, require 4. For sun.com, I would
leave it at two. It's a single company, they tend to have aliases
like firstname.lastname@example.org, which should match @foof.engr.sun.com.
I have never really heard of anyones having big problems w/ majordomo
lists that do this sort of fuzzy matching. I think it makes things a
lot easier on people who forget which machine they were on when they
subscribed, etc... (which I do all the time).
> for, eg, recognizing postings from maillist members - i think we would
> need a mechanism where members explicitly designate alternate posting
I think that's useful no matter what, but not a very high priority.
> > What would a "which" mailcmd do?
> Tell the user all the public maillists of which they are a member. (It
> would also mention that there are private maillist memberships, if any,
> and the command might could take an optional password, which would be
> used to include any of the private maillists which that password
> What we would need to do that is a real subscription confirmation
> mechanism, where a modest random string (a nonce) is sent to the
> delivery address. The user can send back that string from any address,
> proving that they have control over (really, just access to - but that's
> the best we can do, anyway) the delivery address.
Right, that's what I had in mind...
> The problem is that we currently have no infrastructure for tracking
> dispatched nonces - the "confirmation" mechanism is currently stateless,
> which is why i keep putting the "confirmation" in quotes.
> I was interested in doing something like that, but scott cotton seemed
> game to do something like it, so i layed out the situation and he said
> he'd do it (and the membership management stuff). Apparently he has,
> but couldn't offer patches, only an entire new copy of the system
> (including other changes, as well), and i haven't had the time or energy
> to delve into it to unravel the changes. This is what he's been
> referring to the last couple of days, when people bring up these issues,
> when saying he's going to do it when he gets a moment (or two:) to do
> The upshot is that the current requestor-confirms-via-email mechanism
> isn't really a confirmation mechanism, it's a deliver-instructions-for-
> subscribing-via-email mechanism. And it looks like we're getting a real
> confirmation mechanism, soon.
Well, if it's not a confirmation mechanism of some sort, then why was
it added in the first place?
> For example, how about when someone hits reply, cites the entire
> confirmation template, but adds at the top or bottom "What the hell is
> going on, i never asked to subscribe, why did i get sent this?!" It
> would be Not Good (tm) if our mechanism saw the subscription
> confirmation message cited in its entirety and took it as confirmation,
Well, if the title is: REPLY TO CONFIRM YOUR SUBSCRIPTION [SOMECODE#]
Then you would hope people won't make that mistake.
I'm sure some people will nonetheless :)