[BALUG-Admin] mailman-loop ...

[Michael Paoli]

Thanks!  :-)
That rather well anticipated two sets of questions I'd not yet
gotten around to asking.  Notably ...

Mailman bounce processing.  So ... Mailman has per-list bounce
processing - and aliases that go to pipes for those, e.g:
balug-test-bounces:      "|/var/lib/mailman/mail/mailman bounces balug-test"
and I'm presuming those just automagically "do the right thing"...
but it would also be prudent of me to reasonably check/confirm that
too, at some point.
Mailman also ... for various administrivia bits, etc., also uses
its "default" list - normally mailman - that also has bounce processing:
mailman-bounces:      "|/var/lib/mailman/mail/mailman bounces mailman"
but that, like the other list, may "just" be for stuff that's actually
sent to that list.
Then there's mailman-loop - bounce/return address of last resort (or
so I seem to recall reading) - I'm presuming that's used for, e.g.
stuff like password reminders.  And it may get bounces there for
some email addresses the others don't get ... e.g. I'm guestimating
if a subscriber's options are sent to "don't mail", they get no list
postings, but they do (may?) still get monthly password reminders -
presuming they have that option set on ... in which case I'm guestimating
mailman-loop would see bounces, but the other bounce processes, with
the subscriber's option set to not mail postings - wouldn't be seeing
bounces on those others.  So ... *also* well covering - and appropriately,
mailman-loop is fairly important.  I'll have to review that further
soon ... as it's probably not yet right.  :-/
Also, Debian+exmi4 - by default doesn't allow aliases to go to pipes
or files.  Now, I did earlier discover that mailman-loop itself
was bouncing 8-O (that was apparent in the exim4 logs - it was rejecting
email coming in to that address) ... did (at least partially) "fix"
that ... but alas, it's not (yet) being handed off to Mailman bounce
processing ... whereas it ought to be.
# fgrep loop /var/lib/mailman/data/aliases
# The ultimate loop stopper address
mailman-loop: /var/lib/mailman/data/owner-bounces.mbox
# ls -l /var/lib/mailman/data/owner-bounces.mbox
ls: cannot access /var/lib/mailman/data/owner-bounces.mbox: No such  
file or directory
# ls -ld /var/lib/mailman/data/
drwxrwsr-x 2 root list 4096 Sep 22 04:07 /var/lib/mailman/data/
#
So ... I do see the alias in that file, but would appear it's
either not using that alias file, or it's not enabled to write
to file - in either case, incoming email to mailman-loop was
bouncing and present config isn't sufficient for that alias
in that file to have the alias write out to that file.
So, ... like I say, will need to review/fix ... and soon.
Thanks for mentioning it, etc. - covered some of my questions,
and I wasn't aware of the /var/lib/mailman/data/aliases file.

VERP :-) ... yeah, I'd forgotten what it was called, but recalled
reading about it in Mailman configuration stuff.  And yes,
advantages/disadvantages ... but can be quite good for better
processing of bounces and backscatter.  So, yeah, may be better
on balance, to enable it, than not ... or maybe at least
occasionally/periodically enable it.  Ah, but should probably
first get mailman-loop working as it ought.

> From: "Rick Moen" <rick@linuxmafia.com>
> Subject: Re: [BALUG-Admin] mailman-loop ...
> Date: Thu, 21 Sep 2017 19:15:37 -0700

> Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
>
>> So ... in reviewing /var/log/exim4/rejectlog* files, I discovered
>> mailman-loop alias to be missing 8-O ... anyway, added that 2017-09-09.
>> I guess I somehow missed that earlier step (probably *somewhere* in the
>> mailman setup documentation ... apparently also for Debian, Debian
>> doesn't have an automagic way of adding email aliases - probably
>> mostly due to the variety of MTAs Debian supports).
>
> I'm pretty sure you're mistaken.  It's handled by an automatically
> created entry in /var/lib/mailman/data/aliases , a file that Mailman
> manages for you.
>
>> At least for now it's aliased to postmaster (which gets delivered
>> locally) - probably at least "good enough" for now.
>
> I _think_ you should let Mailman do it as per above.
>
> Here's a post by Mailman chief coder Mark Sapiro re: mailman-loop address:
> https://mail.python.org/pipermail/mailman-announce/2008-July/000117.html
>
>
>> Looks like mailman-loop is mostly used for mailman administrivia
>> emailings - e.g. password reminder mailings - and not used for, e.g.
>> typical/general list postings.
>
> It's for _bounces_ of password reminder mailings.  The special sending
> address is used just in case those messages also bounce, to prevent
> formation of a bounce loop.  You really shouldn't fool with it.
>
>> (e.g.  somewhere on the Announce list, there's apparently a subscribed
>> email address that generates an annoying backscatter ... and there
>> isn't enough data in the received backscatter to identify the
>> subscribed email address that's generating the backscatter).
>
> VERP to the rescue.  Enable it, at least long enough to identify the
> problem child.  (Long term, might leave it off, as there are
> disadvantages.  See first link about that.)
>
> https://wiki.list.org/DOC/So%20what%20is%20this%20VERP%20stuff
> http://www.gnu.org/software/mailman/mailman-install/node27.html