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