We have a newsletter type list that has been running for almost two years
now. The list currently has 1,100 members who receive one email each
morning. The Bounce Configuration page for this list is configured as
follows: Yes, 5.0, 30, 2, 7, Yes, Yes, Yes which I believe may be the
defaults. The system is running under RedHat V4.



I ran the following command: grep 'score' /var/log/mailman/bounce and
received a list of 28 users that have records containing "(score 5.0 >=
5.0)". I can see one duplicate email address in this list of 28 - most of
the records appear to be unique email addresses. The dates on the records
cover a period of one week.



It appears there are a number of candidates that could have their
subscriptions Disabled and/or Removed from the list. I have been the list
admin for two years now and I have never received an email saying a list
member has been Disabled or Removed. This seems odd based on what I am
seeing in the logs. I do receive emails for bounce messages that fail
detection regularly.



Is it possible to see in a log (or through the online interface) when a user
is placed in Disabled status? I would like to be able to grep this log and
see if anyone is being Disabled or Removed - this may confirm if there is
actually a problem or not. Let's say looking at the logs reveals that list
members are not ever being Disabled or Removed - what is the next step to
debugging this problem?



Thank you in advance for your help! Greg Sims

Search Discussions

  • Mark Sapiro at Sep 30, 2007 at 2:45 am

    Greg Sims wrote:
    We have a newsletter type list that has been running for almost two years
    now. The list currently has 1,100 members who receive one email each
    morning. The Bounce Configuration page for this list is configured as
    follows: Yes, 5.0, 30, 2, 7, Yes, Yes, Yes which I believe may be the
    defaults. The system is running under RedHat V4.

    These may be the mm_cfg.py defaults for ne lists at your site, but the
    Defaults.py defaults are Yes, 5.0, 7, 3, 7, Yes, Yes, Yes, but that
    doesn't really affect the rest of your question.

    I ran the following command: grep 'score' /var/log/mailman/bounce and
    received a list of 28 users that have records containing "(score 5.0 >=
    5.0)". I can see one duplicate email address in this list of 28 - most of
    the records appear to be unique email addresses. The dates on the records
    cover a period of one week.

    Do these entries say "sending listname list probe to: user at example.com
    (score 5.0 >= 5.0)"?

    Is VERP_PROBES = Yes in mm_cfg.py (or is this Mailman 2.1.5 where VERP
    probes was unconditionally on)?

    If so, do you see in the bounce log that a probe was sent but didn't
    bounce? If so, it is likely that your MTA doesn't recognize the '+'
    delimiter to separate the VERP probe token from the local part of an
    address and can't deliver the bounce.


    It appears there are a number of candidates that could have their
    subscriptions Disabled and/or Removed from the list. I have been the list
    admin for two years now and I have never received an email saying a list
    member has been Disabled or Removed. This seems odd based on what I am
    seeing in the logs. I do receive emails for bounce messages that fail
    detection regularly.

    With the settings you have, you should receive disabled notices.

    Is it possible to see in a log (or through the online interface) when a user
    is placed in Disabled status? I would like to be able to grep this log and
    see if anyone is being Disabled or Removed - this may confirm if there is
    actually a problem or not. Let's say looking at the logs reveals that list
    members are not ever being Disabled or Removed - what is the next step to
    debugging this problem?
    'Disabling' entries will appear in the bounce log if members are
    actually disabled.

    bin/list_members --nomail=bybounce listname

    will list all the disabled by bounce members.

    If there aren't any, and I suspect there aren't, I suspect that
    examination of the bounce log will show "sending listname list probe
    to: user at example.com (score 5.0 >= 5.0)" entries, but no "listname:
    user at example.com disabling due to probe bounce received" entries.

    If this is the case, I suspect it is because the MTA does not know how
    to deliver mail addressed to listname-bounces+xxxxxx at listdomain or at
    least doesn't pipe it to the wrapper as it does for mail to
    listname-bounces at listdomain.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Greg Sims at Sep 30, 2007 at 3:30 am
    Mark,

    I believe you have the problem narrowed down. Here are the answers to your
    questions:

    Do these entries say "sending listname list probe to: user at example.com
    (score 5.0 >= 5.0)"?
    Yes
    Is VERP_PROBES = Yes in mm_cfg.py (or is this Mailman 2.1.5 where VERP
    probes was unconditionally on)?
    2.1.5
    If so, do you see in the bounce log that a probe was sent but didn't
    bounce? If so, it is likely that your MTA doesn't recognize the '+'
    delimiter to separate the VERP probe token from the local part of an
    address and can't deliver the bounce.
    I believe so. A score of 5.0 is reached, the probe message is sent
    and the next thing I see is another bounce with a score of 1.0.
    It appears there are a number of candidates that could have their
    subscriptions Disabled and/or Removed from the list. I have been the list
    admin for two years now and I have never received an email saying a list
    member has been Disabled or Removed. This seems odd based on what I am
    seeing in the logs. I do receive emails for bounce messages that fail
    detection regularly.
    'Disabling' entries will appear in the bounce log if members are
    actually disabled.
    There are no Disabling entries in the logs.
    bin/list_members --nomail=bybounce listname
    will list all the disabled by bounce members.
    This command returns null.
    If there aren't any, and I suspect there aren't, I suspect that
    examination of the bounce log will show "sending listname list probe
    to: user at example.com (score 5.0 >= 5.0)" entries, but no "listname:
    user at example.com disabling due to probe bounce received" entries.
    Correct!
    If this is the case, I suspect it is because the MTA does not know how
    to deliver mail addressed to listname-bounces+xxxxxx at listdomain or at
    least doesn't pipe it to the wrapper as it does for mail to
    listname-bounces at listdomain.
    The server is using Qmail. What can I do to fix this problem or work
    around it. Do I need to remove entries from the subscription manually?
    If this is the case, this will need to be automated in some way as it
    will be very time consuming.
    Thanks again for your help Mark! Greg
  • Mark Sapiro at Sep 30, 2007 at 5:13 am

    Greg Sims wrote:
    I believe you have the problem narrowed down. Here are the answers to your
    questions:

    Do these entries say "sending listname list probe to: user at example.com
    (score 5.0 >= 5.0)"?
    Yes
    Is VERP_PROBES = Yes in mm_cfg.py (or is this Mailman 2.1.5 where VERP
    probes was unconditionally on)?
    2.1.5
    If so, do you see in the bounce log that a probe was sent but didn't
    bounce? If so, it is likely that your MTA doesn't recognize the '+'
    delimiter to separate the VERP probe token from the local part of an
    address and can't deliver the bounce.
    I believe so. A score of 5.0 is reached, the probe message is sent
    and the next thing I see is another bounce with a score of 1.0.

    OK. The probes aren't bouncing or the bounced probes aren't delivered
    back to Mailman. It's extremely unlikely that no probes are bouncing,
    so the most likely thing is the probe bounces aren't getting back to
    Mailman.


    <snip>
    The server is using Qmail. What can I do to fix this problem or work
    around it. Do I need to remove entries from the subscription manually?
    If this is the case, this will need to be automated in some way as it
    will be very time consuming.

    There a couple of possibilities. First, I suggest that you verify that
    mail to user+xyz at example.com is not properly delivered to user where
    example.com is your mail domain and user is a valid local address.
    Then we know for sure that this is the problem. Or, you could check
    qmail's logs from the time a probe bounce was sent to see the return
    in the log and what happened to it.

    If possible, you could upgrade to a later than 2.1.5 Mailman version in
    which you can set VERP_PROBES = No in mm_cfg.py to avoid the issue.

    There is some information on qmail at
    <http://www.list.org/mailman-install/qmail-issues.html>. It looks like
    in order to make this recognition work with qmail, you may have to put

    VERP_PROBE_FORMAT = '%(bounces)s-+%(token)s'
    VERP_PROBE_REGEXP = r'^(?P<bounces>.*?)-\+(?P<token>[^@]+)@.*$'

    mm_cfg.py (the install manual talks about VERP_FORMAT and VERP_REGEXP,
    but that is not what we need here). This changes the delimiter from
    '+' to '-+' and changes the recognizer to recognize it. It looks like
    you also need and additional .qmail-$i-bounces-default alias file ($i
    is the list name) for each affected list.

    There may be a way to change qmail's VERP delimiter from '-' to '+'
    which may be enough by itself, but I don't know.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedSep 29, '07 at 7:33p
activeSep 30, '07 at 5:13a
posts4
users2
websitelist.org

2 users in discussion

Greg Sims: 2 posts Mark Sapiro: 2 posts

People

Translate

site design / logo © 2021 Grokbase