On Fri, 15 Apr 2016, Drake Wilson wrote: > Package: lists.debian.org > Severity: important > > We seem to be having a recurring problem of people who want off > debian-security-announce > unintentionally bothering debian-security about it, or trying to unsubscribe > to the latter > list and then finding it doesn't do what they want. Then they feel helpless > and start > spewing messages in all directions, because feeling unable to shut off an > unpredictable > stimulus that repeatedly yanks one's attention has a way of jamming spikes > into one's > psyche. This also means people who want to be on debian-security get these > messages > flung at them as a side effect. > > I think it would be more reasonable to set the Reply-To address for d-s-a > posts to a > robot that responds with a canned message to the effect of "if you wish to > discuss this > further, subscribe to debian-security and post anew there; if you wish to > unsubscribe, > you should be asking debian-security-announce-request; if you actually meant > to send > this to your colleagues at the NOC, you can ignore this message but you might > want > to be more careful in the future". Bonus points if it recognizes the second > case > and automatically does the first step of the process, so that a reply to the > first > canned message does the unsubscribe-confirmation step. > > By this, I mean that if this address is being set by the senders of such > messages, > the policy should be changed; if it is being set by the mailing list software, > it should be reconfigured; and if it is being set by the senders because the > mail > may be replicated in multiple places, the mailing list software should be > configured > to munge the header on d-s-a only. If there is some other process going on, > extrapolate > accordingly. > > The expanded form of this: > > 1. The Reply-To address for messages on debian-security-announce generally > points > to debian-security. This is unusual; why is this done in the first > place? The > obvious reason is "so that people who wish to discuss DSAs further can do > so on > debian-security conveniently", but if that's the only reason, I think the > side > effects are intolerable by comparison. > > 1a. People who are potentially knowledgeable also don't readily recognize > this, > often treat the situation as the usual "asking _on the list from > which one > wishes to be unsubscribed_" situation, and then provide the _wrong_ > -request > address while trying to help the hapless users who just don't want > their > mailbox flooded with stuff which is now irrelevant to them. If this > then > starts showing up in Web searches and misleads the next user who > tries to > unsubscribe and maybe does a little more research first, so much the > worse! > > 2. I _assume_ what's happening is users are pressured to subscribe to d-s-a > when > they start using Debian, because of important announcements. These > people are > _not_ necessarily even aware of the idea of getting involved in the > interactive > mailing list culture of Debian, and certainly are unlikely to read the > codes of > conduct for the lists first. They later stop using Debian, or decide > that they > will handle security announcements some other way (possibly a bad way, > but that's > a separate problem), but now they can't figure out how to stop receiving > all this > mail. > > 2a. Importantly: these people may not be used to using mailing lists of > the more > usual "free-software world" type _at all_! Nor is it realistic to > expect > them to handle the cognitive load of remembering such things between > a one-off > event and a distant point in time. > > 2b. Note that the pressure to subscribe to d-s-a may come from other > well-meaning > individuals providing tutorials or such, so there's no way to get all > of them. > > 3. Posts to d-s-a have no human-readable subscription-manipulation > information in > the body, so there's no reminder of what to do that actually shows up at > the time. > It would sure be nice if _everyone's_ clients respected List-Unsubscribe > headers > (and if they knew how to request this function in their client!) but > obviously > this isn't consistently true; see (2a). > > 3a. This, in combination with (1), passively encourages users to violate > the "If > you send messages to lists to which you are not subscribed, always > note that > fact in the body of the message" policy in the Debian lists code of > conduct, > because it makes it very easy to forget; normally, sending to lists > to which > one is not subscribed has much more of a conscious barrier to it. > This is > true even for users who are notionally aware of the situation. > > 4. debian-security (like most Debian lists) isn't filtering messages from > unsubscribed > individuals, which isn't inherently bad, but amplifies the rest of this > quite badly > because it means unrelated individuals who _do_ want to engage > interactively take > splash noise. > > 4a. Whatever filter is supposed to be keeping administrivia from hitting > the > list in general obviously isn't working; "machine learning is hard" > aside, > I repeatedly see messages with the subject or first line literally > being > "unsubscribe" in its entirety. In any event, this wouldn't help with > everything, > because inattentive replies in general (which are coming from a > psychological > context of not being in "interactive mailing list mode") and > unsuitably-configured > out-of-office autoresponders are also problems, and all of these seem > to come > from the same disconnect between action and effect caused by the > weird Reply-To > configuration. > > Thus my suggestion at the top. > > Aside from any of that, I'd volunteer to play docent to the users affected by > this > if I had the energy over time, but I really don't. If there's a one-off > action I > can do to help, it would be nice to know what it is in case I can manage it > somehow. > > Can we please get this to stop? It is not up to listmasters to decide that. The policy of a list is decided by its owners - the security team in that case - if the security team decides about a different policy, we will try to set it up.
Alex
