[sf-lug] Google Groups header munging

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] Switch meeting from Jitsi to Zoom
> Date: Sat, 12 Sep 2020 04:16:59 -0700

> Quoting Glen Jarvis (glen at glenjarvis.com):
>
>> I have known about these bounced for some time. I get the DMARC policy
>> reports of which ones get rejected as well and have seen these bounce
>> (but only for linuxmafia). I do not have issues with other mailing
>> lists nor google groups.
>
> I am guessing that other MLMs like Sympa and whatever proprietary junk
> Google Groups uses employ a similar kludge to the DMARC-workaround
> kludge that recent Mailman releases can do.

Oh, Google Groups munges the heck out'a headers.

Let's just look at one typical example ... and for relative simplicity,
not showing all the headers, but mostly those relevant to munging and
likely otherwise of interest and/or surprise:

Let's start with what didn't change (again not showing all), and
here too, I'll also just show the header labels themselves, not
their contents:

= Content-Disposition:
= Content-Transfer-Encoding:
= Date:
= In-Reply-To:
= MIME-Version:
= Message-ID:
= References:
= Subject:
= To:

And ... what was present before, that isn't, or isn't the same after?:
Here's what we have from before, that's gone or totally changed:

< Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
< From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
< Return-Path: <Michael.Paoli at cal.berkeley.edu>
< Received:

Didn't show the contents, but yes, even 2 of the original Received:
headers are completely gone ... they don't even end up as X-Received:
data.
And, Return-Path: may be a pseudo-header that MTA or the like adds,
based upon envelope SMTP FROM: data, so not necessarily concerned
about that one.

And, ... what did we pick up?  What's changed/added?  In the after,
we have ... well, we have 42 sets of header data that weren't there
before, ... but trimming to the more interesting/surprising:

> Content-Type: text/plain; charset="UTF-8"; DelSp=Yes; format=flowed
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;  
> d=googlegroups.com; s=20161025;  
> h=sender:message-id:date:from:to:subject:references:in-reply-to:mime-version:content-disposition:content-transfer-encoding:user-agent:x-original-sender:x-original-authentication-results:reply-to:precedence:mailing-list:list-id:list-post:list-help:list-archive:list-subscribe:list-unsubscribe;
> Delivered-To: michael.paoli at cal.berkeley.edu
> From: Michael Paoli <Michael.Paoli at cal.berkeley.edu>
> List-Help: <https://groups.google.com/support/>,  
> <mailto:berkeleylug+help at googlegroups.com>
> List-Post: <https://groups.google.com/group/berkeleylug/post>,  
> <mailto:berkeleylug at googlegroups.com>
> List-Subscribe:  
> <https://groups.google.com/group/berkeleylug/subscribe>,  
> <mailto:berkeleylug+subscribe at googlegroups.com>
> List-Unsubscribe:  
> <mailto:googlegroups-manage+61884646931+unsubscribe at googlegroups.com>,  
> <https://groups.google.com/group/berkeleylug/subscribe>
> Mailing-list: list berkeleylug at googlegroups.com; contact  
> berkeleylug+owners at googlegroups.com
> Precedence: list
> Reply-To: berkeleylug at googlegroups.com
> Return-Path:  
> <berkeleylug+bncBCAZVTO3Q4BRBIUWVT5AKGQEOCJE5LI at googlegroups.com>
> Sender: berkeleylug at googlegroups.com
> X-Original-Sender: michael.paoli at cal.berkeley.edu

So ... I didn't show the full DKIM data, but did show what fields it
signed and policy and such.
It adds Reply-To - which will supersede any earlier (unless the earlier
just happened to be the same).  It adds Sender: - this is probably needed
to pass any SPF/DKIM/etc. checks while it does manage to leave almost
the same (it trivially changed From: - but wasn't really any reason for
it to change it at all ... equivalent, but not identical).  I find
the way Google Groups does the List-...: headers often quite
annoying.  Most notably those where one would typically
expect email addresses, where it has both email addresses and
https URLs, and even more annoying, puts the https URLs first.
That confuses a lot of older clients.  E.g. client is smart enough to
give an option to reply to list - great, ... I click reply to list,
ugh, it fills in the email address as:
https://groups.google.com/group/berkeleylug/post
definitely not what I wanted.
And the client gets a bit too confused to give me an option to reply
just to the author (From:) ... the reply option it give me,
besides to the list, is just To Sender - which goes to the Sender:
which is the list.
And Return-Path: - no surprises there - it sets that, apparently
uniquely - likely for reasonable proper bounce processing.

Anyway, ... not shown in this example, but any DKIM that was there,
would generally get fully redone, and any prior DKIM might show in
X- or other headers ... or not.  SPF ... that should make it through
okay with the addition of (or change to) Sender: - or may just use
DKIM and not SPF.  There may be some other munging of interest that
goes on, but isn't shown in this example ... and there's a whole lot
of other (mostly not as interesting) fields that get added.

Maybe not as egregious as it could be, but it is quite a bit 'o
header munging.