![](https://secure.gravatar.com/avatar/9e6e91b4d19ab46d2283dee26d7d5f60.jpg?s=120&d=mm&r=g)
Trolls can wreak havoc by subscribing to one or more high volume mailing lists on behalf of a target one. For example, someone could subscribe this list to the Linux kernel mailing list. Everybody would see the confirmation message, but by the time someone realizes the need to unsubscribe, the list will have been flooded, thereby realizing the DoS.
Are there mechanisms to prevent that?
Best Ale
![](https://secure.gravatar.com/avatar/e2371bef92eb40cd7c586e9f2cc75cd8.jpg?s=120&d=mm&r=g)
Alessandro Vesely writes:
Trolls can wreak havoc by subscribing to one or more high volume mailing lists on behalf of a target one.
Are there mechanisms to prevent that?
Don't antagonize trolls. :-/
The subscription to the high-volume list itself can't be prevented by the victim list, because it's the high-volume list that accepts the subscription, then sends to the victim list. However, most lists require confirmation, which is send by email to the list, looks like administrivia and will most likely get filtered by the victim list's Mailman. I guess we could set the bar higher by requiring the confirmation token be returned by email in a DMARC-From-aligned message (and if From alignment fails, require moderator approval for the subscription). This is still a setting on the high-volume list side, though.
On the victim side, I'm not 100% sure that the confirmation message would be filtered as administrivia. If necessary, we could beef up that filter, and add RFC 2369 and 2919 header fields to the filter to catch the actual "DoS" posts. The RFC field filter wouldn't do anything if the high-volume list doesn't use those fields, of course.
But even if the bad actor manages to get the victim subscribed to the high-volume list, most lists nowadays require list membership to post. The bad actor could try to reverse-subscribe the high-volume list to the victim list (but now the bad actor runs into the barriers described above again), so if you're worried about this a lot, you can set the subscription policy at the victim list to confirm and approve. If you're worried about this a little, you can set the victim list's new member policy to 'moderate', which catches the garden variety butthead as well as the sophisticated troll.
I haven't heard of an individual being attacked in this way for many years, and I've never heard of a list attacked this way. The occasional attack now uses the subscription process itself, by getting thousands of lists to send confirmation tokens to the victim. I suspect actually getting the victim subscribed is just not worth the bad actor's effort to hack or social engineer the confirmation process. I figure XKCD 538 applies -- instead trying to hack multiple lists, they'll just use a big pipe-wrench (eg, hire a botnet).
Steve
![](https://secure.gravatar.com/avatar/2d8b084fbf3bb480d8a3b6233b498f4f.jpg?s=120&d=mm&r=g)
Discussion based lists tend to require subscription to post, but many support lists don't. Though I suppose the attacker would need to get subscribed to the support list to act on the confirmation message, which makes that path harder and less likely.
One solution would be to add a 'spam' filter to the 'victim' list to look to see if the message is coming from a mailing list and then either hold or reject them, maybe with a white listing before if there are any lists it is suppose to be subscribed to.
participants (3)
-
Alessandro Vesely
-
Richard Damon
-
Stephen J. Turnbull