[Mailman-Developers] Re: Todo list questions

[Ken Manheimer]

[Greets.  The following message comes out of a side discussion with
barry and john, but it contains some substantial explanations of a few
issues that i think will interest at least some others, so i'm cc'ing
the entire list.]

On Wed, 6 May 1998, John Viega wrote:

> I'm looking at merging the TODO lists.  I have questions.
> 
> You say that address matching isn't working, giving the example
> klm@parrot.python.org should match klm@python.org.  I wrote code to do
> that sort of matching, and it used to work great.  Is it not still
> there?  Or does it not work for some functions?  Or what?

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

because of the matching ".org".  Likewise:

 oldmm_utils.AddressesMatch('klm@kgb.ukraine.ru',
			    'klm@politech.ukraine.ru') => 1

This was actually a serious problem - before, people who had the same
login name as someone already on the list, and who happened to have the
same top level domain, were simply refused subscription with a "you're
already subscribed" message.  That (and tracebacks when either of the
arguments was an unqualified login names, eg 'klm' instead of
'klm@python.org') prompted me to make my revisions. 

My new version does the right thing when the account names are the same
and one domain contains the other:

 mm_utils.AddressesMatch('klm@parrot.python.org', 'klm@python.org') => 1

What my version does *not* do is accept sibling hosts in a domain as the
same email addr:

 mm_utils.AddressesMatch('klm@parrot.python.org',
			 'klm@larch.python.org') => 0

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.

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.

I expect there's more to be exploited in the specifics of the addresses. 
Then again, i could make a table of cases with items that have the same
structure and which should be accepted as matches in some cases but not
in others.  So i'm not convinced that this is a sufficient mechanism
for, eg, recognizing postings from maillist members - i think we would
need a mechanism where members explicitly designate alternate posting
addresses.  In any case, we need to think about it more - i think that's
what i said on my todo list entry... 

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

> Isn't the confirmation code already in place?  (BTW, if I haven't said

When 'web_subscribe_requires_confirmation' is set to "Requestor confirms
via email", which is what we're talking about, then a message is sent to
the delivery address the prospective member specified.  That
subscription-confirmation message is really just a subscription template
- instructions for subscribing, with the exact subscription line that
they can just send back to the reply address.  As such, i don't really
consider it a confirmation mechanism, really it's just a customized
(with the users selected password) template for email subscription.

This is fine when the desired delivery address is the same as the
address the user would be sending the "confirmation".  Where it breaks
down is when the user's delivery address is different than the address
from which they send their "confirmation" (subscription).  If we allowed
a user to subscribe for delivery to an arbitrary address, then we're
fucked - mischief makers can wreak havoc.  That's why we don't.

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.

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

This nice thing is, the specific goal scott and i initially discussed
was alternate-address subscription confirmation, where a user could
subscribe to a delivery address (eg, klm@acm.org) from a different
address (eg, klm@python.org).  I expect this will be useful for this
other issue i was talking about yesterday, enlistment of redistribution
addresses.  The only problem is that it requires the delivery address to
receive the nonce, and some redistribution addresses may already be
active and populated, which would require the redistribution
administrator to either intercept the confirmation request, or just let
it go to their redistribution audience.  Oh well.

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.

> it yet, the confirmation mechanism needs to be a LOT easier to use.
> All you should have to do is hit reply.  Novices aren't going to get
> it to work the way it currently is.)

Yes, you did mention this, and my understanding of that is that the user
should be able to just hit reply and send the resulting message.  (This
will apply equally for a real, nonce-based confirmation mechanism.) 
This should be fairly easy to do, i just haven't yet wanted to spend
time thinking about how to identify significant pitfalls, and avoid
them.  There are some.

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? 

You-thought-you-were-asking-simple-questions-ay'ly yers,

Ken