I'm dealing with (presumably bogus) spam reports for messages from foo-bounces@list.domain
As far as I can tell these messages are triggered by the alleged-victim/apparent-attacker sending messages to foo-subscribe followed immediately by foo-unsubscribe. I have the size and time from postfix and/or mailman's smtp.log, but I don't have the message content.
Are these messages stored somewhere by Mailman? Can I have them stored for a month or so in order to deal with these bureaucratic incidents?
David
On Mon, Nov 20, 2023 at 4:25 PM David Bremner <david@tethera.net> wrote:
I'm dealing with (presumably bogus) spam reports for messages from foo-bounces@list.domain
As far as I can tell these messages are triggered by the alleged-victim/apparent-attacker sending messages to foo-subscribe followed immediately by foo-unsubscribe. I have the size and time from postfix and/or mailman's smtp.log, but I don't have the message content.
Are these messages stored somewhere by Mailman? Can I have them stored for a month or so in order to deal with these bureaucratic incidents?
David
With a subscription policy of confirm & approve, this problem is non-existent.
PS: I haven't looked into other subscription policies, but I see no point of not using the above because it protects your list from unwanted characters.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
Odhiambo Washington <odhiambo@gmail.com> writes:
With a subscription policy of confirm & approve, this problem is non-existent.
As far as I can tell, people (bots? mindless corporate firewalls?) are complaining about the initial confirmation email. So I think an additional approval step won't really help.
David Bremner writes:
As far as I can tell, people (bots? mindless corporate firewalls?) are complaining about the initial confirmation email. So I think an additional approval step won't really help.
Then you can go to approval only, or subscription by admin only. That's probably not what you want, but on the off chance it's better than the current situation I mention them.
I'm not sure what you plan to do with these messages if you get them. Do you think the content is likely to reveal anything about the problem agents that are conducting this apparent attack?
You could try adding
[logging.subscribe]
level: debugor
[logging.smtp]
level: debugto 'mailman.cfg' get more output in the logs. Note that the latter will be *very* verbose and fill up the 'smtp' log very quickly. This will not get the content of the messages.
With Mailman 2 there was a neat dodge: you move the 'mailman' executable wrapper aside and put another executable in its place. I guess you could stick an lmtp server such as Postfix's smtpd on localhost:8024, configure mailman to listen on 8025, and have the smtpd dupe it for you (ie, deliver both to a file and to localhost:8025. Maybe you want to put an instance of a filter like procmail in there so it only looks at -subscribe mailboxes.
I don't really know what to say beyond that.
participants (3)
-
David Bremner -
Odhiambo Washington -
Stephen J. Turnbull