Re: MLM subaddress requirement

[John C Klensin <[e-mail]>]

On Wed, 06 Aug 1997 16:27:41 -0400 Keith Moore 
<[e-mail]> 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 [e-mail] if the subscriber address is [e-mail].

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