Subject: RE: [Asrg] Lets Fix Mailing Lists

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 8 Mar 2003 19:21:21 -0800

> > ...
> >   1   Reply to sends the reply to the original author, not 
> > 	the mailing list. Reply to all sends the reply to the 
> > 	mailing list and to all prior authors, creating a shadow 
> > 	mailing list
> 
> Those are bugs and errors by users. 
> There's nothing the IETF can or should do about it.

No it is a user interface problem that is cause by an inadequate
specification. The IETF should stop sticking its head in the sand 
when these issues come up.

> >   2   Out of office responses getting sent to list members
> 
> Even worse is when out-of-office responses go to the list.
> But both are well known bugs that the responsible parties refuse
> to acknowledge or fix.

The responsible parties including the IETF. 

> >   3   I have to tell the mail client to create a folder for 
> each list
> 
> "Folders" are features of MTAs beyond the appropriate 
> influence of the IETF
> (or IRTF).  Just as the IETF doesn't presume to talk about 
> GUIs, window
> managers, and other stuff, it shouldn't talk about MTA user interface 
> features or bugs.

Should have the information in the protocol to allow the
user interface to do its job properly.

> >   6   Opt-in verification to prove its me when my original request
> > 	had a digital signature and cert.
> 
> That's mistaken.  Signatures and certs may prove (for various notions
> of "prove"; recall the Microsoft cert saga) that you are you, but they
> do not necessarily bind you to any particular RFC 2821 mailbox.  Your
> cert may authenticate you, but it does not by itself authorize you to
> subscribe a mailbox to a mailing list.  Outside Redmond and its
> colonies, authentication differs from authorization.

DNS Linked PKI addresses that problem, the owner of the DNS zone
can specify what certificates they consider to be valid for the zone.

As for the authorization thing, it is exactly the same as with existing
mail opt-in, if you can read mail to the account you can subscribe it
to a mailing list.

> RFC 2369 is more than merely a proposal.

How much effort went into getting the software vendor community to
buy into it?

> > The mailing lists stores Alice's subscription blob along 
> > with each message and sends it out with each mailing. This
> > allows Alice's MTA (and if public key is used all the 
> > intervening MTAs) to determine that the message was solicited.
> 
> Where's the connection between Alice's key and the email address
> she subscribed?  Again, authentication is not the same as 
> authorization.

In the public key case check the digital signature, use XKMS or 
other mechanism of your choice to verify the key.

> > Legacy mailing lists can also be supported with a bit of 
> > intelligence on the part of the subscriber's MTA. 
> >
> > Basically it records the fact that Alice has subscribed 
> > and then records the fact she is subscribed locally.
> > It can also process the opt-in callback loop for her.
> 
> If you can teach MTA's to recognize mailing lists enough to do that,
> then you do not need to send any keys, blobs, or other crypto stuff
> to any mailing list.

Only if you can count on always going through the same MTA and
that there is only one MTA in your receving path. Some of us
have a lot of MTAs...

		Phill 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 8 Mar 2003 20:50:18 -0700 (MST)

> From: "Hallam-Baker, Phillip" <[email-masked]>

> mail opt-in, if you can read mail to the account you can subscribe it

Then why did you mention "digital signature and cert"?  Certs, DNS
linked PKI, owners of DNS zones and so forth are all fine and dandy
when you need them but why do you need them to authorize a stream of
mail from a mailing list to a mailbox?  They're irrelevant to
authorization based on replying to a confirmation request recieved by
the subscribing mailbox.  The only relevance I can see of any sort of
crypto in the subscription process is confidentiality using STMP-TLS,
PGP, SMIME or the like on the mail stream, but that's is not particular
to the subscription process.

I'd also like to see encryption used far more often, but I don't
pump for it when it's irrelevant.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg