accept_these_nonmembers @ notation
I have now upgraded to mailman 2.1.14 (to run on suse 11.3 with bundled python 2.6) and it runs nicely.
The help text for accept_these_nonmembers says
Add member addresses one per line; start the line with a ^ character to designate a regular expression match. A line consisting of the @ character followed by a list name specifies another Mailman list in this installation, all of whose member addresses will be accepted for this list.
I succeed (not surprisingly, I tested this already on other installations) using regex. E.g. to allow posting to any list from root of any machine (which is exposed) this works
^root@.+\.lambrate\.inaf\.it
I cannot manage to have the @ notation working though.
I am testing this with two lists, pseudoastro of which I'm the only member, and pseudotecno (with a colleague as member, and me as non member). Ideally I'd want to set up a list as template and then work for all others (we will have some 6 DISJOINCT lists with categories of our staff, we want to be able that members of each can post to any other [and in addition to set up some umbrella lists])
Notation
@pseudoastro @pseudotecno
fails at web level entry (Error: Invalid value for variable: accept_these_nonmembers)
Notation (with a blank between @ and list name) @ pseudoastro @ pseudotecno
gives an entry in the error log
*_these_nonmembers in pseudotecno references non-existent list pseudoastro *_these_nonmembers in pseudotecno references non-existent list pseudotecno
I tried capitalizing the first letter, adding the host and domain, using a notation list_host.domain (according to a posting found on the net), but in all cases I get the "non-existent list" error !!
What's the correct syntax ?
(and by the way ... are those checks to be considered effective as antispam measures ? do they just use the value of the header From field (which can be faked) or use info from the SMTP dialogue ?
--
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
Lucio Chiappetti wrote:
The first syntax without the space after the @ is the correct one. It is being rejected because a list cannot reference itself in *_these_nonmembers. You must put only '@pseudoastro' in accept_these_nonmembers of the pseudotecno list and vice versa.
When you put a space following @, it is accepted with the space as part of the list name, but then the list name is not found during processing of a post and is logged as an error because ' pseudoastro' and ' pseudotecno' are not lists.
[...]
The address used as the sender of the post for this test is determined by the Mailman.Message.get_sender() method. This method searches three places and returns the first address found. The default search order is From: header, then Sender: header, then unix From_ which is the envelope sender. All of these can be easily faked. If USE_ENVELOPE_SENDER (not well named) is set to a true value in mm_cfg.py, the order is changed to Sender: header, then From: header, then unix From_.
If you want to actually prefer the envelope sender (SMTP time MAIL FROM), you'd need to modify the definition of the method in Mailman/Message.py, but there is little point as envelope sender can be faked as easily as From:
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Mon, 11 Apr 2011, Mark Sapiro wrote:
Lucio Chiappetti wrote:
Thanks, I was trying to copy a common configurations for ALL lists from the first one with /usr/lib/mailman/bin/config_list -o and -i, so I thought to include all the lists in accept_these_nonmembers
Now (listing all sibling lists EXCEPT "itself") I can achieve what I want.
I tried this in conjunction with sibling lists as defined in regular_include_lists. Of course in this case I use the full list name pseudoastro@poseidon.lambrate.inaf.it ...
Only I noticed that nesting of sibling lists is not allowed (it does not work as expected).
I created the following cases :
list members siblings accept non members
pseudoa A none pseudot pseudop * pseudot B none pseudoa pseudop * pseudos none pseudoa pseudot pseudoa pseudot pseudop pseudop A+x(,C) none pseudoa pseudot * pseudoi none pseudos pseudop pseudoa pseudot pseudop
The three lists marked with * contain members (in the regime they will contain several members and they will be disjoinct, and there will be six such lists).
The other two lists (no *) are umbrella lists. They have no members but only sibling lists.
All the lists will be closed. Members of all real lists (and only they) can post to any of the lists.
However with the configuration given above, list "pseudoi", which is a 2-level umbrella list (one of the sibling has siblings) does not work. Message sent to it are never dispatched to pseudot.
The SOLUTION is to avoid nesting. "pseudoi" siblings are all three level-0 lists pseudoa pseudot pseudop.
This way it works.
And it is also smart. Originally in pseudop I defined as member myself with a subaddress (A+x). This is not realistic but I did not want to annoy another colleague for the tests.
Mailman is so smart that when sending to pseudoi send just to A,B and C and removes the duplicate to A+x. Great !
While when receiving, a subaddress is honoured (so if I post from e.g. lucio+fakenonmember, this triggers moderation). As it should be !
Maybe part of this information could go in a FAQ.
Lucio Chiappetti wrote:
Only I noticed that nesting of sibling lists is not allowed (it does not work as expected).
The sibling list feature, regular_include_lists and regular_exclude_lists does not work as you expect because it only affects recipients of posts to 'this list'. For example if lista contains listb@... in its regular_include_lists, The recipient list for a post to lista which doesn't also address listb will be augmented by those regular members of listb who aren't members of lista. Since the post is sent only to lista, only lista's regular_*_lists are considered in modifying the recipient list. listb's regular_include_lists is only considered for posts to listb, and not when augmenting the recipient list for a post to lista.
I don't think Mailman did this. Possibly it was the MTA or your MUA that dropped one of the (A, A+x) recipients, but I don't think Mailman will.
I have added a note about only one level of inclusion to the FAQ at <http://wiki.list.org/x/TIA9>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Tue, 12 Apr 2011, Mark Sapiro wrote:
Now all is clear
I have added a note about only one level of inclusion to the FAQ at <http://wiki.list.org/x/TIA9>.
Thanks.
The important thing is that one can make things work as it should creating
umb1 with siblings listA listB umb2 with siblings listA listB listC
this is equivalent to umb2 = umb1 + listC (which won't work). Since the definition is done only once there is no different effort required in setting up things with nesting or with flat one-level arrangement.
The MUA could not have done that since it was unaware of the addresses (they were just list members). I verified (outside of mailman) that it is our MTA (sendmail) which does that, and it does it while sending. Subaddresses are preserved in the header if they were included (true for a "plain" sending, not true for a mailman sending). Since we use the same sendmail.cf on all our machines, this is fine for us.
Lucio Chiappetti wrote:
The first syntax without the space after the @ is the correct one. It is being rejected because a list cannot reference itself in *_these_nonmembers. You must put only '@pseudoastro' in accept_these_nonmembers of the pseudotecno list and vice versa.
When you put a space following @, it is accepted with the space as part of the list name, but then the list name is not found during processing of a post and is logged as an error because ' pseudoastro' and ' pseudotecno' are not lists.
[...]
The address used as the sender of the post for this test is determined by the Mailman.Message.get_sender() method. This method searches three places and returns the first address found. The default search order is From: header, then Sender: header, then unix From_ which is the envelope sender. All of these can be easily faked. If USE_ENVELOPE_SENDER (not well named) is set to a true value in mm_cfg.py, the order is changed to Sender: header, then From: header, then unix From_.
If you want to actually prefer the envelope sender (SMTP time MAIL FROM), you'd need to modify the definition of the method in Mailman/Message.py, but there is little point as envelope sender can be faked as easily as From:
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Mon, 11 Apr 2011, Mark Sapiro wrote:
Lucio Chiappetti wrote:
Thanks, I was trying to copy a common configurations for ALL lists from the first one with /usr/lib/mailman/bin/config_list -o and -i, so I thought to include all the lists in accept_these_nonmembers
Now (listing all sibling lists EXCEPT "itself") I can achieve what I want.
I tried this in conjunction with sibling lists as defined in regular_include_lists. Of course in this case I use the full list name pseudoastro@poseidon.lambrate.inaf.it ...
Only I noticed that nesting of sibling lists is not allowed (it does not work as expected).
I created the following cases :
list members siblings accept non members
pseudoa A none pseudot pseudop * pseudot B none pseudoa pseudop * pseudos none pseudoa pseudot pseudoa pseudot pseudop pseudop A+x(,C) none pseudoa pseudot * pseudoi none pseudos pseudop pseudoa pseudot pseudop
The three lists marked with * contain members (in the regime they will contain several members and they will be disjoinct, and there will be six such lists).
The other two lists (no *) are umbrella lists. They have no members but only sibling lists.
All the lists will be closed. Members of all real lists (and only they) can post to any of the lists.
However with the configuration given above, list "pseudoi", which is a 2-level umbrella list (one of the sibling has siblings) does not work. Message sent to it are never dispatched to pseudot.
The SOLUTION is to avoid nesting. "pseudoi" siblings are all three level-0 lists pseudoa pseudot pseudop.
This way it works.
And it is also smart. Originally in pseudop I defined as member myself with a subaddress (A+x). This is not realistic but I did not want to annoy another colleague for the tests.
Mailman is so smart that when sending to pseudoi send just to A,B and C and removes the duplicate to A+x. Great !
While when receiving, a subaddress is honoured (so if I post from e.g. lucio+fakenonmember, this triggers moderation). As it should be !
Maybe part of this information could go in a FAQ.
Lucio Chiappetti wrote:
Only I noticed that nesting of sibling lists is not allowed (it does not work as expected).
The sibling list feature, regular_include_lists and regular_exclude_lists does not work as you expect because it only affects recipients of posts to 'this list'. For example if lista contains listb@... in its regular_include_lists, The recipient list for a post to lista which doesn't also address listb will be augmented by those regular members of listb who aren't members of lista. Since the post is sent only to lista, only lista's regular_*_lists are considered in modifying the recipient list. listb's regular_include_lists is only considered for posts to listb, and not when augmenting the recipient list for a post to lista.
I don't think Mailman did this. Possibly it was the MTA or your MUA that dropped one of the (A, A+x) recipients, but I don't think Mailman will.
I have added a note about only one level of inclusion to the FAQ at <http://wiki.list.org/x/TIA9>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Tue, 12 Apr 2011, Mark Sapiro wrote:
Now all is clear
I have added a note about only one level of inclusion to the FAQ at <http://wiki.list.org/x/TIA9>.
Thanks.
The important thing is that one can make things work as it should creating
umb1 with siblings listA listB umb2 with siblings listA listB listC
this is equivalent to umb2 = umb1 + listC (which won't work). Since the definition is done only once there is no different effort required in setting up things with nesting or with flat one-level arrangement.
The MUA could not have done that since it was unaware of the addresses (they were just list members). I verified (outside of mailman) that it is our MTA (sendmail) which does that, and it does it while sending. Subaddresses are preserved in the header if they were included (true for a "plain" sending, not true for a mailman sending). Since we use the same sendmail.cf on all our machines, this is fine for us.
participants (2)
-
Lucio Chiappetti -
Mark Sapiro