...
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg