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.netThe highway is for gamblers,
San Francisco Bay Area, Californiabetter 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