From mark at msapiro.net  Mon Jul  1 01:38:25 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 30 Jun 2013 16:38:25 -0700
Subject: [Mailman-Users] Privacy Options Filtering
In-Reply-To: <14EF8E75-B00E-466F-AEA3-786B5438FD8E@norwitz.net>
References: <F6EC2488-52F2-4352-AE65-BED5935B2B3F@norwitz.net>
	<633AA8E8-6C17-4027-A566-7D45A5900D7C@norwitz.net>
	<51AD2E30.8030606@msapiro.net>
	<14EF8E75-B00E-466F-AEA3-786B5438FD8E@norwitz.net>
Message-ID: <51D0C171.3070806@msapiro.net>

On 06/30/2013 12:51 PM, Cyndi Norwitz wrote:
> 
> On Jun 3, 2013, at 5:00 PM, Mark Sapiro wrote:
> 
>> On 06/03/2013 03:21 PM, Cyndi Norwitz wrote:

>>> 2) To add a domain name to the list, you have to use a regular expression in this form:
>>> ^[^@]+@(.*\.)?domain\.com$  (or use net, info, etc).
>>> In other words, the only way to actually know that is to be a programmer or to ask on this list and save it for years, as I did.
>>
>>
>> Your regexp is a bit more complicated than it needs to be.
> 
> LOL!  
> 
> Well maybe it is but YOU are the one who told me to use it.  Years ago.  (or possibly someone else on a thread that you contributed to as well)


I'm sure I did, but I learn things over time too.


>> This is equivalent.
>>
>> ^.*[@.]domain\.com$
> 
> Since I just cut and paste the relevant parts, I'm not sure it matters.


It matters in that people looking at the first form say "this is so
complicated I'll never understand it" whereas they can look at the
second and say "Oh yeah, I get that"



>> That's my inclination for the fix. I.e. don't add the address to the
>> filter and say why, but what else should or shouldn't be done. E.g.
>> suppose this is one address out of 5 to be added from 5 posts. Do we
>> abort the whole transaction, do everything else anyway or something in
>> between.
> 
> Ideally it would accept the good addresses and reject the bad one and say which address was rejected and why.  But I would accept a total rejection as a solution if the former one was too much of a PITA to implement.  Even though it might mean repeating a couple minutes worth of work.  One note: the page allows you to discard an attempted post without putting the return address into a filter.  If I don't check a filter button when I discard a message, the message will simply disappear when i save the changes.  My concern is that I might lose the opportunity to add good addresses to the filter if the entire set is rejected.  I typically have 20-30 spam posts when I go through moderation (once a week or so since almost everyone on the mailing list is unmoderated (only newbies and a couple select individuals are on moderation)).
> 
> Another in-between solution might be to reject the "save changes" because there is an error but not partially process the messages or reset the button settings.  Ideally it would say what the error was.  This might be harder to program than the other ways, I don't really know.  My preference would be not to lose my work, however that manifests itself.  But whatever it takes to keep bad addresses out of the filter, that's the most important part.


The bug report is at <https://launchpad.net/bugs/1187201>. The actual
commited fix is at
<http://bazaar.launchpad.net/~mailman-coders/mailman/2.1/revision/1390>.

I believe the fix addresses all your concerns. What it does is run each
address to be added to a *_these_nonmembers filter or the ban_list
through Mailman's ValidateEmail() function (a check on form, not actual
deliverability; the same check the web UI uses) and it simply reports
each bad address as bad and does everything as though the bad addresses
weren't selected to be added to a filter or the ban_list.

The reporting can report the same address multiple times as it is
reported for each checked box that references it.

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

From cnulk at scu.edu  Mon Jul  1 19:24:20 2013
From: cnulk at scu.edu (Chris Nulk)
Date: Mon, 01 Jul 2013 10:24:20 -0700
Subject: [Mailman-Users] Writing a custom handler
Message-ID: <51D1BB44.2060000@scu.edu>

Hello user,

I am writing a custom handler to globally ban email address from sending 
messages sent to Mailman.  I know I can use Mark's add_banned.py script 
to add an address to all lists.  However, if I add an address to be 
banned, as the administrator for all lists, I don't want a list admin to 
remove a pest from their list(s).  I banned an address for being a pest 
to all lists (or a majority of them), therefore, the address stays banned.

Before I put the custom handler in place and screw up my lists, I 
thought I would post it here so others more knowledgeable can review it 
and let me know if it will work, correct it, and/or improve it.

Thanks,
Chris

--------------------------- Custom Handler Below 
-------------------------------

#!/usr/bin/env python
#

"""This is a custom handler that will check all the sender addresses of
a message against a global ban list.  If any of the sender addresses are
on the global ban list, the message will get logged and discarded.
"""

import sys

from Mailman import mm_cfg
from Mailman import Utils
from Mailman import Message
from Mailman import Errors
from Mailman.i18n import _
from Mailman.Logging.Syslog import syslog
from Mailman.MailList import MailList

def process(mlist, msg, msgdata):
     # added because it was in Mailman/Handlers/Moderate.py
     #   I am guessing it has to due in part with an upstream
     #   pipeline handler marking the message approved and/or
     #   because the handler can be moved to different parts
     #   of the pipeline.
     #   But, I have been wrong before.
     if msgdata.get('approved') or msgdata.get('fromusenet'):
         return

     # First, initialize the banlist
     banlist = []

     # Read in the global ban list of email addresses
     #  mm_cfg.GLOBALBANLIST_FILENAME is defined in mm_cfg and should
     #  be the full path to the file.
     try:
         with open(mm_cfg.GLOBALBANLIST_FILENAME) as f:
             for addr in f:
                 banlist.append(addr.lower().strip())
     except IOError:
         # cannot open the global ban list for whatever reason
         # log it and continue with the next pipeline handler
         syslog('error', 'An error occurred opening the global ban list')
         return
     except:
         # unspecified error
         # log it and continue with the next pipeline handler
         syslog('error', "ERROR: Unknown error: ", sys.exc_info()[0])
         return

     # Go through possible senders.  Check if any of them are
     #   on the global ban list
     for sender in msg.get_senders():
         if sender.lower() in banlist:
             break
     else:
         # None of the sender addresses were in the global ban
         #   list so return and continue with the next pipeline
         #   handler
         return

     # A sender was found on the global ban list.  Log it and
     #   discard the message notifying the list owner
     if sender:
         # Log banned sender to the vette log
         syslog('vette', '%s is banned by the global ban list', sender)
         # Perform message discard
         do_discard_globalban(mlist, msg)
     else:
         assert 0, 'Bad sender in GlobalBan.py'


# copied almost verbatim from Mailman/Handlers/Moderate.py
def do_discard_globalban(mlist, msg):
     sender = msg.get_sender
     # forward auto-discards to list owners?
     if mlist.forward_auto_discards:
         lang = mlist.preferred_language
         # is varhelp used anywhere?
         varhelp = '%s/?VARHELP=privacy/sender/discard_these_nonmembers' % \
                   mlist.GetScriptURL('admin', absolute=1)
         nmsg = Message.UserNotification(mlist.GetOwnerEmail(),
                                         mlist.GetBouncesEmail(),
                                         _('Global Ban List Auto-discard 
notification'),
                                         lang=lang)
         nmsg.set_type('multipart/mixed')
         text = MIMEText(Utils.wrap(_("""\
The sender of the attached message is on the Global Ban list. Therefore, 
the message
has been automatically discarded.""")),
                         _charset=Utils.GetCharSet(lang))
         nmsg.attach(text)
         nmsg.attach(MIMEMessage(msg))
         nmsg.send(mlist)
     # Discard the message
     raise Errors.DiscardMessage


From mark at msapiro.net  Tue Jul  2 00:35:34 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 01 Jul 2013 15:35:34 -0700
Subject: [Mailman-Users] Writing a custom handler
In-Reply-To: <51D1BB44.2060000@scu.edu>
References: <51D1BB44.2060000@scu.edu>
Message-ID: <51D20436.4050300@msapiro.net>

On 7/1/2013 10:24 AM, Chris Nulk wrote:
> Hello user,
> 
> I am writing a custom handler to globally ban email address from sending
> messages sent to Mailman.  I know I can use Mark's add_banned.py script
> to add an address to all lists.  However, if I add an address to be
> banned, as the administrator for all lists, I don't want a list admin to
> remove a pest from their list(s).  I banned an address for being a pest
> to all lists (or a majority of them), therefore, the address stays banned.


Note that the ban_list only prevents the address from subscribing. If
the address was already a member when banned, it can still post.


> Before I put the custom handler in place and screw up my lists, I
> thought I would post it here so others more knowledgeable can review it
> and let me know if it will work, correct it, and/or improve it.
> 
> #!/usr/bin/env python
> #
> 
> """This is a custom handler that will check all the sender addresses of
> a message against a global ban list.  If any of the sender addresses are
> on the global ban list, the message will get logged and discarded.
> """
> 
> import sys
> 
> from Mailman import mm_cfg
> from Mailman import Utils
> from Mailman import Message
> from Mailman import Errors
> from Mailman.i18n import _
> from Mailman.Logging.Syslog import syslog
> from Mailman.MailList import MailList


You don't actually use MailList so there's no need to import it. Also
Utils, Message, Errors and _ are used only by the discard code you
copied. You could instead just

>From Mailman.Handlers.Moderate import do_discard

and use that if it wasn't important to have specific messages. OTOH, see
below.


> 
> def process(mlist, msg, msgdata):
>     # added because it was in Mailman/Handlers/Moderate.py
>     #   I am guessing it has to due in part with an upstream
>     #   pipeline handler marking the message approved and/or
>     #   because the handler can be moved to different parts
>     #   of the pipeline.
>     #   But, I have been wrong before.
>     if msgdata.get('approved') or msgdata.get('fromusenet'):
>         return


There are two things in the above. The test for 'approved' says if this
message was pre-approved by inclusion of an Approved: <list_pw> header
or pseudo-header, or if this message was held for moderation by a prior
handler and approved by the moderator, then skip this handler.

The test for 'fromusenet' says if this post arrived via the
Mail<->Usenet gateway, then skip this handler.

You probably don't want the " or msgdata.get('fromusenet')" part even if
you are gating from usenet.

> 
>     # First, initialize the banlist
>     banlist = []
> 
>     # Read in the global ban list of email addresses
>     #  mm_cfg.GLOBALBANLIST_FILENAME is defined in mm_cfg and should
>     #  be the full path to the file.
>     try:
>         with open(mm_cfg.GLOBALBANLIST_FILENAME) as f:
>             for addr in f:
>                 banlist.append(addr.lower().strip())
>     except IOError:
>         # cannot open the global ban list for whatever reason
>         # log it and continue with the next pipeline handler
>         syslog('error', 'An error occurred opening the global ban list')


I would put something like

    except IOError, e:
        syslog('error',
               "Can't open %s: %s" % (mm_cfg.GLOBALBANLIST_FILENAME, e)
              )


>         return
>     except:
>         # unspecified error
>         # log it and continue with the next pipeline handler
>         syslog('error', "ERROR: Unknown error: ", sys.exc_info()[0])


and here I would put

        syslog('error',
               'ERROR: %s: %s' % (sys.exc_info()[0], sys.exc_info()[1])
              )


>         return
> 
>     # Go through possible senders.  Check if any of them are
>     #   on the global ban list
>     for sender in msg.get_senders():
>         if sender.lower() in banlist:
>             break
>     else:
>         # None of the sender addresses were in the global ban
>         #   list so return and continue with the next pipeline
>         #   handler
>         return
> 
>     # A sender was found on the global ban list.  Log it and
>     #   discard the message notifying the list owner
>     if sender:


How can this be False?


>         # Log banned sender to the vette log
>         syslog('vette', '%s is banned by the global ban list', sender)
>         # Perform message discard
>         do_discard_globalban(mlist, msg)


You could just import do_discard from Mailman.Handlers.Moderate and use
that, but you may want the custom messages. If so, you may also want

        do_discard_globalban(mlist, msg, sender)


>     else:
>         assert 0, 'Bad sender in GlobalBan.py'
> 
> 
> # copied almost verbatim from Mailman/Handlers/Moderate.py
> def do_discard_globalban(mlist, msg):
>     sender = msg.get_sender


Actually, that should be

    sender = msg.get_sender()

but as I indicate above it would be better to pass the bad sender in the
call because msg.get_senders() returns a list of sender addresses and
msg.get_sender() returns a single address which may not be the
get_senders() address you found in your blacklist.


>     # forward auto-discards to list owners?
>     if mlist.forward_auto_discards:
>         lang = mlist.preferred_language
>         # is varhelp used anywhere?
>         varhelp = '%s/?VARHELP=privacy/sender/discard_these_nonmembers' % \
>                   mlist.GetScriptURL('admin', absolute=1)


It is the URL to the web admin (Details for discard_these_nonmembers)
page. Someone intended to include it in the auto-discard notice but
either never did or at some point it was dropped without removing the
above. It is currently superfluous.


>         nmsg = Message.UserNotification(mlist.GetOwnerEmail(),
>                                         mlist.GetBouncesEmail(),
>                                         _('Global Ban List Auto-discard
> notification'),
>                                         lang=lang)
>         nmsg.set_type('multipart/mixed')
>         text = MIMEText(Utils.wrap(_("""\
> The sender of the attached message is on the Global Ban list. Therefore,
> the message
> has been automatically discarded.""")),
>                         _charset=Utils.GetCharSet(lang))
>         nmsg.attach(text)
>         nmsg.attach(MIMEMessage(msg))
>         nmsg.send(mlist)
>     # Discard the message
>     raise Errors.DiscardMessage

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

From cnulk at scu.edu  Tue Jul  2 17:48:29 2013
From: cnulk at scu.edu (Chris Nulk)
Date: Tue, 02 Jul 2013 08:48:29 -0700
Subject: [Mailman-Users] Writing a custom handler
In-Reply-To: <51D20436.4050300@msapiro.net>
References: <51D1BB44.2060000@scu.edu> <51D20436.4050300@msapiro.net>
Message-ID: <51D2F64D.80809@scu.edu>

Thank you Mark for your time.

I went through and made the syslog change, removed the usenet bit, and 
correct my typing error.

On 7/1/2013 3:35 PM, Mark Sapiro wrote:
> On 7/1/2013 10:24 AM, Chris Nulk wrote:
>> Hello user,
>>
>> I am writing a custom handler to globally ban email address from sending
>> messages sent to Mailman.  I know I can use Mark's add_banned.py script
>> to add an address to all lists.  However, if I add an address to be
>> banned, as the administrator for all lists, I don't want a list admin to
>> remove a pest from their list(s).  I banned an address for being a pest
>> to all lists (or a majority of them), therefore, the address stays banned.
>
> Note that the ban_list only prevents the address from subscribing. If
> the address was already a member when banned, it can still post.

I know the ban_list only prevents the address from subscribing.  My goal 
for this custom handler is to stop a pesky addresses from subscribing, 
unsubscribing, posting, or having any interaction with any of my lists.  
I have add a few addresses try to subscribe to all the lists on my 
site.  I highly doubt those are all legit so I want to ban and have 
nothing to do with those addresses in the future.

> from Mailman import Errors
> from Mailman.i18n import _
> from Mailman.Logging.Syslog import syslog
> from Mailman.MailList import MailList
>
> You don't actually use MailList so there's no need to import it. Also
> Utils, Message, Errors and _ are used only by the discard code you
> copied. You could instead just
>
>  From Mailman.Handlers.Moderate import do_discard
>
> and use that if it wasn't important to have specific messages. OTOH, see
> below.

I removed the MailList line.  As for the do_discard, I actually was 
going to import it, however, I decided I wanted to have a different 
discard message indicating the global ban list caused the discard. Then, 
the list owners would know it wasn't something with their list 
configuration.

>>
>>      # Go through possible senders.  Check if any of them are
>>      #   on the global ban list
>>      for sender in msg.get_senders():
>>          if sender.lower() in banlist:
>>              break
>>      else:
>>          # None of the sender addresses were in the global ban
>>          #   list so return and continue with the next pipeline
>>          #   handler
>>          return
>>
>>      # A sender was found on the global ban list.  Log it and
>>      #   discard the message notifying the list owner
>>      if sender:
>
> How can this be False?

If I understand the code properly, sender should never be False or None 
but if something happens that I do not expect, I have a way to catch 
it.  Or, am I missing something?

> You could just import do_discard from Mailman.Handlers.Moderate and 
> use that, but you may want the custom messages. If so, you may also 
> want do_discard_globalban(mlist, msg, sender)
>> 
>> # copied almost verbatim from Mailman/Handlers/Moderate.py
>> def do_discard_globalban(mlist, msg):
>>      sender = msg.get_sender

I take it that should I change the line -

     do_discard_globalban(mlist, msg, sender)

I should also update the def for it to -

     def do_discard_globalban(mlist, msg, sender)

and I can remove the line -

     sender = msg.get_sender()


I have a few more questions.  My plan for the custom handler is install 
it as the first handler in the global pipeline for all lists.  I have 
seen how to do that in the faqs.   I also believe that once it is 
running with Mailman, it will be in memory and executable - no loading 
and unloading of the handler.  Once Mailman loads, it loads all the 
handlers and is ready to go.

My handler reads a file every time it runs.  Not very efficient. Once I 
have read in the banlist from the file, will the banlist always be 
available for future iterations through the code?

What I would like to do is read the global ban list file once to build 
the ban list but update the ban list if there has been a change in the 
global ban list file.

Thanks for any assistance,

Chris


----------------------- Updated Global Ban list custom handler 
--------------------

#!/usr/bin/env python
#

"""This is a custom handler that will check all the sender addresses of
a message against a global ban list.  If any of the sender addresses are
on the global ban list, the message will get logged and discarded.
"""

import sys

from Mailman import mm_cfg
from Mailman import Utils
from Mailman import Message
from Mailman import Errors
from Mailman.i18n import _
from Mailman.Logging.Syslog import syslog

def process(mlist, msg, msgdata):
     # added because it was in Mailman/Handlers/Moderate.py
     #   I am guessing it has to due in part with an upstream
     #   pipeline handler marking the message approved and/or
     #   because the handler can be moved to different parts
     #   of the pipeline.
     if msgdata.get('approved'):
         return

     # First, initialize the banlist
     banlist = []

     # Read in the global ban list of email addresses
     #  mm_cfg.GLOBALBANLIST_FILENAME is defined in mm_cfg and should
     #  be the full path to the file.
     try:
         with open(mm_cfg.GLOBALBANLIST_FILENAME) as f:
             for addr in f:
                 banlist.append(addr.lower().strip())
     except IOError, e:
         # cannot open the global ban list for whatever reason
         # log it and continue with the next pipeline handler
         syslog('error',
                "Can't open %s: %s" % (mm_cfg.GLOBALBANLIST_FILENAME, e)
                )
         return
     except:
         # unspecified error
         # log it and continue with the next pipeline handler
         syslog('error',
                'ERROR: %s: %s' % (sys.exc_info()[0], sys.exc_info()[1])
               )
         return

     # Go through possible senders.  Check if any of them are
     #   on the global ban list
     for sender in msg.get_senders():
         if sender.lower() in banlist:
             break
     else:
         # None of the sender addresses were in the global ban
         #   list so return and continue with the next pipeline
         #   handler
         return

     # A sender was found on the global ban list.  Log it and
     #   discard the message notifying the list owner
     if sender:
         # Log banned sender to the vette log
         syslog('vette', '%s is banned by the global ban list', sender)
         # Perform message discard
         do_discard_globalban(mlist, msg, sender)
     else:
         assert 0, 'Bad sender in GlobalBan.py'

# copied almost verbatim from Mailman/Handlers/Moderate.py
def do_discard_globalban(mlist, msg, sender):
     # forward auto-discards to list owners?
     if mlist.forward_auto_discards:
         lang = mlist.preferred_language
         nmsg = Message.UserNotification(mlist.GetOwnerEmail(),
                                         mlist.GetBouncesEmail(),
                                         _('Global Ban List Auto-discard 
notification'),
                                         lang=lang)
         nmsg.set_type('multipart/mixed')
         text = MIMEText(Utils.wrap(_("""\
The sender of the attached message is on the Global Ban list. Therefore, 
the message
has been automatically discarded.""")),
                         _charset=Utils.GetCharSet(lang))
         nmsg.attach(text)
         nmsg.attach(MIMEMessage(msg))
         nmsg.send(mlist)
     # Discard the message
     raise Errors.DiscardMessage




From mark at msapiro.net  Tue Jul  2 19:16:54 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 02 Jul 2013 10:16:54 -0700
Subject: [Mailman-Users] Writing a custom handler
In-Reply-To: <51D2F64D.80809@scu.edu>
References: <51D1BB44.2060000@scu.edu> <51D20436.4050300@msapiro.net>
	<51D2F64D.80809@scu.edu>
Message-ID: <51D30B06.5000500@msapiro.net>

On 07/02/2013 08:48 AM, Chris Nulk wrote:

> On 7/1/2013 3:35 PM, Mark Sapiro wrote:
>> On 7/1/2013 10:24 AM, Chris Nulk wrote:
>>>
>>>      # Go through possible senders.  Check if any of them are
>>>      #   on the global ban list
>>>      for sender in msg.get_senders():
>>>          if sender.lower() in banlist:
>>>              break
>>>      else:
>>>          # None of the sender addresses were in the global ban
>>>          #   list so return and continue with the next pipeline
>>>          #   handler
>>>          return
>>>
>>>      # A sender was found on the global ban list.  Log it and
>>>      #   discard the message notifying the list owner
>>>      if sender:
>>
>> How can this be False?
> 
> If I understand the code properly, sender should never be False or None
> but if something happens that I do not expect, I have a way to catch
> it.  Or, am I missing something?


Yes and no. It is usually fine to test for conditions that "can't
happen" just to be on the safe side.

However, in this case, I was thinking it is so immediately obvious that
the only way to get this far is if sender.lower() is in banlist so you
must have had a sender, but just to show that you were right, in
starting to type this I realized that get_senders() possibly could
return a null string and there could be an empty line in banlist, so in
fact sender could be False in this case.


>> You could just import do_discard from Mailman.Handlers.Moderate and
>> use that, but you may want the custom messages. If so, you may also
>> want do_discard_globalban(mlist, msg, sender)
>>> 
>>> # copied almost verbatim from Mailman/Handlers/Moderate.py
>>> def do_discard_globalban(mlist, msg):
>>>      sender = msg.get_sender
> 
> I take it that should I change the line -
> 
>     do_discard_globalban(mlist, msg, sender)
> 
> I should also update the def for it to -
> 
>     def do_discard_globalban(mlist, msg, sender)
> 
> and I can remove the line -
> 
>     sender = msg.get_sender()


Yes, that is what I meant, but I now realize that sender isn't actually
referenced in the discard code, so I suggest you do the above, but also
change

         text = MIMEText(Utils.wrap(_("""\
The sender of the attached message is on the Global Ban list. Therefore,
the message
has been automatically discarded.""")),

to something like

         text = MIMEText(Utils.wrap(_("""\
The sender - %(sender)s - of the attached message is on the Global Ban
list. Therefore,
the message
has been automatically discarded.""")),


The i18n._() function will replace %(sender)s with the value of sender.


> I have a few more questions.  My plan for the custom handler is install
> it as the first handler in the global pipeline for all lists.  I have
> seen how to do that in the faqs.   I also believe that once it is
> running with Mailman, it will be in memory and executable - no loading
> and unloading of the handler.  Once Mailman loads, it loads all the
> handlers and is ready to go.


Yes and no. Only IncomingRunner imports the pipeline handlers, and it
does that only when a message arrives. I.e. the first time
IncomingRunner needs to process a message through the pipeline, it will
import the handlers, and once the handlers are imported, they remain in
memory.


> My handler reads a file every time it runs.  Not very efficient. Once I
> have read in the banlist from the file, will the banlist always be
> available for future iterations through the code?


You could change your code as follows:

1) Make the banlist global by putting

# First, initialize the banlist
banlist = []

ahead of

def process(mlist, msg, msgdata):

and remove that from the process() definition:

Then make the code inside process() that loads the banlist conditional
on banlist being the empty list, e.g.,

    if not banlist:
        ...

Then once the global banlist is loaded with the file data, the file
won't be read again.


> What I would like to do is read the global ban list file once to build
> the ban list but update the ban list if there has been a change in the
> global ban list file.


You have a couple of choices:

1) Do the above and just restart Mailman if you update the banlist.

2) add code to test and remember (in a global) the mod time of the
banlist file and read it only if the file is newer.

Method 2) may involve comparable overhead to just reading the file each
time so may not be worth it. I would either do 1) or just read the file
every time based on how often I expect the file to change.

Note that if posts are infrequent, the overhead of reading the file each
time doesn't much matter, and if posts are frequent, the file will
probably be in an OS disk cache anyway.

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

From cnulk at scu.edu  Tue Jul  2 20:38:25 2013
From: cnulk at scu.edu (Chris Nulk)
Date: Tue, 02 Jul 2013 11:38:25 -0700
Subject: [Mailman-Users] Writing a custom handler
In-Reply-To: <51D30B06.5000500@msapiro.net>
References: <51D1BB44.2060000@scu.edu> <51D20436.4050300@msapiro.net>
	<51D2F64D.80809@scu.edu> <51D30B06.5000500@msapiro.net>
Message-ID: <51D31E21.8030601@scu.edu>


On 7/2/2013 10:16 AM, Mark Sapiro wrote:
> On 07/02/2013 08:48 AM, Chris Nulk wrote:
>
>
> You could change your code as follows:
>
> 1) Make the banlist global by putting
>
> # First, initialize the banlist
> banlist = []
>
> ahead of
>
> def process(mlist, msg, msgdata):
>
> and remove that from the process() definition:
>
> Then make the code inside process() that loads the banlist conditional
> on banlist being the empty list, e.g.,
>
>      if not banlist:
>          ...
>
> Then once the global banlist is loaded with the file data, the file
> won't be read again.
>
>
>> What I would like to do is read the global ban list file once to build
>> the ban list but update the ban list if there has been a change in the
>> global ban list file.
>
> You have a couple of choices:
>
> 1) Do the above and just restart Mailman if you update the banlist.
>
> 2) add code to test and remember (in a global) the mod time of the
> banlist file and read it only if the file is newer.
>
> Method 2) may involve comparable overhead to just reading the file each
> time so may not be worth it. I would either do 1) or just read the file
> every time based on how often I expect the file to change.
>
> Note that if posts are infrequent, the overhead of reading the file each
> time doesn't much matter, and if posts are frequent, the file will
> probably be in an OS disk cache anyway.
>
Mark,

Thanks again for all the help.  I choose method 2.  I have a few 
processes that monitor the log files.  I can modify them to 
automatically update the ban list file based on whatever parameters I 
want to set.  With method 2, my Mailman instance is updated on the next 
message that comes in without me having to do anything.  Our site has 
some activity but not a lot as some places do so I am not worried about 
the overhead.

I did forget about some of my other questions.  I plan on writing 
another custom handler for a list-specific issue.  Where would I look if 
I wanted to intercept messages related to subscribing, unsubscribing, 
and options processing?  How would I tell the difference between a 
subscribe message and an unsubscribe message? Also, is there a 
difference if the person does the subscribing or unsubscribing via the 
web?  Can I trap those?

Below is the latest update incorporating your suggestions.

Thanks again,
Chris

------------------------ Updated Global Ban Custom Handler 
----------------------

#!/usr/bin/env python
#

"""This is a custom handler that will check all the sender addresses of
a message against a global ban list.  If any of the sender addresses are
on the global ban list, the message will get logged and discarded.
"""

import sys
import os

from Mailman import mm_cfg
from Mailman import Utils
from Mailman import Message
from Mailman import Errors
from Mailman.i18n import _
from Mailman.Logging.Syslog import syslog

# Global variables
#   Initialize the banlist
banlist = []

#   Keep the Global Ban lists modification time
#     set to -1 to indicate ban file hasn't been read
ban_mtime = -1

# Define ban_file
#   mm_cfg.GLOBALBANLIST_FILENAME is defined in mm_cfg and should
#   be the full path to the file.
ban_file = mm_cfg.GLOBALBANLIST_FILENAME

def process(mlist, msg, msgdata):
     # Upstream pipeline handler marked message approved -
     #   respect the decision
     if msgdata.get('approved'):
         return

     # ban_file gets its value from mm_cfg.GLOBALBANLIST_FILENAME. If
     #   mm_cfg.GLOBALBANLIST_FILENAME is not defined neither is
     #   ban_file, so simply return.
     if not ban_file:
         return

     # Read in the global ban list of email addresses
     if Ban_File_Changed(ban_file, ban_mlist):
         # Global Ban list has changed (or ban_mlist = -1),
         #   read in the changes
         rc = Read_GlobalBan_File(ban_file)
         if not rc:
             # Problems reading the GlobalBan list
             return

     # Check if banlist has anything, if not, no need to go further
     if not banlist:
         return

     # Go through possible senders.  Check if any of them are
     #   on the global ban list
     for sender in msg.get_senders():
         if sender.lower() in banlist:
             break
     else:
         # None of the sender addresses were in the global ban
         #   list so return and continue with the next pipeline
         #   handler
         return

     # A sender was found on the global ban list.  Log it and
     #   discard the message notifying the list owner
     if sender:
         # Log banned sender to the vette log
         syslog('vette', '%s is banned by the global ban list', sender)
         # Perform message discard
         do_discard_globalban(mlist, msg, sender)
     else:
         assert 0, 'Bad sender in GlobalBan.py'


# Stat the ban file to get the modification time and compare it to the
#   last time the file was changed.  If a changed occured, update
#   ban_mtime to current change time
def Ban_File_Changed(ban_file, ban_mtime):
     try:
         statinfo = os.stat(ban_file)
     except IOError, e:
         # cannot stat the global ban list for whatever reason
         # log it and continue with the next pipeline handler
         syslog('error',
                "Can't stat %s: %s" % (ban_file, e)
                )
         return False
     except:
         # unspecified error
         # log it and continue with the next pipeline handler
         syslog('error',
                'ERROR: %s: %s' % (sys.exc_info()[0], sys.exc_info()[1])
               )
         return False

     # if ban_mtime = -1, statinfo.st_mtime should always be greater, this
     #   is a special case for when the code is first loaded and run
     if statinfo.st_mtime > ban_mtime:
         ban_mtime = statinfo.st_mtime
         return True

     # no change in ban file
     return False


# Read the Global Ban file and populate the banlist.
def Read_GlobalBan_File(ban_file):
     try:
         with open(ban_file) as f:
             for addr in f:
                 # if addr is not in banlist, add it - to avoid duplicates
                 if addr not in banlist:
                     banlist.append(addr.lower().strip())
     except IOError, e:
         # cannot open the global ban list for whatever reason
         # log it and continue with the next pipeline handler
         syslog('error',
                "Can't open %s: %s" % (ban_file, e)
                )
         return False
     except:
         # unspecified error
         # log it and continue with the next pipeline handler
         syslog('error',
                'ERROR: %s: %s' % (sys.exc_info()[0], sys.exc_info()[1])
               )
         return False

     # success
     return True


