So, I updated, clarified, and relatively unified/standardized the language.
Basic idea is if one is subscribed to BALUG-Talk and/or BALUG-Admin, but not BALUG-Announce, one gets subscribed to BALUG-announce ... but there's also an exception process if one really doesn't want that.
Various pros/cons compared to, e.g. "umbrella list" - went over that many moons ago, and opted to *not* do "umbrella list" - and I still think that's generally better (more flexible, etc., but adds wee bit 'o code/work to (semi-)automate the handling without doing "umbrella list".
Anyway, many moons ago, I semi-automated it. The only part that is likely to remain manual, is if anyone requests to be added to (or removed from) exception - fairly simple, their email address(es) get added to (or removed from) a file. The other bits thus far have been semi-manual/semi-automated (I probably should've further automated it long ago ... but not it's getting much closer to being fully automated - except for folks requesting change of their exception status).
Basic idea also, with the automation, will probably code it up to check daily, but also include a bit 'o hysteresis - so we don't catch user just as they're manually subscribing, and "race" and beat 'em to adding 'em to BALUG-Announce (that would be kind'a impolite and confusing). So, I was thinkin', code would check, upon finding candidates to add, note that ... and once so noted information is >~=48 hours old, upon subsequent checks, with situation otherwise being still the same, *then*, they'd get automagically added.
Oh, also updated those relevant URLs from lists.balug.org to temp.balug.org. So, locations of updated text and web pages, etc. There are the list info pages, directly under (one link level beyond): https://temp.balug.org/cgi-bin/mailman/listinfo
There's old link location, and newer, all same content: http://www.balug.org/lists/balug-announce-do-not-auto-add.html https://temp.balug.org/lists/balug-announce-do-not-auto-add.html and will be in future: https://lists.balug.org/lists/balug-announce-do-not-auto-add.html I'm thinking eventually canonicalize upon the one above ... but we're not there yet (and then also then have: https://www.balug.org/lists/balug-announce-do-not-auto-add.html redirect to that same canonical - also future ).
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Basic idea is if one is subscribed to BALUG-Talk and/or BALUG-Admin, but not BALUG-Announce, one gets subscribed to BALUG-announce ... but there's also an exception process if one really doesn't want that.
I continue to think this is a blunder.
Autosubscribing people to mailing lists is going to get BALUG in trouble, one day. It[1] is widely considered an egregious violation of netiquette and gets domains on DNS blocklists.
[1] 'It' meaning subscribing anyone to an MLM without the standard three-way confirmation process or close equivalent.
Well, reasonable opinions will reasonably differ. :-) Appreciate the opinions and critique, etc. Maybe also tightening up the hysteresis (delay) time, from, e.g. 2 days, to ... something more like 2 hours, would also help.
The additional introductory text sent also makes things fairly clear too ... and it's also on the list pages, and was well covered on the lists long ago. I suppose the only way one could never get exposed to that text would be if the subscription was done entirely via email - they it may be fair bit more of a surprise. But kind'a unlikely folks would do that, as most all the pointers start with the web pages. Unless folks happen to know the lists are Mailman, and what those conventions are for interacting with it via email ... but even then to find the post addresses to be able to figure out the -request addresses, where does one see the posting addresses? On the same web page that's used for subscribing - and has the relevant text there.
Anyway, the boiler plate additional text I've been sending when "auto-subscribing" folks ... and it can probably do with at least some bit of update (haven't had anyone yet to get auto-subscribed since we've added the BALUG-Test list): $ cat add_to_announce.txt Per BALUG's policy,
If an e-mail address is subscribed to one or more BALUG lists other than BALUG-Announce, but not subscribed to BALUG-Announce, we may subscribe the e-mail address to BALUG-Announce.
In general, if one is subscribed to any of BALUG's lists, one should also be subscribed to BALUG-Announce (most notably to receive important BALUG announcements which may not be sent to BALUG lists other than BALUG-Announce).
If for some reason one doesn't want that to happen, see: http://www.balug.org/lists/balug-announce-do-not-auto-add.html
references: http://www.balug.org/ http://lists.balug.org/listinfo.cgi/balug-announce-balug.org http://lists.balug.org/listinfo.cgi/balug-talk-balug.org http://lists.balug.org/listinfo.cgi/balug-admin-balug.org http://lists.balug.org/pipermail/balug-admin-balug.org/2007-December/000470.... http://lists.balug.org/pipermail/balug-talk-balug.org/2007-December/004105.h... $
Anyway, I should update that boiler plate text before the next time it's used.
From: "Rick Moen" rick@linuxmafia.com Subject: Re: [BALUG-Admin] "automatically" subscribe to BALUG-Announce if ... - various descriptive updates, etc. Date: Wed, 16 Aug 2017 10:45:02 -0700
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Basic idea is if one is subscribed to BALUG-Talk and/or BALUG-Admin, but not BALUG-Announce, one gets subscribed to BALUG-announce ... but there's also an exception process if one really doesn't want that.
I continue to think this is a blunder.
Autosubscribing people to mailing lists is going to get BALUG in trouble, one day. It[1] is widely considered an egregious violation of netiquette and gets domains on DNS blocklists.
[1] 'It' meaning subscribing anyone to an MLM without the standard three-way confirmation process or close equivalent.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
The additional introductory text sent also makes things fairly clear too ... and it's also on the list pages, and was well covered on the lists long ago.
When a system gets nominated for inclusion on a DNSBL for failing to confirm the user's desire to subscribe, it'll be from someone who simply didn't read those advisories -- or read them but then forgot, or read them but got pissy and didn't care.
Then, the DNSBL will do some verification like what the reporting user suggested. ('I subscribed to balug-talk, and without confirmation ended up on balug-announce.') Et voila, your IP is listed in the DNSBL, and potentially also in trouble with its hosting provider.
https://www.spamhaus.org/faq/section/Marketing%20FAQs#15
Q: What is "confirmed opt-in" (COI)?
A: Confirmed opt-in (COI) is a process by which a mailing list owner verifies that an opt-in request did in fact come from the owner of the email address and was therefore not spoofed, forged, typo'd or otherwise fraudulently subscribed. The essence of COI is that the subscriber MUST respond affirmatively to the initial message sent to their e-mail address or else they are NOT added to the list. COI ensures that all addresses are added to the list legitimately and only with the owner's permission. Note that simply sending a "welcome" message where the e-mail address owner is subscribed unless they take specific action in order to stop the mail is a form of "opt out" and does not fulfill the "opt in" standard required by Spamhaus' users.
For the user subscribing to a mailing list, COI is as simple as replying to an automated confirmation e-mail or clicking a link in an automated confirmation e-mail. In professional list management software, COI utilizes a unique token (sort of like a single-use password) passed from the list software to the would-be subscriber, and the subscriber returns the token to confirm their permission. Such "closed-loop confirmation" has been Best Current Practice in mailing list management software since about 1996. Software handles all the token transactions and maintains logs to document each and every subscription.
https://www.spamhaus.org/whitepapers/mailinglists/
Unconfirmed Opt-In [...] In the event of a "spam" accusation:
The Bulk Email Sender has no verifiable proof that the recipient consented to be placed on the bulk mailing list and is therefore liable for having sent Unsolicited Bulk Email a/k/a Spam. Action can be taken against the Sender. The sending of Unsolicited Bulk Email is against all ISP Terms of Service worldwide, is illegal in many countries, and is against Spamhaus SBL policy.
https://www.scconsult.com/bill/dnsblhelp.html
How to control spam without blacklists getting involved [...]
o Use meticulous list management practices. [...] o Do not add an address to any list until you have proof that someone who reads the mail sent to that address wants to have the address added to the list. [...]
The core principles behind good mailing list management are:
o Mailings should be fully consensual o No one should ever have to unsubscribe from mailings to which they did not knowingly subscribe. o List owners should always know for sure whether an address owner actually wishes to be subscribed or not.
You feel we comply with those three principles through advisories. The problem is that it's very easy for any user to create a case that we don't -- for lack of the confirmation step as to balug-announce. And then your IP is on the list of spam hosts.
_Or_, even without a complaint from a BALUG participant, one such DNSBL happens to test BALUG mailing lists with one of its spam trap email addresses:
https://sendgrid.com/blog/avoiding-email-blacklists/
How Do Email Blacklists Work?
Most blacklists use networks of spam trap email addresses [link] to identify IP addresses and domains that send unwanted commercial email. Spam traps are email addresses that the operator believes should not be receiving email from marketers, or any other source for that matter. [...]
Reducing Your Risk
There are several things that can be done to reduce this exposure:
Confirmed opt-in: Before adding a new recipient address to your active mailing list(s),send a confirmation email.
I suppose the only way one could never get exposed to that text would be if the subscription was done entirely via email - they it may be fair bit more of a surprise.
That's not the point, Michael. The point is that mailing list hosts that don't confirm opt-in tend to get put on DNSBLs and considered to exhibit spammer behaviour, and in some cases get in trouble with their hosting. No amount of saying 'But our documentation _warns_ we do this' will change that.
Good points as always.
Despite opting in and/or double/confirmed opting in, etc., some folks will sometimes be idiots or forget or whatever and claim something is spam, when it's not. I've certainly seen that on much larger mailing lists, e.g. >>1,000,000 subscribers. And yes, such does happen, and then have to deal with some blacklist or ISP or the like - but generally fairly easy and relatively quick to get squared away - though it's still a bit of a nuisance. But even umbrella list configurations have some of those same hazards.
To cover it yet a bit more fully :-) ... could also tweak the text in the confirmation email, and on the confirmation web page. That'd cover it yet more fully. And yes, some folks will still be idiots, and not read what they're doing or agreeing to.
Likewise could also add the information to the BALUG-Announce unsubscribe information.
Nearly 10 years the policy has been in place, over 800 subscribers, and thus far hasn't been an issue. >>1,000,000 subscribers, and even perfectly run, there will be some problematic subscribers.
From: "Rick Moen" rick@linuxmafia.com Subject: Re: [BALUG-Admin] "automatically" subscribe to BALUG-Announce if ... - various descriptive updates, etc. Date: Thu, 17 Aug 2017 03:19:06 -0700
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
The additional introductory text sent also makes things fairly clear too ... and it's also on the list pages, and was well covered on the lists long ago.
When a system gets nominated for inclusion on a DNSBL for failing to confirm the user's desire to subscribe, it'll be from someone who simply didn't read those advisories -- or read them but then forgot, or read them but got pissy and didn't care.
Then, the DNSBL will do some verification like what the reporting user suggested. ('I subscribed to balug-talk, and without confirmation ended up on balug-announce.') Et voila, your IP is listed in the DNSBL, and potentially also in trouble with its hosting provider.
https://www.spamhaus.org/faq/section/Marketing%20FAQs#15
Q: What is "confirmed opt-in" (COI)?
A: Confirmed opt-in (COI) is a process by which a mailing list owner verifies that an opt-in request did in fact come from the owner of the email address and was therefore not spoofed, forged, typo'd or otherwise fraudulently subscribed. The essence of COI is that the subscriber MUST respond affirmatively to the initial message sent to their e-mail address or else they are NOT added to the list. COI ensures that all addresses are added to the list legitimately and only with the owner's permission. Note that simply sending a "welcome" message where the e-mail address owner is subscribed unless they take specific action in order to stop the mail is a form of "opt out" and does not fulfill the "opt in" standard required by Spamhaus' users.
For the user subscribing to a mailing list, COI is as simple as replying to an automated confirmation e-mail or clicking a link in an automated confirmation e-mail. In professional list management software, COI utilizes a unique token (sort of like a single-use password) passed from the list software to the would-be subscriber, and the subscriber returns the token to confirm their permission. Such "closed-loop confirmation" has been Best Current Practice in mailing list management software since about 1996. Software handles all the token transactions and maintains logs to document each and every subscription.
https://www.spamhaus.org/whitepapers/mailinglists/
Unconfirmed Opt-In [...] In the event of a "spam" accusation:
The Bulk Email Sender has no verifiable proof that the recipient consented to be placed on the bulk mailing list and is therefore liable for having sent Unsolicited Bulk Email a/k/a Spam. Action can be taken against the Sender. The sending of Unsolicited Bulk Email is against all ISP Terms of Service worldwide, is illegal in many countries, and is against Spamhaus SBL policy.
https://www.scconsult.com/bill/dnsblhelp.html
How to control spam without blacklists getting involved [...]
o Use meticulous list management practices. [...] o Do not add an address to any list until you have proof that someone who reads the mail sent to that address wants to have the address added to the list. [...]
The core principles behind good mailing list management are:
o Mailings should be fully consensual o No one should ever have to unsubscribe from mailings to which they did not knowingly subscribe. o List owners should always know for sure whether an address owner actually wishes to be subscribed or not.
You feel we comply with those three principles through advisories. The problem is that it's very easy for any user to create a case that we don't -- for lack of the confirmation step as to balug-announce. And then your IP is on the list of spam hosts.
_Or_, even without a complaint from a BALUG participant, one such DNSBL happens to test BALUG mailing lists with one of its spam trap email addresses:
https://sendgrid.com/blog/avoiding-email-blacklists/
How Do Email Blacklists Work?
Most blacklists use networks of spam trap email addresses [link] to identify IP addresses and domains that send unwanted commercial email. Spam traps are email addresses that the operator believes should not be receiving email from marketers, or any other source for that matter. [...]
Reducing Your Risk
There are several things that can be done to reduce this exposure:
Confirmed opt-in: Before adding a new recipient address to your active mailing list(s),send a confirmation email.
I suppose the only way one could never get exposed to that text would be if the subscription was done entirely via email - they it may be fair bit more of a surprise.
That's not the point, Michael. The point is that mailing list hosts that don't confirm opt-in tend to get put on DNSBLs and considered to exhibit spammer behaviour, and in some cases get in trouble with their hosting. No amount of saying 'But our documentation _warns_ we do this' will change that.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
To cover it yet a bit more fully :-) ... could also tweak the text in the confirmation email, and on the confirmation web page. That'd cover it yet more fully. And yes, some folks will still be idiots, and not read what they're doing or agreeing to.
Likewise could also add the information to the BALUG-Announce unsubscribe information.
Which would not actually address the fundamental problem.
Nearly 10 years the policy has been in place, over 800 subscribers, and thus far hasn't been an issue.
Well, I wish BALUG continued good luck.
Me, I'd not feel ethically right, doing that.