ietf-asrg
[Top] [All Lists]

Re: [Asrg] Lets Fix Mailing Lists

2003-03-08 18:19:10
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>

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

  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.

  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.

  4a  Delays introduced by anti-spam moderation
  4b  Time taken to do anti-spam moderation
  4c  Time spent reading idiotic posts from 'Prof' Bernstein 
      complaining that the anti-spam filtering is censorship.

The first two may have something to do with the IESG.  The entire IETF
including IAB and IESG has working on the more general case of 4c for
at leaset 10 years.  See http://www.google.com/search?q=tap+ident+Bernstein

  5   Spam on mailing lists

In general, if you can stop spam to individual mailboxes, you can stop
it to mailing lists.  I think defenses such as the DCC and Pyzor/Razor are
particularly well suited for mailing lists, since bulk mail sent to
mailing lists is almost always spam.

  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.

  7   Unsubscribe that does not work (often due to burster lists)

Those are bugs, often in the very existence of the burster.

  8   Web archives that only show an index of 20 messages at a time
      so you have to backspace through 15 pages when catching up.
      [OK its only the IETF that configures MonHarc this stupid way]

That's high on my list, but it's the domain of the IESG not the IRTF.

  9   Maintenance messages that get sent to the list complaining about
      the above.

 10   Having the messages from a list get trapped in some dozy
      spam filter.

yes.

...
A header that identified mail as comming from a mailing list
would help a lot here. There have been proposals, but how do 
we get to DEPLOYMENT???

RFC 2369 is more than merely a proposal.

On the spam issue what we need is a means of communicating 
consent from the MUA to MTAs in the path. This can be done 
efficiently using either symmetric cryptography or public
key.

Cryptography might be a part of implementing that, but it's not
the whole thing.  Neither confidentiality, authentication, nor
non-repudiation are the same as authorization.   "Consent" sounds
more like authorization than the other crypto stuff.


If we are using a symmetric scheme Alice generates a key and
sends the symmetric key to her receiving MTA. if we are using
a public key scheme Alice probably has her key already, 
the MTA can pull the public key from her XKMS service.

To subscribe to a list Alice goes to the 'subscribe to list'
option in the tools menu of her client. This generates a
subscription blob that contains Alice's email address, the
address of the list [possibly including a wildcard], date
and is signed with Alice's key. We might want to use DSA 
for this for compactness. 

The subscription blob is sent to the mailing list server 
manager. If the mailing list is compliant then it will 
subscribe Alice immediately.

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.

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.

The crypto stuff that is needed is not from Alice to the mailing list,
but only something that authenticates the mailing list so that Alice's
MTA or MUA can authorize its mail.


Vernon Schryver    vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg