ietf-asrg
[Top] [All Lists]

[Asrg] Lets Fix Mailing Lists

2003-03-08 17:44:50
Lets face it the management of mailing lists is a mess. A member of the IESG
told me that this is because the mailing lists and mail MUAs don't adhere to
the specs. An employee of a company that writes one of the most widely used
MTAs gave a reply that to use the J.K.Rowling technique would go
'horsepuckey, indecipherable, impractical, arrogant, not suprised'.

I think that we need to address mailing lists as a special case for action.
In particular it should be possible to communicate to MTAs in the
communication path the fact that a user has opted in to the list.

One reason for this is that if my mailer could detect mail from mailing
lists reliably I could then ditch the 50% of the spam I get that is not
addressed to me at all. [Yes I know that they would adapt, but their current
behaviour has a purpose and I want to block that purpose].


If we are going to get the mail infrastructure sorted out for the sake of
stopping spam we might as well sort out a bunch of the other pathologies it
currently suffers from if the cost is low. I believe that the way we will
eventually end up propagating whatever changes are required will be through
some form of branding, whether it be 'RFC6388 Compliant' or 'JamSpam
Compliant' or whatever.


My pet mailing list peves:

  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

  2   Out of office responses getting sent to list members

  3   I have to tell the mail client to create a folder for each list

  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.

  5   Spam on mailing lists

  6   Opt-in verification to prove its me when my original request
        had a digital signature and cert.

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

  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]

  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.

Lots of these are synchronization problems. There is one basic 
behavior that people expect from mailing lists. However the 
clients and mailing lists have slightly different configurations,
work arrounds etc. that causes chaos.

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


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.

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.


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.

                Phill
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>