BerkeleyLUG Google Groups (list) - backup(s) & ... (possibly) migrate to ...
17 views
Skip to first unread message
Michael Paoli
Apr 3, 2021, 4:29:29 PM4/3/21
to BerkeleyLUG
Submitted for your consideration ...
So, Google Groups, and BerkeleyLUG (and the Pi.BerkeleyLUG SIG thereof)
having list on Google Groups ... folks have differing opinions about if
it ought be/stay there, or move elsewhere (e.g. self-hosted list, such
as on mailman/mailman2/mailman3).
So ... your thoughts?
And ... list admin's can backup the existing Google Groups data,
and in form that can presumably be reasonably migrated to
something else. Anyway, I have backed that up (and ought turn it
into a regular occurrence - though it may or may not be feasible to
fully automate that).
And also, if we wanted to, e.g. change that instead to a mailman managed
list (already have other mailman hosted lists on the same host that hosts
http[s]://[www.][pi.]berkeleylug.com/), could, e.g. migrate that to
mailman. That would put it more in "our" control (and more out of Google's
control / out from under Google's thumb), and make it easier to, e.g.
backup. In any case, the list postings are public, so at least that part
of it probably doesn't make a huge difference (at least if it also gets
backed up at least once in a while) ... but other considerations might
be more significant.
Anyway, so ... what say y'all? Should we maybe setup a
survey or vote? (or will only like about 2 or 3 folks on the list
vote anyway?).
So, Google Groups, and BerkeleyLUG (and the Pi.BerkeleyLUG SIG thereof)
having list on Google Groups ... folks have differing opinions about if
it ought be/stay there, or move elsewhere (e.g. self-hosted list, such
as on mailman/mailman2/mailman3).
So ... your thoughts?
And ... list admin's can backup the existing Google Groups data,
and in form that can presumably be reasonably migrated to
something else. Anyway, I have backed that up (and ought turn it
into a regular occurrence - though it may or may not be feasible to
fully automate that).
And also, if we wanted to, e.g. change that instead to a mailman managed
list (already have other mailman hosted lists on the same host that hosts
http[s]://[www.][pi.]berkeleylug.com/), could, e.g. migrate that to
mailman. That would put it more in "our" control (and more out of Google's
control / out from under Google's thumb), and make it easier to, e.g.
backup. In any case, the list postings are public, so at least that part
of it probably doesn't make a huge difference (at least if it also gets
backed up at least once in a while) ... but other considerations might
be more significant.
Anyway, so ... what say y'all? Should we maybe setup a
survey or vote? (or will only like about 2 or 3 folks on the list
vote anyway?).
Christian Peeples
Apr 3, 2021, 8:10:08 PM4/3/21
to berke...@googlegroups.com
Michael:
It does not make much difference to me. My major concern is that I would not want to make too much extra work for you. I do not think anything we put in the list is all that confidential or sensitive.
-- Chris Peeples --
(c) +1-510-851-0968
(c) +1-510-851-0968
--
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/20210403132927.55661dmp4zqq3rj4%40webmail.rawbw.com.
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/20210403132927.55661dmp4zqq3rj4%40webmail.rawbw.com.
goossbears
Apr 6, 2021, 12:35:12 PM4/6/21
to BerkeleyLUG
On Saturday, April 3, 2021 at 1:29:29 PM UTC-7 michae...@cal.berkeley.edu wrote:
And ... list admin's can backup the existing Google Groups data,
and in form that can presumably be reasonably migrated to
something else. Anyway, I have backed that up (and ought turn it
into a regular occurrence - though it may or may not be feasible to
fully automate that).
And also, if we wanted to, e.g. change that instead to a mailman managed
list (already have other mailman hosted lists on the same host that hosts
http[s]://[www.][pi.]berkeleylug.com/), could, e.g. migrate that to
mailman. That would put it more in "our" control (and more out of Google's
control / out from under Google's thumb), and make it easier to, e.g.
backup. In any case, the list postings are public, so at least that part
of it probably doesn't make a huge difference (at least if it also gets
backed up at least once in a while) ... but other considerations might
be more significant.
Anyway, so ... what say y'all?
Have some mixed feelings specifically about migrating BerkeleyLUG's Google Groups-managed mailing-list to a specific mailman-managed mailing-list.
How so?
Pluses/++
+ Moving the mailing-list "more out of Google's control / out from under Google's thumb" is likely a Very Good Thing :-) Already know of at least one other person physically attending live BerkeleyLUG meetups in the past who isn't at all very keen of being under the ever-encroaching aegis of Google's data-mining Bandwagon! :-\
+ While the BerkeleyLUG Google Group's "list postings are [presumably] public", it very much seems to me at least, IMHO, that Mailman-managed mailing-list archives are much more readily and *easily accessible* for all than are the same for Google Groups, e.g., it appears to be much easier to provide a direct link to a particular Mailman mailing-list posting to access from someone without a Google account than a posting to Google Groups.
Minuses/--
- As the renown adage goes; "If It Ain't Broke, Don't Fix It!"
Besides The Google Factor issue as mentioned above, What other specific problems/"brokenness" are there with Google Groups that a mailman-managed list can definitely fix -- but without the latter introducing its *own* unique problems??
- Timing
Having live BerkeleyLUG meetups, IMNSHO, is so much better than the virtual meetups via Jit.si Meet for a number of reasons which won't go into further detail here and now.
How so?
Pluses/++
+ Moving the mailing-list "more out of Google's control / out from under Google's thumb" is likely a Very Good Thing :-) Already know of at least one other person physically attending live BerkeleyLUG meetups in the past who isn't at all very keen of being under the ever-encroaching aegis of Google's data-mining Bandwagon! :-\
+ While the BerkeleyLUG Google Group's "list postings are [presumably] public", it very much seems to me at least, IMHO, that Mailman-managed mailing-list archives are much more readily and *easily accessible* for all than are the same for Google Groups, e.g., it appears to be much easier to provide a direct link to a particular Mailman mailing-list posting to access from someone without a Google account than a posting to Google Groups.
Minuses/--
- As the renown adage goes; "If It Ain't Broke, Don't Fix It!"
Besides The Google Factor issue as mentioned above, What other specific problems/"brokenness" are there with Google Groups that a mailman-managed list can definitely fix -- but without the latter introducing its *own* unique problems??
- Timing
Having live BerkeleyLUG meetups, IMNSHO, is so much better than the virtual meetups via Jit.si Meet for a number of reasons which won't go into further detail here and now.
It's entirely possible that more local people will want to participate in live BerkeleyLUG meetups when it's entirely permissible to do -- even including those on the current Google Groups mailing-list -- rather than virtually participate via Jit.si meet. Therefore ISTM that as far as keeping and attracting more active BerkeleyLUG participation given current predictions of live meetup venue reopenings, there is no impending urgency at all to initiate a potential switch from a Google Groups mailing-list to one managed by mailman.
---
Of course, the big Million Dollar Question then is When will the COVID-19 Pandemic subside enough to finally hold live meetups??
As we can all see from the California's COVID-19 Pandemic-related covid19.ca.gov 'Blueprint for a Safer Economy' links https://covid19.ca.gov/safer-economy/#county-status , https://covid19.ca.gov/safer-economy/ and https://covid19.ca.gov/industry-guidance/#restaurants, Alameda County remains in the Orange/Moderate Tier.
Even when the county reaches the Yellow/Minimal Tier, possible in-person BerkeleyLUG venues will only be limited to ...
* Indoor with modifications
* Capacity must be limited to 50%
Green Tier restriction-loosenings better allowing live meetups by Summertime??
In any case and while all of us may expect and hope that we'll be able to "mark our independence from this virus" on July 4th of this Summer -- as President Joe Biden specifically stated in his 'Speech On Coronavirus, 1 Year Into Pandemic' https://www.npr.org/sections/coronavirus-live-updates/2021/03/11/975420676/biden-to-address-the-nation-marking-1-year-of-coronavirus-pandemic -- it's also entirely conceivable that lingering effects of the COVID-19 Pandemic could extend all the way up to or beyond Labor Day Weekend of this year, and thus directly affect the timeline of full business reopenings including venues for live BerkeleyLUG meetups :-\
---
Of course, the big Million Dollar Question then is When will the COVID-19 Pandemic subside enough to finally hold live meetups??
As we can all see from the California's COVID-19 Pandemic-related covid19.ca.gov 'Blueprint for a Safer Economy' links https://covid19.ca.gov/safer-economy/#county-status , https://covid19.ca.gov/safer-economy/ and https://covid19.ca.gov/industry-guidance/#restaurants, Alameda County remains in the Orange/Moderate Tier.
Even when the county reaches the Yellow/Minimal Tier, possible in-person BerkeleyLUG venues will only be limited to ...
* Indoor with modifications
* Capacity must be limited to 50%
Green Tier restriction-loosenings better allowing live meetups by Summertime??
In any case and while all of us may expect and hope that we'll be able to "mark our independence from this virus" on July 4th of this Summer -- as President Joe Biden specifically stated in his 'Speech On Coronavirus, 1 Year Into Pandemic' https://www.npr.org/sections/coronavirus-live-updates/2021/03/11/975420676/biden-to-address-the-nation-marking-1-year-of-coronavirus-pandemic -- it's also entirely conceivable that lingering effects of the COVID-19 Pandemic could extend all the way up to or beyond Labor Day Weekend of this year, and thus directly affect the timeline of full business reopenings including venues for live BerkeleyLUG meetups :-\
---
- Costs
There may be minor (hopefully!) costs from switching over from the free mailing-list managed by Google Groups to costs specific that of sole mailman mailing-list management. Also, there are potential and additional future costs in upgrading local hardware (HW resources such as memory, local backup capability, machine availability/uptime, ...etc.) as well as administrative "costs" (i.e., administrative time, effort, troubleshooting) when hosting and managing mailman as compared to the same with Google Groups.
There may be minor (hopefully!) costs from switching over from the free mailing-list managed by Google Groups to costs specific that of sole mailman mailing-list management. Also, there are potential and additional future costs in upgrading local hardware (HW resources such as memory, local backup capability, machine availability/uptime, ...etc.) as well as administrative "costs" (i.e., administrative time, effort, troubleshooting) when hosting and managing mailman as compared to the same with Google Groups.
Given all of the above, would guess that unless Michael P and/or others are particularly deadset on doing a full mailing-list switchover from Google Groups to mailman in an ASAP fashion, in balance, it's probably best to hold off on such a switchover.
-Aaron
-Aaron
Michael Paoli
Apr 6, 2021, 8:55:34 PM4/6/21
to BerkeleyLUG
> From: goossbears <acoh...@gmail.com>
> Subject: Re: BerkeleyLUG Google Groups (list) - backup(s) & ...
> (possibly) migrate to ...
> Date: Tue, 6 Apr 2021 09:35:12 -0700 (PDT)
Actually looks helluva lot easier than migrating BALUG's lists off
of DreamHost.com was - as DreamHost.com made extricating data a very
painful process. Comparatively, getting the data off of Google Groups
is quite easy and relatively fast.
And one of the benefits of switching over would be better backups and
general comparative ease-of-maintenance. Notably Google Groups is
essentially a one-off, needing it's own separate procedures and
interfaces for backing up, managing, etc., and they also don't well
lend themselves to automation. So ... day-to-day, month-to-month,
etc., it is and generally continues to be an ongoing
bit more work than if the lists were moved over.
Whereas all the other LUG lists on that host where the web sites are
hosted, are all already using mailman, so, the incremental on having
"one more list" there, is quite small. And would also benefit from
the regular backups that routinely happen for that host, etc.
And ... timing?
Well, currently, the lists are using mailman2.
mailman3, but not mailman2, is supported on Debian 11 bullseye, which
will likely be released about mid-year +- a few months. So, a
"least effort" migration of the BerkeleyLUG Google Groups list would
likely look like:
o existing lists migrate to mailman3
o host is upgraded to Debian 11 bullseye
o (the above happen regardless of what happens with the BerkeleyLUG list)
o migrate BerkeleyLUG list from Google Groups to mailman3
Anyway, timing-wise, that would probably put it at 2021H2,
or maybe even later.
> Subject: Re: BerkeleyLUG Google Groups (list) - backup(s) & ...
> (possibly) migrate to ...
> Date: Tue, 6 Apr 2021 09:35:12 -0700 (PDT)
> - Costs
> There may be minor (hopefully!) costs from switching over from the free
> mailing-list managed by Google Groups to costs specific that of sole
> mailman mailing-list management. Also, there are potential and additional
> future costs in upgrading local hardware (HW resources such as memory,
> local backup capability, machine availability/uptime, ...etc.) as well as
> administrative "costs" (i.e., administrative time, effort, troubleshooting)
> when hosting and managing mailman as compared to the same with Google
> Groups.
>
>
> Given all of the above, would guess that unless Michael P and/or others are
> particularly deadset on doing a full mailing-list switchover from Google
> Groups to mailman in an ASAP fashion, in balance, it's probably best to
> hold off on such a switchover.
>
> -Aaron
Well, there would be bit 'o work switching over, but not all that much.
> There may be minor (hopefully!) costs from switching over from the free
> mailing-list managed by Google Groups to costs specific that of sole
> mailman mailing-list management. Also, there are potential and additional
> future costs in upgrading local hardware (HW resources such as memory,
> local backup capability, machine availability/uptime, ...etc.) as well as
> administrative "costs" (i.e., administrative time, effort, troubleshooting)
> when hosting and managing mailman as compared to the same with Google
> Groups.
>
>
> Given all of the above, would guess that unless Michael P and/or others are
> particularly deadset on doing a full mailing-list switchover from Google
> Groups to mailman in an ASAP fashion, in balance, it's probably best to
> hold off on such a switchover.
>
> -Aaron
Actually looks helluva lot easier than migrating BALUG's lists off
of DreamHost.com was - as DreamHost.com made extricating data a very
painful process. Comparatively, getting the data off of Google Groups
is quite easy and relatively fast.
And one of the benefits of switching over would be better backups and
general comparative ease-of-maintenance. Notably Google Groups is
essentially a one-off, needing it's own separate procedures and
interfaces for backing up, managing, etc., and they also don't well
lend themselves to automation. So ... day-to-day, month-to-month,
etc., it is and generally continues to be an ongoing
bit more work than if the lists were moved over.
Whereas all the other LUG lists on that host where the web sites are
hosted, are all already using mailman, so, the incremental on having
"one more list" there, is quite small. And would also benefit from
the regular backups that routinely happen for that host, etc.
And ... timing?
Well, currently, the lists are using mailman2.
mailman3, but not mailman2, is supported on Debian 11 bullseye, which
will likely be released about mid-year +- a few months. So, a
"least effort" migration of the BerkeleyLUG Google Groups list would
likely look like:
o existing lists migrate to mailman3
o host is upgraded to Debian 11 bullseye
o (the above happen regardless of what happens with the BerkeleyLUG list)
o migrate BerkeleyLUG list from Google Groups to mailman3
Anyway, timing-wise, that would probably put it at 2021H2,
or maybe even later.
Rick Moen
May 6, 2021, 6:50:23 PM5/6/21
to BerkeleyLUG
Quoting goossbears (acoh...@gmail.com):
> Have some mixed feelings specifically about migrating BerkeleyLUG's Google
> Groups-managed mailing-list to a specific mailman-managed mailing-list.
>
> How so?
>
> Pluses/++
> + Moving the mailing-list "more out of Google's control / out from under
> Google's thumb" is likely a Very Good Thing :-) Already know of at least
> one other person physically attending live BerkeleyLUG meetups in the past
> who isn't at all very keen of being under the ever-encroaching aegis of
> Google's data-mining Bandwagon! :-\
As a nuance to this, Auntie Goog has always left it _possible_ to join a
> Have some mixed feelings specifically about migrating BerkeleyLUG's Google
> Groups-managed mailing-list to a specific mailman-managed mailing-list.
>
> How so?
>
> Pluses/++
> + Moving the mailing-list "more out of Google's control / out from under
> Google's thumb" is likely a Very Good Thing :-) Already know of at least
> one other person physically attending live BerkeleyLUG meetups in the past
> who isn't at all very keen of being under the ever-encroaching aegis of
> Google's data-mining Bandwagon! :-\
Google Group from a non-GMail subscription address, but the way to do
that is very non-obvious and findable by only the rather determined.
In consequence, even on a mailing list like this one that skews heavily
geekish, I'm pretty sure there are vanishingly few non-GMail
subscribers. Dunno, are there even any other than me and Michael?
When I join a _typical_ Google Group, I observe over time that I am
literally the only non-GMail contributor.
And that's Auntie Goog in a nutshell: They act so that they can
honestly claim to support open, commodity standards, and don't
absolutely 100% prevent people from asserting moderate amounts of
computing independence. It just 'ends up' that doing that is notably
difficult. (Same thing with trying to use a regular IMAP/SMTP client
mail program with GMail in place of Auntie Goog's proprietary hosted
webmail client that gives them such a wealth of real-time datamining
data: Technically it's supported. Sort of? But you'll tear your hair
out dealing with the obstacles.)
Auntie Goog knows that people are just damned lazy, and they'll gladly
put up with something that sort-of does most of what they want,
especially if it is perceivable as 'free', and will just ignore
limitations, lock-in, etc.
> Of course, the big Million Dollar Question then is When will the COVID-19
> Pandemic subside enough to finally hold live meetups??
CABAL is resuming with me hosting a big BBQ for the fellow vaccinated,
and we'll also have the live attendees able to interact to some degree
with remote ones via http://meet.jit.si/CABAL .
http://linuxmafia.com/pipermail/conspire/2021-May/011587.html
Christian Peeples
May 6, 2021, 9:46:06 PM5/6/21
to berke...@googlegroups.com
Rick:
I’m on the list with a Yahoo account.
-- Chris Peeples --
(c) +1-510-851-0968
(c) +1-510-851-0968
--
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/20210506225019.GH18306%40linuxmafia.com.
Michael Paoli
May 6, 2021, 10:47:05 PM5/6/21
to BerkeleyLUG
> From: "'Christian Peeples' via BerkeleyLUG" <berke...@googlegroups.com>
> Rick:
> I’m on the list with a Yahoo account.
> -- Chris Peeples --
> (c) +1-510-851-0968
>
> On Thursday, May 6, 2021, 03:50:23 PM PDT, Rick Moen
> <ri...@linuxmafia.com> wrote:
>
> Quoting goossbears (acoh...@gmail.com):
>
>> Have some mixed feelings specifically about migrating BerkeleyLUG's Google
>> Groups-managed mailing-list to a specific mailman-managed mailing-list.
>>
>> How so?
>>
>> Pluses/++
>> + Moving the mailing-list "more out of Google's control / out from under
>> Google's thumb" is likely a Very Good Thing :-) Already know of at least
>> one other person physically attending live BerkeleyLUG meetups in the past
>> who isn't at all very keen of being under the ever-encroaching aegis of
>> Google's data-mining Bandwagon! :-\
>
> As a nuance to this, Auntie Goog has always left it _possible_ to join a
> Google Group from a non-GMail subscription address, but the way to do
> that is very non-obvious and findable by only the rather determined.
> In consequence, even on a mailing list like this one that skews heavily
> geekish, I'm pretty sure there are vanishingly few non-GMail
> subscribers. Dunno, are there even any other than me and Michael?
Well ... from the last backup/dump/export I did not too long ago ...
# ls -o --full-time *.zip
-r-------- 1 berklug 29000081 2021-04-03 20:14:51.000000000 +0000
takeout-20210403T200029Z-001.zip
# unzip -p *.zip 'Takeout/Groups/googlegroups.com/owned
groups/berke...@googlegroups.com/members.csv' | awk -F, '{print
$2;}' | sed -e '/@/!d;s/^.*@//' | tr A-Z a-z | sort | uniq -c | sort
-bnr
118 gmail.com
5 yahoo.com
2 berkeley.edu
1 ucsc.edu
1 subspacefield.org
1 stilen.com
1 softwarepeople.us
1 sbcglobal.net
1 roguehorse.com
1 princessleia.com
1 plasmabat.com
1 pacbell.net
1 ocf.berkeley.edu
1 netisland.net
1 mac.com
1 linuxmafia.com
1 fonz.net
1 esamir.com
1 enomem.net
1 earthlink.net
1 comcast.net
1 cal.berkeley.edu
# unzip -p *.zip 'Takeout/Groups/googlegroups.com/owned
groups/berke...@googlegroups.com/members.csv' | wc -l
145
# expr 145 - 118
27
#
... although also, many of those domains besides just gmail.com are managed
by Google's Gmail ... because, well, folks handed 'em over ...
like berkeley.edu - and probably all subdomains thereunder.
> Subject: Re: BerkeleyLUG Google Groups (list) - backup(s) & ...
> (possibly) migrate to ...
> Date: Fri, 7 May 2021 01:45:59 +0000 (UTC)
> (possibly) migrate to ...
> Rick:
> I’m on the list with a Yahoo account.
> -- Chris Peeples --
> (c) +1-510-851-0968
>
> On Thursday, May 6, 2021, 03:50:23 PM PDT, Rick Moen
> <ri...@linuxmafia.com> wrote:
>
> Quoting goossbears (acoh...@gmail.com):
>
>> Have some mixed feelings specifically about migrating BerkeleyLUG's Google
>> Groups-managed mailing-list to a specific mailman-managed mailing-list.
>>
>> How so?
>>
>> Pluses/++
>> + Moving the mailing-list "more out of Google's control / out from under
>> Google's thumb" is likely a Very Good Thing :-) Already know of at least
>> one other person physically attending live BerkeleyLUG meetups in the past
>> who isn't at all very keen of being under the ever-encroaching aegis of
>> Google's data-mining Bandwagon! :-\
>
> As a nuance to this, Auntie Goog has always left it _possible_ to join a
> Google Group from a non-GMail subscription address, but the way to do
> that is very non-obvious and findable by only the rather determined.
> In consequence, even on a mailing list like this one that skews heavily
> geekish, I'm pretty sure there are vanishingly few non-GMail
> subscribers. Dunno, are there even any other than me and Michael?
# ls -o --full-time *.zip
-r-------- 1 berklug 29000081 2021-04-03 20:14:51.000000000 +0000
takeout-20210403T200029Z-001.zip
# unzip -p *.zip 'Takeout/Groups/googlegroups.com/owned
groups/berke...@googlegroups.com/members.csv' | awk -F, '{print
$2;}' | sed -e '/@/!d;s/^.*@//' | tr A-Z a-z | sort | uniq -c | sort
-bnr
118 gmail.com
5 yahoo.com
2 berkeley.edu
1 ucsc.edu
1 subspacefield.org
1 stilen.com
1 softwarepeople.us
1 sbcglobal.net
1 roguehorse.com
1 princessleia.com
1 plasmabat.com
1 pacbell.net
1 ocf.berkeley.edu
1 netisland.net
1 mac.com
1 linuxmafia.com
1 fonz.net
1 esamir.com
1 enomem.net
1 earthlink.net
1 comcast.net
1 cal.berkeley.edu
# unzip -p *.zip 'Takeout/Groups/googlegroups.com/owned
groups/berke...@googlegroups.com/members.csv' | wc -l
145
# expr 145 - 118
27
#
... although also, many of those domains besides just gmail.com are managed
by Google's Gmail ... because, well, folks handed 'em over ...
like berkeley.edu - and probably all subdomains thereunder.
goossbears
May 7, 2021, 1:29:49 AM5/7/21
to BerkeleyLUG
On Thursday, May 6, 2021 at 6:46:06 PM UTC-7 Chris Peeples wrote:
Rick:I’m on the list with a Yahoo account.-- Chris Peeples --
(c) +1-510-851-0968
Chris and others,
From what I've been reading on other mailing lists, not all is sweet-smelling roses as far as migrating mailing-list(s) to Mailman using Yahoo.com addresses.
A big thorn with using Yahoo.com is its "DMARC badness" as Rick put it in his conspire mailing-list post '(forw) [skeptic] me.com is shooting Skeptic subscribers in the foot w/DMARC (was: I have questions...)' at http://linuxmafia.com/pipermail/conspire/2021-April/011582.html
Directly quoting Rick from that post:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DMARC is a badly designed antiforgery method designed by Yahoo that is
built atop an equally badly designed earlier antiforgery method named
DKIM. DKIM allows an individual user to cryptographically sign the
composed contents of his/her message, including many of the internal
SMTP headers. DMARC is a metastandard that includes DKIM, and adds
a method (SPF) to determine whether the IP address attempting to deliver
mail ostensibly from a claimed sending domain is among the IP addresses
predeclared as authorised to issue mail from that domain onto the
Internet.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
... and then further down in Rick's selfsame post http://linuxmafia.com/pipermail/conspire/2021-April/011582.html :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Why is this happening? Fundamentally, Yahoo designed an antiforgery
method (DKIM) that is hostile to mailing lists, not being willing to
take into account the need for software like Mailman to make some
changes to the body and headers of a subscriber's post, in making the
copies sent to fellow subscribers. All across the world, DKIM is
failing on mailing list postings sent through Mailman, Sympa, Majordomo,
Listproc, ezmlm, and all of the other mailing list managers.
_Any_ sending domain that declares a DMARC policy of "p=reject" or
"p=quarantine" causes massive problems for mailing list subscribers
receiving mail sent from a subscriber on that domain, _if_ the receiving
mail system implements the overly aggressive DKIM/DMARC policy request.
And, please note, this is not the user's fault, and the user cannot fix
the problem -- except by not participating in mailing lists from a
domain with a "p=reject" or "p=quarantine" DMARC policy.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please do read the remainder of that posting.
Michael's proposed Mailman upgrade to v3 might help (and both Rick and Michael are encouraged to elaborate upon this further) in reducing Yahoo.com's "DMARC badness".
-A
Michael Paoli
May 7, 2021, 3:16:47 AM5/7/21
to BerkeleyLUG
> From: goossbears <acoh...@gmail.com>
> Chris and others,
>> From what I've been reading on other mailing lists, not all is
> sweet-smelling roses as far as migrating mailing-list(s) to Mailman using
> Yahoo.com addresses.
> A big thorn with using Yahoo.com is its "DMARC badness" as Rick put it in
> his conspire mailing-list post '(forw) [skeptic] me.com is shooting Skeptic
> subscribers in the foot w/DMARC (was: I have questions...)' at
> http://linuxmafia.com/pipermail/conspire/2021-April/011582.html
DKIM/DMARC "badness" is an issue for lists, be it Mailman, or even
Google Groups! ... as [Pi.]BerkeleyLUG is presently using.
Modern lists generally kludge around that ... because, though not
pretty, that's effective, and there really isn't a better solution
for that "badness". E.g. @yahoo.com which has a quite strict policy
on DKIM. So, e.g. even Google Groups has to kludge around that:
To: <berke...@googlegroups.com>
X-Original-Sender: chris_...@yahoo.com
X-Original-From: Christian Peeples <chris_...@yahoo.com>
Mailing-list: list berke...@googlegroups.com; contact
berkeleyl...@googlegroups.com
List-ID: <berkeleylug.googlegroups.com>
List-Post: <https://groups.google.com/group/berkeleylug/post>,
<mailto:berke...@googlegroups.com>
That's what we've got in headers ... after reformatting a bit and
stripping out what's not highly relevant. That's what Google Groups
itself does. Though the Original Header From: and perhaps also Sender:
are buried in some X-Original- headers, most folks will never see that.
If, in their typically mail client, they take actions to
reply or reply all or reply to list, they get
berke...@googlegroups.com and/or
https://groups.google.com/group/berkeleylug/post
and absolutely noting gives them a simple means to reply directly
to the original author of the posting if they so wish to ...
though some response actions may carry part of that along in the
Full Name data - essentially comment data, so a response may end up
going
To: "'Christian Peeples' via BerkeleyLUG" <berke...@googlegroups.com>
but the email address is still the list posting address. Chris's email
address ends up relatively inaccessible in the X-Original- header(s).
Anyway, here's that messages as it is on Google Groups itself:
https://groups.google.com/g/berkeleylug/c/Xe9u548NqKI/m/aTZzIxTECAAJ
... but there, Google Groups doesn't even offer a "Show Original" or
the like ... unless perhaps one is logged in with a Google [Groups]
account.
Well, Mailman does similar to kludge around DKIM and the like ... though not
quite as egregiously as Google Groups, which really clearly shows they
want all responses to go thorough Google Groups - whether that's one's
preference or not. Even replying to "'Christian Peeples' via BerkeleyLUG"
would end up posting to the Google Groups list.
Christian Peeples <chris_...@yahoo.com>
isn't even among the options Google Groups offers at all for replying.
Contrast that with Mailman ... non-ancient 2.x series, that kludges
around the DKIM etc. badness reasonably effectively (and I'd think 3.x
likely does so as well or maybe even a bit better). Let's see ...
This one
https://lists.balug.org/pipermail/balug-test/2021/000061.html
From: @yahoo.com
email address.
This is what the Mailman 2.x on the BALUG VM does with that:
To: BALGU-Test <balug...@lists.balug.org>
List-Post: <mailto:balug...@lists.balug.org>
From: Michael Paoli via BALUG-Test <balug...@lists.balug.org>
Reply-To: Michael Paoli <micha...@yahoo.com>
Sender: BALUG-Test <balug-tes...@lists.balug.org>
Note that reply will still go to the original sender as Mailman added
Reply-To: and set that to the original sender (that takes precedence
over From: for reply). A reply/post to list will go to the list
posting address. Mailman isn't trying to hijack the interaction and
coerce you to send all data thorough it for data mining and
advertising or whatever. In fact if the relevant parties and MTAs
are doing encryption (generally recommended as feasible these days),
very possible none other than receiving and sending parties (and
their hosts and MTAs) may be privy to the communication. "Of course"
if it goes to the list, well, that's generally many recipients and
publicly archived - but presumably that would be intentional by sender,
rather than accidental.
Contrast that with the case of Google Groups, where one is pretty
much coerced to have the data go to Google Groups list. And Google
Groups doesn't care if your list is public or not ... it goes to/through
the list, and Google can mine that data - even if it's closed off from
the rest of The Internet.
Hmm, thought I'd mentioned more about DKIM & such recently on this
list ... but no, ... else-list. Somewhat different scenario - and
different list, and presently located yet somewhere else ... but you
can read some more about the DKIM bits here:
http://linuxmafia.com/pipermail/sf-lug/2021q2/015246.html
... and likewise on some of Ricks earlier posts too, which Aaron
also pointed out.
Anyway, my earlier about potentially migrating this list:
https://groups.google.com/g/berkeleylug/c/Xe9u548NqKI/m/YUoXiQm4CAAJ
> Subject: Re: BerkeleyLUG Google Groups (list) - backup(s) & ...
> (possibly) migrate to ...
> Date: Thu, 6 May 2021 22:29:49 -0700 (PDT)
> (possibly) migrate to ...
> Chris and others,
>> From what I've been reading on other mailing lists, not all is
> sweet-smelling roses as far as migrating mailing-list(s) to Mailman using
> Yahoo.com addresses.
> A big thorn with using Yahoo.com is its "DMARC badness" as Rick put it in
> his conspire mailing-list post '(forw) [skeptic] me.com is shooting Skeptic
> subscribers in the foot w/DMARC (was: I have questions...)' at
> http://linuxmafia.com/pipermail/conspire/2021-April/011582.html
Google Groups! ... as [Pi.]BerkeleyLUG is presently using.
Modern lists generally kludge around that ... because, though not
pretty, that's effective, and there really isn't a better solution
for that "badness". E.g. @yahoo.com which has a quite strict policy
on DKIM. So, e.g. even Google Groups has to kludge around that:
From: "'Christian Peeples' via BerkeleyLUG" <berke...@googlegroups.com>
Reply-To: berke...@googlegroups.com
To: <berke...@googlegroups.com>
X-Original-Sender: chris_...@yahoo.com
X-Original-From: Christian Peeples <chris_...@yahoo.com>
Mailing-list: list berke...@googlegroups.com; contact
berkeleyl...@googlegroups.com
List-ID: <berkeleylug.googlegroups.com>
List-Post: <https://groups.google.com/group/berkeleylug/post>,
<mailto:berke...@googlegroups.com>
That's what we've got in headers ... after reformatting a bit and
stripping out what's not highly relevant. That's what Google Groups
itself does. Though the Original Header From: and perhaps also Sender:
are buried in some X-Original- headers, most folks will never see that.
If, in their typically mail client, they take actions to
reply or reply all or reply to list, they get
berke...@googlegroups.com and/or
https://groups.google.com/group/berkeleylug/post
and absolutely noting gives them a simple means to reply directly
to the original author of the posting if they so wish to ...
though some response actions may carry part of that along in the
Full Name data - essentially comment data, so a response may end up
going
To: "'Christian Peeples' via BerkeleyLUG" <berke...@googlegroups.com>
but the email address is still the list posting address. Chris's email
address ends up relatively inaccessible in the X-Original- header(s).
Anyway, here's that messages as it is on Google Groups itself:
https://groups.google.com/g/berkeleylug/c/Xe9u548NqKI/m/aTZzIxTECAAJ
... but there, Google Groups doesn't even offer a "Show Original" or
the like ... unless perhaps one is logged in with a Google [Groups]
account.
Well, Mailman does similar to kludge around DKIM and the like ... though not
quite as egregiously as Google Groups, which really clearly shows they
want all responses to go thorough Google Groups - whether that's one's
preference or not. Even replying to "'Christian Peeples' via BerkeleyLUG"
would end up posting to the Google Groups list.
Christian Peeples <chris_...@yahoo.com>
isn't even among the options Google Groups offers at all for replying.
Contrast that with Mailman ... non-ancient 2.x series, that kludges
around the DKIM etc. badness reasonably effectively (and I'd think 3.x
likely does so as well or maybe even a bit better). Let's see ...
This one
https://lists.balug.org/pipermail/balug-test/2021/000061.html
From: @yahoo.com
email address.
This is what the Mailman 2.x on the BALUG VM does with that:
To: BALGU-Test <balug...@lists.balug.org>
List-Post: <mailto:balug...@lists.balug.org>
From: Michael Paoli via BALUG-Test <balug...@lists.balug.org>
Reply-To: Michael Paoli <micha...@yahoo.com>
Sender: BALUG-Test <balug-tes...@lists.balug.org>
Note that reply will still go to the original sender as Mailman added
Reply-To: and set that to the original sender (that takes precedence
over From: for reply). A reply/post to list will go to the list
posting address. Mailman isn't trying to hijack the interaction and
coerce you to send all data thorough it for data mining and
advertising or whatever. In fact if the relevant parties and MTAs
are doing encryption (generally recommended as feasible these days),
very possible none other than receiving and sending parties (and
their hosts and MTAs) may be privy to the communication. "Of course"
if it goes to the list, well, that's generally many recipients and
publicly archived - but presumably that would be intentional by sender,
rather than accidental.
Contrast that with the case of Google Groups, where one is pretty
much coerced to have the data go to Google Groups list. And Google
Groups doesn't care if your list is public or not ... it goes to/through
the list, and Google can mine that data - even if it's closed off from
the rest of The Internet.
Hmm, thought I'd mentioned more about DKIM & such recently on this
list ... but no, ... else-list. Somewhat different scenario - and
different list, and presently located yet somewhere else ... but you
can read some more about the DKIM bits here:
http://linuxmafia.com/pipermail/sf-lug/2021q2/015246.html
... and likewise on some of Ricks earlier posts too, which Aaron
also pointed out.
Anyway, my earlier about potentially migrating this list:
https://groups.google.com/g/berkeleylug/c/Xe9u548NqKI/m/YUoXiQm4CAAJ
goossbears
May 7, 2021, 9:07:09 PM5/7/21
to BerkeleyLUG
On Thursday, May 6, 2021 at 10:29:49 PM UTC-7 goossbears wrote:
Chris and others,From what I've been reading on other mailing lists, not all is sweet-smelling roses as far as migrating mailing-list(s) to Mailman using Yahoo.com addresses.A big thorn with using Yahoo.com is its "DMARC badness" as Rick put it in his conspire mailing-list post '(forw) [skeptic] me.com is shooting Skeptic subscribers in the foot w/DMARC (was: I have questions...)' at http://linuxmafia.com/pipermail/conspire/2021-April/011582.htmlDirectly quoting Rick from that post:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~DMARC is a badly designed antiforgery method designed by Yahoo that is built atop an equally badly designed earlier antiforgery method named DKIM. DKIM allows an individual user to cryptographically sign the composed contents of his/her message, including many of the internal SMTP headers. DMARC is a metastandard that includes DKIM, and adds a method (SPF) to determine whether the IP address attempting to deliver mail ostensibly from a claimed sending domain is among the IP addresses predeclared as authorised to issue mail from that domain onto the Internet.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It may also help one or two persons following this thread to recognize further details about DMARC, DKIM, and SPF not only from Mailman's perspective but also directly from the fully non-ranting yet justifiably vilified "data-mining" mouth of Auntie Google....
1. Google Workspace Admin Help's 'About DMARC' webpage https://support.google.com/a/answer/2466580?hl=en
Directly quoting the first section of that link :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Prevent spoofing and phishing with DMARC
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a standard email authentication method. DMARC helps mail administrators prevent hackers and other attackers from spoofing their organization and domain. Spoofing is a type of attack in which the From address of an email message is forged. A spoofed message appears to be from the impersonated organization or domain.
DMARC also lets you request reports
from email servers that get messages from your organization or domain.
These reports have information to help you identify possible
authentication issues and malicious activity for messages sent from your
domain.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Three other sections of that 'About DMARC' link are
o - Spooofing and Phishing
o - How DMARC prevents spoofing (including relevant expanded "zippys"; 'Authenticates messages (DMARC alignment)', 'Manages messages that fail authentication (receiver policy)', and 'Sends you reports so you can monitor and change your policy' )
o - What you need to do
2. Google Workspace Admin Help's 'Increase security for outgoing email with DKIM...Set up DKIM to prevent email spoofing' webpage https://support.google.com/a/answer/174124?hl=en
Directly quoting the first section of that link :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Make your email more secure and protect your domain
Use the DomainKeys Identified Mail (DKIM) standard to help prevent spoofing on outgoing messages sent from your domain.
Email spoofing is when email content is changed to make the message appear from someone or somewhere other than the actual source. Spoofing is a common unauthorized use of email, so some email servers require DKIM to prevent email spoofing.
DKIM adds an encrypted signature to the header of all outgoing messages. Email servers that get signed messages use DKIM to decrypt the message header, and verify the message was not changed after it was sent.
If you want more email security, we recommend setting up these security methods along with DKIM:
- Sender Policy Framework (SPF)–SPF specifies which domains can send messages for your organization.
- Domain-based Message Authentication, Reporting & Conformance (DMARC)–DMARC specifies how your domain handles suspicious emails.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Three other sections of that 'Increase security for outgoing email with DKIM...' link are
o - If you don't set up DKIM, Gmail uses default DKIM
o - Steps to set up DKIM
o - Common questions about DKIM (including relevant expanded "zippys"; 'How does DKIM work?', 'What if my domain already has a DKIM key?' and 'How do I set up DKIM for a server that modifies the content of outgoing emails?' )
3. Google Workspace Admin Help's 'Ensure mail delivery & prevent spoofing (SPF)' webpage https://support.google.com/a/answer/33786?hl=en
Directly quoting the first section of that link :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Protect against forged emails & make sure messages aren't marked as spam
Using
Sender Policy Framework (SPF), you can protect your domain from
spoofing and help ensure that your messages are delivered correctly. You
use SPF to authenticate email and specify the mail servers authorized
to send email for your domain. Mail servers use SPF to verify that
messages that appear to come from your domain actually are from your
domain.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Six other expanded "zippy" sections of that 'Ensure mail delivery & prevent spoofing (SPF)' link are
o - Reasons to use SPF
o - Reasons to use SPF
o - Before you begin
o - Step 1: Create your TXT record for SPF
o - Step 2. Enable SPF for your domain
o - Follow other best practices for email authentication (partially covered in the DMARC and DKIM webpages of 1 and 2 above)
o - Troubleshoot SPF records
-------------------------------------------------------
Perhaps the Google "beast's" own more organized info will be easier to wade through? ;-)
-A
Reply all
Reply to author
Forward
0 new messages