[BALUG-Admin] mailman-loop ...

[Michael Paoli]

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).

At least for now it's aliased to postmaster (which gets delivered
locally) - probably at least "good enough" for now.

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.

Hmmmm... but optimal bounce processing for mailman (and with exim4 MTA)?
I do recall also mailman has some option(s) that use different mechanisms
on the envelope FROM ... notably so bounces - even after initial
SMTP - may be better correlated to and processed for, the targeted
address ... might also help with other bits of backscatter (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).  So ... there might be some
more general advantages to tweaking of such sending configuration ...
but I recall too it has one notable disadvantage ... since envelope
FROM is adjusted per-recipient, each mail is sent as a separate
SMTP transaction ... which is somewhat inefficient.  Without
setting such an option, bunches of same email to same SMTP server with
multiple distinct recipients are sent as a single SMTP transaction.
Anyway, subscriber volume isn't so huge as to make a major difference
in that efficiency ... so ... may be worth at least considering?
I think also, if I recall correctly, it's overall configuration, not
per-list, ... so ... testing first on lower subscriber count lists
would mostly be a matter of timing - at least if I recall that detail
correctly.

/var/log/exim4/rejectlog* ... default retention appears to be about 10
days ... maybe I ought bump it up to something in the 15 to 65 day range.
I probably ought review it more frequently, but ... if/when I don't,
might be good to have some more data to look over there - lest I
miss something that may be of interest/significance.
Yeah, ... I'll adjust that ...
# fgrep -l rejectlog /etc/logrotate.d/*exim*
/etc/logrotate.d/exim4-base
# ex /etc/logrotate.d/exim4-base
/etc/logrotate.d/exim4-base: unmodified: line 9
:1,$p
/var/log/exim4/mainlog /var/log/exim4/rejectlog {
         daily
         missingok
         rotate 10
         compress
         delaycompress
         notifempty
         create 640 Debian-exim adm
}
:1,$t$
9 lines added
}
:?rotate
         rotate 10
:s/10/65/p
         rotate 65
:?rejectlog
/var/log/exim4/mainlog /var/log/exim4/rejectlog {
:s/^[^ ]* //p
/var/log/exim4/rejectlog {
:?rejectlog
/var/log/exim4/mainlog /var/log/exim4/rejectlog {
:s/[^ ]*rejectlog //p
/var/log/exim4/mainlog {
:1,$p
/var/log/exim4/mainlog {
         daily
         missingok
         rotate 10
         compress
         delaycompress
         notifempty
         create 640 Debian-exim adm
}
/var/log/exim4/rejectlog {
         daily
         missingok
         rotate 65
         compress
         delaycompress
         notifempty
         create 640 Debian-exim adm
}
:w
/etc/logrotate.d/exim4-base: 18 lines, 244 characters
:q
#
Okay, ... that bit is done.

Anyway, rejectlog data still generally continuing to look good.
Did catch and correct the missing mailman-loop issue,
otherwise generally not seeing false-positive rejects
(there remains the blank body and such issues - but we've got
work-arounds to mostly address that - at least until it's properly
fixed "some day").