FAQ
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 at .+\.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
------------------------------------------------------------------------

Search Discussions

  • Mark Sapiro at Apr 11, 2011 at 7:30 pm

    Lucio Chiappetti wrote:
    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 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

    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.


    [...]
    (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 ?

    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 at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Lucio Chiappetti at Apr 12, 2011 at 10:15 am

    On Mon, 11 Apr 2011, Mark Sapiro wrote:
    Lucio Chiappetti wrote:
    The help text for accept_these_nonmembers says
    [...]
    I cannot manage to have the @ notation working though.
    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.
    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 at 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.
  • Mark Sapiro at Apr 12, 2011 at 6:06 pm

    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 at ... 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 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 !

    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.

    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.

    I have added a note about only one level of inclusion to the FAQ at
    <http://wiki.list.org/x/TIA9>.

    --
    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Lucio Chiappetti at Apr 13, 2011 at 9:09 am

    On Tue, 12 Apr 2011, Mark Sapiro wrote:
    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'.
    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.
    Mailman is so smart that when sending to pseudoi send just to A,B and C
    and removes the duplicate to A+x. Great !
    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.
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedApr 11, '11 at 4:07p
activeApr 13, '11 at 9:09a
posts5
users2
websitelist.org

2 users in discussion

Lucio Chiappetti: 3 posts Mark Sapiro: 2 posts

People

Translate

site design / logo © 2021 Grokbase