The recipient address abc-given.name@online.de (member of list mylist@myserver.de) has currently an out of office responder and mails are returning to my mailman3 system as unrecognized bounce messages.
I suspect the "-" in his address to be in conflict with the bounce address hyphen:
<mylist-bounces+abc-given.name=online.de@myserver.de>
Can any of you experts try on their systems, whether this a bug of mailman3 due to the "-" in the address?
Systeminfo:
Mailman Core-Version GNU Mailman 3.3.10 (Tom Sawyer) Mailman Core API-Version 3.1 Mailman Core Python-Version 3.11.2 (main, Apr 28 2025, 14:11:48) [GCC 12.2.0]
I thought, that such mails should be sent to the original sender and not go to me as the list owner.
However, I am not sure about this.
The prepended mailman text is
"Die angehängte Nachricht wurde als unzustellbar empfangen, aber das Format konnte nicht erkannt werden, oder keine Abonnenten-Adresse konnte daraus extrahiert werden. Diese Mailingliste ist so konfiguriert, dass alle nicht erkannten Bounce-Nachrichten an die Listen-Administrator*innen weitergeleitet werden."
On 2025-10-13 22:09:18 -0000 (-0000), Wikinaut wrote:
The recipient address abc-given.name@online.de (member of list mylist@myserver.de) has currently an out of office responder and mails are returning to my mailman3 system as unrecognized bounce messages.
I suspect the "-" in his address to be in conflict with the bounce address hyphen:
<mylist-bounces+abc-given.name=online.de@myserver.de>
Can any of you experts try on their systems, whether this a bug of mailman3 due to the "-" in the address? [...]
My recollection is that there's a bunch of lists of known bounce message content patterns in the flufl.bounce library that the message body is matched against, and if the wording of the bounce message isn't a recognized one then the bounce is considered unidentified in order to not count against the subscriber's bounce score. See https://gitlab.com/warsaw/flufl.bounce for details.
-- Jeremy Stanley
I do not see how this library understands German "out of office until...." messages, perhaps Mark can say something to it. Many links in that repository are also broken.
I am lost.
On October 13, 2025 3:37:36 PM PDT, Wikinaut <mail@tgries.de> wrote:
I do not see how this library understands German "out of office until...." messages, perhaps Mark can say something to it. Many links in that repository are also broken.
Flufl-bounce doesn't recognize any out of office messages in any language because they aren't non-delivery notices.
What links in <https://gitlab.com/warsaw/flufl.bounce/> are broken?
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
On October 13, 2025 3:09:18 PM PDT, Wikinaut <mail@tgries.de> wrote:
The recipient address abc-given.name@online.de (member of list mylist@myserver.de) has currently an out of office responder and mails are returning to my mailman3 system as unrecognized bounce messages.
I suspect the "-" in his address to be in conflict with the bounce address hyphen:
It has nothing to do with the hyphen in the address. The issue is the recipient's ooo responder is 1 responding to the envelope sender rather than the From: address. 2 responding to a message with Precedence: list. Both these are wrong. The resultant message to the list-bounces address is an unrecognized bounce because it doesn't look like any known DSN.
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
Dear Mark,
what are your recommendations on my side to alleviate the problems with mails to that person? Personally, I don't want to block his address.
What countermeasures offer mailman3?
On Tue, Oct 14, 2025 at 12:07 PM Wikinaut <mail@tgries.de> wrote:
Dear Mark,
what are your recommendations on my side to alleviate the problems with mails to that person? Personally, I don't want to block his address.
What countermeasures offer mailman3?
Mailman3 to deal with an OOO responder from an insane MuA? You can filter emails at the MTA level using several criteria and let MM3 perform its primary function. If your server is dedicated to MM3 only and not other emails, you can filter using header_checks and discard any OOO responses.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
Wikinaut writes:
Personally, I don't want to block his address.
If you're worried about blowback on you, that's your call.
But if you're just trying to be nice, consider the following.
- Most important, he likely doesn't know he's causing problems. There are plenty of conformant vacation utilities, so it's not difficult for him to fix. Most people are happy to do it right (and there's some chance that a tried and tested utility will have additional features he could use). Put his subscription hold, tell him why, and explain how to fix the problem and reenable his subscription.
- If there are other people he corresponds with where sender != author, the OOO message is going to the wrong place, and colleagues, vendors, and customers may think he's ghosting them.
- He's very likely causing the same problem on multiple lists, and will continue to do so the next time he's out of office.
- He may be sending OOO messages in response to other low-precedence messages. I don't think this can do him harm, but I don't know that it can't.
- If you put in an MTA filter, you will probably forget what it's for the next time you work on the MTA configuration, and you may have to do maintenance on it if he changes the vacation utility.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
On 2025-10-14 23:44:13 +0900 (+0900), Stephen J. Turnbull wrote: [...]
Most important, he likely doesn't know he's causing problems. There are plenty of conformant vacation utilities, so it's not difficult for him to fix. Most people are happy to do it right (and there's some chance that a tried and tested utility will have additional features he could use). [...]
I used to refer offenders to RFC 3834, but any more neither they nor even their mail admins have much control over the "out of office" implementations they inflict on the rest of us. Too many commercial groupware systems make poor design choices, and managers in charge of purchasing decisions don't seem to care one bit about the problem (much less the vendors hawking such trash).
Any more I try to detect and discard these at the receiving end, insofar as that's feasible.
Jeremy Stanley
participants (5)
-
Jeremy Stanley -
Mark Sapiro -
Odhiambo Washington -
Stephen J. Turnbull -
Wikinaut