Andreas Barth writes:
- Stephen J. Turnbull (stephenjturnbull@gmail.com) [210824 19:31]:
[I]t's possible that Mailman had nothing to do with it.
Well, the mail adress got disabled, and the user got warning mails ("Your subscription for list mailing list has been disabled"). [...] Please note that individualsation was enabled,
OK. But all you told us was the user got disabled or unsubscribed.
so all mails are sent out with per-subscriber mail envelope address, which then makes bounce detection quite straight-forward.
We can identify the subscription easily, but there are still complexities. Is it a hard bounce, or a soft bounce, in particular, but it could also be spam or a rogue autoresponder.
They are sent to the bounce address (more specifically list-bounces+user=domain@listdomain where user@domain is subscribed to the list).
OK.
I didn't get them as list owner, so no.
You have to request that unparseable bounces be sent to owner in the list configuration. It defaults off because most owners wouldn't know what to do with them, although maybe we should default on and provide an explanation of how to forward them to us for future versions, or turn off the forwarding.
This decision isn't something Mailman should be doing because it depends on context and guessing what the subscriber wants. Really, this is an owner problem, not a Mailman problem.
What should I do different as owner? The user was set to disabled without any manual intervention from me as list owner.
As I wrote before, you can set up your lists with a large number of bounces allowed so that their accounts don't get disabled for the period of anticipated absence. You can set the list to send bounce mail that isn't parseable as a standard delivery status notifications (DSN) to you. In this case it would probably have saved everybody a bit of annoyance. Finally, you can filter on that header either using the standard Mailman header filtering[1], or better yet, in the MTA as you suggest:
It's not obvious what *we* should do.
My proposal would be to ignore messages sent to the bounce address with the 'Auto-Submitted: auto-replied (vacation)' header. I'm thinking about doing that change on the MTA level,
Filtering in the MTA the right thing to do. You can already filter and discard such messages in Mailman using the "header filtering" capabilities, I think. But as always, this kind of filtering is far more efficient at the MTA because the MTA is doing a lot of it anyway at most sites.
It's also not easy to be sure we get it right. The 'Auto-Submitted' field is standard (RFC 3834), but unfortunately "Auto-Submitted: auto-replied" is the RFC-3834-recommended format for DSNs, ie, bounce messages. We do parse standard DSNs for soft vs. hard bounces, so we can identify standard DSNs but unparsable DSNs still show up occasionally, which are not distinguishable from vacation messages using Auto-Submitted. Relying on the string "(vacation)", which is a comment, would suck for us. We would inevitably get requests for translations into a few dozen languages and additions of "(out of office)" etc, etc, all for a few users / providers (I can't recall hearing of this problem until you brought it up, although it seems like a plausible bug at providers).
but I believe it would be more appropriate at the mailman level.
I don't see a good reason to have a standard feature for this in Mailman, because (1) based on the Auto-Submitted field as defined in the standard we can't distinguish "vacation" from a DSN, (2) the comment is arbitrary which would impose a maintenance burden on us as variants and translations appear in that comment, and (3) both Mailman and MTAs already provide sufficiently configurable header filtering.
Sorry, I meant "disabled". A contributing fact was for sure that the users mail setup sent out the vacation mail on any incoming mail, not only the first, and also on mails with precendence list. I adressed that already to the user (because I believe it's a bug),
RFC 3834 which specifically calls for efforts to not spam from auto- responder users.
(Especially as the mail provider is gmx, this is *the* largest webmail provider in Germany, so both the probability of fixes is rather low, and the probability of happening with users users is not too low.)
That's important to you, and other admins in Germany, and I sympathize. But for us there's no guarantee that other providers will use exactly that format, or won't allow users to specify the comment (even worse). So I respectfully ask you to use the filtering capabilities you already have available to you.
Steve
Footnotes: [1] I should check this, as filtering probably takes place differently for bounce messages and the rest of Mailman. If we don't already have filtering on bounce messages, I would support adding it to the chain for bounce messages, with the same UI but allowing it to have a different set of filtering rules from ordinary posts and email commands for configuring subscripts.