One often overlooked element when considering the security posture of an organization's email configuration is the surface area exposed by externally accessible mailing lists. Organizations often set up mailing lists (Google Groups in Google Workspace or Distribution Lists in Microsoft 365) to expose contact points for security, support, invoices, etc to third-party organizations and individuals.

However, these mailing lists sometimes present additional risk to the organization. Specifically, the email addresses linked to these mailing lists are often easy to guess and in the case of Google Groups, the level of anti-spam and anti-forged message protection is greatly reduced compared to messages sent directly to individuals.

Google Groups does not apply the same level of filtering against emails sent to mailing lists as it does to individual users, even if the Google Group spam settings are explicitly configured to reject spam email. 

The concerns above aren’t just theoretical. Material began looking into this activity when we noticed some Material customers escalating Phishing Herd Immunity cases to us that contained messages that should have been sent to spam, but instead were delivered to a users' inbox. These messages often failed DKIM or SPF and would certainly have been moved to spam if they had been sent directly to the user's email address. This led us to question if the filtering behavior applied to incoming emails was consistent between Google Groups and emails sent directly to an individual's email address.

The following tests were run using a combination of our own self-hosted SMTP servers and Email Spoof Test. We ran these tests against multiple Google Groups in different Google Workspaces and observed the following behavior:

We found these results to be surprising and unexpected. It would be entirely reasonable to expect the same level of filtering that is applied to individual accounts to also be applied to Google Groups, but that does not appear to be the case. We ran the same tests against a Microsoft 365 distribution list, but in all of the tests the messages were properly categorized as spam for both individual users and distribution lists.

We reported this behavior to Google on June 6, 2022 and to date the only communication we have received is that they have classified the case as a "Bug/Feature Request" and are continuing to investigate this issue.

Tip: Flag Unauthenticated Messages Delivered to Google Groups

As a workaround, it is possible to create a content compliance rule to modify the subject line of unauthenticated emails that are sent to mailing lists. "Unauthenticated" in this context means emails that are failing SPF/DKIM/DMARC. 

You can construct this content compliance rule by navigating to the "Compliance" section of Gmail settings: https://admin.google.com/ac/apps/gmail/compliance

Once there, click "Add another rule" under "Content Compliance" and fill out the rule definition as follows:

1. Email messages to affect

• Check "Inbound" and 'Internal - Receiving"

2. Add expressions that describe the content you want to search for in each message

• Select "If ANY of the following match the message"
• Expressions: "Metadata match: Message is not authenticated"

3. If the above expressions match, do the following

• Select "Modify message"
• Check "Prepend custom subject"
• You can use whatever you'd like here, but we use "[UNAUTHENTICATED]"

Scroll to the bottom and click "Show options"

B. Account types to affect

• Check the box next to "Groups"

This rule provides members of a group an additional datapoint when attempting to determine the authenticity of an email delivered to a mailing list.

Other Interesting Behaviors

An additional point to note is that some messages sent to Google Groups will render the "From" field in a Gmail inbox as the sender's display name while others will display as the display name with "via <Google Group Name>" appended. 

For example, if our sender is "John Doe <john@johndoe.com>" and John sends an email to our mailing list at MailList@example.com, the "From" field will render in Gmail either as "John" or "John via MailList". At first glance, the addition of "via" to the "From" field appears to be random. However, in computing, things rarely happen at random.

Google Groups appends this "via <Google Group Name>" on emails where the DMARC record of the sender domain is configured as p=REJECT or p=QUARANTINE. The reason for this is that Google Groups modifies the From header of the original message when it delivers it to recipients of the group, which would cause the modified message to fail DKIM verification. In these cases, Google Groups adds a "X-Original-Sender" and "X-Original-From" header to the message and sets the value of the "From" header to contain the domain of the Google Group as opposed to the domain of the sender. 

A simplified version of the transformation can be visualized below:

This transformation is important to keep in mind when running header-based searches in Email search tools.

Uncover Your Exposed Google Group Surface Area with Material

In our next release, the Material console will contain a risk report that displays all of your Google Groups that accept email from anyone on the internet. We use the same dataset to construct this risk report as we do when we display your group settings in the console. We recommend reviewing all of your Google Groups displayed in this risk report and enabling moderation and increasing spam filtering where possible. In conjunction with the content compliance rule posted above, this greatly increases the amount of scrutiny that can be applied to messages delivered to these groups.

If you’re interested in learning more about Material’s new approach to securing mailboxes, request time with our team here or DM me on LinkedIn or Twitter.

References:

1. Email Spoof Test
2. Usage of X-Original-From