Configuration Question: Regarding mailfilter based email addresses
Sorry if the subject is not quite clear, but I have a question on configuring mailman. I set up a list for a group I'm apart of, and one person uses easier to filter on email addresses. I guess I'll jump to the example it'll make sense then
Suppose I had an email: person@world.com
However, for the purpose of mailman-users list I want to register my email as: person+mmusers@world.com person%2Bmmusers@world.com
As we all (or at least most may) know, the +tag format described in RFC3696 (http://tools.ietf.org/html/rfc3696) allows for this format. However mailman, doesn't. Since the "registered" user person+mmusers exists and is all good, when person sends a message to the list it gets bounced.
So my question is: how can I configure mailman to allow person to post when he registered as person+mmusers
Thanks!
Dave
On Tue, Aug 25, 2009 at 08:55:20AM -0400, David Walker wrote:
Since the "registered" user person+mmusers exists and is all good, when person sends a message to the list it gets bounced.
So my question is: how can I configure mailman to allow person to post when he registered as person+mmusers
I'd probably use list_members, diff, awk, and with_list as a cron'd job.
(or list_members > file.new, diff file.new against file: if there are changes; pass the appropriate localpart plus an appropriate wildcard regexp [1]via awk to an outfile, and feed the outfile to with_list assaulting 'accept_these_nonmembers', or if no changes, bail out).
I've not got anything written for that purpose, but it shouldn't take too long to work out a quick script to do that. Saying that "it shouldn't take too long" does assume some knowledge of scripting, and awk, not always the friendliest ways. And, natch, does require the abilitity to run/create cronjobs on the machine where Mailman's installed/accessible to.
An easier option may be to wildcard accept people's domains, but that could be rather pointless, say with non-(personal|vanity|corporate) domains and en-masse email hosting providers (gmail, hotmail, &c)
[1] http://www.mail-archive.com/mailman-users@python.org/msg51929.html may be a good starting point.
``Foot-and-mouth believed to be first virus unable to spread through Microsoft Outlook'' (spoof headline)
On 08/25/09 07:55, David Walker wrote:
However mailman, doesn't. Since the "registered" user person+mmusers exists and is all good, when person sends a message to the list it gets bounced.
So my question is: how can I configure mailman to allow person to post when he registered as person+mmusers
I personally ran in to that very issue a while ago. My (sub-optimal) solution was to subscribe both "person" and "person+mmusers" to the mailing list. I have "person" subscribed, but set to not receive deliveries, for the sole purpose of recognizing when I send emails from "person".
I don't know if it is still the case, but last I messed with this, this was the only trivial solution that I found. Since then I have done it multiple times on multiple different lists and it works out quite well.
Grant. . . .
Grant Taylor wrote:
On 08/25/09 07:55, David Walker wrote:
So my question is: how can I configure mailman to allow person to post when he registered as person+mmusers
I personally ran in to that very issue a while ago. My (sub-optimal) solution was to subscribe both "person" and "person+mmusers" to the mailing list. I have "person" subscribed, but set to not receive deliveries, for the sole purpose of recognizing when I send emails from "person".
I don't know if it is still the case, but last I messed with this, this was the only trivial solution that I found. Since then I have done it multiple times on multiple different lists and it works out quite well.
That is the user based solution. The list admin based solution is to add person@example.com or ^person(\+.*)?@example\.com to accept_these_nonmembers.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 08/25/09 22:57, Mark Sapiro wrote:
That is the user based solution.
Agreed.
The list admin based solution is to add person@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".
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.
Grant. . . .
Grant Taylor wrote:
On 08/25/09 22:57, Mark Sapiro wrote:
The list admin based solution is to add person@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 mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 08/26/09 09:40, Mark Sapiro wrote:
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.
I see examples of the user+detail in RFC 3696, but like you I don't see any reference as to how it is to be interpreted, just that it is allowed.
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.
I can see how you come to that understanding. (Further I don't have any problems with that understanding.)
The only thing that I see (and experience) is that it would be nice if Mailman did something (even if it was non-standard) to support user+detail format addresses. What that /something/ is or should be, I have no idea.
Note that Mailman 3 will make this much easier as it will have a single user record with the ability to specify multiple addresses.
I think this will fill the bill quite nicely.
Grant. . . .
That is the user based solution. The list admin based solution is to add person@example.com or ^person(\+.*)?@example\.com to accept_these_nonmembers.
Thanks Mark. However, as others will probably chime in, this is still a per-user setting. IE I'd need to set a accept_these_nonmembers for everyone who uses the +tag email option. I was thinking that there should be some config option that would (and if i knew python a bit better I may have attacked this)
When mailman checks if this sender is registered, I'm assuming (sorry for the phpesque here): if (in_array($sender, $registered_users))
Well before doing this check, the registered_users array could be walked through foreach($registered_user as &$user) { $user = preg_replace('/(.*)+.*(@.*)/', '/$1$2/', $user); }
-- Dave
David Walker wrote:
Thanks Mark. However, as others will probably chime in, this is still a per-user setting. IE I'd need to set a accept_these_nonmembers for everyone who uses the +tag email option. I was thinking that there should be some config option that would (and if i knew python a bit better I may have attacked this)
When mailman checks if this sender is registered, I'm assuming (sorry for the phpesque here): if (in_array($sender, $registered_users))
Well before doing this check, the registered_users array could be walked through foreach($registered_user as &$user) { $user = preg_replace('/(.*)+.*(@.*)/', '/$1$2/', $user); }
I have already given my opinion on this in another thread, but I note that the above is not really correct. I think it's more complicated than that. It is possible under the RFCs that the addresses part0+part1@example.com and part0+part2@example.com belong to different people.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (4)
-
Adam McGreggor -
David Walker -
Grant Taylor -
Mark Sapiro