On Wed, 06 Aug 1997 16:27:41 -0400 Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
...
But if the list is potentially available to anyone just for signing
up, comparing the return-path isn't really an authentication mechanism
-- it's just a crude heuristic to filter out bogons.
There's nothing wrong with refining that heuristic to allow posting
from xxx(_at_)yyy(_dot_)zzz if the subscriber address is
xxx+foo(_at_)yyy(_dot_)zzz(_dot_)
Keith,
This, with which I agree, brings us back to a note I sent Chris
some weeks ago that suggested that some of the issue being
addressed was "too little, too late". While I found his
response was reasonable, the "what is the list manager to do"
question brings me full circle. If I can have
subscribe foo-list [my-address]
(i.e., get a slightly funny address in there without messing
with the From field) then the author of an automated list
manager can presumably extend that to
subscribe foo-list [outbound-address] [inbound-address]
or
subscribe foo-list [outbound-address]
[subaddress-indicator-and-delimiter]
The posting/acceptance engine has to understand either the rule
or a pair of lists in any case, so getting this from the user,
especially if we start automating the subscription process, is
just not a big deal. And this model would permit someone to use
"-", someone else to use "+", a third party to use "=" and,
modulo some understanding about what to do if more than one such
symbol is encountered (an area where a recommendation would be
very useful in avoiding user astonishment), and the rest of us
to get on with our lives.
My local MUA and MTA would probably need to be told too, but
that is presumably a local problem -- they probably know what
they are willing to treat as a subaddress.
There are, of course, authentication problems in any of these
cases. But they aren't much different by case, and the cheap
heuristics, as you point out, don't accomplish much or provide
much protection against anything but a casual slip-up.
While I wish we could do something sensible about subaddresses,
our experience has been that every attempt to relax the rule
that nothing but the destination host is permitted to interpret
or mess with the local-part leads to a "gotcha" somewhere. I
fear the discussion of the last week or so is evidence that we
now have another example.
Recommendation:
(i) We progress a revised version of Chris's note as
a guideline and recommendation, not a standard. You
and IESG figure out how to do that: vote-counting among
captive audiences is silly, since this is one of those
"what you already know is better" situations.
(ii) We try to get a strong "security considerations" statement
into the revision that discusses the interplay between
subaddressing mechanisms and various security UI models.
(iii) We keep it from saying anything that will violate the
"don't mess with the local-part" rule.
(iv) We create a separate document, or a clearly-deliniated
piece of Chris's document, addressed to authors of
automated intermediary systems (e.g., list exploders and
semi-automatic list maintainer software). It should start
from the premiss that people _will_ use these things and
thus give advice about the facilities such systems might
sensibly use to minimize trouble and effort.
Does that make sense and, if so, do we have volunteers to do
some calm writing (as distinct from more flaming, misquotation
and misinterpretation, etc.)? If we believe that this is
important and useful enough to justify the recent traffic level,
then Chris shouldn't have to do all of the writing (although it
is fine with me if he wants to sign up).
john