Right now we have conventions: we have majordomo-style
and listserv-style listname-request addresses or listname-unsubscribe
addresses, but the mailing list world lacks a consistent
machine-readable format for unsubscriptions.
Don't we have that in the mailing list headers? There was a proposal
that added an unsubscribe header some time ago.
List-Archive: <http://www.imc.org/ietf-mxcomp/mail-archive/>
List-Unsubscribe:
<mailto:ietf-mxcomp-request(_at_)imc(_dot_)org?body=unsubscribe>
List-ID: <ietf-mxcomp.imc.org>
The problem here is that most email readers (correctly) do not
fuzz up the user interface with irrelevant header info. So the
headers do little to solve the clueless user problem.
I think that after the core spec is written we should circle back
and do some cleanup. I know the charter says enter FIN_WAIT in
August, but if the group delivers the spec by then I think we
have a pretty good case to recharter using the pinball precedent
(you win, you get to play again).
What concerned me here is that we might end up with a spec that
has no extension sockets and hence be unable to add features in
version 2 that are essential - accreditation is one example. I
think that the conversation with Gordon has persuaded me we might
need a flag to say 'I am a frequent target of impersonation,
interpret the rules for my domain with extreme strictness'.
I don't want to get into the anti-phishing stuff in detail here,
it is an occasion when full disclosure is not the best move.
Suffice it to say that we are anticipating attacks that are
more sophisticated than sending out ten million criminal
solicitations at the same time.
The other concern was that we end up diving into the rat-hole of
fixing the mailing list and forwarding problem when there
are much better ways to address the same problem.
Phill