[Mailman-Developers] Re: Todo list questions

[John Viega]

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: 
> 
>  oldmm_utils.AddressesMatch('klm@perl.org', 
> 			    'klm@python.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:
> 
>  oldmm_utils.AddressesMatch('klm@kgb.ukraine.ru',
> 			    'klm@politech.ukraine.ru') => 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 jim.gosling@sun.com, 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
> addresses. 

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
> qualifies.) 

Ah, ok.

> 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.

Ok.

> 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
> it.

Ok.

> 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,
> ay? 

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 :)

John