On Tue, Aug 6, 2019 at 7:24 AM David Gibbs via Mailman-Users < mailman-users@python.org> wrote:

On Mon, Aug 5, 2019 at 11:40 PM Scott Neader scott@qth.com wrote:

...

Do any of you have any ideas for me to identify this serial 'mark-as-spammer'? Could I hack something together temporarily that would put maybe the first few characters of their email in the footer? (so that Comcast won't sense it as an email and won't redact it?) Other ideas?

Check out the RCPT_BASE64_HEADER_NAME setting in Defaults.py. That will let you tag personalized & verped deliveries with the base64 encoding of the recipient's email address.

I want to send a BIG thanks to David Gibbs on this one. This actually worked perfectly! The body of the FBL report shows just the basic To, From, Subject, Date/Time and Body, so I did not think adding a new header would do diddly-squat. I *wrongly* assumed that the FBL reports do not include any header information. David and I traded some direct emails on the topic and he finally convinced me to do a "View Original" or "View Source" (depending on your email client) on the FBL report from Comcast and low and behold... the full headers are exposed... not only from the FBL itself, but *also* from the original offending message that the ISP forwarded in the FBL. So, you have two sets of headers to scroll through... but, sure enough, my new header was there, exposing the culprit list subscriber that was flagging all emails as spam.

Here's a step-by-step (not hard) to get this going:

1. At the server level, Personalization or VERP must be enabled. I chose Personalization since I already had it enabled. This is done by adding "OWNERS_CAN_ENABLE_PERSONALIZATION = Yes" to mm_cfg.py
2. At the list level, Personalization needs to be set to Yes (Non-Digest options > Personalize)
3. At the server level, add " RCPT_BASE64_HEADER_NAME = 'X-Mailman-R-Data' " to mm_cfg.py

This will add a new header to each email, like this:

X-Mailman-R-Data: Ym9ndXNzcGFtcmVwb3J0ZXJAY29tY2FzdC5uZXQ=

My next goal is to try VERP, and see if I can use that to find the habitual "mark as spam" folks on some Digest emails. Personalization doesn't work for Digests, but maybe VERP will?

Again, thanks David Gibbs for sticking with me on this!!

• Scott

On Tue, Aug 6, 2019 at 7:38 PM Grant Taylor via Mailman-Users < mailman-users@python.org> wrote:

On 8/5/19 10:14 PM, Scott Neader wrote:

...

Hi all! I have a list member with a comcast.net email address that is marking most every list message as spam. I have Personalization enabled, and have the subscriber's email address in the footer, but Comcast redacts the email address. Unfortunately, there are quite a few comcast.net users on this list, making this really difficult to find the offender.

Oy vey!

...

Do any of you have any ideas for me to identify this serial 'mark-as-spammer'?

Are you using VERP? I would think that the VERP data would survive Comcast's redaction.

I appreciate the suggestion, but VERP (as I understand it) changes the return-path. I do not get to see any headers, including return-path, other than the ones I mentioned (To, From, CC, BCC, Subject and the Body itself). So, I do not believe VERP will help.

I need a way to put some clue about the recipient into the footer, when personalization is enabled. I've seen some past solutions where admins were successful in adding some type of hash or encoded version of the recipient's email address into the footer, but the steps to get that done were not shared. Open to other ideas.

• Scott

Wouldn't it be simple enough just to use rot13, or the senders name without the domain?

On 8/7/2019 5:20 PM, Carl Zwanzig wrote:

On 8/7/2019 1:17 PM, Scott Neader wrote:

...

I need a way to put some clue about the recipient into the footer, when personalization is enabled.  I've seen some past solutions where admins were successful in adding some type of hash or encoded version of the recipient's email address into the footer, but the steps to get that done were not shared.  Open to other ideas.

See- https://wiki.list.org/DOC/What%20variables%20can%20I%20use%20in%20the%20head...

I regularly get email from a list with the footer (redacted)

UUU mailing list UUU@DOMAIN.org http://listsmgt.DOMAIN.org/mailman/listinfo/UUU Sent to Carl Zwanzig at zbang@sonic.net All posts to the UUU mailing list are copyright the individual senders.

z!

On 8/7/2019 6:23 PM, David Gibbs via Mailman-Users wrote:

On Wed, Aug 7, 2019 at 8:18 PM David Josephsondlj04@josephson.com wrote:

...

Wouldn't it be simple enough just to use rot13, or the senders name without the domain?

The first thing they redact is the users name.

That's if they edit (or send) the footer at all. You could edit the footer generation code to rot13 the name or perhaps put it in the msg body. Or even to put the message ID in the footer, too.

Later,

z!

On Fri, Aug 9, 2019 at 2:55 AM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:

Have you had any luck with this in the last couple of days?

Hi Stephen (and all). Indeed, I am having MUCH luck with this! First, the option to base64 encode the recipient's email as a new header with the RCPT_BASE64_HEADER_NAME config setting (discussed in my last post) is working great! In addition, as you mentioned, I am ALSO getting lucky in reviewing the headers for the queue id... and I am using this successfully on one older server that has an older version of Mailman (which does not have the base64 option).

So, I am in really good shape at this point... thank you!!!

• Scott

Scott Neader writes:

...

I have Personalization enabled, and have the subscriber's email address in the footer, but Comcast redacts the email address. Unfortunately, there are quite a few comcast.net users on this list, making this really difficult to find the offender.

Does the returned mail contain the full trace of "Received" fields? If you're very lucky, one of them may contain the offender's address.

Otherwise, the oldest one frequently has an MTA queue id from your MTA (and depending on your network, there may be a couple of these under your control in the Received chain), and that can be matched with the queue id in the MTA's log, which will typically tell you who it was sent to. Since you have full personalization enabled, there should be one such queue id per message. Here is an example of my own:

Received: from steve by turnbull.sk.tsukuba.ac.jp with local (Exim 4.92) (envelope-from steve@turnbull.sk.tsukuba.ac.jp) id 1htOUc-0000Rx-F5; Fri, 02 Aug 2019 12:44:34 +0900

2019-08-02 12:44:39 1htOUc-0000Rx-F5 => mailman-developers@python.org R=dn...

The log line is truncated by me since the rest is irrelevant, the MTA is Exim. Note that some MTAs don't do this, some MTAs don't do it by default, but you can reconfigure the log message and the Received header this way. And some MTAs that do it change the prefix or suffix of the queue id at various stages, so you may need to search on a truncated portion of the full id.

...

I've read through the Mailman Users archives and have seen others with this problem, and it seems some of you have come up with your own creative solutions, but no solutions have been posted,

Here's a partial solution from Mailman-Developers:

https://mail.python.org/pipermail/mailman-developers/2012-June/022200.html

(the "partial" is because you'll have to come up with your own way to iterate over the mailing list and match MD5s). I suspect you can get the same effect by base64- or base85-encoding the email address, or even simply %-encoding (or removing!) all the punctuation, instead of MD5-ing. Those are easily reversible, and the punctuation-munging solutions can be "decoded" by eye!

Note that it's barely possible you're using the Sendmail.py module, in which case you will have the line "DELIVERY_MODULE = 'Sendmail'" in mm_cfg.py. If so, come back and we can discuss the "cons" (there are no "pros") of that module, and what to do next.