Re: MLM subaddress requirement

[Chris Newman <[e-mail]>]

On Tue, 5 Aug 1997 [e-mail] wrote:
> > (3) Ignoring subaddresses for the purpose of permitting postings.
> 
> This doesn't work.  Remember - the MLM *CAN NOT TELL* whether a piece
> of mail from '[e-mail]' is from a subaddress-aware site or if
> it's just from a site that has some OTHER meaning for '+'.  As such,
> if you "ignore", and the list is closed, you just allowed '[e-mail]'
> to improperly post/subscribe/etc to the list.

What is the purpose of restricting postings based on the envelope address?
It's obviously *not* a security issue as anyone can generate email from
any address trivially (own a copy of Netscape?).  I claim the primary
purpose is to reduce spam.  Permitting postings from user if user+foo is
subscribed has no impact on this primary purpose.

In the case of a signature verifying list, there has to be some way to
register a PGP key to use with the list.  The way to meet the
interoperability requirement is simply to allow the address in the
registered PGP key (used for posting & control) to be different from the
subscription address.  This is not particularly cumbersome or painful
given the key has to be registered anyway.

> Yes.  If the remote system is unable to tell if an optional feature is in
> use, it *MUST* assume that the feature is *NOT* present.  Blindly saying
> "This is SO $%(*^$% neat that I'll assume the world does it TOO" is just
> a good way to screw the users to the wall.

What negative impact does the loosened form of the requirement have?

I've actually been thinking about a feature negotiation for email
mechanism (e.g. a simple way to say "don't send me s/mime gunk or 
text/html but I like UTF-8"), but such a mechanism needs to be used
sparingly and I just don't think subaddresses merit this level of
complexity.

The fact is, subaddresses _mostly_ work today.  I had to switch a compile
time option to allow editing of the from address in my MUA.  Every final
delivery agent I've used supports them.  And only one mailing list I'm on
currently (IETF-TLS) doesn't meet this revised MLM requirement from what I
can tell.

		- Chris