# copied almost verbatim from Mailman/Handlers/Moderate.py
def do_discard_globalban(mlist, msg, sender):
     # forward auto-discards to list owners?
     if mlist.forward_auto_discards:
         lang = mlist.preferred_language
         nmsg = Message.UserNotification(mlist.GetOwnerEmail(),
                                         mlist.GetBouncesEmail(),
                                         _('Global Ban List Auto-discard 
notification'),
                                         lang=lang)
         nmsg.set_type('multipart/mixed')
         text = MIMEText(Utils.wrap(_("""\
The sender - %(sender)s - of the attached message is on the Global Ban 
list.  Therefore, the message
has been automatically discarded.""")),
                         _charset=Utils.GetCharSet(lang))
         nmsg.attach(text)
         nmsg.attach(MIMEMessage(msg))
         nmsg.send(mlist)
     # Discard the message
     raise Errors.DiscardMessage


From mark at msapiro.net  Tue Jul  2 21:17:12 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 02 Jul 2013 12:17:12 -0700
Subject: [Mailman-Users] Writing a custom handler
In-Reply-To: <51D31E21.8030601@scu.edu>
References: <51D1BB44.2060000@scu.edu> <51D20436.4050300@msapiro.net>
	<51D2F64D.80809@scu.edu> <51D30B06.5000500@msapiro.net>
	<51D31E21.8030601@scu.edu>
Message-ID: <51D32738.4040500@msapiro.net>

On 07/02/2013 11:38 AM, Chris Nulk wrote:
> 
> 
> I did forget about some of my other questions.  I plan on writing
> another custom handler for a list-specific issue.  Where would I look if
> I wanted to intercept messages related to subscribing, unsubscribing,
> and options processing?


These are messages to the -request, -join, -subscribe, -leave and
-unsubscribe addresses and are all processed by CommandRunner. Only
IncomingRunner processes a pipeline of handlers. There is no comparable
processing or custom handler option for CommandRunner. You would have to
modify Mailman/Queue/CommandRunner.py itself.


> How would I tell the difference between a
> subscribe message and an unsubscribe message? Also, is there a
> difference if the person does the subscribing or unsubscribing via the
> web?  Can I trap those?


The web functions are handled by modules in Mailman/Cgi. They don't
involve qrunners at all.



> Below is the latest update incorporating your suggestions.


See some inline comments.


> #!/usr/bin/env python
> #
> 
> """This is a custom handler that will check all the sender addresses of
> a message against a global ban list.  If any of the sender addresses are
> on the global ban list, the message will get logged and discarded.
> """
> 
> import sys
> import os
> 
> from Mailman import mm_cfg
> from Mailman import Utils
> from Mailman import Message
> from Mailman import Errors
> from Mailman.i18n import _
> from Mailman.Logging.Syslog import syslog
> 
> # Global variables
> #   Initialize the banlist
> banlist = []
> 
> #   Keep the Global Ban lists modification time
> #     set to -1 to indicate ban file hasn't been read
> ban_mtime = -1
> 
> # Define ban_file
> #   mm_cfg.GLOBALBANLIST_FILENAME is defined in mm_cfg and should
> #   be the full path to the file.
> ban_file = mm_cfg.GLOBALBANLIST_FILENAME
> 
> def process(mlist, msg, msgdata):
>     # Upstream pipeline handler marked message approved -

Or message contained an Approved: <password> header.


>     #   respect the decision
>     if msgdata.get('approved'):
>         return
> 
>     # ban_file gets its value from mm_cfg.GLOBALBANLIST_FILENAME. If
>     #   mm_cfg.GLOBALBANLIST_FILENAME is not defined neither is
>     #   ban_file, so simply return.
>     if not ban_file:
>         return
> 
>     # Read in the global ban list of email addresses
>     if Ban_File_Changed(ban_file, ban_mlist):


ban_mtime, not ban_mlist.


>         # Global Ban list has changed (or ban_mlist = -1),


ban_mtime.


>         #   read in the changes
>         rc = Read_GlobalBan_File(ban_file)
>         if not rc:
>             # Problems reading the GlobalBan list
>             return


Or just
        if not Read_GlobalBan_File(ban_file):
            return


>     # Check if banlist has anything, if not, no need to go further
>     if not banlist:
>         return
> 
>     # Go through possible senders.  Check if any of them are
>     #   on the global ban list
>     for sender in msg.get_senders():
>         if sender.lower() in banlist:
>             break
>     else:
>         # None of the sender addresses were in the global ban
>         #   list so return and continue with the next pipeline
>         #   handler
>         return
> 
>     # A sender was found on the global ban list.  Log it and
>     #   discard the message notifying the list owner
>     if sender:
>         # Log banned sender to the vette log
>         syslog('vette', '%s is banned by the global ban list', sender)
>         # Perform message discard
>         do_discard_globalban(mlist, msg, sender)
>     else:
>         assert 0, 'Bad sender in GlobalBan.py'
> 
> 
> # Stat the ban file to get the modification time and compare it to the
> #   last time the file was changed.  If a changed occured, update
> #   ban_mtime to current change time
> def Ban_File_Changed(ban_file, ban_mtime):
>     try:
>         statinfo = os.stat(ban_file)
>     except IOError, e:
>         # cannot stat the global ban list for whatever reason
>         # log it and continue with the next pipeline handler
>         syslog('error',
>                "Can't stat %s: %s" % (ban_file, e)
>                )
>         return False
>     except:
>         # unspecified error
>         # log it and continue with the next pipeline handler
>         syslog('error',
>                'ERROR: %s: %s' % (sys.exc_info()[0], sys.exc_info()[1])
>               )
>         return False


Do you really want to do this? The Mailman philosophy is all caught and
handled exceptions should be explicit. An unanticipated exception will
be caught at the top qrunner level which will log the error with
traceback in the 'error' log and shunt the message rather than
continuing processing with a message that triggered an unanticipated
exception.


>     # if ban_mtime = -1, statinfo.st_mtime should always be greater, this
>     #   is a special case for when the code is first loaded and run
>     if statinfo.st_mtime > ban_mtime:
>         ban_mtime = statinfo.st_mtime
>         return True
> 
>     # no change in ban file
>     return False
> 
> 
> # Read the Global Ban file and populate the banlist.
> def Read_GlobalBan_File(ban_file):
>     try:
>         with open(ban_file) as f:
>             for addr in f:
>                 # if addr is not in banlist, add it - to avoid duplicates
>                 if addr not in banlist:
>                     banlist.append(addr.lower().strip())
>     except IOError, e:
>         # cannot open the global ban list for whatever reason
>         # log it and continue with the next pipeline handler
>         syslog('error',
>                "Can't open %s: %s" % (ban_file, e)
>                )
>         return False
>     except:
>         # unspecified error
>         # log it and continue with the next pipeline handler
>         syslog('error',
>                'ERROR: %s: %s' % (sys.exc_info()[0], sys.exc_info()[1])
>               )
>         return False


See comment above about generic exceptions.


> 
>     # success
>     return True
> 
> 
> # copied almost verbatim from Mailman/Handlers/Moderate.py
> def do_discard_globalban(mlist, msg, sender):
>     # forward auto-discards to list owners?
>     if mlist.forward_auto_discards:
>         lang = mlist.preferred_language
>         nmsg = Message.UserNotification(mlist.GetOwnerEmail(),
>                                         mlist.GetBouncesEmail(),
>                                         _('Global Ban List Auto-discard
> notification'),
>                                         lang=lang)
>         nmsg.set_type('multipart/mixed')
>         text = MIMEText(Utils.wrap(_("""\
> The sender - %(sender)s - of the attached message is on the Global Ban
> list.  Therefore, the message
> has been automatically discarded.""")),
>                         _charset=Utils.GetCharSet(lang))
>         nmsg.attach(text)
>         nmsg.attach(MIMEMessage(msg))
>         nmsg.send(mlist)
>     # Discard the message
>     raise Errors.DiscardMessage

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

From cnulk at scu.edu  Tue Jul  2 22:49:35 2013
From: cnulk at scu.edu (Chris Nulk)
Date: Tue, 02 Jul 2013 13:49:35 -0700
Subject: [Mailman-Users] Writing a custom handler
In-Reply-To: <51D32738.4040500@msapiro.net>
References: <51D1BB44.2060000@scu.edu> <51D20436.4050300@msapiro.net>
	<51D2F64D.80809@scu.edu> <51D30B06.5000500@msapiro.net>
	<51D31E21.8030601@scu.edu> <51D32738.4040500@msapiro.net>
Message-ID: <51D33CDF.3080209@scu.edu>


On 7/2/2013 12:17 PM, Mark Sapiro wrote:
> On 07/02/2013 11:38 AM, Chris Nulk wrote:
>>
>> I did forget about some of my other questions.  I plan on writing
>> another custom handler for a list-specific issue.  Where would I look if
>> I wanted to intercept messages related to subscribing, unsubscribing,
>> and options processing?
>
> These are messages to the -request, -join, -subscribe, -leave and
> -unsubscribe addresses and are all processed by CommandRunner. Only
> IncomingRunner processes a pipeline of handlers. There is no comparable
> processing or custom handler option for CommandRunner. You would have to
> modify Mailman/Queue/CommandRunner.py itself.

Hmmm.  I have a few lists where unsubscribes are not allowed (not my 
decision).  On one of them, a persistent member keeps trying to 
unsubscribe.  I wanted to setup an automated response and discard mechanism.

>
>
>> How would I tell the difference between a
>> subscribe message and an unsubscribe message? Also, is there a
>> difference if the person does the subscribing or unsubscribing via the
>> web?  Can I trap those?
>
> The web functions are handled by modules in Mailman/Cgi. They don't
> involve qrunners at all.

I have made enough mods to Mailman.  Don't want make any more if I don't 
have to so I will just keep discarding the unsubscribe requests.

>> Below is the latest update incorporating your suggestions.
>
> See some inline comments.
>
>
> def process(mlist, msg, msgdata):
>      # Upstream pipeline handler marked message approved -
> Or message contained an Approved: <password> header.

Yep.

>
>>      #   respect the decision
>>      if msgdata.get('approved'):
>>          return
>>
>>      # ban_file gets its value from mm_cfg.GLOBALBANLIST_FILENAME. If
>>      #   mm_cfg.GLOBALBANLIST_FILENAME is not defined neither is
>>      #   ban_file, so simply return.
>>      if not ban_file:
>>          return
>>
>>      # Read in the global ban list of email addresses
>>      if Ban_File_Changed(ban_file, ban_mlist):
>
> ban_mtime, not ban_mlist.

Yeah, I fixed it after I sent the message.

>
>
>>          # Global Ban list has changed (or ban_mlist = -1),
>
> ban_mtime.

Same here.

>
>
>>          #   read in the changes
>>          rc = Read_GlobalBan_File(ban_file)
>>          if not rc:
>>              # Problems reading the GlobalBan list
>>              return
>
> Or just
>          if not Read_GlobalBan_File(ban_file):
>              return

I actually had more code here.  As I reduced the code, I tightened the 
code.  Missed this one.

>> # Stat the ban file to get the modification time and compare it to the
>> #   last time the file was changed.  If a changed occured, update
>> #   ban_mtime to current change time
>> def Ban_File_Changed(ban_file, ban_mtime):
>>      try:
>>          statinfo = os.stat(ban_file)
>>      except IOError, e:
>>          # cannot stat the global ban list for whatever reason
>>          # log it and continue with the next pipeline handler
>>          syslog('error',
>>                 "Can't stat %s: %s" % (ban_file, e)
>>                 )
>>          return False
>>      except:
>>          # unspecified error
>>          # log it and continue with the next pipeline handler
>>          syslog('error',
>>                 'ERROR: %s: %s' % (sys.exc_info()[0], sys.exc_info()[1])
>>                )
>>          return False
>
> Do you really want to do this? The Mailman philosophy is all caught and
> handled exceptions should be explicit. An unanticipated exception will
> be caught at the top qrunner level which will log the error with
> traceback in the 'error' log and shunt the message rather than
> continuing processing with a message that triggered an unanticipated
> exception.

Instead of returning, should I raise an exception?  For the IOError or 
any error, whether or not the file can be read or perform a stat isn't a 
big deal.  I would rather log the error, clear the exception and keep 
going.  If there is a problem in this function, returning False just 
means the ban_file hasn't changed so I will still be running sender 
addresses against a potentially older banlist.
>> 
>> # Read the Global Ban file and populate the banlist.
>> def Read_GlobalBan_File(ban_file):
>>      try:
>>          with open(ban_file) as f:
>>              for addr in f:
>>                  # if addr is not in banlist, add it - to avoid duplicates
>>                  if addr not in banlist:
>>                      banlist.append(addr.lower().strip())
>>      except IOError, e:
>>          # cannot open the global ban list for whatever reason
>>          # log it and continue with the next pipeline handler
>>          syslog('error',
>>                 "Can't open %s: %s" % (ban_file, e)
>>                 )
>>          return False
>>      except:
>>          # unspecified error
>>          # log it and continue with the next pipeline handler
>>          syslog('error',
>>                 'ERROR: %s: %s' % (sys.exc_info()[0], sys.exc_info()[1])
>>                )
>>          return False
>
> See comment above about generic exceptions.

The same applies here also.  If there is a problem, the banlist doesn't 
get updated.

I would rather not have the code produce a traceback for a file system 
error.  If for some reason, the file became unreadable, then the error 
would kill Mailman repeatedly since this custom handler is going into 
the global pipeline.

Can I get rid of the exception handling while still logging those errors?

Thanks,
Chris


From mark at msapiro.net  Tue Jul  2 23:37:22 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 02 Jul 2013 14:37:22 -0700
Subject: [Mailman-Users] Writing a custom handler
In-Reply-To: <51D33CDF.3080209@scu.edu>
References: <51D1BB44.2060000@scu.edu> <51D20436.4050300@msapiro.net>
	<51D2F64D.80809@scu.edu> <51D30B06.5000500@msapiro.net>
	<51D31E21.8030601@scu.edu> <51D32738.4040500@msapiro.net>
	<51D33CDF.3080209@scu.edu>
Message-ID: <51D34812.4060000@msapiro.net>

On 07/02/2013 01:49 PM, Chris Nulk wrote:
> 
> On 7/2/2013 12:17 PM, Mark Sapiro wrote:
>> On 07/02/2013 11:38 AM, Chris Nulk wrote:

>>>      except:
>>>          # unspecified error
>>>          # log it and continue with the next pipeline handler
>>>          syslog('error',
>>>                 'ERROR: %s: %s' % (sys.exc_info()[0], sys.exc_info()[1])
>>>                )
>>>          return False
>>
>> Do you really want to do this? The Mailman philosophy is all caught and
>> handled exceptions should be explicit. An unanticipated exception will
>> be caught at the top qrunner level which will log the error with
>> traceback in the 'error' log and shunt the message rather than
>> continuing processing with a message that triggered an unanticipated
>> exception.
> 
> Instead of returning, should I raise an exception?  For the IOError or
> any error, whether or not the file can be read or perform a stat isn't a
> big deal.  I would rather log the error, clear the exception and keep
> going.  If there is a problem in this function, returning False just
> means the ban_file hasn't changed so I will still be running sender
> addresses against a potentially older banlist.


If you raise some exception other than the Mailman.Errors exceptions
DiscardMessage, HoldMessage or RejectMessage, it will be the same as if
you didn't catch the exception, i.e., the exception will be logged in
the 'error' log with a traceback and the message will be shunted.

I can see that you don't really want that because if your ban file is
unreadable or you can't stat it for some reason, you'd be shunting every
message for a reason that has really nothing to do with processing the
message. So, I think you do want to catch the exception, log it and
return as that is the only way to continue processing messages.

Just watch your 'error' log as you'll get an entry per message if
something is wrong.

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

From cnulk at scu.edu  Wed Jul  3 00:09:51 2013
From: cnulk at scu.edu (Chris Nulk)
Date: Tue, 02 Jul 2013 15:09:51 -0700
Subject: [Mailman-Users] Writing a custom handler
In-Reply-To: <51D34812.4060000@msapiro.net>
References: <51D1BB44.2060000@scu.edu> <51D20436.4050300@msapiro.net>
	<51D2F64D.80809@scu.edu> <51D30B06.5000500@msapiro.net>
	<51D31E21.8030601@scu.edu> <51D32738.4040500@msapiro.net>
	<51D33CDF.3080209@scu.edu> <51D34812.4060000@msapiro.net>
Message-ID: <51D34FAF.2010907@scu.edu>


On 7/2/2013 2:37 PM, Mark Sapiro wrote:
> If you raise some exception other than the Mailman.Errors exceptions
> DiscardMessage, HoldMessage or RejectMessage, it will be the same as if
> you didn't catch the exception, i.e., the exception will be logged in
> the 'error' log with a traceback and the message will be shunted.
>
> I can see that you don't really want that because if your ban file is
> unreadable or you can't stat it for some reason, you'd be shunting every
> message for a reason that has really nothing to do with processing the
> message. So, I think you do want to catch the exception, log it and
> return as that is the only way to continue processing messages.
>
> Just watch your 'error' log as you'll get an entry per message if
> something is wrong.
>

Thank you for the help.   Hopefully a last question.  In the 
do_discard_globalban function, how can I send the discard message to 
mailman list?  Or should I?  As it stands now, each list owner/admin 
would be getting the message for their list.  I am thinking that as the 
site administrator and maintainer of the global ban list, I should also 
get the message.

In the updated code, I did change the populating of the banlist in the 
Read_GlobalBan_File function.  Now, it strips and lowercases the 
addresses before it checks if the address is in the banlist. Before, it 
checked then populated a stripped, lowercase version. This could have 
resulted in duplicates if the address in the banlist but the address 
checked had a different case profile.

Thanks,
Chris

------------------------  Updated Global Ban list Custom Handler 
--------------------

#!/usr/bin/env python
#

"""This is a custom handler that will check all the sender addresses of
a message against a global ban list.  If any of the sender addresses are
on the global ban list, the message will get logged and discarded.
"""

import sys
import os

from Mailman import mm_cfg
from Mailman import Utils
from Mailman import Message
from Mailman import Errors
from Mailman.i18n import _
from Mailman.Logging.Syslog import syslog

# Global variables
#   Initialize the banlist
banlist = []

#   Keep the Global Ban lists modification time
#     set to -1 to indicate ban file hasn't been read
ban_mtime = -1

# Define ban_file
#   mm_cfg.GLOBALBANLIST_FILENAME is defined in mm_cfg and should
#   be the full path to the file.
ban_file = mm_cfg.GLOBALBANLIST_FILENAME

def process(mlist, msg, msgdata):
     # Upstream pipeline handler marked message approved -
     #   respect the decision or message has 'Approved: <pwd>' header
     if msgdata.get('approved'):
         return

     # ban_file gets its value from mm_cfg.GLOBALBANLIST_FILENAME. If
     #   mm_cfg.GLOBALBANLIST_FILENAME is not defined, then neither is
     #   ban_file, so simply return.
     if not ban_file:
         return

     # Read in the global ban list of email addresses
     if Ban_File_Changed(ban_file, ban_mtime):
         # Global Ban list has changed (or ban_mtime = -1),
         #   read in the changes
         if not Read_GlobalBan_File(ban_file):
             # Problems reading the GlobalBan list
             return

     # Check if banlist has anything, if not, no need to go further
     if not banlist:
         return

     # Go through possible senders.  Check if any of them are
     #   on the global ban list
     for sender in msg.get_senders():
         if sender.lower() in banlist:
             break
     else:
         # None of the sender addresses were in the global ban
         #   list so return and continue with the next pipeline
         #   handler
         return

     # A sender was found on the global ban list.  Log it and
     #   discard the message notifying the list owner
     if sender:
         # Log banned sender to the vette log
         syslog('vette', '%s is banned by the global ban list', sender)
         # Perform message discard
         do_discard_globalban(mlist, msg, sender)
     else:
         assert 0, 'Bad sender in GlobalBan.py'


# Stat the ban file to get the modification time and compare it to the
#   last time the file was changed.  If a changed occured, update
#   ban_mtime to current change time
def Ban_File_Changed(ban_file, ban_mtime):
     try:
         statinfo = os.stat(ban_file)
     except IOError, e:
         # cannot stat the global ban list for whatever reason
         # log it and continue with the next pipeline handler
         syslog('error',
                "Can't stat %s: %s" % (ban_file, e)
                )
         return False
     except:
         # unspecified error
         # log it and continue with the next pipeline handler
         syslog('error',
                'ERROR: %s: %s' % (sys.exc_info()[0], sys.exc_info()[1])
               )
         return False

     # if ban_mtime = -1, statinfo.st_mtime should always be greater, this
     #   is a special case for when the code is first loaded and run
     if statinfo.st_mtime > ban_mtime:
         # ban_file has changed or it's the special case
         ban_mtime = statinfo.st_mtime
         return True

     # no change in ban file
     return False


# Read the Global Ban file and populate the banlist.
def Read_GlobalBan_File(ban_file):
     try:
         with open(ban_file) as f:
             for addr in f:
                 # strip and lowercase addr
                 addr = addr.lower().strip()
                 # if addr is not in banlist, add it - to avoid 
duplicates, should not add blank addresses
                 if (addr) and (addr not in banlist):
                     banlist.append(addr)
     except IOError, e:
         # cannot open the global ban list for whatever reason
         # log it and continue with the next pipeline handler
         syslog('error',
                "Can't open %s: %s" % (ban_file, e)
                )
         return False
     except:
         # unspecified error
         # log it and continue with the next pipeline handler
         syslog('error',
                'ERROR: %s: %s' % (sys.exc_info()[0], sys.exc_info()[1])
               )
         return False

     # success
     return True


# copied almost verbatim from Mailman/Handlers/Moderate.py
def do_discard_globalban(mlist, msg, sender):
     # forward auto-discards to list owners?
     if mlist.forward_auto_discards:
         lang = mlist.preferred_language
         nmsg = Message.UserNotification(mlist.GetOwnerEmail(),
                                         mlist.GetBouncesEmail(),
                                         _('Global Ban List Auto-discard 
notification'),
                                         lang=lang)
         nmsg.set_type('multipart/mixed')
         text = MIMEText(Utils.wrap(_("""\
The sender - %(sender)s - of the attached message is on the Global Ban 
list.  Therefore, the message
has been automatically discarded.""")),
                         _charset=Utils.GetCharSet(lang))
         nmsg.attach(text)
         nmsg.attach(MIMEMessage(msg))
         nmsg.send(mlist)
     # Discard the message
     raise Errors.DiscardMessage


From kip at thevertigo.com  Wed Jul  3 01:14:33 2013
From: kip at thevertigo.com (Kip Warner)
Date: Tue, 02 Jul 2013 16:14:33 -0700
Subject: [Mailman-Users] Confirmation logging
Message-ID: <1372806873.27939.13.camel@rommel>

Greetings,

I'd like to setup a project announcement mailing list on my DreamHost
server using Mailman, however DreamHost has informed me that Mailman is
allegedly not compliant with their Anti-Spam policy.

        <https://dreamhost.com/anti-spam-policy/>

Apparently Mailman doesn't handle opt-in confirmations in a way that is
compliant with it. Specifically, it doesn't log new subscriptions or the
IP addresses of the confirmation. Is this correct?

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130702/01483b9a/attachment.pgp>

From mark at msapiro.net  Wed Jul  3 02:23:54 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 02 Jul 2013 17:23:54 -0700
Subject: [Mailman-Users] Writing a custom handler
In-Reply-To: <51D34FAF.2010907@scu.edu>
References: <51D1BB44.2060000@scu.edu> <51D20436.4050300@msapiro.net>
	<51D2F64D.80809@scu.edu> <51D30B06.5000500@msapiro.net>
	<51D31E21.8030601@scu.edu> <51D32738.4040500@msapiro.net>
	<51D33CDF.3080209@scu.edu> <51D34812.4060000@msapiro.net>
	<51D34FAF.2010907@scu.edu>
Message-ID: <51D36F1A.6050909@msapiro.net>

On 07/02/2013 03:09 PM, Chris Nulk wrote:
> 
> Thank you for the help.   Hopefully a last question.  In the
> do_discard_globalban function, how can I send the discard message to
> mailman list?  Or should I?  As it stands now, each list owner/admin
> would be getting the message for their list.  I am thinking that as the
> site administrator and maintainer of the global ban list, I should also
> get the message.


See below.


> In the updated code, I did change the populating of the banlist in the
> Read_GlobalBan_File function.  Now, it strips and lowercases the
> addresses before it checks if the address is in the banlist. Before, it
> checked then populated a stripped, lowercase version. This could have
> resulted in duplicates if the address in the banlist but the address
> checked had a different case profile.


See below.


>     # Go through possible senders.  Check if any of them are
>     #   on the global ban list
>     for sender in msg.get_senders():
>         if sender.lower() in banlist:


Not necessary to lowercase sender here as msg.get_senders() always
returns lowercased addresses unless called with a preserve_case argument
with a True value.


> # copied almost verbatim from Mailman/Handlers/Moderate.py
> def do_discard_globalban(mlist, msg, sender):
>     # forward auto-discards to list owners?
>     if mlist.forward_auto_discards:


Note that no forwarding of the discard occurs unless the list's Privacy
options... -> Sender filters -> forward_auto_discards is set to Yes.
Otherwise, no notice is sent and the only indication is a "Message
discarded, msgid: ..." entry in the 'vette' log.

You may wish to remove the above condition.


>         lang = mlist.preferred_language
>         nmsg = Message.UserNotification(mlist.GetOwnerEmail(),


mlist.GetOwnerEmail() returns the LISTNAME-owner address which is the
recipient of this mail. This argument can be a string with a single
address as it's value as it is here or a list of strings, each of which
is an address. So the above line could be changed to

        nmsg = Message.UserNotification([
                                         mlist.GetOwnerEmail(),
                                         'you at example.com',
                                         ],

with whatever list of addresses you want, or maybe since list owners
aren't much involved with this ban list

        nmsg = Message.UserNotification('you at example.com',


>                                         mlist.GetBouncesEmail(),
>                                         _('Global Ban List Auto-discard
> notification'),
>                                         lang=lang)

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

From mark at msapiro.net  Wed Jul  3 03:07:04 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 02 Jul 2013 18:07:04 -0700
Subject: [Mailman-Users] Confirmation logging
In-Reply-To: <1372806873.27939.13.camel@rommel>
References: <1372806873.27939.13.camel@rommel>
Message-ID: <51D37938.5000104@msapiro.net>

On 07/02/2013 04:14 PM, Kip Warner wrote:
> Greetings,
> 
> I'd like to setup a project announcement mailing list on my DreamHost
> server using Mailman, however DreamHost has informed me that Mailman is
> allegedly not compliant with their Anti-Spam policy.
> 
>         <https://dreamhost.com/anti-spam-policy/>
> 
> Apparently Mailman doesn't handle opt-in confirmations in a way that is
> compliant with it. Specifically, it doesn't log new subscriptions or the
> IP addresses of the confirmation. Is this correct?


Mailman does log new subscriptions in its 'subscribe' log, and some log
entries do contain IP addresses. If everything is done from the web we
get the following in the case where subscribe_policy is confirm:

Jul 02 17:36:02 2013 (3762) list1: pending Mark Sapiro
<mark at msapiro.net>  192.168.1.1

The subscription request.


Jul 02 17:37:18 2013 (3786) list1: new Mark Sapiro <mark at msapiro.net>,
via web confirmation

The confirmation. There is no IP for the confirmation which is a problem.

In the case where subscribe_policy is confirm and approve we get:

Jul 02 17:38:40 2013 (3796) list1: pending Mark Sapiro
<mark at msapiro.net>  192.168.1.1

The subscription request.


Jul 02 17:40:08 2013 (3810) list1: new Mark Sapiro <mark at msapiro.net>,
via admin approval

The approval. Note the confirmation isn't even logged.

In the case of subscription requests and/or confirmations by email,
there is just a "via email" notastion and what would you log for IP in
those cases anyway.

You could ensure subscribe_policy is confirm so confirmations are
logged, disable all email commands having to do with subscription or
confirmation, edit the verify.txt template to remove the email
confirmation language, edit the call to mlist.ProcessConfirmation() in
Mailman/Cgi/confirm.py to pass the IP and edit the definition of
ProcessConfirmation() in Mailman/MailList.py to pass the IP to
ApprovedAddMember() as part of the whence argument.

Otherwise, you probably can't satisfy DreamHost's requirement.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130702/e075db78/attachment.pgp>

From stephen at xemacs.org  Wed Jul  3 05:41:36 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 03 Jul 2013 12:41:36 +0900
Subject: [Mailman-Users]  Confirmation logging
In-Reply-To: <1372806873.27939.13.camel@rommel>
References: <1372806873.27939.13.camel@rommel>
Message-ID: <87ppv0wbrj.fsf@uwakimon.sk.tsukuba.ac.jp>

Kip Warner writes:

 > Apparently Mailman doesn't handle opt-in confirmations in a way that is
 > compliant with it. Specifically, it doesn't log new subscriptions or the
 > IP addresses of the confirmation. Is this correct?

Each step of a subscription is logged.  IP addresses of web requests
are logged, both in logs/subscribe and by the webserver.

IP addresses of the last remote MTA for a request by mail are logged
by the local MTA.  IP address of the source MTA or MUA cannot be
reliably determined in malicious cases, and even for honest messages,
the source IP is both expensive to compute accurately and less than
100% reliable.  I don't think Mailman even tries to log these, but I
don't have an actual case to hand in my own logs -- everybody uses the
web interface.

It seems to me that you can probably comply with DreamHost's
requirements simply by disabling processing of admin commands by
mail.  Caveat: I haven't read DreamHost's policy so I don't know for
sure.  Most likely very few people will be bothered.  You'll also want
to edit the "please confirm" message to remove the reference to
confirm by mail.  You could also achieve the same effect by requiring
confirmation by mail, but this might require more invasive changes to
the code.

I'm not sure how to disable admin-by-mail offhand, but Mark can
probably help.

From cnulk at scu.edu  Wed Jul  3 16:40:43 2013
From: cnulk at scu.edu (Chris Nulk)
Date: Wed, 03 Jul 2013 07:40:43 -0700
Subject: [Mailman-Users] Writing a custom handler
In-Reply-To: <51D36F1A.6050909@msapiro.net>
References: <51D1BB44.2060000@scu.edu> <51D20436.4050300@msapiro.net>
	<51D2F64D.80809@scu.edu> <51D30B06.5000500@msapiro.net>
	<51D31E21.8030601@scu.edu> <51D32738.4040500@msapiro.net>
	<51D33CDF.3080209@scu.edu> <51D34812.4060000@msapiro.net>
	<51D34FAF.2010907@scu.edu> <51D36F1A.6050909@msapiro.net>
Message-ID: <51D437EB.5070403@scu.edu>


On 7/2/2013 5:23 PM, Mark Sapiro wrote:
> On 07/02/2013 03:09 PM, Chris Nulk wrote:
>> In the updated code, I did change the populating of the banlist in the
>> Read_GlobalBan_File function.  Now, it strips and lowercases the
>> addresses before it checks if the address is in the banlist. Before, it
>> checked then populated a stripped, lowercase version. This could have
>> resulted in duplicates if the address in the banlist but the address
>> checked had a different case profile.

>>      # Go through possible senders.  Check if any of them are
>>      #   on the global ban list
>>      for sender in msg.get_senders():
>>          if sender.lower() in banlist:
>
> Not necessary to lowercase sender here as msg.get_senders() always
> returns lowercased addresses unless called with a preserve_case argument
> with a True value.

Thanks.  It was more of a just to make sure thing.

Actually, I code I was referring to was in Read_GlobalBan_File:

def Read_GlobalBan_File(ban_file):
     try:
         with open(ban_file) as f:
             for addr in f:
                 # strip and lowercase addr
                 addr = addr.lower().strip()
                 # if addr is not in banlist, add it - to avoid 
duplicates, should not add blank addresses
                 if (addr) and (addr not in banlist):
                     banlist.append(addr)

In previous versions, lower() and strip() were in the banlist.append not 
where they are now.  That would have allowed the possibility of 
duplicates if the same addr was presented with different cases (i.e. 
jdoe at example.com and JDoe at example.com)

>> # copied almost verbatim from Mailman/Handlers/Moderate.py
>> def do_discard_globalban(mlist, msg, sender):
>>      # forward auto-discards to list owners?
>>      if mlist.forward_auto_discards:
>
> Note that no forwarding of the discard occurs unless the list's Privacy
> options... -> Sender filters -> forward_auto_discards is set to Yes.
> Otherwise, no notice is sent and the only indication is a "Message
> discarded, msgid: ..." entry in the 'vette' log.
>
> You may wish to remove the above condition.

I will let the list-owners decide if they want the messages. Granted, it 
will be all or nothing for the discards.

>>          lang = mlist.preferred_language
>>          nmsg = Message.UserNotification(mlist.GetOwnerEmail(),
>
> mlist.GetOwnerEmail() returns the LISTNAME-owner address which is the
> recipient of this mail. This argument can be a string with a single
> address as it's value as it is here or a list of strings, each of which
> is an address. So the above line could be changed to
>
>          nmsg = Message.UserNotification([
>                                           mlist.GetOwnerEmail(),
>                                           'you at example.com',
>                                           ],
>
> with whatever list of addresses you want, or maybe since list owners
> aren't much involved with this ban list
>
>          nmsg = Message.UserNotification('you at example.com',
>

Okay.  Makes sense.  Here is the modified do_discard_globalban code:

def do_discard_globalban(mlist, msg, sender):
     # forward discarded message to site administrator(s) if defined
     #    in mm_cfg.GLOBALBANLIST_NOTIFY
     notifylist = []
     if mm_cfg.GLOBALBANLIST_NOTIFY:
         notifylist.append(mm_cfg.GLOBALBANLIST_NOTIFY)

     # forward auto-discards to list owners?
     if mlist.forward_auto_discards:
         notifylist.append(mlist.GetOwnerEmail())

     # Send message if notifylist is not empty
     if notifylist:
         lang = mlist.preferred_language
         nmsg = Message.UserNotification(notifylist,
                                         mlist.GetBouncesEmail(),
                                         _('Global Ban List Auto-discard 
notification'),
                                         lang=lang)
         nmsg.set_type('multipart/mixed')
         text = MIMEText(Utils.wrap(_("""\
The sender - %(sender)s - of the attached message is on the Global Ban 
list.  Therefore, the message
has been automatically discarded.""")),
                         _charset=Utils.GetCharSet(lang))
         nmsg.attach(text)
         nmsg.attach(MIMEMessage(msg))
         nmsg.send(mlist)
     # Discard the message
     raise Errors.DiscardMessage


Thanks again for the help,
Chris

From javad at irannopendar.com  Wed Jul  3 23:02:08 2013
From: javad at irannopendar.com (Javad Hoseini-Nopendar)
Date: Thu, 4 Jul 2013 01:32:08 +0430
Subject: [Mailman-Users] How to create a topic?
Message-ID: <003f01ce7833$e9993440$0201a8c0@home3c459be30f>

Hello
I have created a mailing list named IranRAVI at IranRAVI.com, but I have a
problem. I believe a few members of the mailing list don't really like to
receive all the emails of the list. They don't like to take part in
discussions. but they only like to receive the newsletters. Now I want to
create a Topic or a sub-mailing list. For example:
IranRAVI-Newsletter at IranRAVI.com

This way, when I send an email to IranRAVI-Newsletter at IranRAVI.com, the
subscribers of this list will only receive the newsletter, but can't reply
to group. They can only reply to the sender. At the same time, the
subscribers of IranRAVI at IranRAVI.com will also receive this email. The
subscribers of IranRAVI at IranRAVI.com should be able to take part in the
discussions by replying to the group. I know the users can change the
reply-address manually, but that is not what I am looking for. Maybe this
matter refers to Umbrella list, but I really couldn't make heads or tails of
umbrella lists. Please explain to me clearly what I should do.

Thanks in advance.


From kip at thevertigo.com  Thu Jul  4 01:28:30 2013
From: kip at thevertigo.com (Kip Warner)
Date: Wed, 03 Jul 2013 16:28:30 -0700
Subject: [Mailman-Users] Confirmation logging
In-Reply-To: <87ppv0wbrj.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <1372806873.27939.13.camel@rommel>
	<87ppv0wbrj.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <1372894110.6116.14.camel@rommel>

On Wed, 2013-07-03 at 12:41 +0900, Stephen J. Turnbull wrote:
> Each step of a subscription is logged.  IP addresses of web requests
> are logged, both in logs/subscribe and by the webserver.
> 
> IP addresses of the last remote MTA for a request by mail are logged
> by the local MTA.  IP address of the source MTA or MUA cannot be
> reliably determined in malicious cases, and even for honest messages,
> the source IP is both expensive to compute accurately and less than
> 100% reliable.  I don't think Mailman even tries to log these, but I
> don't have an actual case to hand in my own logs -- everybody uses the
> web interface.
> 
> It seems to me that you can probably comply with DreamHost's
> requirements simply by disabling processing of admin commands by
> mail.  Caveat: I haven't read DreamHost's policy so I don't know for
> sure.  Most likely very few people will be bothered.  You'll also want
> to edit the "please confirm" message to remove the reference to
> confirm by mail.  You could also achieve the same effect by requiring
> confirmation by mail, but this might require more invasive changes to
> the code.
> 
> I'm not sure how to disable admin-by-mail offhand, but Mark can
> probably help.

Hey Stephen. Thanks for your help. I passed on your comments to DH and
this is what they said:

        The web interface has the same problem as the mail interface --
        the logs rotate and are not available after a certain span of
        time. Everything else in [Stephen's] email is theoretical and
        not applicable to our installation as it exists now.

It just seems goofy, given that they allow us to use Mailman for a
discussion list, but not as an announcement list. The only practical
difference between the former and latter is that only one person is
typically allowed to post in the latter case, whereas both situations
can potentially have a post with thousands of recipients.

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130703/62ccdfca/attachment.pgp>

From mark at msapiro.net  Thu Jul  4 03:21:33 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 03 Jul 2013 18:21:33 -0700
Subject: [Mailman-Users] Confirmation logging
In-Reply-To: <1372894110.6116.14.camel@rommel>
References: <1372806873.27939.13.camel@rommel>
	<87ppv0wbrj.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1372894110.6116.14.camel@rommel>
Message-ID: <51D4CE1D.8040007@msapiro.net>

On 07/03/2013 04:28 PM, Kip Warner wrote:
> 
> Hey Stephen. Thanks for your help. I passed on your comments to DH and
> this is what they said:
> 
>         The web interface has the same problem as the mail interface --
>         the logs rotate and are not available after a certain span of
>         time. Everything else in [Stephen's] email is theoretical and
>         not applicable to our installation as it exists now.


Well, I don't know what they mean by theoretical. Stephen's post, which
correctly mentioned MTA and web server logs which I had ignored in my
reply, was right on target.

Perhaps if you had a simple script that ran daily under cron that picked
up new entries from the subscribe log, correlated them with MTA and web
server logs and wrote sufficient information to a cumulative file would
satisfy them.

Or possibly you could require admin approval for subscribes and convince
them that you will collect sufficient info before approving a
subscription, although that would be a pain if there were many subscribes.


> It just seems goofy, given that they allow us to use Mailman for a
> discussion list, but not as an announcement list. The only practical
> difference between the former and latter is that only one person is
> typically allowed to post in the latter case, whereas both situations
> can potentially have a post with thousands of recipients.


Yes, it is goofy, but they can set any policy they want for use of their
service, no matter how irrational.

What if you set your list up as a "discussion" list and just decide to
moderate everyone and only allow posts with an Approved: <password>
header and only give the password to one or a few people. Would that be
a violation?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130703/ac4a46ae/attachment.pgp>

From stephen at xemacs.org  Thu Jul  4 04:21:47 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 04 Jul 2013 11:21:47 +0900
Subject: [Mailman-Users] Confirmation logging
In-Reply-To: <1372894110.6116.14.camel@rommel>
References: <1372806873.27939.13.camel@rommel>
	<87ppv0wbrj.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1372894110.6116.14.camel@rommel>
Message-ID: <87fvvvvzd0.fsf@uwakimon.sk.tsukuba.ac.jp>

Kip Warner writes:

 > Hey Stephen. Thanks for your help. I passed on your comments to DH and
 > this is what they said:
 > 
 >         The web interface has the same problem as the mail interface --
 >         the logs rotate and are not available after a certain span of
 >         time. Everything else in [Stephen's] email is theoretical and
 >         not applicable to our installation as it exists now.

So they're changing their story!

AFAICS, log rotation is *not* a Mailman function -- it's a *host*
function.  (Mark will know for sure, I'm not that familiar with the
logging code, but I can't see any provision for rotation in either the
logging code or in our stock cronjobs.)  On my Debian GNU/Linux host,
it's done via logrotate.  In any case, if they want the logs, *they*
can keep the logs.  *They* have root, *they* own the disk, *they*
should know about cron.

I don't know how important Dreamhost is to you, what features they
offer.  But it seems to me that either they don't understand the
services they offer, or they're merely offering specious excuses that
they hope you'll accept for not doing what you want.  I'd consider
looking for somebody who *does* know what they're offering (but then,
I run my own hosts for exactly that reason -- I am not 100% informed
about everything I do, but I know what I don't know and where to find
more information at need).

 > It just seems goofy, given that they allow us to use Mailman for a
 > discussion list, but not as an announcement list. The only practical
 > difference between the former and latter is that only one person is
 > typically allowed to post in the latter case, whereas both situations
 > can potentially have a post with thousands of recipients.

Dealing with spam turns otherwise sane sysadmins into blubbering
goofballs.  I sympathize with you, not with them, but I have to admit
that keeping up with the spammers is a full-time job -- or two!, and
they have other work to do.  In a world where people blacklist whole
netblocks for a few spams, they're seriously at risk.

There's a fine line dividing announce-only lists from spamming.  I'm
not sure why they think keeping IP addresses is going to help them
draw the line; I think they're just grasping at any straw.  Or, as I
suggested earlier, maybe it's just an excuse.

Sorry I can't be of more help, but I think this is a political
problem, not a technical one.

Regards,
Steve

From stephen at xemacs.org  Thu Jul  4 04:51:20 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 04 Jul 2013 11:51:20 +0900
Subject: [Mailman-Users]  How to create a topic?
In-Reply-To: <003f01ce7833$e9993440$0201a8c0@home3c459be30f>
References: <003f01ce7833$e9993440$0201a8c0@home3c459be30f>
Message-ID: <87ehbfvxzr.fsf@uwakimon.sk.tsukuba.ac.jp>

Javad Hoseini-Nopendar writes:

 > I have created a mailing list named IranRAVI at IranRAVI.com, but I have a
 > problem. I believe a few members of the mailing list don't really like to
 > receive all the emails of the list. They don't like to take part in
 > discussions. but they only like to receive the newsletters. Now I want to
 > create a Topic or a sub-mailing list. For example:
 > IranRAVI-Newsletter at IranRAVI.com

This requirement is quite simple: just add IranRAVI at IranRAVI.com as a
subscriber to IranRAVI-Newsletter at IranRAVI.com.  Tell users to
subscribe to only one of the two lists, or they will receive duplicates.

 > This way, when I send an email to IranRAVI-Newsletter at IranRAVI.com, the
 > subscribers of this list will only receive the newsletter, but can't reply
 > to group. They can only reply to the sender.

You cannot do exactly what you say with Mailman.  The "Reply-To"
function is part of the mail client the subscriber uses, and Mailman
cannot prevent them from sending mail to any address they like.

 > At the same time, the subscribers of IranRAVI at IranRAVI.com will
 > also receive this email. The subscribers of IranRAVI at IranRAVI.com
 > should be able to take part in the discussions by replying to the
 > group.

What you can do is

- Set IranRAVI-Newsletter to refuse member posts.
- Set IranRAVI-Newsletter to accept posts from you (and other
  authorized posters' addresses, if any).
- Set IranRAVI-Newsletter to DISCARD (not REJECT!) posts from anyone
  else.
- Set IranRAVI-Newsletter's reply-to to the appropriate address (which
  can be the same as the authorized posting address, but doesn't need
  to be).

All of the above is perfectly safe, since the Newsletter is intended
to be read-only, and its subscribers want that.  Then

- Set IranRAVI's reply-to to the list, OR

This can create problems depending on the nature of the list.  If a
subscriber decides to send a nasty message to another one, *both*
reply to list and reply to author send to the *list*.  This almost
forces them to hold their fight in public, which you probably don't
want.

- Set IranRAVI's reply-to to remove existing reply-to, OR

This can also create problems if any of your users are sophisticated
enough to use Reply-To themselves, but you need to remove the Reply-To
set by IranRAVI-Newsletter (which is sending posts to IranRAVI).

- Add a Handler to the mail processing pipeline to remove the
  IranRAVI-Newsletter Reply-To from posts to IranRAVI.

This is safe but you need to be able and willing to add code to your
Mailman installation, and add a configuration option to IranRAVI using
the command-line tool (it's not possible from the web interface).
This is also fairly safe because it will only affect IranRAVI, and
it's easy to test and fix.  If you are interested in this option, let
us know and we can explain the procedure.

From mark at msapiro.net  Thu Jul  4 06:44:46 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 03 Jul 2013 21:44:46 -0700
Subject: [Mailman-Users] Writing a custom handler
In-Reply-To: <51D437EB.5070403@scu.edu>
References: <51D1BB44.2060000@scu.edu> <51D20436.4050300@msapiro.net>
	<51D2F64D.80809@scu.edu> <51D30B06.5000500@msapiro.net>
	<51D31E21.8030601@scu.edu> <51D32738.4040500@msapiro.net>
	<51D33CDF.3080209@scu.edu> <51D34812.4060000@msapiro.net>
	<51D34FAF.2010907@scu.edu> <51D36F1A.6050909@msapiro.net>
	<51D437EB.5070403@scu.edu>
Message-ID: <51D4FDBE.7040009@msapiro.net>

On 07/03/2013 07:40 AM, Chris Nulk wrote:
> 
> On 7/2/2013 5:23 PM, Mark Sapiro wrote:
>> On 07/02/2013 03:09 PM, Chris Nulk wrote:

>>
>> Not necessary to lowercase sender here as msg.get_senders() always
>> returns lowercased addresses unless called with a preserve_case argument
>> with a True value.
> 
> Thanks.  It was more of a just to make sure thing.


OK.


> Actually, I code I was referring to was in Read_GlobalBan_File:


Yes, I understood that. I didn't comment on the change to
Read_GlobalBan_File as I had no comment.


> Okay.  Makes sense.  Here is the modified do_discard_globalban code:
> 
> def do_discard_globalban(mlist, msg, sender):
>     # forward discarded message to site administrator(s) if defined
>     #    in mm_cfg.GLOBALBANLIST_NOTIFY
>     notifylist = []
>     if mm_cfg.GLOBALBANLIST_NOTIFY:
>         notifylist.append(mm_cfg.GLOBALBANLIST_NOTIFY)


You might consider making mm_cfg.GLOBALBANLIST_NOTIFY a list of 1 or
more addresses in which case the above would be

    if mm_cfg.GLOBALBANLIST_NOTIFY:
        notifylist.extend(mm_cfg.GLOBALBANLIST_NOTIFY)

or you could get fancy and test if it's a list or a string and extend or
append accordingly.

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

From eminmn at sysmatrix.net  Thu Jul  4 13:15:11 2013
From: eminmn at sysmatrix.net (e.c.)
Date: Thu, 4 Jul 2013 06:15:11 -0500
Subject: [Mailman-Users] Related question about limiting postings [was:
 Is there any throttle function in mailman?]
In-Reply-To: <51CC8078.9000108@msapiro.net>
References: <CAM4eEPKHK=M0NnTnVkuu1GqVSRn9XyePSEjhM1WomxHoRMybTg@mail.gmail.com>
	<51CC8078.9000108@msapiro.net>
Message-ID: <CAM4eEPJZz5j2Sixj__4gZXUv+aLmd2aX7uVDXk5GAAnaGBXNBA@mail.gmail.com>

Thanks, Mark. Apparently the option to provide for limiting postings is a
hard problem. The Sympa people didn't know whether it could be accomplised
with a scenario or not. I will start reading the mailman developers archive
and submit a request for such features in mailman ver. 3.

On Thu, Jun 27, 2013 at 1:12 PM, Mark Sapiro <mark at msapiro.net> wrote:

> On 06/27/2013 09:30 AM, e.c. wrote:
> >
> > Two possibly related features available on the LISTSERV product are (1)
> > limiting postings per listmember and (2) per list.
> [...]
> > Could they be implemented on mailman (or postfix, exim, sendmail)?
>
>
> Mailman is open source so anyone is free to modify it to include these
> features. It shouldn't be too difficult for someone familiar with
> Mailman's internals.
>

I hope you're right about that assessment of the difficulty. If it really
is rather easy, I would be willing to pay a python (or Linux) wizard to add
that functionality.


>
> It is very unlikely that these features will ever be
> implemented/included in a GNU Mailman 2.1 release. Possibly they could
> be considered for Mailman 3. You could submit a feature request (bug
> report) at <https://bugs.launchpad.net/mailman/+filebug> and tag it
> 'mailman3'.
>
>
> > is it
> > possible to use mailmain with LSMTP  on Gnu/Linux? Any advice would be
> > appreciated.
>
>
> Isn't LSMTP a Windows product?
>

I know that there is a limited free version of LISTSERV that runs on
Gnu/Linux but I don't know if LSMTP can be used in that context.



>
>
> > Apologies if this should have gone to a developers forum. I don't know
> > where that is.
>
>
> <http://mail.python.org/mailman/listinfo/mailman-developers>
>
> --
> Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
>

From dave at fiteyes.com  Thu Jul  4 20:58:17 2013
From: dave at fiteyes.com (David)
Date: Thu, 4 Jul 2013 14:58:17 -0400
Subject: [Mailman-Users] Migration to a new server: recommendations for
 testing the new Mailman server before changing DNS records;
 also how to avoid lost/bounced messages during change-over?
Message-ID: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>

Hi. Well, Mailman and Linode have been very trouble-free for the last year
(or more). It's been great! We are making some changes although we are
sticking with Mailman and Linode. We are moving to a new physical server
(and new OS -- Debian). Our hostname and domain name are not changing. (In
fact, our IP address won't change either, thanks to Linode's ability to
easily swap IP addresses between servers.)

Our sysadmin has the new Debian server set up, Mailman is installed and our
lists are copied over. This new server does not yet have our domain name or
IP address. We want to test the new setup before making those changes.

I would appreciate some recommendations for how to do this testing. What
mail functions can we test? (Our MX records don't point to the new server
yet.) Afaik, we can't really test normal mail processing in advance of
making the final cut-over (or can we?). Are there things in addition to
changing /etc/hosts that I can implement on my computer for testing the new
Mailman server? Any ideas or suggestions are appreciated.

Also, in terms of the actual cut-over, how can we avoid bounced or lost
messages if it takes several hours to transition?

My plan is roughly something like this:

First I will moderate any pending messages. Then I will stop mailman. At
this point our sysadmin will do a final data migration. Then I will shut
down the server. I will do the IP swap at Linode. Then I will boot up the
new server. I hope we can do all that within a window of about an hour. I
appreciate any advice on this too.

For reference, here are some posts I have read in preparation for this move:

How do I move a list to a different server-Mailman installation. -
Documentation - Confluence
http://wiki.list.org/pages/viewpage.action?pageId=4030682

Re: [Mailman-Developers] Upgrading from 2.0.10 to 2.1.b2
http://www.mail-archive.com/mailman-developers at python.org/msg03127.html

[Mailman-Users] migrating mailman lists
http://mail.python.org/pipermail/mailman-users/2007-January/055208.html

[Mailman-Users] migrating mailman lists
http://mail.python.org/pipermail/mailman-users/2007-January/055211.html

[Mailman-Users] export/import of lists
http://mail.python.org/pipermail/mailman-users/2004-June/037086.html


BTW, does anyone have an itemized check list of all files that need to be
copied? The posts above are not 100% complete (afaik) because, for example,
they don't consider that some apache config settings may be related to
Mailman. In our case we have ScriptAlias /m/ /usr/lib/cgi-bin/mailman/ and
related changes.

Furthermore, files like /etc/mailname are related to Mailman configuration.

If anyone has or can come up with an itemized, file-by-file, checklist, I
would like to be able to offer that to our sysadmin. The only alternative I
know is a trial and error approach to making sure we don't overlook
anything, and I prefer to avoid that method (especially the "and error"
part!).

Regards,
David

From stephen at xemacs.org  Fri Jul  5 02:08:19 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 05 Jul 2013 09:08:19 +0900
Subject: [Mailman-Users] Migration to a new server: recommendations for
 testing the new Mailman server before changing DNS records;
 also how to avoid lost/bounced messages during change-over?
In-Reply-To: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>
References: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>
Message-ID: <878v1lx40c.fsf@uwakimon.sk.tsukuba.ac.jp>

David writes:

 > If anyone has or can come up with an itemized, file-by-file,
 > checklist,

There's not going to be anything like that.  These things differ from
OS to OS and from site to site.

I can tell you that aside from standard Mailman code, docs, and
website data, Debian's mailman package installs the following
configuration directories and files:

/etc
/etc/init.d
/etc/init.d/mailman
/etc/cron.d
/etc/cron.d/mailman                          # Debian location
/etc/logrotate.d
/etc/logrotate.d/mailman                     # Debian addition
/etc/mailman
/etc/mailman/apache.conf                     # Debian location
/usr/share/doc/mailman/images
/usr/lib/mailman/mail/wrapper
/usr/lib/mailman/bin/postfix-to-mailman.py   # Debian addition
/usr/lib/mailman/bin/qmail-to-mailman.py     # Debian addition
/usr/lib/mailman/Mailman/mm_cfg.py           # Debian modifications?

Notes: "Debian location" indicates files that contain standard
configuration but on Debian are in these locations -- you need to read
them to figure out what is there.  "Debian addition" are files that
Debian adds.  Pay special attention to logrotate, as the Debian policy
for keeping log files may not be what you want.  We do not recommend
use of postfix-to-mailman.py, although "it works for me".  We know
that is doesn't work for some people.  YMMV.  I don't know about
qmail-to-mailman.py, but I would guess that similar caveat applies.
Of course if you're using a different MTA you don't need to worry
about these files.  Finally, I don't know if there are Debian-specific
modifications in mm_cfg.py, but you may want to beware of that.  I
recommend you save Debian's version, copy yours over, and do a diff.


From kip at thevertigo.com  Fri Jul  5 04:22:09 2013
From: kip at thevertigo.com (Kip Warner)
Date: Thu, 04 Jul 2013 19:22:09 -0700
Subject: [Mailman-Users] Confirmation logging
In-Reply-To: <87fvvvvzd0.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <1372806873.27939.13.camel@rommel>
	<87ppv0wbrj.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1372894110.6116.14.camel@rommel>
	<87fvvvvzd0.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <1372990929.6116.115.camel@rommel>

On Thu, 2013-07-04 at 11:21 +0900, Stephen J. Turnbull wrote:
> Sorry I can't be of more help, but I think this is a political
> problem, not a technical one.

Hey Steve,

Yes indeed. I'd say it's just pure lazyiness. This is what they said in
response to your comments.

        Our  Mailman is set-up to serve a specific use case. All configuration
        choices made are to that end. You are requesting that we make changes to
        our overall service so that the Discussion lists can serve a purpose that
        they are not intended for and can already be achieved a number of
        different ways. It's not going to happen. All of the requested changes
        are theoretically possible, but they aren't likely to happen any time
        soon, if ever. 
        
        We will not be changing our Discussion list service so that it can act as
        an Announcement list service. We already have an Announcement list
        service that meets that need.

They want me to use their ad-hoc announcement list feature which is
useless. I already have Mailman subscribers in the hundreds and there is
no straightforward way to have them moved to their DH list without
resending confirmations out to hundreds of people. Moreover, their ad
hoc announcement list is not only feature poor, but non-free and I don't
want to use it largely for that reason.

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130704/47974dd9/attachment.pgp>

From mark at msapiro.net  Fri Jul  5 04:49:53 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 04 Jul 2013 19:49:53 -0700
Subject: [Mailman-Users] Migration to a new server: recommendations for
 testing the new Mailman server before changing DNS records;
 also how to avoid lost/bounced messages during change-over?
In-Reply-To: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>
References: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>
Message-ID: <51D63451.9040006@msapiro.net>

On 07/04/2013 11:58 AM, David wrote:
> 
> Our sysadmin has the new Debian server set up, Mailman is installed and our
> lists are copied over. This new server does not yet have our domain name or
> IP address. We want to test the new setup before making those changes.
> 
> I would appreciate some recommendations for how to do this testing. What
> mail functions can we test? (Our MX records don't point to the new server
> yet.) Afaik, we can't really test normal mail processing in advance of
> making the final cut-over (or can we?).


If the mail server on the new box thinks list domains are in its local
delivery space (mydestination in Postfix), you can just send mail from
an MUA on the local box configured to deliver via SMTP to the local MTA,
and it all should work except that mail from Mailman to local addresses
will be delivered to the new box instead of the current live box.


> Are there things in addition to
> changing /etc/hosts that I can implement on my computer for testing the new
> Mailman server? Any ideas or suggestions are appreciated.


Adding an entry for 127.0.0.1 (IPv4) with the domain name should be
enough for a local web browser to access Mailman.


> Also, in terms of the actual cut-over, how can we avoid bounced or lost
> messages if it takes several hours to transition?


You need to stop the MTA on the old box so it doesn't accept mail that
won't get moved.

Then, during the transition before the IP is moved to the new box, mail
to the MTAs attempting to deliver to to IP will get a connection refused
or a time out; probably connection refused because nothing is listening
on port 25. This is a retryable error. Possibly the majority of MTAs
will retry for 5 days before giving up and bouncing the mail. Almost all
will retry for at least 24 hours. Only a pathological few will bounce
the mail within a few hours, although some may send a delayed DSN after
say 4 hours but keep trying.


> My plan is roughly something like this:
> 
> First I will moderate any pending messages. Then I will stop mailman. At
> this point our sysadmin will do a final data migration. Then I will shut
> down the server.


If you stop Mailman before stopping the MTA, be sure that Mailman's
qfiles are migrated.


> I will do the IP swap at Linode. Then I will boot up the
> new server. I hope we can do all that within a window of about an hour. I
> appreciate any advice on this too.
> 
> For reference, here are some posts I have read in preparation for this move:
> 
> How do I move a list to a different server-Mailman installation. -
> Documentation - Confluence
> http://wiki.list.org/pages/viewpage.action?pageId=4030682
> 
> Re: [Mailman-Developers] Upgrading from 2.0.10 to 2.1.b2
> http://www.mail-archive.com/mailman-developers at python.org/msg03127.html
> 
> [Mailman-Users] migrating mailman lists
> http://mail.python.org/pipermail/mailman-users/2007-January/055208.html
> 
> [Mailman-Users] migrating mailman lists
> http://mail.python.org/pipermail/mailman-users/2007-January/055211.html
> 
> [Mailman-Users] export/import of lists
> http://mail.python.org/pipermail/mailman-users/2004-June/037086.html
> 
> 
> BTW, does anyone have an itemized check list of all files that need to be
> copied? The posts above are not 100% complete (afaik) because, for example,
> they don't consider that some apache config settings may be related to
> Mailman. In our case we have ScriptAlias /m/ /usr/lib/cgi-bin/mailman/ and
> related changes.


Many posts on this subject are not 100% complete because they are based
on a standard GNU Mailman installation of Mailman itself. They do not
address the issue of getting Mailman installed and working as you want
on the new server. As Stephen points out, this is highly dependent on
source vs. package install, which package and what things have been
locally tweaked.

>From the Mailman point of view, at least for a source install, the only
things that need to be moved are the contents of Mailman's var-prefix
directory which are the directories
$var-prefix/archives/
$var-prefix/data/
$var-prefix/lists/
$var-prefix/locks/
$var-prefix/logs/
$var-prefix/qfiles/ and
$var-prefix/spam/

Everything else comes under the heading of making Mailman work on the
new server as opposed to migrating lists, archives, etc. from the old
server.

This is further confused and complicated by the fact that various
packages split that into different places. For example, RedHat puts some
of these directories in /var/lib/mailman, but locks/ is
/var/lock/mailman/, logs is /var/log/mailman/ and qfiles is
/var/spool/mailman.


> Furthermore, files like /etc/mailname are related to Mailman configuration.


I happen to know that this is a Debian package trick for providing the
group with which the MTA invokes the mail wrapper to the wrapper without
recompiling the wrapper (is there a similar one for the web server
group?), but I can't possibly know all these things for all packages
(See the FAQ at <http://wiki.list.org/x/OIDD>).


> If anyone has or can come up with an itemized, file-by-file, checklist, I
> would like to be able to offer that to our sysadmin. The only alternative I
> know is a trial and error approach to making sure we don't overlook
> anything, and I prefer to avoid that method (especially the "and error"
> part!).


If Mailman works on the new box, all you need to move is the mutable
data described above. There is one important

CAVEAT! The contents of the archives/public/ directory are symlinks. You
don't actually have to move them at all as they are rewritten as needed
each time a list is saved, but if you do move them, you MUST move the
symlinks, not the referent directories in archives/private/.

If you move the referent directories, that static structure will never
be updated and the 'pipermail' public archive URL will continue to show
the archive as of the move. The actual archive in archives/private will
be updated and the updated will be visible via the 'private' URL but not
via the 'public' one.

Also note that if you are using an MTA with manual Mailman aliases, you
need to move those too. This does not apply to Postfix with
Postfix/Mailman integration as in that case, Mailman's aliases are in
the $var-prefix/data/ directory.

Finally, after the migration, run Mailman's bin/check_perms to be sure
ownership and permissions are OK. It wouldn't hurt to run it on the old
box before the move to get a baseline (some packages tend to use
symlinks which check_perms was not designed to handle).

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

From stephen at xemacs.org  Fri Jul  5 16:23:23 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Fri, 05 Jul 2013 23:23:23 +0900
Subject: [Mailman-Users] Confirmation logging
In-Reply-To: <1372990929.6116.115.camel@rommel>
References: <1372806873.27939.13.camel@rommel>
	<87ppv0wbrj.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1372894110.6116.14.camel@rommel>
	<87fvvvvzd0.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1372990929.6116.115.camel@rommel>
Message-ID: <8761wpw0f8.fsf@uwakimon.sk.tsukuba.ac.jp>

Kip Warner writes:

 > Yes indeed. I'd say it's just pure lazyiness.

Sorry to hear that.  If there's anything we can do to help, let us
know.

And they may see the light.  Anything's possible, these days:
cPanel has decided to adopt a positive attitude and support us with
feature requests and possibly code to implement them.  Yay!  :-)

Steve

From kip at thevertigo.com  Sat Jul  6 01:38:01 2013
From: kip at thevertigo.com (Kip Warner)
Date: Fri, 05 Jul 2013 16:38:01 -0700
Subject: [Mailman-Users] Confirmation logging
In-Reply-To: <8761wpw0f8.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <1372806873.27939.13.camel@rommel>
	<87ppv0wbrj.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1372894110.6116.14.camel@rommel>
	<87fvvvvzd0.fsf@uwakimon.sk.tsukuba.ac.jp>
	<1372990929.6116.115.camel@rommel>
	<8761wpw0f8.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <1373067481.7037.19.camel@rommel>

On Fri, 2013-07-05 at 23:23 +0900, Stephen J. Turnbull wrote:
> Sorry to hear that.  If there's anything we can do to help, let us
> know.

Hey Steve. You've been most helpful. You've helped me realize that as
soon as the first opportunity presents itself, I'm going to finally get
off DreamHost. They are great for the mid level to advanced tech savvy
crowd, but it's easy to hit the artificial limitations they put on their
users.

> And they may see the light.  Anything's possible, these days:
> cPanel has decided to adopt a positive attitude and support us with
> feature requests and possibly code to implement them.  Yay!  :-)

Good for them. I hope it will be beneficial for both parties.

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130705/8c5c1b3c/attachment.pgp>

From daveblakemore at rogers.com  Sat Jul  6 00:26:32 2013
From: daveblakemore at rogers.com (Dave Blakemore)
Date: Fri, 5 Jul 2013 18:26:32 -0400
Subject: [Mailman-Users] bounce processing / bounce score
Message-ID: <02a601ce79ce$b3ec3a30$1bc4ae90$@rogers.com>

I am trying to determine how many bounces are occurring and to who, but
cannot figure out where to look.

 

Specifically I have one user who is not receiving notes and I am wondering
if it is at her end or mine.

 

I went to the administrator panel, the 2 most obvious possibilities seemed
to be "bounce processing" and "membership management" but could not find
anything.

 

How can I see bounced mail? 

 

Dave


From stephen at xemacs.org  Sat Jul  6 13:34:22 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sat, 06 Jul 2013 20:34:22 +0900
Subject: [Mailman-Users]  bounce processing / bounce score
In-Reply-To: <02a601ce79ce$b3ec3a30$1bc4ae90$@rogers.com>
References: <02a601ce79ce$b3ec3a30$1bc4ae90$@rogers.com>
Message-ID: <87txk7vs5d.fsf@uwakimon.sk.tsukuba.ac.jp>

Dave Blakemore writes:

 > Specifically I have one user who is not receiving notes

It would help if you are more precise about this.  Never received
anything since subscription?  Check the subscribed address for
accuracy.  I'm not sure how you can check for invisible characters
(like space and tab), Mark would know.  Suddenly stopped receiving,
and nothing since?  Intermittently?  If so, is it only her posts she
doesn't receive?  (If yes, betcha she's a Gmail user).

 > and I am wondering if it is at her end or mine.

Check the membership management page for her address, and see if
delivery has been disabled for bouncing.  If not, the mail is still
going out from your end.

You could also check logs/bounce, but you'll only find how many
bounces are being processed in total, not whose.

You could also check the MTA queues and logs for temporary and
permanent failures to her address.

 > How can I see bounced mail? 

The delivery status notification?  As far as I know you can only see
it normally when it's an unknown format.  It doesn't contain any
interesting information that isn't in other places, anyway.

From mark at msapiro.net  Sat Jul  6 20:20:37 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 06 Jul 2013 11:20:37 -0700
Subject: [Mailman-Users] bounce processing / bounce score
In-Reply-To: <87txk7vs5d.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <02a601ce79ce$b3ec3a30$1bc4ae90$@rogers.com>
	<87txk7vs5d.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <51D85FF5.1050403@msapiro.net>

On 07/06/2013 04:34 AM, Stephen J. Turnbull wrote:
> Dave Blakemore writes:
> 
>  > Specifically I have one user who is not receiving notes
> 
> ...
> I'm not sure how you can check for invisible characters
> (like space and tab), Mark would know.


For some time, Mailman has not allowed subscription of an address with
whitespace or 'invalid' characters, but if you have command line access,

bin/list_members -i <listname>

will print any addresses with invalid characters although the invalid
characters ma not themselves be displayed.


> 
>  > and I am wondering if it is at her end or mine.
> 
> Check the membership management page for her address, and see if
> delivery has been disabled for bouncing.  If not, the mail is still
> going out from your end.
> 
> You could also check logs/bounce, but you'll only find how many
> bounces are being processed in total, not whose.


Actually, the bounce log shows the list, user and score for each bounce
from a list member address.

In addition, you can see the user's current bounce score if > 0 by
clicking the user's address in the Membership Management...-> Membership
List page to go to her user options page where that info is displayed.

Also, there is a withlist script at
<http://www.msapiro.net/scripts/get_bounce_info.py> which will display
bounce info for members that have any.


> You could also check the MTA queues and logs for temporary and
> permanent failures to her address.
> 
>  > How can I see bounced mail? 
> 
> The delivery status notification?  As far as I know you can only see
> it normally when it's an unknown format.  It doesn't contain any
> interesting information that isn't in other places, anyway.


The actual DSN is not available except that in the case where
bounce_notify_owner_on_disable is Yes, the one DSN that triggers the
disable is included in the notice to the owner.

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

From javad at irannopendar.com  Mon Jul  8 01:11:36 2013
From: javad at irannopendar.com (Javad Hoseini-Nopendar)
Date: Mon, 8 Jul 2013 03:41:36 +0430
Subject: [Mailman-Users] Problem with duplicate emails
Message-ID: <002c01ce7b67$55f8a6d0$0201a8c0@home3c459be30f>

Hello
I created two mailing lists on my website:
newsletter at iranravi.com
And:
iranravi at iranravi.com

Also, IranRAVI at IranRAVI.com is a member of newsletter at IranRAVI.com. That 
means, when I send an email to Newsletter at iranravi.com, if someone is not 
the member of this group, but is the member of IranRAVI at IranRAVI.com, this 
person will also receive the email. In fact, one group is only for sending 
newsletters and the other group is for discussing about various matters. now 
I have a problem. When I send an email, if someone is the member of both 
groups, this person will receive two copies of the email. Is there any way I 
can prevent duplicate emails? I saw a choice in General options:
Prevent Duplicate Emails.

I thought mailman would delete the duplicates automatically, but it seems 
not to be the case. Please help.

Thank you






From Richard at Damon-Family.org  Mon Jul  8 02:33:49 2013
From: Richard at Damon-Family.org (Richard Damon)
Date: Sun, 07 Jul 2013 20:33:49 -0400
Subject: [Mailman-Users] Problem with duplicate emails
In-Reply-To: <002c01ce7b67$55f8a6d0$0201a8c0@home3c459be30f>
References: <002c01ce7b67$55f8a6d0$0201a8c0@home3c459be30f>
Message-ID: <51DA08ED.9000900@Damon-Family.org>

On 7/7/13 7:11 PM, Javad Hoseini-Nopendar wrote:
> Hello
> I created two mailing lists on my website:
> newsletter at iranravi.com
> And:
> iranravi at iranravi.com
>
> Also, IranRAVI at IranRAVI.com is a member of newsletter at IranRAVI.com. That 
> means, when I send an email to Newsletter at iranravi.com, if someone is not 
> the member of this group, but is the member of IranRAVI at IranRAVI.com, this 
> person will also receive the email. In fact, one group is only for sending 
> newsletters and the other group is for discussing about various matters. now 
> I have a problem. When I send an email, if someone is the member of both 
> groups, this person will receive two copies of the email. Is there any way I 
> can prevent duplicate emails? I saw a choice in General options:
> Prevent Duplicate Emails.
>
> I thought mailman would delete the duplicates automatically, but it seems 
> not to be the case. Please help.
>
> Thank you
>
Since IranRAVI is a member of newsletter, and newsletter is announce
only, there really is no big reason to subscribe to both, you just need
to subscribe to IranRAVI and you will get all the messages, and can
reply to the discussion list about them.

The problem is that each list processes its sending independently, and
don't know about the details of the interlocking subscriptions, so I
don;t think there is any way to stop the multiple emails in this case.

-- 
Richard Damon


From mark at msapiro.net  Mon Jul  8 03:14:03 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 07 Jul 2013 18:14:03 -0700
Subject: [Mailman-Users] Problem with duplicate emails
In-Reply-To: <002c01ce7b67$55f8a6d0$0201a8c0@home3c459be30f>
References: <002c01ce7b67$55f8a6d0$0201a8c0@home3c459be30f>
Message-ID: <51DA125B.4080609@msapiro.net>

On 07/07/2013 04:11 PM, Javad Hoseini-Nopendar wrote:

> I have a problem. When I send an email, if someone is the member of both 
> groups, this person will receive two copies of the email. Is there any way I 
> can prevent duplicate emails? I saw a choice in General options:
> Prevent Duplicate Emails.


The choice in General Options "Filter out duplicate messages to list
members (if possible)" is a setting for new_member_options which
controls what usetr options are set by default for new subscribers to
the list. This affects the user option "Avoid duplicate copies of
messages?" which in turn only affects whether the user is sent a list
copy of the mail when the user is a direct To: or Cc: recipient of the post.


> I thought mailman would delete the duplicates automatically, but it seems 
> not to be the case. Please help.


You have two choices. Either tell members of the iranravi at iranravi.com
list not to subscribe to the newsletter at iranravi.com list as it will
only result in their receiving duplicates, or delete
iranravi at iranravi.com from the newsletter at iranravi.com list and instead
add iranravi at iranravi.com to the Non-digest options ->
regular_include_lists setting of the newsletter at iranravi.com list.

To make the second option completely effective, also set the
iranravi at iranravi.com list's Digest options -> digestable to No because
if there are any digest subscribers, they won't receive
newsletter at iranravi.com posts.

See 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

From audit at hostindia.net  Mon Jul  8 12:06:12 2013
From: audit at hostindia.net (Audit)
Date: Mon, 08 Jul 2013 15:36:12 +0530
Subject: [Mailman-Users] Request to mailing list Mailman-cabal rejected
In-Reply-To: <mailman.0.1373043570.14914.mailman-cabal@python.org>
References: <mailman.0.1373043570.14914.mailman-cabal@python.org>
Message-ID: <51DA8F14.2010007@hostindia.net>

On Friday 05 July 2013 10:29 PM, mailman-cabal-owner at python.org wrote:
> Your request to the Mailman-cabal mailing list
>
>      Posting of your message titled "Moderator not getting post
> notification"
>
> has been rejected by the list moderator.  The moderator gave the
> following reason for rejecting your request:
>
> "1) Putting the same address as both 'owner' and 'moderator' is
> redundant, see <http://wiki.list.org/x/WYA9>.
>
> 2) is the list's web admin General Options -> admin_immed_notify set
> to Yes?
>
> Do the owners/moderators receive the daily summary of outsting
> requests?
>
> To follow up or if you have other questions, please join the
> mailman-users at python.org list at
> <http://mail.python.org/mailman/listinfo/mailman-users> and post your
> request there.  Note that this is a publicly archived list.  Do not
> post personal information that you don't want to expose to the world.
> "
>
> Any questions or comments should be directed to the list administrator
> at:
>
>      mailman-cabal-owner at python.org
Hello there,

1) Putting the same address as both 'owner' and 'moderator' is
redundant,

I have removed email address from moderator field.

Still the mailing list moderator or owner not receiving notification email of member/non-member post to list.

2) is the list's web admin General Options -> admin_immed_notify set
to Yes?

Yes it is already set to Yes.

Do the owners/moderators receive the daily summary of outsting
requests?

No moderator does not receive any email from mailman.

I have found below logs in smtp-failure file of mailman:

Jul 08 13:15:00 2013 (26273) All recipients refused: {'all_cartesian-owner at exampledomain.com': (550, 'sorry, no mailbox here by that name. (#5.7.17)')}, msgid: <mailman.1.1373269495.26271.all_direxions
@exampledomain.com>
Jul 08 13:15:00 2013 (26273) delivery toall_cartesian-owner at exampledomain.com failed with code 550: sorry, no mailbox here by that name. (#5.7.17)
Jul 08 14:09:01 2013 (24312) All recipients refused: {'all_cartesian-owner at exampledomain.com': (550, 'sorry, no mailbox here by that name. (#5.7.17)')}, msgid: <mailman.1.1373272737.24310.all_direxions
@exampledomain.com>
Jul 08 14:09:01 2013 (24312) delivery toall_cartesian-owner at exampledomain.com failed with code 550: sorry, no mailbox here by that name. (#5.7.17)

Please help me to solve this issue.

Thanks






From mark at msapiro.net  Mon Jul  8 20:06:30 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 08 Jul 2013 11:06:30 -0700
Subject: [Mailman-Users] Moderator not receiving notices - was: Request
 to mailing list Mailman-cabal rejected
In-Reply-To: <51DA8F14.2010007@hostindia.net>
References: <mailman.0.1373043570.14914.mailman-cabal@python.org>
	<51DA8F14.2010007@hostindia.net>
Message-ID: <51DAFFA6.9060705@msapiro.net>

On 07/08/2013 03:06 AM, Audit wrote:
> 
> I have found below logs in smtp-failure file of mailman:
> 
> Jul 08 13:15:00 2013 (26273) All recipients refused:
> {'all_cartesian-owner at exampledomain.com': (550, 'sorry, no mailbox here
> by that name. (#5.7.17)')}


Your MTA does not know how to deliver mail to
all_cartesian-owner at exampledomain.com.

The solution depends on the MTA and how it delivers to Mailman, but most
likely it uses aliases and you are missing the alias for the -owner address.

See item 3 in the FAQ at <http://wiki.list.org/x/A4E9>.

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

From montoliu at cnb.csic.es  Mon Jul  8 21:12:30 2013
From: montoliu at cnb.csic.es (Lluis Montoliu)
Date: Mon, 08 Jul 2013 21:12:30 +0200
Subject: [Mailman-Users] lists lost labels (and footers) after moving
 mailman to a new server
Message-ID: <20130708211230.Horde.1e54VbAD0gVR2w8eA4BQgyA@webmail.csic.es>


Hi,

We have recently upgraded our web server to one with bigger capacity.  
Actual moving occurred earlier today and was done by our hosting  
provider (since we don't have access to root to our dedicated server).  
Moving involved transferring all services active, including our  
mailman lists.

Once moving has been completed we can see the lists have been actually  
moved, apparently correctly, configuration parameters remain the same  
as they were before, but, curiously enough, the messages are  
distributed without the usual label and without the footer, even  
though both label and footer are well defined in the configuration  
page and were working nicely in the old server configuration.

According to the hosting provider they transferred everything to the  
new server, including all parameters of the list. They have been  
investigating the cause of these missing labels and footers but so far  
could not find any obvious cause.

Things that I have tried so far:

1) Deleting the label, saving parameters, re-installing the label,  
saving parameters. Doesn't work, messages continue to be posted  
without label.

2) I created a new list in the new server, created a label for it,  
and, in this case, messages are posted with label in this newly  
created list in the new server location

I am using mailman 2.1.11

I have been searching for similar posts before posting this to the  
list. I couldn't find any.

Thanks for help and suggestions.

best regards

Lluis

-- 
Dr. Lluis Montoliu
Investigador Cientifico - Research Scientist CSIC
Centro Nacional de Biotecnologia (CNB-CSIC)
Campus de Cantoblanco
C/ Darwin, 3
28049 Madrid (Spain)
Tel. +34-91-5854844  / Fax +34-91-5854506
e-mail: montoliu at cnb.csic.es
WEB: http://www.cnb.csic.es/~montoliu/


From mark at msapiro.net  Mon Jul  8 22:12:41 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 08 Jul 2013 13:12:41 -0700
Subject: [Mailman-Users] lists lost labels (and footers) after moving
 mailman to a new server
In-Reply-To: <20130708211230.Horde.1e54VbAD0gVR2w8eA4BQgyA@webmail.csic.es>
References: <20130708211230.Horde.1e54VbAD0gVR2w8eA4BQgyA@webmail.csic.es>
Message-ID: <51DB1D39.1010804@msapiro.net>

On 07/08/2013 12:12 PM, Lluis Montoliu wrote:
> 
> Once moving has been completed we can see the lists have been actually
> moved, apparently correctly, configuration parameters remain the same as
> they were before, but, curiously enough, the messages are distributed
> without the usual label and without the footer, even though both label
> and footer are well defined in the configuration page and were working
> nicely in the old server configuration.


I assume by 'label' you mean subject_prefix.


> According to the hosting provider they transferred everything to the new
> server, including all parameters of the list. They have been
> investigating the cause of these missing labels and footers but so far
> could not find any obvious cause.
> 
> Things that I have tried so far:
> 
> 1) Deleting the label, saving parameters, re-installing the label,
> saving parameters. Doesn't work, messages continue to be posted without
> label.


I would not expect this to change anything. Presumably you are changing
these things via the web admin interface. Is this using the same
configuration file (lists/LISTNAME/config.pck) as the running Mailman?
I.e. is the web server pointing at a different file, maybe a backup made
during migration or even the old server?


> 2) I created a new list in the new server, created a label for it, and,
> in this case, messages are posted with label in this newly created list
> in the new server location


So Mailman is properly processing it. Thus, if it exists in the web
interface, it should be processed unless the web server and the Mailman
qrunners are using different copies of the list's config.pck.


> Thanks for help and suggestions.


If the hosting provider can't solve this, ask them to join this list and
contact us directly.

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

From dave at fiteyes.com  Mon Jul  8 22:29:56 2013
From: dave at fiteyes.com (David)
Date: Mon, 8 Jul 2013 16:29:56 -0400
Subject: [Mailman-Users] Migration to a new server: recommendations for
 testing the new Mailman server before changing DNS records;
 also how to avoid lost/bounced messages during change-over?
In-Reply-To: <51D63451.9040006@msapiro.net>
References: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>
	<51D63451.9040006@msapiro.net>
Message-ID: <CAH=dxU5vabyKXzpmqV4S6o3b-nF0VA3V-TMm+hts-TkJezo+HQ@mail.gmail.com>

On Thu, Jul 4, 2013 at 10:49 PM, Mark Sapiro <mark at msapiro.net> wrote:

> On 07/04/2013 11:58 AM, David wrote:
>
> If the mail server on the new box thinks list domains are in its local
> delivery space (mydestination in Postfix), you can just send mail from
> an MUA on the local box configured to deliver via SMTP to the local MTA,
> and it all should work except that mail from Mailman to local addresses
> will be delivered to the new box instead of the current live box.
>

The new box has no GUI. The OS is Debian 6.
$ uname -r
3.9.3-x86_64-linode33

The MUA is:
heirloom-mailx
$ mailx -V
12.5 6/20/10

The MTA is postfix. (For some reason I can't run "postconf -d | grep
mail_version" so I'll have to ask the sysadmin later about that. But at the
moment, I don't know the postfix version.)

Given that info, which settings changes should I make to proceed with the
testing plan you described above?

So far all I did was:
1. create a ~/.mailrc file with contents:

set smtp=localhost

2. edit /etc/postfix/main.cf and change mydestination to the line below:
mydestination = localhost, localhost.localdomain

I did not restart postfix yet... I appreciate any feedback regarding next
steps.

From montoliu at cnb.csic.es  Mon Jul  8 23:06:40 2013
From: montoliu at cnb.csic.es (Lluis Montoliu)
Date: Mon, 8 Jul 2013 23:06:40 +0200
Subject: [Mailman-Users] lists lost labels (and footers) after moving
	mailman to a new server
In-Reply-To: <51DB1D39.1010804@msapiro.net>
References: <20130708211230.Horde.1e54VbAD0gVR2w8eA4BQgyA@webmail.csic.es>
	<51DB1D39.1010804@msapiro.net>
Message-ID: <F13025B1-EC47-494A-9262-9CC071173BF6@cnb.csic.es>

Thanks Mark, yes I am referring to subject_prefix (and footers) and I am using only the web interface. 

Good suggestion about mailman pointing to a different config file, but that would be strange since everything worked before (regarding labels and footers) in the old server.  

Will transmit your suggestions to our hosting.

Thanks again

Lluia

--
Lluis Montoliu, PhD
Research Scientist CSIC
Centro Nacional de Biotecnologia (CNB)
Darwin 3, 28049 Madrid - Spain
Tel. +34 915854844
email: montoliu at cnb.csic.es
web: http://www.cnb.csic.es/~montoliu

El 08/07/2013, a las 10:12 PM, Mark Sapiro <mark at msapiro.net> escribi?:

> On 07/08/2013 12:12 PM, Lluis Montoliu wrote:
>> 
>> Once moving has been completed we can see the lists have been actually
>> moved, apparently correctly, configuration parameters remain the same as
>> they were before, but, curiously enough, the messages are distributed
>> without the usual label and without the footer, even though both label
>> and footer are well defined in the configuration page and were working
>> nicely in the old server configuration.
> 
> 
> I assume by 'label' you mean subject_prefix.
> 
> 
>> According to the hosting provider they transferred everything to the new
>> server, including all parameters of the list. They have been
>> investigating the cause of these missing labels and footers but so far
>> could not find any obvious cause.
>> 
>> Things that I have tried so far:
>> 
>> 1) Deleting the label, saving parameters, re-installing the label,
>> saving parameters. Doesn't work, messages continue to be posted without
>> label.
> 
> 
> I would not expect this to change anything. Presumably you are changing
> these things via the web admin interface. Is this using the same
> configuration file (lists/LISTNAME/config.pck) as the running Mailman?
> I.e. is the web server pointing at a different file, maybe a backup made
> during migration or even the old server?
> 
> 
>> 2) I created a new list in the new server, created a label for it, and,
>> in this case, messages are posted with label in this newly created list
>> in the new server location
> 
> 
> So Mailman is properly processing it. Thus, if it exists in the web
> interface, it should be processed unless the web server and the Mailman
> qrunners are using different copies of the list's config.pck.
> 
> 
>> Thanks for help and suggestions.
> 
> 
> If the hosting provider can't solve this, ask them to join this list and
> contact us directly.
> 
> -- 
> Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at python.org
> http://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Security Policy: http://wiki.list.org/x/QIA9
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-users/montoliu%40cnb.csic.es

From mark at msapiro.net  Tue Jul  9 00:27:41 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 08 Jul 2013 15:27:41 -0700
Subject: [Mailman-Users] Migration to a new server: recommendations for
 testing the new Mailman server before changing DNS records;
 also how to avoid lost/bounced messages during change-over?
In-Reply-To: <CAH=dxU5vabyKXzpmqV4S6o3b-nF0VA3V-TMm+hts-TkJezo+HQ@mail.gmail.com>
References: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>
	<51D63451.9040006@msapiro.net>
	<CAH=dxU5vabyKXzpmqV4S6o3b-nF0VA3V-TMm+hts-TkJezo+HQ@mail.gmail.com>
Message-ID: <51DB3CDD.9090204@msapiro.net>

On 07/08/2013 01:29 PM, David wrote:
> On Thu, Jul 4, 2013 at 10:49 PM, Mark Sapiro <mark at msapiro.net> wrote:
> 
>     If the mail server on the new box thinks list domains are in its local
>     delivery space (mydestination in Postfix), you can just send mail from
>     an MUA on the local box configured to deliver via SMTP to the local MTA,
>     and it all should work except that mail from Mailman to local addresses
>     will be delivered to the new box instead of the current live box.
> 
> 
> The new box has no GUI. The OS is Debian 6.
> $ uname -r
> 3.9.3-x86_64-linode33
> 
> The MUA is:
> heirloom-mailx
> $ mailx -V
> 12.5 6/20/10
> 
> The MTA is postfix. (For some reason I can't run "postconf -d | grep
> mail_version" so I'll have to ask the sysadmin later about that. But at
> the moment, I don't know the postfix version.)
> 
> Given that info, which settings changes should I make to proceed with
> the testing plan you described above?
> 
> So far all I did was:
> 1. create a ~/.mailrc file with contents:
> 
> set smtp=localhost


If that tells mailx to send via smtp to localhost, that's good.


> 2. edit /etc/postfix/main.cf <http://main.cf> and change mydestination
> to the line below:
> mydestination = localhost, localhost.localdomain


If I understood correctly, this is not what you want. My understanding
is you have an old (current) box with a domain and an IP and DNS for the
domain pointing to the IP, and after the switch the domain and IP will
be those of the new box, but for now, the new box has a different IP.

If this is the case, you should not be making any changes to main.cf
over what you want after the switch, i.e. it should look like that on
the old box.

Now, in this configuration, list mail should be delivered locally, so if
you send mail from the local MUA on the new box to a list address, the
MUA will deliver it to the local Postfix and that in turn will deliver
it to the local Mailman.

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

From dave at fiteyes.com  Tue Jul  9 01:19:59 2013
From: dave at fiteyes.com (David)
Date: Mon, 8 Jul 2013 19:19:59 -0400
Subject: [Mailman-Users] Migration to a new server: recommendations for
 testing the new Mailman server before changing DNS records;
 also how to avoid lost/bounced messages during change-over?
In-Reply-To: <51DB3CDD.9090204@msapiro.net>
References: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>
	<51D63451.9040006@msapiro.net>
	<CAH=dxU5vabyKXzpmqV4S6o3b-nF0VA3V-TMm+hts-TkJezo+HQ@mail.gmail.com>
	<51DB3CDD.9090204@msapiro.net>
Message-ID: <CAH=dxU7OzsG1KF=CXc4bknCTwjfxzFBWbCWGKSczHQdxCxZqMg@mail.gmail.com>

On Mon, Jul 8, 2013 at 6:27 PM, Mark Sapiro <mark at msapiro.net> wrote:

>
> >
> > So far all I did was:
> > 1. create a ~/.mailrc file with contents:
> >
> > set smtp=localhost
>
>
> If that tells mailx to send via smtp to localhost, that's good.
>
>
> > 2. edit /etc/postfix/main.cf <http://main.cf> and change mydestination
> > to the line below:
> > mydestination = localhost, localhost.localdomain
>
>
> If I understood correctly, this is not what you want. My understanding
> is you have an old (current) box with a domain and an IP and DNS for the
> domain pointing to the IP, and after the switch the domain and IP will
> be those of the new box, but for now, the new box has a different IP.
>

The old/current box is live. It has a domain, IP and matching DNS records
and it works as it should.

The new/migrated box is not yet live. We have copied Mailman to it, but we
need to test. The migration process is a bit complex because of opendkim
settings and a few other things, so I think testing first is a good idea
before we go live.

When we finish testing, I will move the old IP address to the new box (swap
IPs).



>
> If this is the case, you should not be making any changes to main.cf
> over what you want after the switch, i.e. it should look like that on
> the old box.
>

OK. I misunderstood.


>
> Now, in this configuration, list mail should be delivered locally, so if
> you send mail from the local MUA on the new box to a list address, the
> MUA will deliver it to the local Postfix and that in turn will deliver
> it to the local Mailman.
>

For some reason, it is not working. I will review the settings.

From dave at fiteyes.com  Tue Jul  9 01:34:11 2013
From: dave at fiteyes.com (David)
Date: Mon, 8 Jul 2013 19:34:11 -0400
Subject: [Mailman-Users] Migration to a new server: recommendations for
 testing the new Mailman server before changing DNS records;
 also how to avoid lost/bounced messages during change-over?
In-Reply-To: <CAH=dxU7OzsG1KF=CXc4bknCTwjfxzFBWbCWGKSczHQdxCxZqMg@mail.gmail.com>
References: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>
	<51D63451.9040006@msapiro.net>
	<CAH=dxU5vabyKXzpmqV4S6o3b-nF0VA3V-TMm+hts-TkJezo+HQ@mail.gmail.com>
	<51DB3CDD.9090204@msapiro.net>
	<CAH=dxU7OzsG1KF=CXc4bknCTwjfxzFBWbCWGKSczHQdxCxZqMg@mail.gmail.com>
Message-ID: <CAH=dxU4i5qUuUQ2T-xU2XQfRpLrTEK1O_691VGd5EE2P+25QgA@mail.gmail.com>

I am beginning to wonder if it is even possible to test Mailman before
going live. With opendkim, the TrustedHosts file reflects the IP address
and domain name the server will have after it is live (after I swap IP
addresses).

Therefore, opendkim won't work now. And if I go fiddling with config files
for testing (and changing to a temporary IP address, for example), then I
increase the risk that the server won't work after I swap IP addresses and
go live.

It seems to be a bit of a dilemma...

From mark at msapiro.net  Tue Jul  9 01:48:31 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 08 Jul 2013 16:48:31 -0700
Subject: [Mailman-Users] Migration to a new server: recommendations for
 testing the new Mailman server before changing DNS records;
 also how to avoid lost/bounced messages during change-over?
In-Reply-To: <CAH=dxU4i5qUuUQ2T-xU2XQfRpLrTEK1O_691VGd5EE2P+25QgA@mail.gmail.com>
References: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>
	<51D63451.9040006@msapiro.net>
	<CAH=dxU5vabyKXzpmqV4S6o3b-nF0VA3V-TMm+hts-TkJezo+HQ@mail.gmail.com>
	<51DB3CDD.9090204@msapiro.net>
	<CAH=dxU7OzsG1KF=CXc4bknCTwjfxzFBWbCWGKSczHQdxCxZqMg@mail.gmail.com>
	<CAH=dxU4i5qUuUQ2T-xU2XQfRpLrTEK1O_691VGd5EE2P+25QgA@mail.gmail.com>
Message-ID: <51DB4FCF.5010903@msapiro.net>

On 07/08/2013 04:34 PM, David wrote:
> 
> Therefore, opendkim won't work now. And if I go fiddling with config
> files for testing (and changing to a temporary IP address, for example),
> then I increase the risk that the server won't work after I swap IP
> addresses and go live.


The mail you are submitting for testing should be coming from localhost
(the loopback port, 127.0.0.1 for IPv4). I'm not knowledgeable about
OpenDKIM, but it seems that maybe this should be in TrustedHosts anyway.

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

From dave at fiteyes.com  Tue Jul  9 01:50:00 2013
From: dave at fiteyes.com (David)
Date: Mon, 8 Jul 2013 19:50:00 -0400
Subject: [Mailman-Users] Migration to a new server: recommendations for
 testing the new Mailman server before changing DNS records;
 also how to avoid lost/bounced messages during change-over?
In-Reply-To: <51DB4FCF.5010903@msapiro.net>
References: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>
	<51D63451.9040006@msapiro.net>
	<CAH=dxU5vabyKXzpmqV4S6o3b-nF0VA3V-TMm+hts-TkJezo+HQ@mail.gmail.com>
	<51DB3CDD.9090204@msapiro.net>
	<CAH=dxU7OzsG1KF=CXc4bknCTwjfxzFBWbCWGKSczHQdxCxZqMg@mail.gmail.com>
	<CAH=dxU4i5qUuUQ2T-xU2XQfRpLrTEK1O_691VGd5EE2P+25QgA@mail.gmail.com>
	<51DB4FCF.5010903@msapiro.net>
Message-ID: <CAH=dxU7e_MZ0aqYhQXQ6UpBJoGB=wsTR8oYQj4_6jygpe3eNFQ@mail.gmail.com>

Yes, you are correct. Thanks

cat /etc/opendkim/TrustedHosts
127.0.0.1
localhost
[...]


On Mon, Jul 8, 2013 at 7:48 PM, Mark Sapiro <mark at msapiro.net> wrote:

> On 07/08/2013 04:34 PM, David wrote:
> >
> > Therefore, opendkim won't work now. And if I go fiddling with config
> > files for testing (and changing to a temporary IP address, for example),
> > then I increase the risk that the server won't work after I swap IP
> > addresses and go live.
>
>
> The mail you are submitting for testing should be coming from localhost
> (the loopback port, 127.0.0.1 for IPv4). I'm not knowledgeable about
> OpenDKIM, but it seems that maybe this should be in TrustedHosts anyway.
>
> --
> Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
>

From joemailgroups at gmail.com  Tue Jul  9 23:34:01 2013
From: joemailgroups at gmail.com (Joe)
Date: Tue, 9 Jul 2013 14:34:01 -0700
Subject: [Mailman-Users] Mailman and Google Groups.
Message-ID: <8117FDFC-8EE7-4ADE-951A-E37340EDAFFD@gmail.com>

Hello, everyone.

I have two questions for the group.

Question 1:

I have set up (or attempted to set up) five discussion groups on the Internet using Mailman running on an Apple with Mac OS X server. The process hasn't been as smooth as I thought or as easy as Apple advertised.

With this in mind, I would like to get some help with this. Lists are running for the most part with few members and some (not all) receiving mail from the lists.

However, there are those who don't seem to receive. In addition there have been problems related to greylisting and other such phenomena that fly above my head.

Is anyone with experience on both Mailman and Mac OS X server available for consulting ?

Question 2:

Assuming I were to choose to abandon this project (hosting the lists and running Mailman) is anyone aware if I can transfer the lists to Google Groups while maintaining the same domain name ? In other words, the lists would be hosted by Google Groups but under the same names and domain they now have.

I have been told that this can be done if I sign up for a Gooble Apps business account. As a business account user I would have the ability to create discussion groups using Google Groups but do so under my own domain name.

Does anyone have any experience with this ?

Thank you in advance for all your answers.

Joe.

From Benjamin_Joyner at ao.uscourts.gov  Tue Jul  9 22:22:12 2013
From: Benjamin_Joyner at ao.uscourts.gov (Benjamin_Joyner at ao.uscourts.gov)
Date: Tue, 9 Jul 2013 16:22:12 -0400
Subject: [Mailman-Users] Mailman and Postfix
Message-ID: <OF450A65CE.BEFF3312-ON85257BA3.006F9B6C-85257BA3.006FE5F8@uscmail.uscourts.gov>

Hello,

I am new to mail servers in general and so I apologize if my questions is 
a simple one.  I setup mailman on a rhel5 server and it seems to be 
running fine with the exception that incoming mail is not being accepted 
and forwarded to the test list I setup.  I can create lists and subscribe 
users and mailman sends the confirmation out to the user, yet if I send a 
message to the mailing list I get nothing.  I don't see it registered on 
the /var/log/maillog or any errors in the mailman logs.  The message 
itself is not being rejected its just sort of vanishing.

Thank you, Regards,
Ben Joyner

From carsten.dominik at gmail.com  Wed Jul 10 13:52:43 2013
From: carsten.dominik at gmail.com (Carsten Dominik)
Date: Wed, 10 Jul 2013 11:52:43 +0000 (UTC)
Subject: [Mailman-Users] moderation flag flips off automatically
Message-ID: <loom.20130710T134457-378@post.gmane.org>

Hi,

I have a question about moderation that I was not able to find
an answer to, even though I searched  quite a bit.

I am running a mailing list where I have placed a single
rogue user under moderation by turning on  the
moderation flag for this user.  When I leave the interface, go
back in, the flag is set for the user,  as I want it.

However, each time a mail arrives from the user, the flag
somehow magically flips itself, the message  goes through,
and when I check the user data, the moderation flag is off now.

I cannot find out how this is possible - I checked the
whitelist (that is only for non-members, I think)  and the
user is not on it.

Any ideas where I should look for a problem in my settings?

Thank you.

Carsten


From mark at msapiro.net  Wed Jul 10 17:51:57 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 10 Jul 2013 08:51:57 -0700
Subject: [Mailman-Users] Mailman and Postfix
In-Reply-To: <OF450A65CE.BEFF3312-ON85257BA3.006F9B6C-85257BA3.006FE5F8@uscmail.uscourts.gov>
References: <OF450A65CE.BEFF3312-ON85257BA3.006F9B6C-85257BA3.006FE5F8@uscmail.uscourts.gov>
Message-ID: <51DD831D.5090605@msapiro.net>

On 07/09/2013 01:22 PM, Benjamin_Joyner at ao.uscourts.gov wrote:

> I can create lists and subscribe 
> users and mailman sends the confirmation out to the user, yet if I send a 
> message to the mailing list I get nothing.  I don't see it registered on 
> the /var/log/maillog or any errors in the mailman logs.  The message 
> itself is not being rejected its just sort of vanishing.


If there is nothing in /var/log/maillog, the message isn't even reaching
the incoming MTA (Postfix ?). How are you sending the mail? Is there DNS
for the domain with either an MX pointing to the Mailman server or no MX
and an A with the IP of the Mailman server?

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

From Benjamin_Joyner at ao.uscourts.gov  Wed Jul 10 17:55:23 2013
From: Benjamin_Joyner at ao.uscourts.gov (Benjamin_Joyner at ao.uscourts.gov)
Date: Wed, 10 Jul 2013 11:55:23 -0400
Subject: [Mailman-Users] Mailman and Postfix
In-Reply-To: <51DD831D.5090605@msapiro.net>
References: <OF450A65CE.BEFF3312-ON85257BA3.006F9B6C-85257BA3.006FE5F8@uscmail.uscourts.gov>
	<51DD831D.5090605@msapiro.net>
Message-ID: <OF866E6785.15B2D03A-ON85257BA4.00575EE3-85257BA4.0057788F@uscmail.uscourts.gov>

This actualy just started working today.  I asked our network person and 
he said everything was fine, but then today all of a sudden it started 
working.  so... something wasent fine obviously but whatever it is he 
fixed it, possibly a missing mx record



From:   Mark Sapiro <mark at msapiro.net>
To:     mailman-users at python.org
Date:   07/10/2013 11:53 AM
Subject:        Re: [Mailman-Users] Mailman and Postfix
Sent by:        "Mailman-Users" 
<mailman-users-bounces+benjamin_joyner=ao.uscourts.gov at python.org>



On 07/09/2013 01:22 PM, Benjamin_Joyner at ao.uscourts.gov wrote:

> I can create lists and subscribe 
> users and mailman sends the confirmation out to the user, yet if I send 
a 
> message to the mailing list I get nothing.  I don't see it registered on 

> the /var/log/maillog or any errors in the mailman logs.  The message 
> itself is not being rejected its just sort of vanishing.


If there is nothing in /var/log/maillog, the message isn't even reaching
the incoming MTA (Postfix ?). How are you sending the mail? Is there DNS
for the domain with either an MX pointing to the Mailman server or no MX
and an A with the IP of the Mailman server?

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan
------------------------------------------------------
Mailman-Users mailing list Mailman-Users at python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: 
http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/benjamin_joyner%40ao.uscourts.gov



From mark at msapiro.net  Thu Jul 11 01:30:52 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 10 Jul 2013 16:30:52 -0700
Subject: [Mailman-Users] moderation flag flips off automatically
In-Reply-To: <loom.20130710T134457-378@post.gmane.org>
References: <loom.20130710T134457-378@post.gmane.org>
Message-ID: <51DDEEAC.1010807@msapiro.net>

On 07/10/2013 04:52 AM, Carsten Dominik wrote:
> 
> I am running a mailing list where I have placed a single
> rogue user under moderation by turning on  the
> moderation flag for this user.  When I leave the interface, go
> back in, the flag is set for the user,  as I want it.
> 
> However, each time a mail arrives from the user, the flag
> somehow magically flips itself, the message  goes through,
> and when I check the user data, the moderation flag is off now.


Are you the sole list owner/moderator. If so, change the password(s) and
don't tell anyone the new ones.


> I cannot find out how this is possible - I checked the
> whitelist (that is only for non-members, I think)  and the
> user is not on it.


Yes, accept_these_nonmembers only applies to non members. This can
happen if someone other than you knows a moderator password and is
approving the message and clearing the members moderate flag as part of
the approval.

If I had to guess, I would suspect that the rogue user has learned or
guessed the list moderator password and when he gets the notice that his
message is held, he approves it and clears his mod flag.

Other possibilities are he has an agent doing this for him or another
moderator is doing it innocently.


> Any ideas where I should look for a problem in my settings?


I don't believe it is a problem with settings. I think it is a problem
with someone knowing a password and not behaving as you would wish.

Do the messages that reach the list have an X-Mailman-Approved-At: header?

Is admin_immed_notify Yes and do you get a notice of the held message
before it is delivered to the list?

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

From carsten.dominik at gmail.com  Thu Jul 11 14:12:12 2013
From: carsten.dominik at gmail.com (Carsten Dominik)
Date: Thu, 11 Jul 2013 14:12:12 +0200
Subject: [Mailman-Users] moderation flag flips off automatically
In-Reply-To: <51DDEEAC.1010807@msapiro.net>
References: <loom.20130710T134457-378@post.gmane.org>
	<51DDEEAC.1010807@msapiro.net>
Message-ID: <54A14DA1-B4B9-45A1-B1EE-426E3A7609FE@gmail.com>

Hi Mark,

thank you for your reply and your helpful remarks.

Indeed, the messages carry an x-mailman-approved header (at lease some of them, others
got probably through because then the modification flag was off again).

The approved header carries a time stamp with a time zone - this is probably the
time at the mailman server, not at the moderators location, right?  The header lists
-0400 as offset, so this is somewhere on the east coast of the US, probably the
GNU mailing list server.  Is this a fail assumption?  Or would the time stamp
carry information about the moderators time zone?

I have followed your advice and changed the passwords - will see what happens now.

Thanks!

- Carsten

On Jul 11, 2013, at 1:30 AM, Mark Sapiro <mark at msapiro.net> wrote:

> On 07/10/2013 04:52 AM, Carsten Dominik wrote:
>> 
>> I am running a mailing list where I have placed a single
>> rogue user under moderation by turning on  the
>> moderation flag for this user.  When I leave the interface, go
>> back in, the flag is set for the user,  as I want it.
>> 
>> However, each time a mail arrives from the user, the flag
>> somehow magically flips itself, the message  goes through,
>> and when I check the user data, the moderation flag is off now.
> 
> 
> Are you the sole list owner/moderator. If so, change the password(s) and
> don't tell anyone the new ones.
> 
> 
>> I cannot find out how this is possible - I checked the
>> whitelist (that is only for non-members, I think)  and the
>> user is not on it.
> 
> 
> Yes, accept_these_nonmembers only applies to non members. This can
> happen if someone other than you knows a moderator password and is
> approving the message and clearing the members moderate flag as part of
> the approval.
> 
> If I had to guess, I would suspect that the rogue user has learned or
> guessed the list moderator password and when he gets the notice that his
> message is held, he approves it and clears his mod flag.
> 
> Other possibilities are he has an agent doing this for him or another
> moderator is doing it innocently.
> 
> 
>> Any ideas where I should look for a problem in my settings?
> 
> 
> I don't believe it is a problem with settings. I think it is a problem
> with someone knowing a password and not behaving as you would wish.
> 
> Do the messages that reach the list have an X-Mailman-Approved-At: header?
> 
> Is admin_immed_notify Yes and do you get a notice of the held message
> before it is delivered to the list?
> 
> -- 
> Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at python.org
> http://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Security Policy: http://wiki.list.org/x/QIA9
> Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-users/carsten.dominik%40gmail.com


From mark at msapiro.net  Thu Jul 11 17:01:12 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 11 Jul 2013 08:01:12 -0700
Subject: [Mailman-Users] moderation flag flips off automatically
In-Reply-To: <54A14DA1-B4B9-45A1-B1EE-426E3A7609FE@gmail.com>
References: <loom.20130710T134457-378@post.gmane.org>
	<51DDEEAC.1010807@msapiro.net>
	<54A14DA1-B4B9-45A1-B1EE-426E3A7609FE@gmail.com>
Message-ID: <51DEC8B8.7080304@msapiro.net>

On 07/11/2013 05:12 AM, Carsten Dominik wrote:
> 
> The approved header carries a time stamp with a time zone - this is probably the
> time at the mailman server, not at the moderators location, right?


Yes, this is the local time at the Mailman server and gives no
information as to the approver's time zone.

You can only get information about the approver from the web server and
mail server logs.

If the approval was by email, there would still be web activity because
the mod flag can't be reset by email.

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

From javad at irannopendar.com  Thu Jul 11 17:46:51 2013
From: javad at irannopendar.com (Javad Hoseini-Nopendar)
Date: Thu, 11 Jul 2013 20:16:51 +0430
Subject: [Mailman-Users] Question about mailman 3
Message-ID: <000c01ce7e4d$de64e9a0$0201a8c0@home3c459be30f>

Hello
I have a question about later versions of mailman. Do they have the feature 
to export list of members to Excel or TXT file?




From fmouse at fmp.com  Thu Jul 11 18:48:06 2013
From: fmouse at fmp.com (Lindsay Haisley)
Date: Thu, 11 Jul 2013 11:48:06 -0500
Subject: [Mailman-Users] Question about mailman 3
In-Reply-To: <000c01ce7e4d$de64e9a0$0201a8c0@home3c459be30f>
References: <000c01ce7e4d$de64e9a0$0201a8c0@home3c459be30f>
Message-ID: <1373561286.52505.24.camel@pudina.fmp.com>

On Thu, 2013-07-11 at 20:16 +0430, Javad Hoseini-Nopendar wrote:
> I have a question about later versions of mailman. Do they have the feature 
> to export list of members to Excel or TXT file?

If you have console access to the account, you can use the list_members
command:

list_members listname 		[lists member emails]
list_members -f listname	[lists emails w. names as RFC-compliant address]
> 
You can also send a "who" command in the subject line to
listname-request at example.com with a password.  This isn't well
documented, but you'll find what documentation there is at
http://www.gnu.org/software/mailman/mailman-member/node10.html and
http://www.gnu.org/software/mailman/mailman-member/node41.html#a:commands

-- 
Lindsay Haisley       | "Everything works if you let it"
FMP Computer Services |
512-259-1190          |          --- The Roadie
http://www.fmp.com    |


From Benjamin_Joyner at ao.uscourts.gov  Thu Jul 11 21:05:45 2013
From: Benjamin_Joyner at ao.uscourts.gov (Benjamin_Joyner at ao.uscourts.gov)
Date: Thu, 11 Jul 2013 15:05:45 -0400
Subject: [Mailman-Users] Domain name
Message-ID: <OF7D192628.02491EB5-ON85257BA5.00689AFA-85257BA5.0068E5C0@uscmail.uscourts.gov>

Hello,

I am having an issue with the configured domain name for my mailman 
server.  The dome name does not have a www apendation on it it is 
xxx.chnt.gtwy.dcn we also have a virtual name setup as xxx.gtwy.dcn.  The 
problem is that when I create a new mailing list, the domain name referred 
to in the email sent out to users is truncated to .gtwy.dcn.  This cuts 
off the first part of the needed domain name.  I know I can go in and 
under the general option fix this, but is there a way to set it so that it 
will not truncate the domain name automaticaly.  This way users can create 
their lists, without this added configuration needed?

From mark at msapiro.net  Fri Jul 12 00:54:59 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 11 Jul 2013 15:54:59 -0700
Subject: [Mailman-Users] Question about mailman 3
In-Reply-To: <1373561286.52505.24.camel@pudina.fmp.com>
References: <000c01ce7e4d$de64e9a0$0201a8c0@home3c459be30f>
	<1373561286.52505.24.camel@pudina.fmp.com>
Message-ID: <51DF37C3.8000009@msapiro.net>

On 07/11/2013 09:48 AM, Lindsay Haisley wrote:
> On Thu, 2013-07-11 at 20:16 +0430, Javad Hoseini-Nopendar wrote:
>> I have a question about later versions of mailman. Do they have the feature 
>> to export list of members to Excel or TXT file?
> 
> If you have console access to the account, you can use the list_members
> command:
> 
> list_members listname 		[lists member emails]
> list_members -f listname	[lists emails w. names as RFC-compliant address]
>>
> You can also send a "who" command in the subject line to
> listname-request at example.com with a password.  This isn't well
> documented, but you'll find what documentation there is at
> http://www.gnu.org/software/mailman/mailman-member/node10.html and
> http://www.gnu.org/software/mailman/mailman-member/node41.html#a:commands


Or in the FAQ at <http://wiki.list.org/x/aYA9>, but the OP's question
appears to be about MM 3. In MM 3, Postorius may or may not have the
ability to export a membership list directly from the web UI. My guess
is that it does, but I don't actually know for sure.

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

From mark at msapiro.net  Fri Jul 12 00:58:33 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 11 Jul 2013 15:58:33 -0700
Subject: [Mailman-Users] Domain name
In-Reply-To: <OF7D192628.02491EB5-ON85257BA5.00689AFA-85257BA5.0068E5C0@uscmail.uscourts.gov>
References: <OF7D192628.02491EB5-ON85257BA5.00689AFA-85257BA5.0068E5C0@uscmail.uscourts.gov>
Message-ID: <51DF3899.6080607@msapiro.net>

On 07/11/2013 12:05 PM, Benjamin_Joyner at ao.uscourts.gov wrote:
> 
> I am having an issue with the configured domain name for my mailman 
> server.  The dome name does not have a www apendation on it it is 
> xxx.chnt.gtwy.dcn we also have a virtual name setup as xxx.gtwy.dcn.  The 
> problem is that when I create a new mailing list, the domain name referred 
> to in the email sent out to users is truncated to .gtwy.dcn.  This cuts 
> off the first part of the needed domain name.  I know I can go in and 
> under the general option fix this, but is there a way to set it so that it 
> will not truncate the domain name automaticaly.  This way users can create 
> their lists, without this added configuration needed?


See the first part of the FAQ at <http://wiki.list.org/x/gIA9>.

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

From mark at msapiro.net  Fri Jul 12 02:51:13 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Thu, 11 Jul 2013 17:51:13 -0700
Subject: [Mailman-Users] Mailman 2.1.16 release.
Message-ID: <51DF5301.7070802@msapiro.net>

FYI, I will be releasing 2.1.16rc1 in a few days with a target of a
final release in early September.

I believe the release will be very solid and stable. The main purpose of
the candidate release is to expose any i18n changes so that translators
can submit any updates and get them in the final release. There are a
few new features, contributed programs, i18n changes and bug fixes, all
of which will be announced when the candidate is released.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130711/ec555d04/attachment.pgp>

From Benjamin_Joyner at ao.uscourts.gov  Fri Jul 12 15:10:47 2013
From: Benjamin_Joyner at ao.uscourts.gov (Benjamin_Joyner at ao.uscourts.gov)
Date: Fri, 12 Jul 2013 09:10:47 -0400
Subject: [Mailman-Users] Domain name
In-Reply-To: <51DF3899.6080607@msapiro.net>
References: <OF7D192628.02491EB5-ON85257BA5.00689AFA-85257BA5.0068E5C0@uscmail.uscourts.gov>
	<51DF3899.6080607@msapiro.net>
Message-ID: <OFA342B658.13BA8658-ON85257BA6.00480C5B-85257BA6.0048662E@uscmail.uscourts.gov>

Yes, I saw that page before and set my mm config file toto include the 
default email host setting and it still didn't work.

# Put YOUR site-specific settings below this line.
IMAGE_LOGOS = '/icons/'
#MTA = 'Sendmail'
MTA='Postfix'
POSTFIX_ALIAS_CMD = '/usr/bin/sudo /usr/local/sbin/mailman.aliases'
POSTFIX_STYLE_VIRTUAL_DOMAINS = []
DEFAULT_EMAIL_HOST = 'HOSTNAME.gtwy.dcn'
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
add_virtualhost('HOSTNAME.gtwy.dcn')



From:   Mark Sapiro <mark at msapiro.net>
To:     mailman-users at python.org
Date:   07/11/2013 06:59 PM
Subject:        Re: [Mailman-Users] Domain name
Sent by:        "Mailman-Users" 
<mailman-users-bounces+benjamin_joyner=ao.uscourts.gov at python.org>



On 07/11/2013 12:05 PM, Benjamin_Joyner at ao.uscourts.gov wrote:
> 
> I am having an issue with the configured domain name for my mailman 
> server.  The dome name does not have a www apendation on it it is 
> xxx.chnt.gtwy.dcn we also have a virtual name setup as xxx.gtwy.dcn. The 

> problem is that when I create a new mailing list, the domain name 
referred 
> to in the email sent out to users is truncated to .gtwy.dcn.  This cuts 
> off the first part of the needed domain name.  I know I can go in and 
> under the general option fix this, but is there a way to set it so that 
it 
> will not truncate the domain name automaticaly.  This way users can 
create 
> their lists, without this added configuration needed?


See the first part of the FAQ at <http://wiki.list.org/x/gIA9>.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan
------------------------------------------------------
Mailman-Users mailing list Mailman-Users at python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: 
http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/options/mailman-users/benjamin_joyner%40ao.uscourts.gov



From dave at fiteyes.com  Fri Jul 12 22:19:29 2013
From: dave at fiteyes.com (David)
Date: Fri, 12 Jul 2013 16:19:29 -0400
Subject: [Mailman-Users] Mailman consulting services
Message-ID: <CAH=dxU5y1XsuHvqBgSSyAZWr5s+Cvu5V1OBavv1kPX0+HofbTQ@mail.gmail.com>

I see this page was last updated in 2009. If anyone knows of consultants
that should be on this page, please let me know. I'm looking for one.
Thanks.

Mailman consulting services - Community - Confluence
http://wiki.list.org/display/COM/Mailman+consulting+services

From mark at msapiro.net  Sat Jul 13 07:47:41 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 12 Jul 2013 22:47:41 -0700
Subject: [Mailman-Users] Domain name
In-Reply-To: <OFA342B658.13BA8658-ON85257BA6.00480C5B-85257BA6.0048662E@uscmail.uscourts.gov>
References: <OF7D192628.02491EB5-ON85257BA5.00689AFA-85257BA5.0068E5C0@uscmail.uscourts.gov>
	<51DF3899.6080607@msapiro.net>
	<OFA342B658.13BA8658-ON85257BA6.00480C5B-85257BA6.0048662E@uscmail.uscourts.gov>
Message-ID: <51E0E9FD.8050700@msapiro.net>

On 07/12/2013 06:10 AM, Benjamin_Joyner at ao.uscourts.gov wrote:
> Yes, I saw that page before and set my mm config file toto include the
> default email host setting and it still didn't work.
> 
> # Put YOUR site-specific settings below this line.
> IMAGE_LOGOS = '/icons/'
> #MTA = 'Sendmail'
> MTA='Postfix'
> POSTFIX_ALIAS_CMD = '/usr/bin/sudo /usr/local/sbin/mailman.aliases'
> POSTFIX_STYLE_VIRTUAL_DOMAINS = []
> DEFAULT_EMAIL_HOST = 'HOSTNAME.gtwy.dcn'
> add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
> add_virtualhost('HOSTNAME.gtwy.dcn')

I don't know what the value of DEFAULT_URL_HOST is but I'm sure your
problem is the line above -

add_virtualhost('HOSTNAME.gtwy.dcn')

This is equivalent to

add_virtualhost('HOSTNAME.gtwy.dcn', 'gtwy.dcn')

Just remove that line, and if the value of DEFAULT_URL_HOST is not
'HOSTNAME.gtwy.dcn' from Defaults.py, set it here as in

DEFAULT_URL_HOST = 'HOSTNAME.gtwy.dcn'
DEFAULT_EMAIL_HOST = 'HOSTNAME.gtwy.dcn'
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)

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

From mark at msapiro.net  Sun Jul 14 22:45:43 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 14 Jul 2013 13:45:43 -0700
Subject: [Mailman-Users] Mailman 2.1.16 release.
In-Reply-To: <51DF5301.7070802@msapiro.net>
References: <51DF5301.7070802@msapiro.net>
Message-ID: <51E30DF7.8020306@msapiro.net>

I am pleased to announce the first release candidate for Mailman 2.1.16.

Python 2.4 is the minimum supported, but Python 2.7 is recommended.

This release has a few new features and several bug fixed as detailed in
the attached README.

Mailman is free software for managing email mailing lists and
e-newsletters. Mailman is used for all the python.org and
SourceForge.net mailing lists, as well as at hundreds of other sites.

For more information, please see:

http://www.list.org
http://www.gnu.org/software/mailman
http://mailman.sourceforge.net/

Mailman 2.1.16rc1 can be downloaded from

https://launchpad.net/mailman/2.1/
http://ftp.gnu.org/gnu/mailman/
https://sourceforge.net/projects/mailman/

I anticipate that the 2.1.16 final release will be in early September.
Bugs found between now and then will be fixed if possible, but I hope
that most if not all changes between now and then will be i18n updates.
Please send any updates to the templates and/or message catalogs in the
2.1.16rc1 release directly to me no later than 1 Sept 2013.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan
-------------- next part --------------
2.1.16rc1 (14-Aug-2013)

  New Features

    - Setting digest_size_threshhold to zero now means no digests will be
      sent based on size instead of a digest being sent with every post.
      (LP: #558274)

    - There is a new mm_cfg.py setting SUBSCRIBE_FORM_SECRET which will put
      a dynamically generated, hidden hash in the listinfo subscribe form and
      check it upon submission.  Setting this will prevent automated processes
      (bots) from successfully POSTing web subscribes without first retrieving
      and parsing the form from the listinfo page.  The form must also be
      submitted no later than FORM_LIFETIME nor no earlier than
      SUBSCRIBE_FORM_MIN_TIME after retrieval.  Note that enabling this will
      break any static subscribe forms on your site.  See the description in
      Defaults.py for more info.  (LP: #1082746)

    - add_members now has an option to add members with mail delivery disabled
      by admin.  (LP: #1070574)

    - IncomingRunner now logs rejected messages to the vette log.
      (LP: #1068837)

    - The name of the mailmanctl master lock file is now congigurable via the
      mm_cfg.py setting MASTER_LOCK_FILE.  (LP: #1082308)

    - list_lists now has an option to list only lists with public archives.
      (LP: #1082711)

  Contributed programs

    - A new import_majordomo_into_mailman.pl script has been contributed by
      Geoff Mayes.  (LP: #1129742)

    - A new "sitemap" bash script has been contributed by Tomasz Chmielewski
      <mangoo at wpkg.org> to generate a sitemap.xml file of an installation's
      public archives for submission to search engines.

  i18n

    - A Farsi (Persian) translation has been added thanks to Javad Hoseini and
      Mahyar Moghimi.

    - Fixed several misspelled or garbled string replacements in the Spanish
      message catalog.  (LP: #1160138)

    - pt_BR message catalog has two new and an updated message per Hugo Koji
      Kobayashi.  (LP: #1138578)

    - German message catalog has been updated per Ralf Hildebrandt.

    - Corrected typo in templates/it/private.html.

  Bug Fixes and other patches

    - Added "message_id" to the interpolation dictionary for the Article.html
      template.  (LP: #725498)

    - Changed the admin GUI to report only the bad entries in a list of email
      addresses if any are bad.  (LP: #558253)

    - Added logging for template errors in HyperArch.py.  (LP: #558254)

    - Added more explanation to the bad owner address message from
      bin/newlist.  (LP: #1200763)

    - Fixed a bug causing the admin web interface to fail CSRF checking if
      the list name contains a '+' character.  (LP: #1190802)

    - Fixed bin/mailmanctl -s to not remove the master lock if it can't be
      determined to be truly stale.  (LP: #1189558)

    - It is no longer possible to add 'invalid' addresses to the ban_list
      and the *_these_nonmembers filters from the check boxes on the admindb
      interface.  (LP: #1187201)

    - Backported recognition for mail.ru DSNs and minor bug fixes from
      lp:flufl.bounce.  (LP: #1074592, LP: #1079249 and #1079254)

    - Defended against buggy web servers that don't include an empty
      QUERY_STRING in the CGI environment.  (LP: #1160647)

    - The Switchboard.finish() method now logs the text of the exception when
      it fails to unlink/preserve a .bak file.  (LP: #1165589)

    - The pending (un)subscriptions waiting approval are now sorted by email
      address in the admindb interface as intended.  (LP: #1164160)

    - The subscribe log entry for a bin/add_members subscribe now identifies
      bin/add_members as the source.  (LP: #1161642)

    - Fixed a bug where the Subject: of the user notification of a
      bin/remove_members unsubscribe was not in the user's language.
      (LP: #1161445)

    - Fixed a bug where BounceRunner could create and leave behind zero length
      bounce-events files.  (LP: #1161610)

    - Added recognition for another Yahoo bounce format.  (LP: #1157961)

    - Changed configure's method for getting Python's include directory from
      distutils.sysconfig.get_config_var('CONFINCLUDEPY') to
      distutils.sysconfig.get_python_inc().  (LP: #1098162)

    - Added an Auto-Generated: header to password reminders.  (LP: #558240)

    - Fixed a bug where non-ascii characters in the real name in a subscription
      request could throw a UnicodeEncodeError upon subscription approval and
      perhaps in other situations too.  (LP: #1047100)

    - The query fragments send_unsub_notifications_to_list_owner and
      send_unsub_ack_to_this_batch will now assume default values if not set
      in mass unsubscribe URLs.  (LP: #1032378)

    - Replaced utf-8 encoded characters in newly added German templates with
      HTML entities. (LP: #1018208)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130714/cfc3ad8e/attachment.pgp>

From nyasar at bilgievi.net  Sun Jul 14 20:32:22 2013
From: nyasar at bilgievi.net (Nezih Yasar)
Date: Sun, 14 Jul 2013 21:32:22 +0300
Subject: [Mailman-Users] To restrict sending email messages per day
Message-ID: <CADbT6qLsqu_VDnMTEqgp6ukhCGo37FeYc_Dg6mUkKGJDehkPhg@mail.gmail.com>

Hello everybody,
I am an owner of a list using Mailman.
We have more than 200 active senders in a 2000-member list.
We need a setup tool to restrict 2 messages per day for every user.
Is it available such a setup in Mailman?
Does anyone have any experience like this?
Thank you in advance?
Nezih Yasar

From stephen at xemacs.org  Mon Jul 15 15:43:57 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Mon, 15 Jul 2013 22:43:57 +0900
Subject: [Mailman-Users]  To restrict sending email messages per day
In-Reply-To: <CADbT6qLsqu_VDnMTEqgp6ukhCGo37FeYc_Dg6mUkKGJDehkPhg@mail.gmail.com>
References: <CADbT6qLsqu_VDnMTEqgp6ukhCGo37FeYc_Dg6mUkKGJDehkPhg@mail.gmail.com>
Message-ID: <87y598rl9e.fsf@uwakimon.sk.tsukuba.ac.jp>

Nezih Yasar writes:

 > Hello everybody,
 > I am an owner of a list using Mailman.
 > We have more than 200 active senders in a 2000-member list.
 > We need a setup tool to restrict 2 messages per day for every user.
 > Is it available such a setup in Mailman?

No.

 > Does anyone have any experience like this?

Such restrictions are typically neither fair nor effective.  It is
quite difficult to prevent a determined and mildly skilled user from
posting without moderation, but your list must be receiving about 500
posts per day.  So moderation doesn't sound like a very attractive
alternative.  But if you don't have moderation, the determined and
skilled will be able to post freely, while others are effectively
suppressed.

Perhaps it would be possible to set up additional lists and split the
traffic?

If that doesn't appeal to you, we need to know more about your
requirements.



From cnulk at scu.edu  Mon Jul 15 17:16:40 2013
From: cnulk at scu.edu (Chris Nulk)
Date: Mon, 15 Jul 2013 08:16:40 -0700
Subject: [Mailman-Users] Writing a custom handler
In-Reply-To: <51D4FDBE.7040009@msapiro.net>
References: <51D1BB44.2060000@scu.edu> <51D20436.4050300@msapiro.net>
	<51D2F64D.80809@scu.edu> <51D30B06.5000500@msapiro.net>
	<51D31E21.8030601@scu.edu> <51D32738.4040500@msapiro.net>
	<51D33CDF.3080209@scu.edu> <51D34812.4060000@msapiro.net>
	<51D34FAF.2010907@scu.edu> <51D36F1A.6050909@msapiro.net>
	<51D437EB.5070403@scu.edu> <51D4FDBE.7040009@msapiro.net>
Message-ID: <51E41258.1040402@scu.edu>


On 7/3/2013 9:44 PM, Mark Sapiro wrote:
> On 07/03/2013 07:40 AM, Chris Nulk wrote:
>> Okay.  Makes sense.  Here is the modified do_discard_globalban code:
>>
>> def do_discard_globalban(mlist, msg, sender):
>>      # forward discarded message to site administrator(s) if defined
>>      #    in mm_cfg.GLOBALBANLIST_NOTIFY
>>      notifylist = []
>>      if mm_cfg.GLOBALBANLIST_NOTIFY:
>>          notifylist.append(mm_cfg.GLOBALBANLIST_NOTIFY)
>
> You might consider making mm_cfg.GLOBALBANLIST_NOTIFY a list of 1 or
> more addresses in which case the above would be
>
>      if mm_cfg.GLOBALBANLIST_NOTIFY:
>          notifylist.extend(mm_cfg.GLOBALBANLIST_NOTIFY)
>
> or you could get fancy and test if it's a list or a string and extend or
> append accordingly.
>

Sorry about not responding earlier, I was on vacation.  That is exactly 
what I intended.  I didn't see extend when I was looking up information 
on lists.  Thanks.

I was thinking about what you mentioned in an earlier message about this 
handler not catching the command requests like subscribe, unsubscribe, 
etc.  I think I have a possible solution but I want to think about it 
some more then ask about it.

Thanks for the help on the handler,
Chris

From nyasar at bilgievi.net  Mon Jul 15 22:03:33 2013
From: nyasar at bilgievi.net (Nezih Yasar)
Date: Mon, 15 Jul 2013 23:03:33 +0300
Subject: [Mailman-Users] To restrict sending email messages per day
In-Reply-To: <87y598rl9e.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CADbT6qLsqu_VDnMTEqgp6ukhCGo37FeYc_Dg6mUkKGJDehkPhg@mail.gmail.com>
	<87y598rl9e.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <CADbT6qLRjA1DBOwiTFsqh5fKyNc_6qEPT4gvMYGBWfJTyU0ZAw@mail.gmail.com>

Thank you Stephen,
We have enough additional lists sharing the traffic but this is an alumni
list without moderation. It has a central role. Each alumni has a right to
affiliate the list.
Our members agree on two-mail-per-day restriction convinced that it
disciplines writing to this central list. So this is a rule in our
procedural document which is like a regulatory framework.
But really a few members do not obey this rule deliberately. Condemnations
had no effect on them. This is the reason we need such a technical way to
obey the rule.
Our members can tolerate two mails per day from these people, but most of
members are very uneasy because of the excessive mail annoyance of them.
Naturally this has caused some drops in memberships.
This our problem, an embedded rule may ease our pain. But we can manage it
as in last fifteen years countenancing dropped memberships continues...
I am not sure whether this situation requires such a tool, some of our
members demand it.
I am really sorry for that weepy and long explanations :(
Thanks a lot.
Nezih Yasar


On Mon, Jul 15, 2013 at 4:43 PM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> Nezih Yasar writes:
>
>  > Hello everybody,
>  > I am an owner of a list using Mailman.
>  > We have more than 200 active senders in a 2000-member list.
>  > We need a setup tool to restrict 2 messages per day for every user.
>  > Is it available such a setup in Mailman?
>
> No.
>
>  > Does anyone have any experience like this?
>
> Such restrictions are typically neither fair nor effective.  It is
> quite difficult to prevent a determined and mildly skilled user from
> posting without moderation, but your list must be receiving about 500
> posts per day.  So moderation doesn't sound like a very attractive
> alternative.  But if you don't have moderation, the determined and
> skilled will be able to post freely, while others are effectively
> suppressed.
>
> Perhaps it would be possible to set up additional lists and split the
> traffic?
>
> If that doesn't appeal to you, we need to know more about your
> requirements.
>
>
>

From Richard at Damon-Family.org  Tue Jul 16 01:38:33 2013
From: Richard at Damon-Family.org (Richard Damon)
Date: Mon, 15 Jul 2013 19:38:33 -0400
Subject: [Mailman-Users] To restrict sending email messages per day
In-Reply-To: <CADbT6qLRjA1DBOwiTFsqh5fKyNc_6qEPT4gvMYGBWfJTyU0ZAw@mail.gmail.com>
References: <CADbT6qLsqu_VDnMTEqgp6ukhCGo37FeYc_Dg6mUkKGJDehkPhg@mail.gmail.com>
	<87y598rl9e.fsf@uwakimon.sk.tsukuba.ac.jp>
	<CADbT6qLRjA1DBOwiTFsqh5fKyNc_6qEPT4gvMYGBWfJTyU0ZAw@mail.gmail.com>
Message-ID: <51E487F9.9080601@Damon-Family.org>

On 7/15/13 4:03 PM, Nezih Yasar wrote:
> Thank you Stephen,
> We have enough additional lists sharing the traffic but this is an alumni
> list without moderation. It has a central role. Each alumni has a right to
> affiliate the list.
> Our members agree on two-mail-per-day restriction convinced that it
> disciplines writing to this central list. So this is a rule in our
> procedural document which is like a regulatory framework.
> But really a few members do not obey this rule deliberately. Condemnations
> had no effect on them. This is the reason we need such a technical way to
> obey the rule.
> Our members can tolerate two mails per day from these people, but most of
> members are very uneasy because of the excessive mail annoyance of them.
> Naturally this has caused some drops in memberships.
> This our problem, an embedded rule may ease our pain. But we can manage it
> as in last fifteen years countenancing dropped memberships continues...
> I am not sure whether this situation requires such a tool, some of our
> members demand it.
> I am really sorry for that weepy and long explanations :(
> Thanks a lot.
> Nezih Yasar
>
One simple solution is once you detect the violator, put them on
moderation and actively limit their posting.

-- 
Richard Damon


From mark at msapiro.net  Tue Jul 16 04:00:31 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 15 Jul 2013 19:00:31 -0700
Subject: [Mailman-Users] To restrict sending email messages per day
In-Reply-To: <CADbT6qLRjA1DBOwiTFsqh5fKyNc_6qEPT4gvMYGBWfJTyU0ZAw@mail.gmail.com>
References: <CADbT6qLsqu_VDnMTEqgp6ukhCGo37FeYc_Dg6mUkKGJDehkPhg@mail.gmail.com>
	<87y598rl9e.fsf@uwakimon.sk.tsukuba.ac.jp>
	<CADbT6qLRjA1DBOwiTFsqh5fKyNc_6qEPT4gvMYGBWfJTyU0ZAw@mail.gmail.com>
Message-ID: <51E4A93F.3080007@msapiro.net>

On 07/15/2013 01:03 PM, Nezih Yasar wrote:

> This our problem, an embedded rule may ease our pain. But we can manage it
> as in last fifteen years countenancing dropped memberships continues...
> I am not sure whether this situation requires such a tool, some of our
> members demand it.


Assuming Richard's suggestion of just moderating the offenders is not
acceptable, you could do this with a custom handler
<http://wiki.list.org/x/l4A9>. If you want to do that and need coding
help, just ask.

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

From benfell at parts-unknown.org  Tue Jul 16 02:09:43 2013
From: benfell at parts-unknown.org (David Benfell)
Date: Mon, 15 Jul 2013 17:09:43 -0700
Subject: [Mailman-Users] To restrict sending email messages per day
In-Reply-To: <51E487F9.9080601@Damon-Family.org>
References: <CADbT6qLsqu_VDnMTEqgp6ukhCGo37FeYc_Dg6mUkKGJDehkPhg@mail.gmail.com>
	<87y598rl9e.fsf@uwakimon.sk.tsukuba.ac.jp>
	<CADbT6qLRjA1DBOwiTFsqh5fKyNc_6qEPT4gvMYGBWfJTyU0ZAw@mail.gmail.com>
	<51E487F9.9080601@Damon-Family.org>
Message-ID: <51E48F47.7080306@parts-unknown.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/15/2013 04:38 PM, Richard Damon wrote:
> On 7/15/13 4:03 PM, Nezih Yasar wrote:

<snip>

>> Our members agree on two-mail-per-day restriction convinced that
>> it disciplines writing to this central list. So this is a rule in
>> our procedural document which is like a regulatory framework. But
>> really a few members do not obey this rule deliberately.
>> Condemnations had no effect on them.

<snip>

> One simple solution is once you detect the violator, put them on 
> moderation and actively limit their posting.
> 
Agreed. You have tried socially shaming them, so they have been
warned. I would just approve the first two for each violator that I
saw per day and explicitly reject the rest.

- -- 
David Benfell / benfell at parts-unknown.org
Please see https://parts-unknown.org/node/2 for GnuPG information (or
the attachment you don't understand)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR5I9GAAoJELJhbl/uPb4SBfwP/jlEZJX4i7zIMSxjM/SrADsK
PNauGhmHvARUgRdSQWVF+YBmB6isZ73UqUQ07gg2NYH5F3k7ozxRZKepc8c6iCAj
v0+5TiY/d1rG9hj1ahYXSiB4VL06sHYPU431MsqPZn66T0lDBzseVBecFxprECv6
6Dl2Nrf+a3Qh5T00NQIlIqN0lgmMbAol4N01eMfuac2EOE0ITFWqmzg1AKZwF8pC
hJiiim4Lw3K1kzE8mWli7YQUXaO+noDxp8C6zTWoA3Sx6HFAHsmL4SYLEdHG3JlA
yWkxuF+wICEZ0Akq0zNR29oaqtFW8tXVcsffmbzSfW90UCZ6E5nJL7g+gPYg2r0a
+3e0B2dZnkQh9QgRaa+1wprzZ4hFrrROsd9XmANvfVkquXQXpVTn7YjROR9vn2+z
Q50O4+SPDDM4TgR87sd58y0BxF86OXrjt1dVj2wPvFJTfU7KzOGUOTMBoNXPwIHt
DM+vf/trRfw82O72OtLtoV4TNAtxv3Y+d4LuOZIvJBliTwjjL74RmX/CSgYKR0yg
WDJSSnaZb3TVV4ZrRjorm5YTAnQPBoFT5EC8iQACWbpnYfQOZ+NPMOGzWH/OLPb3
2d6o/xJvAI1++uGkbpI3v0Jrm0t8Kr6jcw5JVmB5WoYI4cENEj1u11E8s4Ac9MVC
bmDS33AMnYYMGOnSn4Jp
=1XsV
-----END PGP SIGNATURE-----

From alv at alv.cl  Mon Jul 15 16:49:23 2013
From: alv at alv.cl (alv at alv.cl)
Date: Mon, 15 Jul 2013 10:49:23 -0400 (CLT)
Subject: [Mailman-Users] Problems after server migration
Message-ID: <alpine.LRH.2.03.1307150948560.3919@alv.cl>


Hi,

I just migrated my mailman installation from an old fedora server to a new 
centos server.

I followed the instructions described here:

http://mail.python.org/pipermail/mailman-users/2007-January/055208.html

The URLs remained the same, but the IP changed.

If I try to start the mailman service, it says:

# service mailman start
Starting mailman: Site list is missing: mailman

If I run list_lists, it shows all the lists I migrated (including mailman).

I used mailmanctl instead and it worked:

# ./mailmanctl start
Starting Mailman's master qrunner.

But none of the old lists are recognized. Sending a mail to any of them 
results in a bounced message:

Command died with status 1: "/usr/lib/mailman/mail/mailman
    post some-list". Command output: post script, list not found: some-list

Web interface doesn't recognize old lists either.

I created a new list and it worked like a charm.

I tried fixing perms with check_perms, but nothing.

What am I missing?


Thanks in advance for your help!


-alv-

From stephen at xemacs.org  Tue Jul 16 05:18:19 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 16 Jul 2013 12:18:19 +0900
Subject: [Mailman-Users] To restrict sending email messages per day
In-Reply-To: <51E487F9.9080601@Damon-Family.org>
References: <CADbT6qLsqu_VDnMTEqgp6ukhCGo37FeYc_Dg6mUkKGJDehkPhg@mail.gmail.com>
	<87y598rl9e.fsf@uwakimon.sk.tsukuba.ac.jp>
	<CADbT6qLRjA1DBOwiTFsqh5fKyNc_6qEPT4gvMYGBWfJTyU0ZAw@mail.gmail.com>
	<51E487F9.9080601@Damon-Family.org>
Message-ID: <87sizfry4k.fsf@uwakimon.sk.tsukuba.ac.jp>

Richard Damon writes:
 > On 7/15/13 4:03 PM, Nezih Yasar wrote:

 > > We have enough additional lists sharing the traffic but this is an alumni
 > > list without moderation. It has a central role. Each alumni has a right to
 > > affiliate the list.

OK.  I still suspect that starting a new list for active discussants
would be useful as part of a strategy to deal with this, but it has
its disadvantages.

 > > Our members agree on two-mail-per-day restriction convinced that it
 > > disciplines writing to this central list. So this is a rule in our
 > > procedural document which is like a regulatory framework.

OK.  It's really important that you have the backing of the
membership, in my experience.  Most people like having a strong list
owner who enforces such rules that are generally and publicly agreed,
but if it looks like you're making up a new rule, people you really
want on your side will fear you are setting up as censor.  (Even if
it's a very objective rule like "2 per day".)

 > > I am not sure whether this situation requires such a tool, some of our
 > > members demand it.

 > One simple solution is once you detect the violator, put them on
 > moderation and actively limit their posting.

I agree with Richard, this is the quick and simple solution.  You
probably should discuss it with the community before implementing it,
though.

It has a number of social advantages.  The offenders (against the
community custom) are punished, and feel an appropriate amount of
pain.  The pain can be calibrated (by the frequency of moderation,
once a day, once every other day, etc, and by the length of time the
member is place on moderation).

I'll think about writing a "PosterThrottle" handler to implement your
requirements, but it will take a week or two.

Steve

From mark at msapiro.net  Tue Jul 16 07:12:10 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 15 Jul 2013 22:12:10 -0700
Subject: [Mailman-Users] Problems after server migration
In-Reply-To: <alpine.LRH.2.03.1307150948560.3919@alv.cl>
References: <alpine.LRH.2.03.1307150948560.3919@alv.cl>
Message-ID: <51E4D62A.5090408@msapiro.net>

On 07/15/2013 07:49 AM, alv at alv.cl wrote:
> 
> I just migrated my mailman installation from an old fedora server to a
> new centos server.
[...]
> If I try to start the mailman service, it says:
> 
> # service mailman start
> Starting mailman: Site list is missing: mailman
> 
> If I run list_lists, it shows all the lists I migrated (including mailman).
> 
> I used mailmanctl instead and it worked:
> 
> # ./mailmanctl start
> Starting Mailman's master qrunner.


My best guess is your CentOS mailman (a RedHat package ?) doesn't expect
the lists to be in the directory you moved them too. The FAQ at
<http://wiki.list.org/x/KYCB> may help.

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

From alv at alv.cl  Tue Jul 16 16:47:56 2013
From: alv at alv.cl (alv at alv.cl)
Date: Tue, 16 Jul 2013 10:47:56 -0400 (CLT)
Subject: [Mailman-Users] Problems after server migration
In-Reply-To: <51E4D62A.5090408@msapiro.net>
References: <alpine.LRH.2.03.1307150948560.3919@alv.cl>
	<51E4D62A.5090408@msapiro.net>
Message-ID: <alpine.LRH.2.03.1307161042330.3919@alv.cl>

On Mon, 15 Jul 2013 at 10:12pm, Mark Sapiro wrote:

> My best guess is your CentOS mailman (a RedHat package ?) doesn't expect 
> the lists to be in the directory you moved them too. The FAQ at 
> <http://wiki.list.org/x/KYCB> may help.

Thank you for answer, Mark.

When I created a test list after the migration, its files were located in 
the same paths that the ones migrated, so I think unfortunately, that's not 
the problem.

Regards


-alv-

From bsfinkel at att.net  Tue Jul 16 17:10:04 2013
From: bsfinkel at att.net (Barry S. Finkel)
Date: Tue, 16 Jul 2013 10:10:04 -0500
Subject: [Mailman-Users] Problems after server migration
In-Reply-To: <alpine.LRH.2.03.1307150948560.3919@alv.cl>
References: <alpine.LRH.2.03.1307150948560.3919@alv.cl>
Message-ID: <51E5624C.8090406@att.net>

On 7/15/2013 9:49 AM, alv at alv.cl wrote:
>
> Hi,
>
> I just migrated my mailman installation from an old fedora server to a
> new centos server.
>
> I followed the instructions described here:
>
> http://mail.python.org/pipermail/mailman-users/2007-January/055208.html
>
> The URLs remained the same, but the IP changed.
>
> If I try to start the mailman service, it says:
>
> # service mailman start
> Starting mailman: Site list is missing: mailman
>
> If I run list_lists, it shows all the lists I migrated (including mailman).
>
> I used mailmanctl instead and it worked:
>
> # ./mailmanctl start
> Starting Mailman's master qrunner.
>
> But none of the old lists are recognized. Sending a mail to any of them
> results in a bounced message:
>
> Command died with status 1: "/usr/lib/mailman/mail/mailman
>     post some-list". Command output: post script, list not found: some-list
>
> Web interface doesn't recognize old lists either.
>
> I created a new list and it worked like a charm.
>
> I tried fixing perms with check_perms, but nothing.
>
> What am I missing?
>
>
> Thanks in advance for your help!
>
>
> -alv-
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at python.org
> http://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Security Policy: http://wiki.list.org/x/QIA9
> Searchable Archives:
> http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe:
> http://mail.python.org/mailman/options/mailman-users/bsfinkel%40att.net
>

Does Postfix know where your Mailman alias file is?
Does that alias file contain aliases for all of your lists?
Have you run the newaliases command?
--Barry Finkel

From alv at alv.cl  Tue Jul 16 17:35:04 2013
From: alv at alv.cl (Alvaro Navarro)
Date: Tue, 16 Jul 2013 11:35:04 -0400 (CLT)
Subject: [Mailman-Users] Problems after server migration
In-Reply-To: <51E5624C.8090406@att.net>
References: <alpine.LRH.2.03.1307150948560.3919@alv.cl>
	<51E5624C.8090406@att.net>
Message-ID: <alpine.LRH.2.03.1307161128530.3919@alv.cl>

On Tue, 16 Jul 2013 at 10:10am, Barry S. Finkel wrote:

> Does Postfix know where your Mailman alias file is?
> Does that alias file contain aliases for all of your lists?
> Have you run the newaliases command?
> --Barry Finkel

Hi Barry,

Yes, postfix has all the Mailman alias. In fact, the error message received 
when I sent a mail to one of the lists made reference to one of those 
alias:

Command died with status 1: "/usr/lib/mailman/mail/mailman
    post some-list". Command output: post script, list not found: some-list

Best regards


-alv-

From mark at msapiro.net  Tue Jul 16 21:28:24 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 16 Jul 2013 12:28:24 -0700
Subject: [Mailman-Users] Problems after server migration
In-Reply-To: <alpine.LRH.2.03.1307161042330.3919@alv.cl>
References: <alpine.LRH.2.03.1307150948560.3919@alv.cl>
	<51E4D62A.5090408@msapiro.net>
	<alpine.LRH.2.03.1307161042330.3919@alv.cl>
Message-ID: <51E59ED8.7030806@msapiro.net>

On 07/16/2013 07:47 AM, alv at alv.cl wrote:
> On Mon, 15 Jul 2013 at 10:12pm, Mark Sapiro wrote:
> 
>> My best guess is your CentOS mailman (a RedHat package ?) doesn't
>> expect the lists to be in the directory you moved them too. The FAQ at
>> <http://wiki.list.org/x/KYCB> may help.
> 
> Thank you for answer, Mark.
> 
> When I created a test list after the migration, its files were located
> in the same paths that the ones migrated, so I think unfortunately,
> that's not the problem.


This makes no sense. Does bin/list_lists list both the old and the newly
created, working lists? Are the mode and group of the lists/LISTNAME
directories and the lists/LISTNAME/config.pck files the same for all
lists? Does 'bin/dumpdb lists/LISTNAME/config.pck' produce appropriate
output for both old and new lists? Does mail to the newly created lists
work? Does the old server still exist, and if so is there some possible
confusion between IPs and DNS so something is looking at the wrong
machine? Try 'grep -r xxx.xxx.xxx.xxx /usr/lib/mailman /var/lib/mailman'
where xxx.xxx.xxx.xxx is the old IP. There should be no reference by IP,
but ...?

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

From alv at alv.cl  Wed Jul 17 02:38:12 2013
From: alv at alv.cl (alv at alv.cl)
Date: Tue, 16 Jul 2013 20:38:12 -0400 (CLT)
Subject: [Mailman-Users] Problems after server migration
In-Reply-To: <51E59ED8.7030806@msapiro.net>
References: <alpine.LRH.2.03.1307150948560.3919@alv.cl>
	<51E4D62A.5090408@msapiro.net>
	<alpine.LRH.2.03.1307161042330.3919@alv.cl>
	<51E59ED8.7030806@msapiro.net>
Message-ID: <alpine.LRH.2.03.1307162015130.3919@alv.cl>

On Tue, 16 Jul 2013 at 12:28pm, Mark Sapiro wrote:

> This makes no sense.

Yes, that's why I'm so puzzled.


> Does bin/list_lists list both the old and the newly created, working 
> lists?

Yes.


> Are the mode and group of the lists/LISTNAME directories and the 
> lists/LISTNAME/config.pck files the same for all lists?

Yes, all files and directories belong to mailman, and mailman group.


> Does 'bin/dumpdb lists/LISTNAME/config.pck' produce appropriate output 
> for both old and new lists?

They both seem consistent. Is there anything in particular I should look 
more carefully?


> Does mail to the newly created lists work?

Yes.


> Does the old server still exist, and if so is there some possible
> confusion between IPs and DNS so something is looking at the wrong
> machine?

The old server no longer exists. There's no chance of confusing because I'm 
sending the test mails from the mailman server itself.


> Try 'grep -r xxx.xxx.xxx.xxx /usr/lib/mailman /var/lib/mailman'
> where xxx.xxx.xxx.xxx is the old IP. There should be no reference by IP,
> but ...?

As you suggested I did that, but all I found was references to the old IP 
in the archives.

Somehow the old lists are registered somewhere else and the "service 
mailman start" doesn't know where and refuses to start without a 
list called mailman.


Regards


-alv-

From dave at fiteyes.com  Wed Jul 17 03:39:02 2013
From: dave at fiteyes.com (David)
Date: Tue, 16 Jul 2013 21:39:02 -0400
Subject: [Mailman-Users] Migration to a new server: recommendations for
 testing the new Mailman server before changing DNS records;
 also how to avoid lost/bounced messages during change-over?
In-Reply-To: <51DB3CDD.9090204@msapiro.net>
References: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>
	<51D63451.9040006@msapiro.net>
	<CAH=dxU5vabyKXzpmqV4S6o3b-nF0VA3V-TMm+hts-TkJezo+HQ@mail.gmail.com>
	<51DB3CDD.9090204@msapiro.net>
Message-ID: <CAH=dxU4Xz_JXvUD7Xb7hBnbwE_+g25WjsBKnyovDTsb6rMuygA@mail.gmail.com>

see below

On Mon, Jul 8, 2013 at 6:27 PM, Mark Sapiro <mark at msapiro.net> wrote:

> On 07/08/2013 01:29 PM, David wrote:
> > On Thu, Jul 4, 2013 at 10:49 PM, Mark Sapiro <mark at msapiro.net> wrote:
> >
> >     If the mail server on the new box thinks list domains are in its
> local
> >     delivery space (mydestination in Postfix), you can just send mail
> from
> >     an MUA on the local box configured to deliver via SMTP to the local
> MTA,
> >     and it all should work except that mail from Mailman to local
> addresses
> >     will be delivered to the new box instead of the current live box.
> >
> >
> > The new box has no GUI. The OS is Debian 6.
> > $ uname -r
> > 3.9.3-x86_64-linode33
> >
> > The MUA is:
> > heirloom-mailx
> > $ mailx -V
> > 12.5 6/20/10
> >
> > The MTA is postfix. (For some reason I can't run "postconf -d | grep
> > mail_version" so I'll have to ask the sysadmin later about that. But at
> > the moment, I don't know the postfix version.)
> >
> > Given that info, which settings changes should I make to proceed with
> > the testing plan you described above?
> >
> > So far all I did was:
> > 1. create a ~/.mailrc file with contents:
> >
> > set smtp=localhost
>
>
> If that tells mailx to send via smtp to localhost, that's good.
>
>
> > 2. edit /etc/postfix/main.cf <http://main.cf> and change mydestination
> > to the line below:
> > mydestination = localhost, localhost.localdomain
>
>
> If I understood correctly, this is not what you want. My understanding
> is you have an old (current) box with a domain and an IP and DNS for the
> domain pointing to the IP, and after the switch the domain and IP will
> be those of the new box, but for now, the new box has a different IP.
>
> If this is the case, you should not be making any changes to main.cf
> over what you want after the switch, i.e. it should look like that on
> the old box.
>
> Now, in this configuration, list mail should be delivered locally, so if
> you send mail from the local MUA on the new box to a list address, the
> MUA will deliver it to the local Postfix and that in turn will deliver
> it to the local Mailman.
>
> --
> Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
>

Here's what the sysadmin ended up doing.

First, he added our domain in postfix mydestination but it didn't help so
he did these steps:

1) Added our domain in relay_domains

2) Added the following in in master.cf

mailman unix - n n - - pipe
flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
${nexthop} ${user}

3) Added our domain in transport
Now we can test using a local MUA (mailx) with SMTP set to localhost.
Without the steps above, it just was not working (i.e., we were not able to
successfully send test messages to the list).

I am posting this follow-up for a few reasons. Primarily, I would
appreciate any feedback that I can pass along to our sysadmin.

And since I really don't understand the overall ramifications of the
changes above, I would enjoy learning something if there are any comments.
For example, I assume we'll have to undo those changes when we go live, and
I always hate to make any last minute changes because of the possibility
that something will stop working as a result of those changes.

Finally, if anyone else needs to try what I'm doing, this info is relevant.

From mark at msapiro.net  Wed Jul 17 03:42:07 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 16 Jul 2013 18:42:07 -0700
Subject: [Mailman-Users] Problems after server migration
In-Reply-To: <alpine.LRH.2.03.1307162015130.3919@alv.cl>
References: <alpine.LRH.2.03.1307150948560.3919@alv.cl>
	<51E4D62A.5090408@msapiro.net>
	<alpine.LRH.2.03.1307161042330.3919@alv.cl>
	<51E59ED8.7030806@msapiro.net>
	<alpine.LRH.2.03.1307162015130.3919@alv.cl>
Message-ID: <51E5F66F.9010200@msapiro.net>

On 07/16/2013 05:38 PM, alv at alv.cl wrote:
> On Tue, 16 Jul 2013 at 12:28pm, Mark Sapiro wrote:
> 
>> Does 'bin/dumpdb lists/LISTNAME/config.pck' produce appropriate output
>> for both old and new lists?
> 
> They both seem consistent. Is there anything in particular I should look
> more carefully?


No, I was only interested in whether they produced appropriate output as
opposed to an exception and traceback. You might look at web_page_url
for web server issues (see below), but that shouldn't affect postfix.


> Somehow the old lists are registered somewhere else and the "service
> mailman start" doesn't know where and refuses to start without a list
> called mailman.


Yes. This is consistent with Postfix not finding the old lists.

Look at /etc/init.d/mailman. Is it running the same mailmanctl as you
are running by hand.

Look in every aliases file referenced by Postfix in alias_maps. There
should at least be /etc/aliases and /var/lib/mailman/data/aliases and
maybe others. Are there duplicate aliases for any mailman lists. Do they
all point to the same wrapper (/usr/lib/mailman/mail/mailman).

When you said the web server doesn't recognize the old lists, did you
mean just they don't appear on http://example.com/mailman/listinfo or
that also you get a 'no such list' from
http://example.com/mailman/listinfo/listname.

Continuing to grasp at straws, try

sudo find / -name config.pck

Does that return more than just the one
/var/lib/mailman/lists/LISTNAME/config.pck for the new lists.

If you are running SELinux, try disabling it.

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

From mark at msapiro.net  Wed Jul 17 03:56:34 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 16 Jul 2013 18:56:34 -0700
Subject: [Mailman-Users] Migration to a new server: recommendations for
 testing the new Mailman server before changing DNS records;
 also how to avoid lost/bounced messages during change-over?
In-Reply-To: <CAH=dxU4Xz_JXvUD7Xb7hBnbwE_+g25WjsBKnyovDTsb6rMuygA@mail.gmail.com>
References: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>
	<51D63451.9040006@msapiro.net>
	<CAH=dxU5vabyKXzpmqV4S6o3b-nF0VA3V-TMm+hts-TkJezo+HQ@mail.gmail.com>
	<51DB3CDD.9090204@msapiro.net>
	<CAH=dxU4Xz_JXvUD7Xb7hBnbwE_+g25WjsBKnyovDTsb6rMuygA@mail.gmail.com>
Message-ID: <51E5F9D2.6080604@msapiro.net>

On 07/16/2013 06:39 PM, David wrote:
> 
> Here's what the sysadmin ended up doing.
> 
> First, he added our domain in postfix mydestination but it didn't help
> so he did these steps:
> 
> 1) Added our domain in relay_domains
> 
> 2) Added the following in in master.cf <http://master.cf>
> 
> mailman unix - n n - - pipe
> flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
> ${nexthop} ${user}


I think this is the first mention of postfix-to-mailman.py in this
thread. My advice to ensure that the list domain was in mydestination
was based on my incorrect assumption that you were using aliases.

You and your sysadmin may find the FAQ at <http://wiki.list.org/x/EYDt>
and the post at
<http://mail.python.org/pipermail/mailman-users/2012-September/074017.html>
which is linked therefrom to be of interest.

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

From dave at fiteyes.com  Wed Jul 17 04:46:50 2013
From: dave at fiteyes.com (David)
Date: Tue, 16 Jul 2013 22:46:50 -0400
Subject: [Mailman-Users] Migration to a new server: recommendations for
 testing the new Mailman server before changing DNS records;
 also how to avoid lost/bounced messages during change-over?
In-Reply-To: <51E5F9D2.6080604@msapiro.net>
References: <CAH=dxU4auwEPSowRCxrH_CNR33tT=O+7s6vuKsfkA0QOyFjfSA@mail.gmail.com>
	<51D63451.9040006@msapiro.net>
	<CAH=dxU5vabyKXzpmqV4S6o3b-nF0VA3V-TMm+hts-TkJezo+HQ@mail.gmail.com>
	<51DB3CDD.9090204@msapiro.net>
	<CAH=dxU4Xz_JXvUD7Xb7hBnbwE_+g25WjsBKnyovDTsb6rMuygA@mail.gmail.com>
	<51E5F9D2.6080604@msapiro.net>
Message-ID: <CAH=dxU7TLKTsF73pEbB1B8phQpg8Jaq_iY09=0FT7akWaRdDmQ@mail.gmail.com>

see below

On Tue, Jul 16, 2013 at 9:56 PM, Mark Sapiro <mark at msapiro.net> wrote:

> On 07/16/2013 06:39 PM, David wrote:
> >
> > Here's what the sysadmin ended up doing.
> >
> > First, he added our domain in postfix mydestination but it didn't help
> > so he did these steps:
> >
> > 1) Added our domain in relay_domains
> >
> > 2) Added the following in in master.cf <http://master.cf>
> >
> > mailman unix - n n - - pipe
> > flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
> > ${nexthop} ${user}
>
>
> I think this is the first mention of postfix-to-mailman.py in this
> thread. My advice to ensure that the list domain was in mydestination
> was based on my incorrect assumption that you were using aliases.
>
> You and your sysadmin may find the FAQ at <http://wiki.list.org/x/EYDt>
> and the post at
> <http://mail.python.org/pipermail/mailman-users/2012-September/074017.html
> >
> which is linked therefrom to be of interest.
>
> --
> Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
>


Yes, this is the first mention of postfix-to-mailman.py in this thread. I
did not know what it was until I read your links.

And your assumption was *not* incorrect. We *are* using aliases!

>From the links you provided, I see this quote:

"postfix_to_mailman.py is an alternative to and is incompatible with
Mailman delivery via aliases."

So we have a problem here...

BTW, my sysadmin doesn't know Mailman.

From alv at alv.cl  Wed Jul 17 05:43:49 2013
From: alv at alv.cl (Alvaro Navarro)
Date: Tue, 16 Jul 2013 23:43:49 -0400 (CLT)
Subject: [Mailman-Users] Problems after server migration
In-Reply-To: <51E5F66F.9010200@msapiro.net>
References: <alpine.LRH.2.03.1307150948560.3919@alv.cl>
	<51E4D62A.5090408@msapiro.net>
	<alpine.LRH.2.03.1307161042330.3919@alv.cl>
	<51E59ED8.7030806@msapiro.net>
	<alpine.LRH.2.03.1307162015130.3919@alv.cl>
	<51E5F66F.9010200@msapiro.net>
Message-ID: <alpine.LRH.2.03.1307162341150.2068@alv.cl>

On Tue, 16 Jul 2013 at 6:42pm, Mark Sapiro wrote:

> [...]

> If you are running SELinux, try disabling it.

Mark, you rock :-)

That was it!

Thank you very much!


-alv-

From glen at prideaux.id.au  Wed Jul 17 05:27:27 2013
From: glen at prideaux.id.au (Glen Prideaux)
Date: Wed, 17 Jul 2013 11:27:27 +0800
Subject: [Mailman-Users] Problems after server migration
In-Reply-To: <mailman.23303.1374025168.3113.mailman-users@python.org>
References: <mailman.23303.1374025168.3113.mailman-users@python.org>
Message-ID: <F0D2A729-842B-484E-8201-1791FE8DBB66@prideaux.id.au>

Is it possible that the new server has two installations of Mailman in different locations, and the one referenced by the startup script (that can't find the lists) is different from the one you are accessing manually? 

Glen

> From: alv at alv.cl
> Subject: Re: [Mailman-Users] Problems after server migration
> Date: 17 July 2013 8:38:12 AM AWST
> To: mailman-users at python.org
> 
> 
> On Tue, 16 Jul 2013 at 12:28pm, Mark Sapiro wrote:
> 
>> This makes no sense.
> 
> Yes, that's why I'm so puzzled.
> 
> 
>> Does bin/list_lists list both the old and the newly created, working lists?
> 
> Yes.
> 
> 
>> Are the mode and group of the lists/LISTNAME directories and the lists/LISTNAME/config.pck files the same for all lists?
> 
> Yes, all files and directories belong to mailman, and mailman group.
> 
> 
>> Does 'bin/dumpdb lists/LISTNAME/config.pck' produce appropriate output for both old and new lists?
> 
> They both seem consistent. Is there anything in particular I should look more carefully?
> 
> 
>> Does mail to the newly created lists work?
> 
> Yes.
> 
> 
>> Does the old server still exist, and if so is there some possible
>> confusion between IPs and DNS so something is looking at the wrong
>> machine?
> 
> The old server no longer exists. There's no chance of confusing because I'm sending the test mails from the mailman server itself.
> 
> 
>> Try 'grep -r xxx.xxx.xxx.xxx /usr/lib/mailman /var/lib/mailman'
>> where xxx.xxx.xxx.xxx is the old IP. There should be no reference by IP,
>> but ...?
> 
> As you suggested I did that, but all I found was references to the old IP in the archives.
> 
> Somehow the old lists are registered somewhere else and the "service mailman start" doesn't know where and refuses to start without a list called mailman.
> 
> 
> Regards
> 
> 
> -alv-


From cloos at jhcloos.com  Wed Jul 17 17:38:03 2013
From: cloos at jhcloos.com (James Cloos)
Date: Wed, 17 Jul 2013 11:38:03 -0400
Subject: [Mailman-Users] Reactivate delivery confirmation tokens
Message-ID: <m3li55rybv.fsf@carbon.jhcloos.org>

What is the deal with the confirmation tokens sent in the 'delivery
blocked, reply to re-enable' mails?

I've never received such a confirmation token which worked.  And I've
received more than a few over the last decade or more.

They are *always* invalid.

Whereas logging in and manually re-enabling always works.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

From mark at msapiro.net  Wed Jul 17 18:15:11 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 17 Jul 2013 09:15:11 -0700
Subject: [Mailman-Users] Reactivate delivery confirmation tokens
In-Reply-To: <m3li55rybv.fsf@carbon.jhcloos.org>
References: <m3li55rybv.fsf@carbon.jhcloos.org>
Message-ID: <51E6C30F.7080408@msapiro.net>

On 07/17/2013 08:38 AM, James Cloos wrote:
> What is the deal with the confirmation tokens sent in the 'delivery
> blocked, reply to re-enable' mails?
> 
> I've never received such a confirmation token which worked.  And I've
> received more than a few over the last decade or more.


I just tried it using my script at
<http://www.msapiro.net/scripts/set_nomail.py> to set an address to
nomail by bounce. I received the notice and confirmed via the URL in the
notice which worked. I repeated the process and confirmed via email
reply and that worked too.

What do you do and what happens?

Is your problem always with the same site?

Are you confirming within the sites PENDING_REQUEST_LIFE (default 3 days)?

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

From b42 at shastalakefpd.org  Wed Jul 17 23:45:55 2013
From: b42 at shastalakefpd.org (Chuck Dahlen)
Date: Wed, 17 Jul 2013 14:45:55 -0700
Subject: [Mailman-Users] "to" address
Message-ID: <003c01ce8337$08d3eef0$1a7bccd0$@org>

I am trying to figure out if there is a way to have Mailman 2.1.15 put the
actual email address of the list message in the "To:" address so that the
"hard" or "explicit" email address that the message is going out of Mailman
to is their email address.

 

Let me know if there is anything else needed to clarify this request.

 

Thanks,

 

Chuck

 

Charles Dahlen

Battalion Chief / Fire Marshal

 

Shasta Lake Fire Protection District

4126 Ashby Court

Shasta Lake, CA 96019-9215

(530) 275-7474

(530) 275-6502 FAX

B42 at ShastaLakeFPD.org

 

 


From jmwhitco at samford.edu  Wed Jul 17 20:01:29 2013
From: jmwhitco at samford.edu (Whitcomb, Jeff)
Date: Wed, 17 Jul 2013 18:01:29 +0000
Subject: [Mailman-Users] Allow message to auto accept based on another
	list's membership
Message-ID: <AC5132B983F1CF4299857664ECD30269933F1630@exc2010mb1>

I have about 30 to 40 lists I maintain and I'm having an issue with the sender filters.  We got a new spam filter that doesn't have a feature our previous filter did where it allowed me to specify the quarantine report go to a specific email address, so it's going to the list address instead.

I have ^.*@example.com<mailto:%5e.*@example.com> in the accept_these_nonmembers box, then have <spam digest>@example.com in the hold_these_nonmembers box.  I found out that auto accept takes precedence over auto hold.  I read somewhere there is a way, instead of doing ^.*@example.com<mailto:%5e.*@example.com>, I can enter something in the accept_these_nonmembers to use the membership of one or more other lists on the system, or all other lists to be auto accepted on.  I can't find this feature in the documentation, as I'm not sure what it's called.

I also want to see if using lists memberships for acceptance on another list presents any performance issue.

Can you point me to the feature name, or location of the appropriate documentation please?

Currently I have the <spam digest>@example.com email address subscribed to the list and set to moderate and no_mail.

I'm currently on version 2.1.6 (I don't control the upgrade schedule) :)

Thanks,

Jeff Whitcomb
Technology Services Manager
Cumberland School of Law - Samford University
205-726-4662
jmwhitco <at> samford <dot> edu

[SU-email-logo]

P Think before you print


From mark at msapiro.net  Thu Jul 18 08:11:49 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 17 Jul 2013 23:11:49 -0700
Subject: [Mailman-Users] "to" address
In-Reply-To: <003c01ce8337$08d3eef0$1a7bccd0$@org>
References: <003c01ce8337$08d3eef0$1a7bccd0$@org>
Message-ID: <51E78725.9000709@msapiro.net>

On 07/17/2013 02:45 PM, Chuck Dahlen wrote:
> I am trying to figure out if there is a way to have Mailman 2.1.15 put the
> actual email address of the list message in the "To:" address so that the
> "hard" or "explicit" email address that the message is going out of Mailman
> to is their email address.


It's called Full Personalization. See the FAQ at
<http://wiki.list.org/x/UYA9>.

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

From mark at msapiro.net  Thu Jul 18 08:25:42 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 17 Jul 2013 23:25:42 -0700
Subject: [Mailman-Users] Allow message to auto accept based on another
 list's membership
In-Reply-To: <AC5132B983F1CF4299857664ECD30269933F1630@exc2010mb1>
References: <AC5132B983F1CF4299857664ECD30269933F1630@exc2010mb1>
Message-ID: <51E78A66.5030904@msapiro.net>

On 07/17/2013 11:01 AM, Whitcomb, Jeff wrote:
> I read somewhere there is a way, instead of doing ^.*@example.com<mailto:%5e.*@example.com>, I can enter something in the accept_these_nonmembers to use the membership of one or more other lists on the system, or all other lists to be auto accepted on.  I can't find this feature in the documentation, as I'm not sure what it's called.


Click the "(Details for accept_these_nonmembers)" link on the Privacy
options... -> Sender filters page.


> I also want to see if using lists memberships for acceptance on another list presents any performance issue.


It costs a bit of extra IO and processing to instantiate the other
list(s), but it shouldn't be particularly noticeable unless the list is
very large.


> I'm currently on version 2.1.6 (I don't control the upgrade schedule) :)


Sorry, you're out of luck. The @listname feature was first introduced in
2.1.10.

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

From b42 at shastalakefpd.org  Fri Jul 19 01:56:30 2013
From: b42 at shastalakefpd.org (Chuck Dahlen)
Date: Thu, 18 Jul 2013 16:56:30 -0700
Subject: [Mailman-Users] "to" address
In-Reply-To: <51E78725.9000709@msapiro.net>
References: <003c01ce8337$08d3eef0$1a7bccd0$@org>
	<51E78725.9000709@msapiro.net>
Message-ID: <000c01ce8412$71bca7f0$5535f7d0$@org>

Well, bummer, I did a little research and while I am sure this would
probably work for what I need I don't have access to Mailman at that level
from our site host.  Their tech support on Hostmonster was excellent however
they stated that they run a customized version of Mailman and don't allow
users (even owners or administrators) to change even the configuration
variables.  They referred me to "Dadamail" so I am researching that now.

Thanks for the help...

Chuck

-----Original Message-----
From: Mark Sapiro [mailto:mark at msapiro.net] 
Sent: Wednesday, July 17, 2013 11:12 PM
To: mailman-users at python.org
Subject: Re: [Mailman-Users] "to" address

On 07/17/2013 02:45 PM, Chuck Dahlen wrote:
> I am trying to figure out if there is a way to have Mailman 2.1.15 put 
> the actual email address of the list message in the "To:" address so 
> that the "hard" or "explicit" email address that the message is going 
> out of Mailman to is their email address.


It's called Full Personalization. See the FAQ at
<http://wiki.list.org/x/UYA9>.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan
------------------------------------------------------
Mailman-Users mailing list Mailman-Users at python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy:
http://wiki.list.org/x/QIA9 Searchable Archives:
http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/b42%40shastalakefpd.org


From cloos at jhcloos.com  Fri Jul 19 17:47:47 2013
From: cloos at jhcloos.com (James Cloos)
Date: Fri, 19 Jul 2013 11:47:47 -0400
Subject: [Mailman-Users] Reactivate delivery confirmation tokens
In-Reply-To: <51E6C30F.7080408@msapiro.net> (Mark Sapiro's message of "Wed, 17
	Jul 2013 09:15:11 -0700")
References: <m3li55rybv.fsf@carbon.jhcloos.org> <51E6C30F.7080408@msapiro.net>
Message-ID: <m38v12pn43.fsf@carbon.jhcloos.org>

>>>>> "MS" == Mark Sapiro <mark at msapiro.net> writes:

MS> What do you do and what happens?

Mail comes in announcing that:

  Your membership in the mailing list $LISTNAME has been disabled due to
  excessive bounces

Neither replying nor surfing to the mailman/confirm/$LISTNAME/$TOKEN uri
works.

Using the uri and passwd listed after the:

  You can also visit your membership page at

line always works.

MS> Is your problem always with the same site?

No.

In my primary archive, I have 57 such mails from 33 sites over the last
34 months.  There are lots more going back another decade or so in my
burried archives.

The most recent runs 2.1.15.

MS> Are you confirming within the sites PENDING_REQUEST_LIFE (default 3 days)?

Generally w/in 12 hours of when the mail was sent.  Always w/in 24 hours.

I route mailman mail to a high-priority group to ensure that I see it
without delay.

It is only these non-interactive confirm mails which fail; sub, unsub,
and change address confirms always work.

I suspect that most of the sites install mailman via their distributions'
packaging.  Might the dists' packaging break something?

Of the last six (all in 2013), all but sf.net run debian, according to
the apache version strings.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

From shop at justbrits.com  Fri Jul 19 17:54:59 2013
From: shop at justbrits.com (" Just Brits " Shop)
Date: Fri, 19 Jul 2013 10:54:59 -0500
Subject: [Mailman-Users] "to" address
In-Reply-To: <000c01ce8412$71bca7f0$5535f7d0$@org>
References: <003c01ce8337$08d3eef0$1a7bccd0$@org>
	<51E78725.9000709@msapiro.net>
	<000c01ce8412$71bca7f0$5535f7d0$@org>
Message-ID: <51E96153.7060503@justbrits.com>

<< On 7/18/2013 6:56 PM, Chuck Dahlen wrote:
<snip>
> Their tech support on Hostmonster was excellent however
> they stated that they run a customized version of Mailman and don't allow
> users (even owners or administrators) to change even the configuration
> variables.  They referred me to "Dadamail" so I am researching that now.  >>

<snip<

IF Dadamail gives you any 'answer' Chuck, it WILL (should -:) ) be "contact cPanel" -:) ! !

cPanel puts out their "version" of MM.   Try a search for cPanel Forum.

Ed
Please visit MY site at:				www.justbrits.com



From mark at msapiro.net  Fri Jul 19 19:30:46 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 19 Jul 2013 10:30:46 -0700
Subject: [Mailman-Users] Reactivate delivery confirmation tokens
In-Reply-To: <m38v12pn43.fsf@carbon.jhcloos.org>
References: <m3li55rybv.fsf@carbon.jhcloos.org> <51E6C30F.7080408@msapiro.net>
	<m38v12pn43.fsf@carbon.jhcloos.org>
Message-ID: <51E977C6.7060806@msapiro.net>

On 07/19/2013 08:47 AM, James Cloos wrote:
>>>>>> "MS" == Mark Sapiro <mark at msapiro.net> writes:
> 
> MS> What do you do and what happens?
> 
> Mail comes in announcing that:
> 
>   Your membership in the mailing list $LISTNAME has been disabled due to
>   excessive bounces
> 
> Neither replying nor surfing to the mailman/confirm/$LISTNAME/$TOKEN uri
> works.


I understood that, but what else happens? What response do you get from
the web server when you go to the mailman/confirm/$LISTNAME/$TOKEN uri?

When you reply to the mail, do you get a "results of your email
commands" mail in reply and if so, what does it say.?


> It is only these non-interactive confirm mails which fail; sub, unsub,
> and change address confirms always work.


Do other confirmations, e.g. subscription requests, work?


> I suspect that most of the sites install mailman via their distributions'
> packaging.  Might the dists' packaging break something?
> 
> Of the last six (all in 2013), all but sf.net run debian, according to
> the apache version strings.


It's possible, but if Debian's package were broken in this way, I think
I would have heard from more than just you?

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

From cloos at jhcloos.com  Fri Jul 19 20:18:08 2013
From: cloos at jhcloos.com (James Cloos)
Date: Fri, 19 Jul 2013 14:18:08 -0400
Subject: [Mailman-Users] Reactivate delivery confirmation tokens
In-Reply-To: <51E977C6.7060806@msapiro.net> (Mark Sapiro's message of "Fri, 19
	Jul 2013 10:30:46 -0700")
References: <m3li55rybv.fsf@carbon.jhcloos.org> <51E6C30F.7080408@msapiro.net>
	<m38v12pn43.fsf@carbon.jhcloos.org> <51E977C6.7060806@msapiro.net>
Message-ID: <m3wqomo1l2.fsf@carbon.jhcloos.org>

>>>>> "MS" == Mark Sapiro <mark at msapiro.net> writes:

MS> I understood that, but what else happens? What response do you get from
MS> the web server when you go to the mailman/confirm/$LISTNAME/$TOKEN uri?

Sorry; I thought that was clear.  Replies to the confirm mail generate
an invalid token reply; surfing to the token uri returns an invalid
token page.

MS> Do other confirmations, e.g. subscription requests, work?

Yes.  As I wrote, all confirmation tokens generated by active requests
always work, whether change-of-email-address, subscribe or unsubscribe.

A few sites over the years only supported email or only supported http,
but the tokens never generated invalid errors unless they came as part
of a please-reply-to-reactivate mail.

In other words, tokens generated by the cgi or by sending a subscribe or
unsubscribe mail work, but tokens generated by class Bouncer are always
invalid.

Is the cookie expiring before the mail is sent?

I see the comment in Bouncer.py about trying to avoid that, but that
would explain things.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

From mark at msapiro.net  Fri Jul 19 22:48:55 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 19 Jul 2013 13:48:55 -0700
Subject: [Mailman-Users] Reactivate delivery confirmation tokens
In-Reply-To: <m3wqomo1l2.fsf@carbon.jhcloos.org>
References: <m3li55rybv.fsf@carbon.jhcloos.org> <51E6C30F.7080408@msapiro.net>
	<m38v12pn43.fsf@carbon.jhcloos.org> <51E977C6.7060806@msapiro.net>
	<m3wqomo1l2.fsf@carbon.jhcloos.org>
Message-ID: <51E9A637.6080800@msapiro.net>

On 07/19/2013 11:18 AM, James Cloos wrote:

> In other words, tokens generated by the cgi or by sending a subscribe or
> unsubscribe mail work, but tokens generated by class Bouncer are always
> invalid.
> 
> Is the cookie expiring before the mail is sent?
> 
> I see the comment in Bouncer.py about trying to avoid that, but that
> would explain things.


It appears there is a bug here. I'm not certain; I'll look further, but
it looks like when the initial disabling bounce is received, the token
is set and the notification is sent to the user, but if the user's
address is valid, but the user is bouncing for some temporary reason,
that notice will likely bounce too.

Thus, the first notice the user likely receives is sent after
bounce_you_are_disabled_warnings_interval by cron/disabled. The problem
is that a new token is not generated and this notice contains the
original token which almost certainly has expired.

Is the notice you receive sent at random times of day or is it always
sent at 9:00 a.m. in the time zone of the Mailman server?

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

From mark at msapiro.net  Sat Jul 20 01:15:22 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 19 Jul 2013 16:15:22 -0700
Subject: [Mailman-Users] Reactivate delivery confirmation tokens
In-Reply-To: <51E9A637.6080800@msapiro.net>
References: <m3li55rybv.fsf@carbon.jhcloos.org> <51E6C30F.7080408@msapiro.net>
	<m38v12pn43.fsf@carbon.jhcloos.org> <51E977C6.7060806@msapiro.net>
	<m3wqomo1l2.fsf@carbon.jhcloos.org> <51E9A637.6080800@msapiro.net>
Message-ID: <51E9C88A.8060405@msapiro.net>

On 07/19/2013 01:48 PM, Mark Sapiro wrote:
> 
> Thus, the first notice the user likely receives is sent after
> bounce_you_are_disabled_warnings_interval by cron/disabled. The problem
> is that a new token is not generated and this notice contains the
> original token which almost certainly has expired.


This is a bug. See <https://bugs.launchpad.net/mailman/+bug/1203200>.
The fix will be in 2.1.16rc2.

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

From mark at msapiro.net  Sat Jul 20 02:51:48 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 19 Jul 2013 17:51:48 -0700
Subject: [Mailman-Users] Mailman 2.1.16 release.
In-Reply-To: <51E30DF7.8020306@msapiro.net>
References: <51DF5301.7070802@msapiro.net> <51E30DF7.8020306@msapiro.net>
Message-ID: <51E9DF24.6030600@msapiro.net>

I am pleased to announce the second release candidate for Mailman 2.1.16.

Python 2.4 is the minimum supported, but Python 2.7 is recommended.

This release has a few new features and several bug fixed as detailed in
the attached README.

Differences from the first candidate are the inclusion of the admindb
summary sorting options feature and the 'author is list' feature and a
bug fix for lp:1203200. The Farsi translation has also been updated.

Mailman is free software for managing email mailing lists and
e-newsletters. Mailman is used for all the python.org and
SourceForge.net mailing lists, as well as at hundreds of other sites.

For more information, please see:

http://www.list.org
http://www.gnu.org/software/mailman
http://mailman.sourceforge.net/

Mailman 2.1.16rc2 can be downloaded from

https://launchpad.net/mailman/2.1/
http://ftp.gnu.org/gnu/mailman/
https://sourceforge.net/projects/mailman/

I anticipate that the 2.1.16 final release will be in early September.
Bugs found between now and then will be fixed if possible, but I hope
that most if not all changes between now and then will be i18n updates.
Please send any updates to the templates and/or message catalogs in the
2.1.16rc2 release directly to me no later than 1 Sept 2013.

Note that there is a minor glitch in the tarball in that the NEWS file
dates the release as xx-Aug-2013 instead of 19-Jul-2013, but I didn't
think it was worth uploading new files for that.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan
-------------- next part --------------
2.1.16rc2 (19-Jul-2013)

  New Features

    - There is a new list attribute author_is_list to rewrite the From: header
      of posts replacing the posters address with that of the list for
      compatability with DMARC and or ADSP.  There is a new mm_cfg.py setting
      DEFAULT_AUTHOR_IS_LIST to control the default for new lists, and the
      existing REMOVE_DKIM_HEADERS setting has been extended to allow removing
      those headers only for author_is_list = Yes lists.  This feature must be
      enabled by setting ALLOW_AUTHOR_IS_LIST to Yes in mm_cfg.py.

    - There is a new DISPLAY_HELD_SUMMARY_SORT_BUTTONS setting which if set
      in mm_cfg.py will display a set of radio buttons in the admindb held
      message summary to select how the held messages are sorted and grouped
      for display. The exact setting determines the default grouping and
      sorting.  See the description in Defaults.py for details.

    - Setting digest_size_threshhold to zero now means no digests will be
      sent based on size instead of a digest being sent with every post.
      (LP: #558274)

    - There is a new mm_cfg.py setting SUBSCRIBE_FORM_SECRET which will put
      a dynamically generated, hidden hash in the listinfo subscribe form and
      check it upon submission.  Setting this will prevent automated processes
      (bots) from successfully POSTing web subscribes without first retrieving
      and parsing the form from the listinfo page.  The form must also be
      submitted no later than FORM_LIFETIME nor no earlier than
      SUBSCRIBE_FORM_MIN_TIME after retrieval.  Note that enabling this will
      break any static subscribe forms on your site.  See the description in
      Defaults.py for more info.  (LP: #1082746)

    - add_members now has an option to add members with mail delivery disabled
      by admin.  (LP: #1070574)

    - IncomingRunner now logs rejected messages to the vette log.
      (LP: #1068837)

    - The name of the mailmanctl master lock file is now congigurable via the
      mm_cfg.py setting MASTER_LOCK_FILE.  (LP: #1082308)

    - list_lists now has an option to list only lists with public archives.
      (LP: #1082711)

  Contributed programs

    - A new import_majordomo_into_mailman.pl script has been contributed by
      Geoff Mayes.  (LP: #1129742)

    - A new "sitemap" bash script has been contributed by Tomasz Chmielewski
      <mangoo at wpkg.org> to generate a sitemap.xml file of an installation's
      public archives for submission to search engines.

  i18n

    - A Farsi (Persian) translation has been added thanks to Javad Hoseini and
      Mahyar Moghimi.

    - Fixed several misspelled or garbled string replacements in the Spanish
      message catalog.  (LP: #1160138)

    - pt_BR message catalog has two new and an updated message per Hugo Koji
      Kobayashi.  (LP: #1138578)

    - German message catalog has been updated per Ralf Hildebrandt.

    - Corrected typo in templates/it/private.html.

  Bug Fixes and other patches

    - Fixed cron/disabled to send a fresh cookie when notifying disabled
      members.  (LP: #1203200)

    - Added "message_id" to the interpolation dictionary for the Article.html
      template.  (LP: #725498)

    - Changed the admin GUI to report only the bad entries in a list of email
      addresses if any are bad.  (LP: #558253)

    - Added logging for template errors in HyperArch.py.  (LP: #558254)

    - Added more explanation to the bad owner address message from
      bin/newlist.  (LP: #1200763)

    - Fixed a bug causing the admin web interface to fail CSRF checking if
      the list name contains a '+' character.  (LP: #1190802)

    - Fixed bin/mailmanctl -s to not remove the master lock if it can't be
      determined to be truly stale.  (LP: #1189558)

    - It is no longer possible to add 'invalid' addresses to the ban_list
      and the *_these_nonmembers filters from the check boxes on the admindb
      interface.  (LP: #1187201)

    - Backported recognition for mail.ru DSNs and minor bug fixes from
      lp:flufl.bounce.  (LP: #1074592, LP: #1079249 and #1079254)

    - Defended against buggy web servers that don't include an empty
      QUERY_STRING in the CGI environment.  (LP: #1160647)

    - The Switchboard.finish() method now logs the text of the exception when
      it fails to unlink/preserve a .bak file.  (LP: #1165589)

    - The pending (un)subscriptions waiting approval are now sorted by email
      address in the admindb interface as intended.  (LP: #1164160)

    - The subscribe log entry for a bin/add_members subscribe now identifies
      bin/add_members as the source.  (LP: #1161642)

    - Fixed a bug where the Subject: of the user notification of a
      bin/remove_members unsubscribe was not in the user's language.
      (LP: #1161445)

    - Fixed a bug where BounceRunner could create and leave behind zero length
      bounce-events files.  (LP: #1161610)

    - Added recognition for another Yahoo bounce format.  (LP: #1157961)

    - Changed configure's method for getting Python's include directory from
      distutils.sysconfig.get_config_var('CONFINCLUDEPY') to
      distutils.sysconfig.get_python_inc().  (LP: #1098162)

    - Added an Auto-Generated: header to password reminders.  (LP: #558240)

    - Fixed a bug where non-ascii characters in the real name in a subscription
      request could throw a UnicodeEncodeError upon subscription approval and
      perhaps in other situations too.  (LP: #1047100)

    - The query fragments send_unsub_notifications_to_list_owner and
      send_unsub_ack_to_this_batch will now assume default values if not set
      in mass unsubscribe URLs.  (LP: #1032378)

    - Replaced utf-8 encoded characters in newly added German templates with
      HTML entities. (LP: #1018208)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130719/0216e26f/attachment-0001.pgp>

From mark at msapiro.net  Sun Jul 21 06:35:41 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 20 Jul 2013 21:35:41 -0700
Subject: [Mailman-Users] To restrict sending email messages per day
In-Reply-To: <87sizfry4k.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <CADbT6qLsqu_VDnMTEqgp6ukhCGo37FeYc_Dg6mUkKGJDehkPhg@mail.gmail.com>
	<87y598rl9e.fsf@uwakimon.sk.tsukuba.ac.jp>
	<CADbT6qLRjA1DBOwiTFsqh5fKyNc_6qEPT4gvMYGBWfJTyU0ZAw@mail.gmail.com>
	<51E487F9.9080601@Damon-Family.org>
	<87sizfry4k.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <51EB651D.1060704@msapiro.net>

On 07/15/2013 08:18 PM, Stephen J. Turnbull wrote:
> 
> I'll think about writing a "PosterThrottle" handler to implement your
> requirements, but it will take a week or two.


Today was a slow day ;)

See <http://www.msapiro.net/scripts/PostLimit.py> (mirrored at
<http://fog.ccsf.cc.ca.us/~msapiro/scripts/PostLimit.py>)for a script
that limits the number of posts from a member to a list either per
calendar day or a configurable period of hours.

It could be made lots fancier with the limit and time period being list
attributes or mm_cfg variables instead of hard coded and options to hold
rather than reject, but it will work.

The post at
<http://mail.python.org/pipermail/mailman-users/2013-June/075342.html>
had a similar request plus a per list limit. A per list limit could
easily be added. It's the same thing except all post times are kept for
the list instead of separately by poster. The handler could be easily
modified to do both. Maybe on the next slow day ;)

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130720/0795b402/attachment.pgp>

From mark at msapiro.net  Mon Jul 22 03:17:11 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Sun, 21 Jul 2013 18:17:11 -0700
Subject: [Mailman-Users] To restrict sending email messages per day
In-Reply-To: <51EB651D.1060704@msapiro.net>
References: <51EB651D.1060704@msapiro.net>
Message-ID: <51EC8817.8050400@msapiro.net>

Mark Sapiro wrote:

> See <http://www.msapiro.net/scripts/PostLimit.py> (mirrored at
> <http://fog.ccsf.cc.ca.us/~msapiro/scripts/PostLimit.py>)for a script
> that limits the number of posts from a member to a list either per
> calendar day or a configurable period of hours.
> 
> It could be made lots fancier with the limit and time period being list
> attributes or mm_cfg variables instead of hard coded and options to hold
> rather than reject, but it will work.


I have enhanced the script at the above locations to support a per
member limit and/or a per list limit. I have also made it take
parameters from list attributes if set there and provided a sample
extend.py to enable it and set parameters for a list.

Additionally, I have created a FAQ at <http://wiki.list.org/x/V4Hz> with
this information.

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

From drew.tenenholz at isid.org  Mon Jul 22 15:56:26 2013
From: drew.tenenholz at isid.org (Drew Tenenholz)
Date: Mon, 22 Jul 2013 09:56:26 -0400
Subject: [Mailman-Users] RFC 2369 Headers in Digest - customizable?
Message-ID: <p062408cace12e953172f@[192.168.209.11]>

Hi All --

Working with Mailman 2.1.9.

I've got a list where include_rfc2369_headers=No and have moved the contents of those headers into the footer for readability.  All works pretty well, except I'm getting complaints from the digest subscribers, where, indeed, these headers appear at the top of the messages, making them harder to read on mobile devices since it can be two or tree pages of scrolling before the table of contents is visible.

I've looked through the wiki, and only see topics related to the general setting above.

Is there some way to alter what the digest headers look like?

Thanks,
Drew Tenenholz

From mark at msapiro.net  Mon Jul 22 20:55:45 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 22 Jul 2013 11:55:45 -0700
Subject: [Mailman-Users] RFC 2369 Headers in Digest - customizable?
In-Reply-To: <p062408cace12e953172f@[192.168.209.11]>
References: <p062408cace12e953172f@[192.168.209.11]>
Message-ID: <51ED8031.2030303@msapiro.net>

On 07/22/2013 06:56 AM, Drew Tenenholz wrote:
> Hi All --
> 
> Working with Mailman 2.1.9.
> 
> I've got a list where include_rfc2369_headers=No and have moved the contents of those headers into the footer for readability.  All works pretty well, except I'm getting complaints from the digest subscribers, where, indeed, these headers appear at the top of the messages, making them harder to read on mobile devices since it can be two or tree pages of scrolling before the table of contents is visible.


First note that by suppressing the RFC 2369 headers from the actual
header, you are ensuring that any MUA features that use these headers
such as a 'reply list' button won't work.

Anyway, digests are built as follows:

The masthead
digest_header if any
The table of contents
The messages
digest_footer if any


It seems your issue is with the masthead which is built from the
masthead.txt template which can be edited per the FAQ at
<http://wiki.list.org/x/jYA9>.

If your issue is that you want to put the table of contents ahead of
digest_header or do other reordering of the pieces, that would require
modifying the code in Mailman/Handlers/ToDigest.py.

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

From mailman at veggiechinese.net  Mon Jul 22 21:16:48 2013
From: mailman at veggiechinese.net (Will Yardley)
Date: Mon, 22 Jul 2013 12:16:48 -0700
Subject: [Mailman-Users] odd address confirmation spam
Message-ID: <20130722191648.GN2568@aura.veggiechinese.net>

It seems someone is trying to forge-subscribe certain addresses (mostly
AOL / Yahoo / Gmail etc. addresses) on our Mailman install.

For example, (slightly sanitized, though the IP address is the real one):

[19/Jul/2013:09:49:17 -0700] 137.117.103.83 TLSv1 RC4-SHA "GET /mailman/subscribe/listname?email=TARGET at EXAMPLE.COM&fullname=&pw=123456789&pw-conf=123456789&language=en&digest=0&email-button=Subscribe HTTP/1.1" 1587
[19/Jul/2013:09:49:17 -0700] 137.117.103.83 TLSv1 RC4-SHA "GET /mailman/subscribe/listname?email=TARGET at EXAMPLE.COM&fullname=&pw=123456789&pw-conf=123456789&language=en&digest=0&email-button=Subscribe HTTP/1.1" 1587
[19/Jul/2013:09:49:43 -0700] 137.117.103.83 TLSv1 RC4-SHA "GET /mailman/subscribe/listname?email=TARGET at EXAMPLE.COM&fullname=&pw=123456789&pw-conf=123456789&language=en&digest=0&email-button=Subscribe HTTP/1.1" 1587
[19/Jul/2013:09:55:50 -0700] 137.117.103.83 TLSv1 RC4-SHA "GET /mailman/subscribe/listname?email=TARGET at EXAMPLE.COM&fullname=&pw=123456789&pw-conf=123456789&language=en&digest=0&email-button=Subscribe HTTP/1.1" 1587
[19/Jul/2013:09:56:05 -0700] 137.117.103.83 TLSv1 RC4-SHA "GET /mailman/subscribe/listname?email=TARGET at EXAMPLE.COM&fullname=&pw=123456789&pw-conf=123456789&language=en&digest=0&email-button=Subscribe HTTP/1.1" 1587

The password / confirmation token are the same in each case, so doesn't
seem like they're trying to guess those.

So far, this hasn't resulted in any actual subscriptions, nor is there
any spam content in the confirmation message that'se sent to the
end-user. Any idea what they might be trying to accomplish? They only
seem to have been targeting one of the lists on the machine (the list
has several thousand).

Does this correspond to any known exploits for older versions of
Mailman?

w


From Ralf.Hildebrandt at charite.de  Mon Jul 22 21:31:03 2013
From: Ralf.Hildebrandt at charite.de (Ralf Hildebrandt)
Date: Mon, 22 Jul 2013 21:31:03 +0200
Subject: [Mailman-Users] odd address confirmation spam
In-Reply-To: <20130722191648.GN2568@aura.veggiechinese.net>
References: <20130722191648.GN2568@aura.veggiechinese.net>
Message-ID: <20130722193103.GM2436@charite.de>

* Will Yardley <mailman at veggiechinese.net>:
> It seems someone is trying to forge-subscribe certain addresses (mostly
> AOL / Yahoo / Gmail etc. addresses) on our Mailman install.

Which version of mailman is that?

-- 
Ralf Hildebrandt                   Charite Universit?tsmedizin Berlin
ralf.hildebrandt at charite.de        Campus Benjamin Franklin
http://www.charite.de              Hindenburgdamm 30, 12203 Berlin
Gesch?ftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155

From mark at msapiro.net  Mon Jul 22 22:16:29 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 22 Jul 2013 13:16:29 -0700
Subject: [Mailman-Users] odd address confirmation spam
In-Reply-To: <20130722191648.GN2568@aura.veggiechinese.net>
References: <20130722191648.GN2568@aura.veggiechinese.net>
Message-ID: <51ED931D.7070400@msapiro.net>

On 07/22/2013 12:16 PM, Will Yardley wrote:
> It seems someone is trying to forge-subscribe certain addresses (mostly
> AOL / Yahoo / Gmail etc. addresses) on our Mailman install.
> 
> For example, (slightly sanitized, though the IP address is the real one):
> 
> [19/Jul/2013:09:49:17 -0700] 137.117.103.83 TLSv1 RC4-SHA "GET /mailman/subscribe/listname?email=TARGET at EXAMPLE.COM&fullname=&pw=123456789&pw-conf=123456789&language=en&digest=0&email-button=Subscribe HTTP/1.1" 1587
> [19/Jul/2013:09:49:17 -0700] 137.117.103.83 TLSv1 RC4-SHA "GET /mailman/subscribe/listname?email=TARGET at EXAMPLE.COM&fullname=&pw=123456789&pw-conf=123456789&language=en&digest=0&email-button=Subscribe HTTP/1.1" 1587
> [19/Jul/2013:09:49:43 -0700] 137.117.103.83 TLSv1 RC4-SHA "GET /mailman/subscribe/listname?email=TARGET at EXAMPLE.COM&fullname=&pw=123456789&pw-conf=123456789&language=en&digest=0&email-button=Subscribe HTTP/1.1" 1587
> [19/Jul/2013:09:55:50 -0700] 137.117.103.83 TLSv1 RC4-SHA "GET /mailman/subscribe/listname?email=TARGET at EXAMPLE.COM&fullname=&pw=123456789&pw-conf=123456789&language=en&digest=0&email-button=Subscribe HTTP/1.1" 1587
> [19/Jul/2013:09:56:05 -0700] 137.117.103.83 TLSv1 RC4-SHA "GET /mailman/subscribe/listname?email=TARGET at EXAMPLE.COM&fullname=&pw=123456789&pw-conf=123456789&language=en&digest=0&email-button=Subscribe HTTP/1.1" 1587
> 
> The password / confirmation token are the same in each case, so doesn't
> seem like they're trying to guess those.


This very likely results from legitimate search engine web crawlers
crawling your site.

Every time Google crawls mail.python.org, I get an unsubscribe
confirmation for Mailman-users. So far, I haven't had the energy to try
to stop these as they're easy enough to ignore.

In your case, the web crawlers are just blindly submitting the subscribe
form from the listinfo page, and disallowing your listinfo pages in a
robots.txt will likely stop it.

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

From mark at msapiro.net  Mon Jul 22 22:31:45 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 22 Jul 2013 13:31:45 -0700
Subject: [Mailman-Users] RFC 2369 Headers in Digest - customizable?
In-Reply-To: <p062408e1ce13329dbc5f@[192.168.209.11]>
References: <p062408cace12e953172f@[192.168.209.11]>
	<51ED8031.2030303@msapiro.net>
	<p062408e1ce13329dbc5f@[192.168.209.11]>
Message-ID: <51ED96B1.4070504@msapiro.net>

On 07/22/2013 12:12 PM, Drew Tenenholz wrote:
> 
> And, yes, the Masthead is the problem.  I've created my own $PATH/mailman/templates/site/en/masthead.txt file, and hope that fixes it.  If it is an empty file, will I supress any text from appearing?  Or, should I leave a single space or something in the file?


With an empty masthead.txt file, the plain digest will have two empty
lines preceding the digest_header. In the MIME format digest, there will
still be a separate MIME part for the masthead, but its body will be
empty. So yes, an empty file is fine and won't cause a problem.

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

From mailman at veggiechinese.net  Mon Jul 22 22:54:02 2013
From: mailman at veggiechinese.net (Will Yardley)
Date: Mon, 22 Jul 2013 13:54:02 -0700
Subject: [Mailman-Users] odd address confirmation spam
In-Reply-To: <51ED931D.7070400@msapiro.net> <20130722193103.GM2436@charite.de>
Message-ID: <20130722205402.GO2568@aura.veggiechinese.net>

On Mon, Jul 22, 2013 at 09:31:03PM +0200, Ralf Hildebrandt wrote:
> * Will Yardley <mailman at veggiechinese.net>:
> > It seems someone is trying to forge-subscribe certain addresses (mostly
> > AOL / Yahoo / Gmail etc. addresses) on our Mailman install.
> 
> Which version of mailman is that?

2.1.9. And yes, I'm aware that we need to upgrade, it's in progress, but
isn't possible immediately for complicated reasons. So, that's one
reason I'm writing in, just to make sure this isn't an attempt to
exploit a hole that's actually exploitable in this version.

On Mon, Jul 22, 2013 at 01:16:29PM -0700, Mark Sapiro wrote:
> On 07/22/2013 12:16 PM, Will Yardley wrote:

> > For example, (slightly sanitized, though the IP address is the real
> > one):

> > [19/Jul/2013:09:49:17 -0700] 137.117.103.83 TLSv1 RC4-SHA "GET /mailman/subscribe/listname?email=TARGET at EXAMPLE.COM&fullname=&pw=123456789&pw-conf=123456789&language=en&digest=0&email-button=Subscribe HTTP/1.1" 1587
 
> This very likely results from legitimate search engine web crawlers
> crawling your site.
> 
> Every time Google crawls mail.python.org, I get an unsubscribe
> confirmation for Mailman-users. So far, I haven't had the energy to
> try to stop these as they're easy enough to ignore.
> 
> In your case, the web crawlers are just blindly submitting the
> subscribe form from the listinfo page, and disallowing your listinfo
> pages in a robots.txt will likely stop it.

Why do the requests have actual email addresses and a bogus password /
token in the request string, though? The IP doesn't have any RDNS, but
is allocated to MSN, but I'd think a legitimate crawler would be more
easily identifiable as such, and would only be following actual links.
In this case we're getting repeated attempts to subscribe various
addresses. Also, they're only hitting this list (which isn't even set to
'public'), out of all 2000 or so of our Mailman lists.

w


From mark at msapiro.net  Mon Jul 22 23:15:03 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 22 Jul 2013 14:15:03 -0700
Subject: [Mailman-Users] odd address confirmation spam
In-Reply-To: <20130722205402.GO2568@aura.veggiechinese.net>
References: <20130722205402.GO2568@aura.veggiechinese.net>
Message-ID: <51EDA0D7.50008@msapiro.net>

On 07/22/2013 01:54 PM, Will Yardley wrote:
> On Mon, Jul 22, 2013 at 09:31:03PM +0200, Ralf Hildebrandt wrote:
>>
>> Which version of mailman is that?
> 
> 2.1.9. And yes, I'm aware that we need to upgrade, it's in progress, but
> isn't possible immediately for complicated reasons. So, that's one
> reason I'm writing in, just to make sure this isn't an attempt to
> exploit a hole that's actually exploitable in this version.


There is a new feature in 2.1.16 (The second release candidate is
available final due in September)

- There is a new mm_cfg.py setting SUBSCRIBE_FORM_SECRET which will put
  a dynamically generated, hidden hash in the listinfo subscribe form and
  check it upon submission.  Setting this will prevent automated processes
  (bots) from successfully POSTing web subscribes without first retrieving
  and parsing the form from the listinfo page.  The form must also be
  submitted no later than FORM_LIFETIME nor no earlier than
  SUBSCRIBE_FORM_MIN_TIME after retrieval.  Note that enabling this will
  break any static subscribe forms on your site.  See the description in
  Defaults.py for more info.  (LP: #1082746)

If my 'legitimate web crawler' theory is correct, this feature won't help.


> On Mon, Jul 22, 2013 at 01:16:29PM -0700, Mark Sapiro wrote:
>>
>> In your case, the web crawlers are just blindly submitting the
>> subscribe form from the listinfo page, and disallowing your listinfo
>> pages in a robots.txt will likely stop it.
> 
> Why do the requests have actual email addresses and a bogus password /
> token in the request string, though? The IP doesn't have any RDNS, but
> is allocated to MSN, but I'd think a legitimate crawler would be more
> easily identifiable as such, and would only be following actual links.
> In this case we're getting repeated attempts to subscribe various
> addresses. Also, they're only hitting this list (which isn't even set to
> 'public'), out of all 2000 or so of our Mailman lists.


Is the email address always the same?

I can't explain how web crawlers work or why they do what they do, but
I'm not discounting them. What's in your web server logs for the
identity of the agent that submitted these requests? If you do a bing
search for this listinfo page, do you get any hits?

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

From david.westlund at axis.com  Tue Jul 23 15:06:10 2013
From: david.westlund at axis.com (David Westlund)
Date: Tue, 23 Jul 2013 15:06:10 +0200
Subject: [Mailman-Users] File format changes between 2.15 and 2.13
Message-ID: <B10F6CB788F3F24A8088BEAF8441BE11A555D66E3A@xmail3.se.axis.com>

Hi

We have a Mailman cluster setup where two mailman instances share one NFS file storage area. Now we are planning to upgrade from Mailman 2.13 to 2.15. We plan to upgrade one machine in the cluster first, to have the second machine as fallback in case something goes wrong. This, of course, requires that the shared files on the NFS area are still readable for the 2.13 release. Are there any changes done in the file format that can cause issues for this plan?

Thank you for a great product.

BR,
David Westlund

From Peter.Heitzer at rz.uni-regensburg.de  Tue Jul 23 09:29:42 2013
From: Peter.Heitzer at rz.uni-regensburg.de (Peter Heitzer)
Date: Tue, 23 Jul 2013 09:29:42 +0200
Subject: [Mailman-Users] When is last_post_time updated?
Message-ID: <51EE4D060200002C00014AA2@gwsmtp1.uni-regensburg.de>

Hello folks,
I have a few mailing lists which show a last_post_time of 1970-01-01. Does this
really mean that the list has not yet sent any mails to its subscribers, i.e the
list is inactive?
I assume that only a regular post from an allowed mail address forces an update
to a lists last_post_time variable. Is that correct?

The reason for asking is that I want to get rid of some inactive lists. If the
last_post_time is a reliable criterion for inactivity I could contact the list
owners and ask them if the list could be removed.

 






From mark at msapiro.net  Tue Jul 23 19:28:16 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 23 Jul 2013 10:28:16 -0700
Subject: [Mailman-Users] When is last_post_time updated?
In-Reply-To: <51EE4D060200002C00014AA2@gwsmtp1.uni-regensburg.de>
References: <51EE4D060200002C00014AA2@gwsmtp1.uni-regensburg.de>
Message-ID: <51EEBD30.9020700@msapiro.net>

On 07/23/2013 12:29 AM, Peter Heitzer wrote:
> Hello folks,
> I have a few mailing lists which show a last_post_time of 1970-01-01. Does this
> really mean that the list has not yet sent any mails to its subscribers, i.e the
> list is inactive?


Yes.


> I assume that only a regular post from an allowed mail address forces an update
> to a lists last_post_time variable. Is that correct?


Any post that is accepted for delivery to the list members, regardless
of how it got accepted, updates last_post_time just before being queued
for delivery to the outgoing MTA.


> The reason for asking is that I want to get rid of some inactive lists. If the
> last_post_time is a reliable criterion for inactivity I could contact the list
> owners and ask them if the list could be removed.


Yes, it is.

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

From mark at msapiro.net  Tue Jul 23 19:38:08 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Tue, 23 Jul 2013 10:38:08 -0700
Subject: [Mailman-Users] File format changes between 2.15 and 2.13
In-Reply-To: <B10F6CB788F3F24A8088BEAF8441BE11A555D66E3A@xmail3.se.axis.com>
References: <B10F6CB788F3F24A8088BEAF8441BE11A555D66E3A@xmail3.se.axis.com>
Message-ID: <51EEBF80.7020704@msapiro.net>

On 07/23/2013 06:06 AM, David Westlund wrote:
> 
> We have a Mailman cluster setup where two mailman instances share one NFS file storage area. Now we are planning to upgrade from Mailman 2.13 to 2.15. We plan to upgrade one machine in the cluster first, to have the second machine as fallback in case something goes wrong. This, of course, requires that the shared files on the NFS area are still readable for the 2.13 release. Are there any changes done in the file format that can cause issues for this plan?


No.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130723/a85c2ec7/attachment.pgp>

From kardan at riseup.net  Wed Jul 24 23:54:56 2013
From: kardan at riseup.net (kardan)
Date: Wed, 24 Jul 2013 23:54:56 +0200
Subject: [Mailman-Users] message held for moderation "no member",
 adding address: "already member"
Message-ID: <20130724235456.2e852669@delight>

Version: 2.1.13

Hi,

while my first issue was solved with Mark's great support, here is my
current problem:

Messages by one specific sender are held for moderation with the given
reasen, the sender is not part of the list. When it is added, mailman
says "already a member" (original german: "Bereits Mitglied").

Where is the problem then?

Thanks!
kardan

-- 
Kardan <kardan at riseup.net>
Encrypt your email: http://gnupg.org/documentation
Public GPG key 9D6108AE58C06558 at hkp://pool.sks-keyservers.net
fpr: F72F C4D9 6A52 16A1 E7C9  AE94 9D61 08AE 58C0 6558
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130724/06e4a423/attachment.pgp>

From mark at msapiro.net  Thu Jul 25 02:03:52 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 24 Jul 2013 17:03:52 -0700
Subject: [Mailman-Users] message held for moderation "no member",
 adding address: "already member"
In-Reply-To: <20130724235456.2e852669@delight>
References: <20130724235456.2e852669@delight>
Message-ID: <51F06B68.8080806@msapiro.net>

On 07/24/2013 02:54 PM, kardan wrote:
> 
> Messages by one specific sender are held for moderation with the given
> reasen, the sender is not part of the list. When it is added, mailman
> says "already a member" (original german: "Bereits Mitglied").
> 
> Where is the problem then?


The member is not posting from his exact subscribed address. E.g. he is
subscribed as member at example.com and is posting from
member at sub.example.com or vice versa or something similar.

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

From cook_se at hotmail.com  Wed Jul 24 23:30:12 2013
From: cook_se at hotmail.com (Stephen Cook)
Date: Wed, 24 Jul 2013 16:30:12 -0500
Subject: [Mailman-Users] Migrate from Lyris to Mailman
Message-ID: <BLU170-W69FAAC1D36F19420B7A9418E680@phx.gbl>

Hi,
I've been asked to migrate the mailing lists from Lyris Listmanager running on Windows 2003 to Mailman on Red Hat Enterprise.? My director would like the migration to go in such a way that none of the mailing list users would be required to change the entries in their address books.? To complicate matters further, the old server hosts web pages as well.? So requests to "http://oldserver.mydomain.com" should go the the old Windows server, and "mylist at oldserver.mydomain.com" should go to the new server.? I've been banging my head on this problem for the last couple of days.? My questions to the mailman community are 1) is this possible/feasible and 2) If so, what's the best way to do this.

I've figured out how to pull a test file conting the lists & list members from Lyris.? I've also figured out how to forward email address to whatever at oldserver.mydomain.com to the new server.? 

Thanks,
SC 		 	   		  

From mark at msapiro.net  Thu Jul 25 03:18:56 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Wed, 24 Jul 2013 18:18:56 -0700
Subject: [Mailman-Users] Migrate from Lyris to Mailman
In-Reply-To: <BLU170-W69FAAC1D36F19420B7A9418E680@phx.gbl>
References: <BLU170-W69FAAC1D36F19420B7A9418E680@phx.gbl>
Message-ID: <51F07D00.3050007@msapiro.net>

On 07/24/2013 02:30 PM, Stephen Cook wrote:
> So requests to
> "http://oldserver.mydomain.com" should go the the old Windows server,
> and "mylist at oldserver.mydomain.com" should go to the new server.
> I've been banging my head on this problem for the last couple of
> days.  My questions to the mailman community are 1) is this
> possible/feasible and 2) If so, what's the best way to do this.


It's possible, It may and may not be easy. If the only mail to the
oldserver.mydomain.com domain is list mail or if all mail to the
oldserver.mydomain.com domain should go to the new server, just create
an MX record for oldserver.mydomain.com pointing to the new server.

Otherwise


> I've figured out how to pull a test file conting the lists & list
> members from Lyris.  I've also figured out how to forward email
> address to whatever at oldserver.mydomain.com to the new server.


forward the list mail as you already have figured out. Presumably (but
maybe not, I'm not your management...) the only list mail that would
need to be forwarded is for currently existing lists and new lists
wouldn't have an oldserver.mydomain.com address, so you wouldn't have a
maintenance issue with forwards.

There will be issues for web access to Mailman on the new server.
Mailman supports multiple virtual hosts with the restriction that
listnames must be globally unique. However, it doesn't directly support
two virtual hosts with the same web domain, so my suggestion is
configure Mailman on the new server with only DEFAULT_URL_HOST and
DEFAULT_EMAIL_HOST pointing to the new server. Then when you create
lists, they will reference the new server for the Mailman web UI and the
new server for list email.

Then after you create the migrated lists, you can set their email domain
to oldserver.mydomain.com. This can be done by setting each list's
host_name attribute on the web admin General Options page for the list,
or by running Mailman's bin/config_list.

To do the latter for all lists, you could do

#!/bin/sh
cd /path/to mailman
f=`mktemp`
echo > $f host_name = 'oldserver.mydomain.com'
for l in `bin/list_lists --bare`; do
  bin/config_list -i $f $l
done
rm $f

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

From stephen at xemacs.org  Thu Jul 25 05:55:13 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Thu, 25 Jul 2013 12:55:13 +0900
Subject: [Mailman-Users]  Migrate from Lyris to Mailman
In-Reply-To: <BLU170-W69FAAC1D36F19420B7A9418E680@phx.gbl>
References: <BLU170-W69FAAC1D36F19420B7A9418E680@phx.gbl>
Message-ID: <87hafjpa3i.fsf@uwakimon.sk.tsukuba.ac.jp>

Stephen Cook writes:

 > I've been asked to migrate the mailing lists from Lyris Listmanager
 > running on Windows 2003 to Mailman on Red Hat Enterprise.?
 > ... requests to "http://oldserver.mydomain.com" should go the the
 > old Windows server, and "mylist at oldserver.mydomain.com" should go
 > to the new server.

There are several ways to do this, with different advantages and
disadvantages.  None of them are Mailman questions, though.

You need to specify what is happening to the rest of various services
to get good advice.  Is *all* mail received by oldserver moving to
newserver?  Will oldserver be providing any services other than the
webserver?  Especially mail, but not limited to mail.



From kardan at riseup.net  Fri Jul 26 19:30:11 2013
From: kardan at riseup.net (kardan)
Date: Fri, 26 Jul 2013 19:30:11 +0200
Subject: [Mailman-Users] message held for moderation "no member",
 adding address: "already member"
In-Reply-To: <51F06B68.8080806@msapiro.net>
References: <20130724235456.2e852669@delight>
	<51F06B68.8080806@msapiro.net>
Message-ID: <20130726193011.03bad624@delight>

Hi,

On Wed, 24 Jul 2013 17:03:52 -0700 Mark Sapiro wrote:

> On 07/24/2013 02:54 PM, kardan wrote:
> > 
> > Messages by one specific sender are held for moderation with the
> > given reasen, the sender is not part of the list. When it is added,
> > mailman says "already a member" (original german: "Bereits
> > Mitglied").
> > 
> > Where is the problem then?  
> 
> 
> The member is not posting from his exact subscribed address. E.g. he
> is subscribed as member at example.com and is posting from
> member at sub.example.com or vice versa or something similar.

I checked, that the sender address was the same as in the member list
and when I added it, the same one was shown. So I think your case does
not hit this one. Maybe I oversee something?

Kardan

-- 
Kardan <kardan at riseup.net>
Encrypt your email: http://gnupg.org/documentation
Public GPG key 9D6108AE58C06558 at hkp://pool.sks-keyservers.net
fpr: F72F C4D9 6A52 16A1 E7C9  AE94 9D61 08AE 58C0 6558
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130726/b6ab4a61/attachment.pgp>

From mark at msapiro.net  Fri Jul 26 21:21:21 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 26 Jul 2013 12:21:21 -0700
Subject: [Mailman-Users] message held for moderation "no member",
 adding address: "already member"
In-Reply-To: <20130726193011.03bad624@delight>
References: <20130724235456.2e852669@delight> <51F06B68.8080806@msapiro.net>
	<20130726193011.03bad624@delight>
Message-ID: <51F2CC31.9050209@msapiro.net>

On 07/26/2013 10:30 AM, kardan wrote:
> Hi,
> 
> On Wed, 24 Jul 2013 17:03:52 -0700 Mark Sapiro wrote:

>> The member is not posting from his exact subscribed address. E.g. he
>> is subscribed as member at example.com and is posting from
>> member at sub.example.com or vice versa or something similar.
> 
> I checked, that the sender address was the same as in the member list
> and when I added it, the same one was shown. So I think your case does
> not hit this one. Maybe I oversee something?


What is the setting in Defaults.py and if any in mm_cfg.py for
SENDER_HEADERS. The default setting

SENDER_HEADERS = ('from', None, 'reply-to', 'sender')

looks at From:, envelope sender (aka unix from), Reply-To: and Sender:
for a member address. It is possible this installation has changed this
to, for example, look only at the envelope sender.

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

From kardan at riseup.net  Sat Jul 27 02:28:55 2013
From: kardan at riseup.net (kardan)
Date: Sat, 27 Jul 2013 02:28:55 +0200
Subject: [Mailman-Users] [SOLVED] Re: message held for moderation "no
 member", adding address: "already member"
In-Reply-To: <51F2CC31.9050209@msapiro.net>
References: <20130724235456.2e852669@delight> <51F06B68.8080806@msapiro.net>
	<20130726193011.03bad624@delight> <51F2CC31.9050209@msapiro.net>
Message-ID: <20130727022856.2de3c355@delight>

Hi and thanks for your fast answer (as usual)!

Am Fri, 26 Jul 2013 12:21:21 -0700
schrieb Mark Sapiro <mark at msapiro.net>:

> What is the setting in Defaults.py and if any in mm_cfg.py for
> SENDER_HEADERS. 

SENDER_HEADERS = ('from', None, 'reply-to', 'sender')
(none in Defaults.py)

> The default setting
>
> SENDER_HEADERS = ('from', None, 'reply-to', 'sender')
> 
> looks at From:, envelope sender (aka unix from), Reply-To: and Sender:
> for a member address. It is possible this installation has changed
> this to, for example, look only at the envelope sender.

This means there is no configuration problem with the list, but ..

I just had a look at the reason for the moderation request again, which
was not shown like this in the interface:

"Mailadresse der Liste steht nicht im Mailheader (vielleicht wegen einer
Weiterleitung?)" (list address not in the header, maybe forwarded?)

So the sender sends the mail to himself and BCCs the list. I informed
him to at least CC the list in the future.

-- 
Kardan <kardan at riseup.net>
Encrypt your email: http://gnupg.org/documentation
Public GPG key 9D6108AE58C06558 at hkp://pool.sks-keyservers.net
fpr: F72F C4D9 6A52 16A1 E7C9  AE94 9D61 08AE 58C0 6558
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130727/61b0f4d8/attachment.pgp>

From mark at msapiro.net  Sat Jul 27 03:18:18 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Fri, 26 Jul 2013 18:18:18 -0700
Subject: [Mailman-Users] [SOLVED] Re: message held for moderation "no
 member", adding address: "already member"
In-Reply-To: <20130727022856.2de3c355@delight>
References: <20130724235456.2e852669@delight> <51F06B68.8080806@msapiro.net>
	<20130726193011.03bad624@delight> <51F2CC31.9050209@msapiro.net>
	<20130727022856.2de3c355@delight>
Message-ID: <51F31FDA.4070400@msapiro.net>

On 07/26/2013 05:28 PM, kardan wrote:
> 
> I just had a look at the reason for the moderation request again, which
> was not shown like this in the interface:
> 
> "Mailadresse der Liste steht nicht im Mailheader (vielleicht wegen einer
> Weiterleitung?)" (list address not in the header, maybe forwarded?)
> 
> So the sender sends the mail to himself and BCCs the list. I informed
> him to at least CC the list in the future.


There may be a problem with the actual translation. There are four
strings involved. For a post from a non-member, we have
1. reason = _('Post by non-member to a members-only list')
2. rejection = _('Non-members are not allowed to post messages to this
list.')

and for a post with implicit destination, we have

3. reason = _('Message has implicit destination')
4. rejection = _('''Blind carbon copies or other implicit destinations are
not allowed.  Try reposting your message by explicitly including the list
address in the To: or Cc: fields.''')

The 'reasons' are what appear in the admindb summary and the notices to
the admin and user. the 'rejections' appear only in the admindb detail
as the default rejection message and in rejection messages if the
default is not overridden.

The German translations of these are

1. "Absender ist nicht Mitglied der Liste -- E-Mails an die Liste aber
nur f?r Mitglieder erlaubt! "

2. "Nichtmitgliedern ist es nicht gestattet, Nachrichten auf dieser Liste zu
ver?ffentlichen."

3. "Mailadresse der Liste steht nicht im Mailheader (vielleicht wegen
einer Weiterleitung?)"

4.
"Blindkopien ('BCC:'), oder weitere enthaltene Zieladressen,
sind nicht erlaubt. Tragen Sie die Adresse der Mailinmgliste in das 'An:'-
oder 'Cc:'-Adressfeld ein und senden Sie Ihre Nachricht bitte noch einmal."


According to google translate, message 3. translates as "Mail address of
the list is not in the mail header (perhaps because of a redirect?)"
which seems less than completely clear.

Perhaps you or another German speaker can suggest a better alternative.

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

From kardan at riseup.net  Sat Jul 27 13:16:52 2013
From: kardan at riseup.net (kardan)
Date: Sat, 27 Jul 2013 13:16:52 +0200
Subject: [Mailman-Users] [SOLVED] Re: message held for moderation "no
 member", adding address: "already member"
In-Reply-To: <51F31FDA.4070400@msapiro.net>
References: <20130724235456.2e852669@delight> <51F06B68.8080806@msapiro.net>
	<20130726193011.03bad624@delight> <51F2CC31.9050209@msapiro.net>
	<20130727022856.2de3c355@delight> <51F31FDA.4070400@msapiro.net>
Message-ID: <20130727131652.5932912f@delight>

Am Fri, 26 Jul 2013 18:18:18 -0700
schrieb Mark Sapiro <mark at msapiro.net>:

> On 07/26/2013 05:28 PM, kardan wrote:
> > 
> > I just had a look at the reason for the moderation request again,
> > which was not shown like this in the interface:
> > 
> > "Mailadresse der Liste steht nicht im Mailheader (vielleicht wegen
> > einer Weiterleitung?)" (list address not in the header, maybe
> > forwarded?)
> > 
> > So the sender sends the mail to himself and BCCs the list. I
> > informed him to at least CC the list in the future.
> 

These are my favourites:

> There may be a problem with the actual translation. There are four
> strings involved. For a post from a non-member, we have
> 1. reason = _('Post by non-member to a members-only list')
> 1. "Absender ist nicht Mitglied der Liste -- E-Mails an die Liste aber
> nur f?r Mitglieder erlaubt! "
"Absender ist nicht Mitglied der Liste. Nachrichten an diese Liste nur
f?r Mitglieder gestattet."


> 2. rejection = _('Non-members are not allowed to post messages to this
> list.')
> 2. "Nichtmitgliedern ist es nicht gestattet, Nachrichten auf dieser
> Liste zu ver?ffentlichen."
Ok.

> 
> and for a post with implicit destination, we have
> 
> 3. reason = _('Message has implicit destination')
> 3. "Mailadresse der Liste steht nicht im Mailheader (vielleicht wegen
> einer Weiterleitung?)"
The message is quite understandable. My problem was it was not
shown in the moderation interface. There I saw reason 1 instead which
was misleading. This one is a little more informative:
"Die Adresse der Liste ist nicht unter den Empf?ngern (An oder CC).
Wurde die Nachricht weitergeleitet, oder per BCC verschickt?"

> 4. rejection = _('''Blind carbon copies or other implicit
> destinations are not allowed.  Try reposting your message by
> explicitly including the list address in the To: or Cc: fields.''')
> 4.
> "Blindkopien ('BCC:'), oder weitere enthaltene Zieladressen,
> sind nicht erlaubt. Tragen Sie die Adresse der Mailinmgliste in das
> 'An:'- oder 'Cc:'-Adressfeld ein und senden Sie Ihre Nachricht bitte
> noch einmal."
This message is perfect and should have been shown instead of 1 ("the
sender is not part of the list"). I don't know why this went wrong.
 
> The 'reasons' are what appear in the admindb summary and the notices
> to the admin and user. the 'rejections' appear only in the admindb
> detail as the default rejection message and in rejection messages if
> the default is not overridden.

If I would have read the first moderation message properly -
("Mailadresse der Liste steht nicht im Mailheader (vielleicht wegen
einer Weiterleitung?)") - I just had overlooked the misleading reason in
the admindb ("the sender is not part of the list").

-- 
Kardan <kardan at riseup.net>
Encrypt your email: http://gnupg.org/documentation
Public GPG key 9D6108AE58C06558 at hkp://pool.sks-keyservers.net
fpr: F72F C4D9 6A52 16A1 E7C9  AE94 9D61 08AE 58C0 6558
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-users/attachments/20130727/858116ca/attachment.pgp>

From mark at msapiro.net  Sun Jul 28 01:18:03 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Sat, 27 Jul 2013 16:18:03 -0700
Subject: [Mailman-Users] [SOLVED] Re: message held for moderation "no
 member", adding address: "already member"
In-Reply-To: <20130727131652.5932912f@delight>
References: <20130724235456.2e852669@delight> <51F06B68.8080806@msapiro.net>
	<20130726193011.03bad624@delight> <51F2CC31.9050209@msapiro.net>
	<20130727022856.2de3c355@delight> <51F31FDA.4070400@msapiro.net>
	<20130727131652.5932912f@delight>
Message-ID: <51F4552B.6030205@msapiro.net>

On 07/27/2013 04:16 AM, kardan wrote:
> Am Fri, 26 Jul 2013 18:18:18 -0700
> schrieb Mark Sapiro <mark at msapiro.net>:
> 
>> There may be a problem with the actual translation. There are four
>> strings involved. For a post from a non-member, we have
>> 1. reason = _('Post by non-member to a members-only list')
>> 1. "Absender ist nicht Mitglied der Liste -- E-Mails an die Liste aber
>> nur f?r Mitglieder erlaubt! "
> "Absender ist nicht Mitglied der Liste. Nachrichten an diese Liste nur
> f?r Mitglieder gestattet."


I'll look at updating that message. Thanks.


>> 2. rejection = _('Non-members are not allowed to post messages to this
>> list.')
>> 2. "Nichtmitgliedern ist es nicht gestattet, Nachrichten auf dieser
>> Liste zu ver?ffentlichen."
> Ok.
> 
>>
>> and for a post with implicit destination, we have
>>
>> 3. reason = _('Message has implicit destination')
>> 3. "Mailadresse der Liste steht nicht im Mailheader (vielleicht wegen
>> einer Weiterleitung?)"
> The message is quite understandable. My problem was it was not
> shown in the moderation interface. There I saw reason 1 instead which
> was misleading. This one is a little more informative:
> "Die Adresse der Liste ist nicht unter den Empf?ngern (An oder CC).
> Wurde die Nachricht weitergeleitet, oder per BCC verschickt?"


OK. I'll look at updating that one too.


>> 4. rejection = _('''Blind carbon copies or other implicit
>> destinations are not allowed.  Try reposting your message by
>> explicitly including the list address in the To: or Cc: fields.''')
>> 4.
>> "Blindkopien ('BCC:'), oder weitere enthaltene Zieladressen,
>> sind nicht erlaubt. Tragen Sie die Adresse der Mailinmgliste in das
>> 'An:'- oder 'Cc:'-Adressfeld ein und senden Sie Ihre Nachricht bitte
>> noch einmal."
> This message is perfect and should have been shown instead of 1 ("the
> sender is not part of the list"). I don't know why this went wrong.


I don't know wht you saw the wrong message. Two possibilities occur two
me. This could be verified only by looking at the various held message
entries in Mailman's 'vette' log.

The first, and I think more likely possibility is the an initial post
was held as a non-member post and the poster got a notice and subscribed
(You could also check Mailman's 'subscribe' log) before you tried to
subscribe him.

The only other possibility I can think of is the German message catalog
in the Mailman installation that supports your list has been modified or
corrupted somehow and is displaying the wrong translation for strings 3
and 4.

I just thought of a third possibility which seems more likely that the
two above. See below.


>> The 'reasons' are what appear in the admindb summary and the notices
>> to the admin and user. the 'rejections' appear only in the admindb
>> detail as the default rejection message and in rejection messages if
>> the default is not overridden.
> 
> If I would have read the first moderation message properly -
> ("Mailadresse der Liste steht nicht im Mailheader (vielleicht wegen
> einer Weiterleitung?)") - I just had overlooked the misleading reason in
> the admindb ("the sender is not part of the list").


That message can be seen in the admindb even though the user is a list
member in the following way.

I explained before how SENDER_HEADERS are consulted to deterrmine if a
post is from a list member. However, once a post is held and displayed
in the admindb interface, admindb uses a different method to determine
the sender. If USE_ENVELOPE_SENDER is set to Yes in mm_cfg.py (or
changed to Yes in Defaults.py), admindb will take the contents of a
Sender: header if any in preference to From:.

In this case, the message could be From: a member but have a Sender:
which is not a member, and the message could be held for some other
reason like 'too big' or 'implicit destination' and the left hand side
of the admindb summary will say the sender is not a list member.

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

From misterbhatt at gmail.com  Mon Jul 29 11:59:30 2013
From: misterbhatt at gmail.com (Amit Bhatt)
Date: Mon, 29 Jul 2013 15:29:30 +0530
Subject: [Mailman-Users] All the mails are not reaching all the members
Message-ID: <CAOZo=+9tOKyZ+jjqPRAD1b4V2aYvc10cs3DEFG6d1yFv7W4Hiw@mail.gmail.com>

HI team,

When I aproved the held messages from tend to pending moderation list,
they do not reach to the users or do not appear on the mailing list.
Or some of them reach to the  list very late.
Secondly, again all the messages sent by the users are not delivered
to other members of the list since last couple of days.

An advise with solution would be much appreciated.

regards,

Amit Bhatt

From daniel at pocock.com.au  Mon Jul 29 12:58:21 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Mon, 29 Jul 2013 12:58:21 +0200
Subject: [Mailman-Users] pure virtual hosting - possible solution
Message-ID: <51F64ACD.3090408@pocock.com.au>


Hi,

I've been looking at whether it is possible to do pure virtual hosting
with Mailman.  When I say "pure", I mean that there will be no shared
domain for the site list (that is the most important requirement for me)
and that the globally-unique list name issue will be eliminated (maybe
important for some other users).

Some comments I've seen suggest it is necessary to do a full source
build into a standalone tree for each "pure" virtual domain.  I'm also
trying to avoid that, I'd like to use the binaries from Debian packages
so that I get the security updates and so that I don't have extra overhead.

My impression is that the solution can be achieved, but that multiple
copies of /var/lib/mailman are necessary, e.g:

  /var/lib/mailmen/example.org/*
  /var/lib/mailmen/example.net/*

and that some hacks would be needed in the following places:

  paths.py
  Defaults.py

Presumably, somebody could:
a) cp -r /var/lib/mailman /var/lib/mailmen/example.org
b) create a symlink to their hacked paths.py and Defaults.py somehow,
using symlinks to the normal binaries for everything else
c) in the Apache config, use aliases that point to the
/var/lib/mailmen/example.org/cgi-bin directory
d) make sure that the scripts in the aliases file are pointing to
/var/lib/mailmen/example.org/mail/wrapper
e) set up an extra init script for each instance (or some init script
that starts multiple qrunners)

Would this be sufficient for Mailman to run safely with pure virtual
domains?  Have other people implemented variations of this?

Regards,

Daniel

From cook_se at hotmail.com  Mon Jul 29 16:59:02 2013
From: cook_se at hotmail.com (Stephen Cook)
Date: Mon, 29 Jul 2013 09:59:02 -0500
Subject: [Mailman-Users] Migrate from Lyris to Mailman
In-Reply-To: <87hafjpa3i.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <BLU170-W69FAAC1D36F19420B7A9418E680@phx.gbl>,
	<87hafjpa3i.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <BLU170-W1133464A898632C0EBDF6F98E550@phx.gbl>

Yes, oldserver will only be a web server, so all mail can be forwarded to the new server.
In brief, it looks I should:
1) Forward all mail from oldserver.mydomain.com to newserver.mydomain.com using an MX record or an SMTP forward on oldserver.mydomain.com
2) Create a Postfix virtual domain on newserver.mydomain.com for oldserver.mydomain.com
3) Change the new Lists' email domain to oldserver by modifying the host_name attribute on the web admin General Options page.


Does that seem about right?? My understanding is a bit foggy when it comes to virtual domains, virtual mailboxes & virtual hosts in Postfix.? From what I've read, virtual domain seems to be the route I need to go.

----------------------------------------
> From: stephen at xemacs.org
> To: cook_se at hotmail.com
> CC: mailman-users at python.org
> Subject: [Mailman-Users] Migrate from Lyris to Mailman
> Date: Thu, 25 Jul 2013 12:55:13 +0900
>
> Stephen Cook writes:
>
>> I've been asked to migrate the mailing lists from Lyris Listmanager
>> running on Windows 2003 to Mailman on Red Hat Enterprise.
>> ... requests to "http://oldserver.mydomain.com" should go the the
>> old Windows server, and "mylist at oldserver.mydomain.com" should go
>> to the new server.
>
> There are several ways to do this, with different advantages and
> disadvantages. None of them are Mailman questions, though.
>
> You need to specify what is happening to the rest of various services
> to get good advice. Is *all* mail received by oldserver moving to
> newserver? Will oldserver be providing any services other than the
> webserver? Especially mail, but not limited to mail.
>
> 		 	   		  

From mark at msapiro.net  Mon Jul 29 17:20:30 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 29 Jul 2013 08:20:30 -0700
Subject: [Mailman-Users] All the mails are not reaching all the members
In-Reply-To: <CAOZo=+9tOKyZ+jjqPRAD1b4V2aYvc10cs3DEFG6d1yFv7W4Hiw@mail.gmail.com>
References: <CAOZo=+9tOKyZ+jjqPRAD1b4V2aYvc10cs3DEFG6d1yFv7W4Hiw@mail.gmail.com>
Message-ID: <51F6883E.3040805@msapiro.net>

On 07/29/2013 02:59 AM, Amit Bhatt wrote:
> 
> When I aproved the held messages from tend to pending moderation list,
> they do not reach to the users or do not appear on the mailing list.
> Or some of them reach to the  list very late.
> Secondly, again all the messages sent by the users are not delivered
> to other members of the list since last couple of days.
> 
> An advise with solution would be much appreciated.


Check Mailman's logs, particularly 'bounce', 'smtp' and 'smtp-failure',
and the MTA logs to see if messages are being delivered, bouncing or what?

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

From daniel at pocock.com.au  Mon Jul 29 17:35:41 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Mon, 29 Jul 2013 17:35:41 +0200
Subject: [Mailman-Users] aliases file: using globally unique user IDs (as in
 Sympa virtual domains)
Message-ID: <51F68BCD.5050804@pocock.com.au>



I currently run virtual domains with Sympa

To get around the aliases file bottleneck and allow pure virtual
hosting, Sympa uses the virtual aliases file to map the recipients like
this:

  list1 at lists.example.org      lists.example.org-list1 at myhostname

and each of those entries is then matched by an entry like this in the
aliases file:

  lists.example.org-list1:   "|/usr/lib/sympa/bin/queue
list1 at lists.example.org"

Migrating to Mailman, I'd like to do something like this:

  lists.example.org-list1:  
"|/var/lib/mailmen/lists.example.org/mail/mailman post list1"

where I have a dedicated Mailman install under
/var/lib/mailmen/lists.example.org just for that domain.


Should this all work OK with Mailman?

Will Mailman even notice that the envelope address was changed into
something else or does it only look at what is inside the message?

Is there any way to automatically create aliases like this, or any hook
where Mailman can call a script that I use for creating the aliases?


From mark at msapiro.net  Mon Jul 29 17:53:57 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 29 Jul 2013 08:53:57 -0700
Subject: [Mailman-Users] aliases file: using globally unique user IDs
 (as in Sympa virtual domains)
In-Reply-To: <51F68BCD.5050804@pocock.com.au>
References: <51F68BCD.5050804@pocock.com.au>
Message-ID: <51F69015.2070901@msapiro.net>

On 07/29/2013 08:35 AM, Daniel Pocock wrote:
> 
> Migrating to Mailman, I'd like to do something like this:
> 
>   lists.example.org-list1:  
> "|/var/lib/mailmen/lists.example.org/mail/mailman post list1"
> 
> where I have a dedicated Mailman install under
> /var/lib/mailmen/lists.example.org just for that domain.
> 
> 
> Should this all work OK with Mailman?


Yes.


> Will Mailman even notice that the envelope address was changed into
> something else or does it only look at what is inside the message?


I don't see that any envelope address changes, but in any case, Mailman
doesn't look at envelope recipient. Either the message gets to Mailman
or it doesn't. If it got there, Mailman must have been a recipient.

Mailman does look for the list address in To: or Cc: if the list's
require_explicit_destination is yes.


> Is there any way to automatically create aliases like this, or any hook
> where Mailman can call a script that I use for creating the aliases?


See MTA = 'Postfix' and related settings. You may or may not need to
hack Mailman/MTA/Postfix.py.

Note that I will very soon be off line for about 12 days and don't have
time now for more detail or to answer your other post. Perhaps others on
the list can provide more if you need it.

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

From daniel at pocock.com.au  Mon Jul 29 18:27:22 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Mon, 29 Jul 2013 18:27:22 +0200
Subject: [Mailman-Users] aliases file: using globally unique user IDs
 (as in Sympa virtual domains)
In-Reply-To: <51F69015.2070901@msapiro.net>
References: <51F68BCD.5050804@pocock.com.au> <51F69015.2070901@msapiro.net>
Message-ID: <51F697EA.6040805@pocock.com.au>

On 29/07/13 17:53, Mark Sapiro wrote:
> On 07/29/2013 08:35 AM, Daniel Pocock wrote:
>> Migrating to Mailman, I'd like to do something like this:
>>
>>   lists.example.org-list1:  
>> "|/var/lib/mailmen/lists.example.org/mail/mailman post list1"
>>
>> where I have a dedicated Mailman install under
>> /var/lib/mailmen/lists.example.org just for that domain.
>>
>>
>> Should this all work OK with Mailman?
>
> Yes.
>
>
>> Will Mailman even notice that the envelope address was changed into
>> something else or does it only look at what is inside the message?
>
> I don't see that any envelope address changes, but in any case, Mailman
> doesn't look at envelope recipient. Either the message gets to Mailman
> or it doesn't. If it got there, Mailman must have been a recipient.
>
> Mailman does look for the list address in To: or Cc: if the list's
> require_explicit_destination is yes.
>
>
>> Is there any way to automatically create aliases like this, or any hook
>> where Mailman can call a script that I use for creating the aliases?
>
> See MTA = 'Postfix' and related settings. You may or may not need to
> hack Mailman/MTA/Postfix.py.
I've just had a look at the postfix-to-mailman.py script included with
the Debian package so I'm going to try that.  It appears that will get
me halfway to what I want, as it eliminates the need to maintain these
aliases and virtual aliases.  There is some confusion about how MTA
should be set:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718284

and I suspect that further effort (the type of things discussed in my other email) is required to have a site list in each virtual domain.




From bsfinkel at att.net  Mon Jul 29 18:55:08 2013
From: bsfinkel at att.net (Barry S. Finkel)
Date: Mon, 29 Jul 2013 11:55:08 -0500
Subject: [Mailman-Users] aliases file: using globally unique user IDs
 (as in Sympa virtual domains)
In-Reply-To: <51F697EA.6040805@pocock.com.au>
References: <51F68BCD.5050804@pocock.com.au> <51F69015.2070901@msapiro.net>
	<51F697EA.6040805@pocock.com.au>
Message-ID: <51F69E6C.5020105@att.net>

On 7/29/2013 11:27 AM, Daniel Pocock wrote:
> On 29/07/13 17:53, Mark Sapiro wrote:
>> On 07/29/2013 08:35 AM, Daniel Pocock wrote:
>>> Migrating to Mailman, I'd like to do something like this:
>>>
>>>    lists.example.org-list1:
>>> "|/var/lib/mailmen/lists.example.org/mail/mailman post list1"
>>>
>>> where I have a dedicated Mailman install under
>>> /var/lib/mailmen/lists.example.org just for that domain.
>>>
>>>
>>> Should this all work OK with Mailman?
>>
>> Yes.
>>
>>
>>> Will Mailman even notice that the envelope address was changed into
>>> something else or does it only look at what is inside the message?
>>
>> I don't see that any envelope address changes, but in any case, Mailman
>> doesn't look at envelope recipient. Either the message gets to Mailman
>> or it doesn't. If it got there, Mailman must have been a recipient.
>>
>> Mailman does look for the list address in To: or Cc: if the list's
>> require_explicit_destination is yes.
>>
>>
>>> Is there any way to automatically create aliases like this, or any hook
>>> where Mailman can call a script that I use for creating the aliases?
>>
>> See MTA = 'Postfix' and related settings. You may or may not need to
>> hack Mailman/MTA/Postfix.py.
> I've just had a look at the postfix-to-mailman.py script included with
> the Debian package so I'm going to try that.  It appears that will get
> me halfway to what I want, as it eliminates the need to maintain these
> aliases and virtual aliases.  There is some confusion about how MTA
> should be set:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718284
>
> and I suspect that further effort (the type of things discussed in my other email) is required to have a site list in each virtual domain.

When I looked at the Ubuntu/Debian package, I saw that there were lots
of patches, many of which were undocumented.  And one patch deletes a
library that might be needed.  Because of this, I decided to build my
own package for Ubuntu based on the SourceForge source.  The only
Debian patch I included was one that placed libraries in directories
appropriate for Debian/Ubuntu.

Also, as discussed previously on this list, the

      postfix-to-mailman.py

script is NOT part of the SourceForge Mailman, and its use is
discouraged.  There is a Mailman FAQ that describes this
script and the recommendation not to use it.

I have details on building the package, if anyone wants them.

--Barry Finkel



From mark at msapiro.net  Mon Jul 29 19:10:42 2013
From: mark at msapiro.net (Mark Sapiro)
Date: Mon, 29 Jul 2013 10:10:42 -0700
Subject: [Mailman-Users] aliases file: using globally unique user IDs
 (as in Sympa virtual domains)
In-Reply-To: <51F69E6C.5020105@att.net>
References: <51F68BCD.5050804@pocock.com.au> <51F69015.2070901@msapiro.net>
	<51F697EA.6040805@pocock.com.au> <51F69E6C.5020105@att.net>
Message-ID: <51F6A212.3000105@msapiro.net>

On 07/29/2013 09:55 AM, Barry S. Finkel wrote:
> 
> Also, as discussed previously on this list, the
> 
>      postfix-to-mailman.py
> 
> script is NOT part of the SourceForge Mailman, and its use is
> discouraged.  There is a Mailman FAQ that describes this
> script and the recommendation not to use it.


The FAQ is at <http://wiki.list.org/x/EYDt>. Read it and the post at
<http://mail.python.org/pipermail/mailman-users/2012-September/074017.html>
before trying to use postfix_to_mailman.py.

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

From daniel at pocock.com.au  Mon Jul 29 19:26:32 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Mon, 29 Jul 2013 19:26:32 +0200
Subject: [Mailman-Users] aliases file: using globally unique user IDs
	(as in Sympa virtual domains)
In-Reply-To: <51F6A212.3000105@msapiro.net>
References: <51F68BCD.5050804@pocock.com.au> <51F69015.2070901@msapiro.net>
	<51F697EA.6040805@pocock.com.au> <51F69E6C.5020105@att.net>
	<51F6A212.3000105@msapiro.net>
Message-ID: <e6a15ce5-811f-49ae-815c-693b0d9383cd@email.android.com>



Mark Sapiro <mark at msapiro.net> wrote:

>On 07/29/2013 09:55 AM, Barry S. Finkel wrote:
>> 
>> Also, as discussed previously on this list, the
>> 
>>      postfix-to-mailman.py
>> 
>> script is NOT part of the SourceForge Mailman, and its use is
>> discouraged.  There is a Mailman FAQ that describes this
>> script and the recommendation not to use it.
>
>
>The FAQ is at <http://wiki.list.org/x/EYDt>. Read it and the post at
><http://mail.python.org/pipermail/mailman-users/2012-September/074017.html>
>before trying to use postfix_to_mailman.py.
>

So the issue I opened the bug for appears to be a problem with the comments/docs in postfix-to-mailman - is that the case?

I'm not convinced I need it, but I am not inconvenienced by the whole-domain issue, all my lists are in domains such as lists.lumicall.org

I've also had a look at the vhost patch, it generates aliases similar to the Sympa pattern, can anyone comment on it?


>-- 
>Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
>San Francisco Bay Area, California    better use your sense - B. Dylan
>------------------------------------------------------
>Mailman-Users mailing list Mailman-Users at python.org
>http://mail.python.org/mailman/listinfo/mailman-users
>Mailman FAQ: http://wiki.list.org/x/AgA3
>Security Policy: http://wiki.list.org/x/QIA9
>Searchable Archives:
>http://www.mail-archive.com/mailman-users%40python.org/
>Unsubscribe:
>http://mail.python.org/mailman/options/mailman-users/daniel%40pocock.com.au

From stephen at xemacs.org  Mon Jul 29 19:40:49 2013
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 30 Jul 2013 02:40:49 +0900
Subject: [Mailman-Users] Migrate from Lyris to Mailman
In-Reply-To: <BLU170-W1133464A898632C0EBDF6F98E550@phx.gbl>
References: <BLU170-W69FAAC1D36F19420B7A9418E680@phx.gbl>
	<87hafjpa3i.fsf@uwakimon.sk.tsukuba.ac.jp>
	<BLU170-W1133464A898632C0EBDF6F98E550@phx.gbl>
Message-ID: <87ob9lnu1q.fsf@uwakimon.sk.tsukuba.ac.jp>

Stephen Cook writes:
 > Yes, oldserver will only be a web server, so all mail can be forwarded to the new server.
 > In brief, it looks I should:
 > 1) Forward all mail from oldserver.mydomain.com to newserver.mydomain.com using an MX record or an SMTP forward on oldserver.mydomain.com
 > 2) Create a Postfix virtual domain on newserver.mydomain.com for oldserver.mydomain.com
 > 3) Change the new Lists' email domain to oldserver by modifying the host_name attribute on the web admin General Options page.

That sounds about right to me.  The main thing is getting routing
right so that list traffic addressed to oldserver gets routed to the
local Mailman instance.  I don't actually use Postfix virtual domains
so I can't assure you that a virtual domain is necessary or sufficient
to get your setup working, but it sounds like the right thing if I
understand the documentation correctly.

From daniel at pocock.com.au  Mon Jul 29 20:21:41 2013
From: daniel at pocock.com.au (Daniel Pocock)
Date: Mon, 29 Jul 2013 20:21:41 +0200
Subject: [Mailman-Users] mailman vhost patch
Message-ID: <51F6B2B5.5020100@pocock.com.au>




I've just been looking at the wiki about the vhost patch
https://wiki.koumbit.net/VirtualMailman

It writes the aliases file in much the same way as Sympa, except the
domain comes before the list name, e.g.

  Sympa:                 example.org-list1
  Mailman+vhost patch:   list1-example.org

One thing that is not clear from the documentation: the site list (e.g.
mailman at lists.example.org).  With vhosts, can/should there be a site
list for each vhost?  e.g. mailman at lists.example.org and
mailman at lists.example.net should both exist as separate lists?

Regards,

Daniel

From misterbhatt at gmail.com  Tue Jul 30 10:32:55 2013
From: misterbhatt at gmail.com (Amit Bhatt)
Date: Tue, 30 Jul 2013 14:02:55 +0530
Subject: [Mailman-Users] All the mails are not reaching all the members
In-Reply-To: <51F6883E.3040805@msapiro.net>
References: <CAOZo=+9tOKyZ+jjqPRAD1b4V2aYvc10cs3DEFG6d1yFv7W4Hiw@mail.gmail.com>
	<51F6883E.3040805@msapiro.net>
Message-ID: <CAOZo=+9FMD=RknBfnK8FSn01_gdz+jswxMPXph8oLqM0UCfzQA@mail.gmail.com>

I am the list moderator and can manage my  mailing list but not that
much of tech savvy. If you can please let me know where  and how to
Check Mailman's logs, particularly 'bounce', 'smtp' and
'smtp-failure',
and the MTA logs to see if messages are being delivered, bouncing and etc.

Thanks,

Amit Bhatt


On 7/29/13, Mark Sapiro <mark at msapiro.net> wrote:
> On 07/29/2013 02:59 AM, Amit Bhatt wrote:
>>
>> When I aproved the held messages from tend to pending moderation list,
>> they do not reach to the users or do not appear on the mailing list.
>> Or some of them reach to the  list very late.
>> Secondly, again all the messages sent by the users are not delivered
>> to other members of the list since last couple of days.
>>
>> An advise with solution would be much appreciated.
>
>
> Check Mailman's logs, particularly 'bounce', 'smtp' and 'smtp-failure',
> and the MTA logs to see if messages are being delivered, bouncing or what?
>
> --
> Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
> San Francisco Bay Area, California    better use your sense - B. Dylan
> ------------------------------------------------------
> Mailman-Users mailing list Mailman-Users at python.org
> http://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Security Policy: http://wiki.list.org/x/QIA9
> Searchable Archives:
> http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe:
> http://mail.python.org/mailman/options/mailman-users/misterbhatt%40gmail.com
>

From drew.tenenholz at isid.org  Wed Jul 31 13:34:26 2013
From: drew.tenenholz at isid.org (Drew Tenenholz)
Date: Wed, 31 Jul 2013 07:34:26 -0400
Subject: [Mailman-Users] Mailman Moderation Queue - recovery possible?
Message-ID: <p062408a4ce1ea63fd42a@[192.168.209.11]>

All --

Ah, the joys of actually using the Mailman interface instead of just managing the architecture....I just did a couple hours of moderation queue cleanup for one of my lists and trying to send some of the messages on to my personal account.  

I dutifully clicked the button to discard the message, then filled in my personal email address, but forgot to click the check box for 'Additionally forward this message to...'  (Possibly because the list is set to Spanish, which I can't actually read.)

Is there a way to restore or access the messages once they have been discarded?

If I were able to get to a backup snapshot of the system, which file would I be looking to restore?

-- Drew Tenenholz

From kardan at riseup.net  Wed Jul 31 22:38:28 2013
From: kardan at riseup.net (kardan)
Date: Wed, 31 Jul 2013 22:38:28 +0200
Subject: [Mailman-Users] [SOLVED] Re: message held for moderation "no
 member", adding address: "already member"
In-Reply-To: <51F4552B.6030205@msapiro.net>
References: <20130724235456.2e852669@delight> <51F06B68.8080806@msapiro.net>
	<20130726193011.03bad624@delight> <51F2CC31.9050209@msapiro.net>
	<20130727022856.2de3c355@delight> <51F31FDA.4070400@msapiro.net>
	<20130727131652.5932912f@delight> <51F4552B.6030205@msapiro.net>
Message-ID: <20130731223828.31626300@delight>

Hi Mark,

On Sat, 27 Jul 2013 16:18:03 -0700 Mark Sapiro <mark at msapiro.net> wrote:

> >> 4. rejection = _('''Blind carbon copies or other implicit
> >> destinations are not allowed.  Try reposting your message by
> >> explicitly including the list address in the To: or Cc: fields.''')
> >> 4.
> >> "Blindkopien ('BCC:'), oder weitere enthaltene Zieladressen,
> >> sind nicht erlaubt. Tragen Sie die Adresse der Mailinmgliste in das
> >> 'An:'- oder 'Cc:'-Adressfeld ein und senden Sie Ihre Nachricht
> >> bitte noch einmal."  
> > This message is perfect and should have been shown instead of 1
> > ("the sender is not part of the list"). I don't know why this went
> > wrong.  

> I don't know why you saw the wrong message. Two possibilities occur
> two me. This could be verified only by looking at the various held
> message entries in Mailman's 'vette' log.
The log said: "Reason: Blind carbon copies or other implicit
destinations are not allowed. Try reposting your message by explicitly
including the list address in the To: or Cc: fields."

> The first, and I think more likely possibility is the an initial post
> was held as a non-member post and the poster got a notice and
> subscribed (You could also check Mailman's 'subscribe' log) before
> you tried to subscribe him.
Unfortunately this is not the reason as the poster is a member since
the list was created and even is one of the moderators.
(Sorry, I didn't tell before.)

> The only other possibility I can think of is the German message
> catalog in the Mailman installation that supports your list has been
> modified or corrupted somehow and is displaying the wrong translation
> for strings 3 and 4.
Makes sense but seems unlikely. Which file is the right one to check?

> I just thought of a third possibility which seems more likely that the
> two above. See below.
> 
> >> The 'reasons' are what appear in the admindb summary and the
> >> notices to the admin and user. the 'rejections' appear only in the
> >> admindb detail as the default rejection message and in rejection
> >> messages if the default is not overridden.
> > 
> > If I would have read the first moderation message properly -
> > ("Mailadresse der Liste steht nicht im Mailheader (vielleicht wegen
> > einer Weiterleitung?)") - I just had overlooked the misleading
> > reason in the admindb ("the sender is not part of the list").
> 
> That message can be seen in the admindb even though the user is a list
> member in the following way.
> 
> I explained before how SENDER_HEADERS are consulted to deterrmine if a
> post is from a list member. However, once a post is held and displayed
> in the admindb interface, admindb uses a different method to determine
> the sender. If USE_ENVELOPE_SENDER is set to Yes in mm_cfg.py (or
> changed to Yes in Defaults.py), admindb will take the contents of a
> Sender: header if any in preference to From:.
USE_ENVELOPE_SENDER = No
and
there is no Sender defined in the header.

> In this case, the message could be From: a member but have a Sender:
> which is not a member, and the message could be held for some other
> reason like 'too big' or 'implicit destination' and the left hand side
> of the admindb summary will say the sender is not a list member.

Thanks a lot for the explanations and sorry for my delay. The sender
agreed to send messages to the list separatedly instead of BCCing in
the future. Though I like to help to track this down to see if it is a
Mailman bug or misconfiguration.

I send you the original mail and the mailman reminder so you can
inspect the headers.

-- 
Kardan <kardan at riseup.net>
Encrypt your email: http://gnupg.org/documentation
Public GPG key 9D6108AE58C06558 at hkp://pool.sks-keyservers.net
fpr: F72F C4D9 6A52 16A1 E7C9  AE94 9D61 08AE 58C0 6558