Grant Taylor wrote: >On 08/25/09 22:57, Mark Sapiro wrote: > >> The list admin based solution is to add per...@example.com or >> ^person(\+.*)?...@example\.com to accept_these_nonmembers. > >I don't know if I would call that a "solution" so much as I would a (per >user) "work around".
Yes, it is a work-around, not a true solution. >I would be much more interested in a per list option as to whether or >not to honor (understand and utilize) user+detail addresses. I would >consider that to be a true solution. The OP says "the +tag format described in RFC3696 (http://tools.ietf.org/html/rfc3696) allows for this format." I don't know if RFC 3696 is the intended reference, but I see nothing in that RFC regarding the semantics of a local part containing a '+' (or a '-' which is sometimes used for the same purpose. Both RFC 2821 and it's successor RFC 5321 say Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address. Thus, I think it is ultimately up to the user to specify what other local parts are equivalent to that of the delivery address, and it is not up to Mailman to guess this. Note that Mailman 3 will make this much easier as it will have a single user record with the ability to specify multiple addresses. -- Mark Sapiro <m...@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
