Email Infrastructure: Phase 3

Overview of Phase 3

  • Migrate Majordomo2 (Mj2) mailing list services to Google Groups
  • Turn on SPF and DMARC in advisory mode
  • Convert and from an implicit to an explicit alias
  • Launch campus Limited Functionality Relay for devices that cannot OAuth


Turn on SPF in advisory mode

All outbound email for the domain that doesn’t originate from a blessed mail relay currently has an SPF check of “NEUTRAL”.  We will be implementing an SPF record for the domain to set mail originating from Google and SendGrid as “POSITIVE”. A small TTL will be used initially to facilitate a quick backout strategy in the event of adverse impact. The qualifier being used in this record will allow existing senders that are not included in the record to continue delivering with a “NEUTRAL” SPF check.  Once a simple SPF record is in place to set mail originating from Google and SendGrid as “POSITIVE”, we will be evaluating other services to add to the SPF record.  At some point, once we have all verified sending services included in SPF, we will be moving from advisory mode to strict mode by changing it from “NEUTRAL” to “SOFT FAIL”, which will still deliver, but likely be marked as spam.

This was completed on March 16, 2020. See Sysnews post.

Turn on DMARC in advisory/reporting mode

Domain-based Message Authentication, Reporting & Conformance (DMARC) will allow the GST to review logs and possible changes that might be needed in our email environment as we continue to strengthen our domain against phishers and spammers. DMARC is a protocol that requires both SPF and DKIM to be set up before enabling and DMARC then verifies that messages are authentic. Messages that do not pass SPF or DKIM would trigger our DMARC policy, which for now will be set to reporting / no action mode.

This was completed on August 6, 2020. See Sysnews post.

Convert and from an implicit to an explicit alias

We will be removing and from the list of synonymous domains (an implicit alias). Currently all 200,000+ accounts in Google get an alias from each of those domains. As part of this change we will remove the synonymous domain and add it back to only allow explicit aliases for those people who still receive mail using those aliases. This will help greatly in reducing the complexity of our mail environment.

Launch campus Limited Functionality Relay

A number of devices on campus cannot communicate directly to the internet and cannot spool email locally if connectivity is lost.  These devices include SCADA machines, networking devices, and storage equipment as well as others.  OIT works with various units that have these types of devices to provide an on campus relay that provides a local spool and does authenticated SMTP to Google on the back end.

If you feel that you have a need for this, please submit a request via the Service Portal.

Migration of Majordomo2 (Mj2) to Google Groups

The information provided below is targeted at mailing list owners for the migration of their mailing lists from Mj2 to Google Groups.
As always, feel free to consult with the Google Service Team for guidance or assistance.

NOTE: The migration began on April 14th and was completed on April 21, 2020. See Sysnews post.

Mailing List Owner Normalization

Google Group creation for all migrated Mj2 lists will be done by Web Registry.  The initial population of your new group into Web Registry must include 2 unique Contacts and these Contacts must be unity accounts in the format of (no mail aliases allowed).  Current list owners will become contacts in Web Registry for their new group. Since each group needs two unique contacts, we will ask that you provide a second contact if there is only a single list owner.

To assist with populating Web Registry contacts, OIT will programmatically fix some of that data soon by doing the following:

  • Converting any personal alias “owner” to
    • Note that if an owner usually sends email with their alias and does not have that alias registered in Mj2, list management commands will be denied and have to be resent with as the “from” address.
  • If a Google Generic Account is the owner of a list, we will populate the current Generic Account Contacts from Web Registry as “owners” of the list.
    • Note that this means that additional owners will start seeing bounce and moderation emails that previously only went to the Google Generic Account.

Additionally, there are some changes that will happen since the concepts of “Owners” and “Moderators” in Mj2 and Google Groups are different:

  • Owners and Moderators from Mj2 will be initially setup as Managers of the Google Group.
    • While there are options for using custom roles for Moderators instead of using the Managers role, that is a per-list, manual configuration and is up to the list/Group owner should they choose to do so.
  • If a user is an Owner or Moderator only, and not a member of the list, they will be set up as Manager of the Google Group with “Mail Delivery:No Email” and “Posting:Disallow Posting” since a Manager in Google Groups must also be a Member of the Group.
  • Owners from Mj2 will be set as Contacts in Web Registry.

Group Creation and Configuration

  • 3/31/2020 – All Mj2 lists will be created as Google Groups, but mail will still route to Mj2.  This is being done to allow time for manual configuration changes to be done to the Groups prior to them “going live”.
    • List names will NOT change when a list is moved to a Google Group; your list name will remain “”
    • From this point, no Mj2 lists or Google Group delete requests will be processed until the migration is complete.
    • While the back end code of Web Registry and Google Groups will support the “” naming at this point, we will not be updating the front end to allow requests of new “” Google Groups till after the migration is complete.
    • At this point, all list owners will see the new Group in the Google Groups interface.
  • 3/31/2020 – There will be an Initial one-time Automatic Configuration of the Google Group based on the configuration of the Mj2 list.  The configuration items we will be porting over programmatically are:
    • Subject Prefix: e.g., [Groupname]P: due to technical limitations, we cannot migrate list subject prefixes over to Google. For guidance on how to set one in Google Groups see Set a Subject Prefix on your Google Group.
    • Reply_To (list, author, or other) configuration: Replying goes to the whole group, the sender only, or other.
    • Moderation (on or off): A member post goes to the group or is approved first by a moderator. The moderation flag MUST be set for this to carry over; otherwise, the default is OFF.
    • Subscriber Policy: Who can subscribe to the group? Anybody or require Manager approval to join the group.
    • External Subscribers Allowed (on or off): e.g., not an address.
    • Web Archive of messages (on or off): If you are currently archiving in Mj2, we will turn on web archives in the Google Group. Keep in mind that your current Mj2 archive will not be merged with your new Google Group. See below for details on getting a copy of your Mj2 archive.
  • 4/2/2020 – There will be a daily membership synchronization from Mj2 to the Google Group from this point up until the mail routing is changed so the Group is “live”.  All membership changes should still be done in Mj2 at this point.
    • At this point, all list subscribers will see the new Group in the Google Groups interface.  OIT will not be notifying list subscribers directly and it is up to list owners to determine the level of communication that is appropriate for their list subscribers.
    • Group Managers may also notice an additional Google Generic Account that is an “Owner” of the Google Group and cannot be removed in the Google Groups interface. This account is being used as part of the synchronization and will be removed once the Group is “live”.
    • For additional information on Google Groups and commonly used commands, please see our Knowledge Base articles on Google Groups

Mail Routing Changes

  • 4/2/2020 – migrate a couple IT lists
  • 4/9/2020 – A “Mj2 to Google Group Town Hall” will be held in 106 Avent Ferry from 9 am-Noon in order to answer questions of list owners and to assist in any initial manual configuration that is needed. No registration is required; stop by and talk with experts and get your questions answered.
  • 4/14/2020 – Simple list migration – There are roughly 850 “simple lists”.  “Simple lists” are defined as lists that are NOT:
    • Moderated lists
    • Lists with complex access rules
    • Lists with another list as a subscriber
    • Lists with more than 100 subscribers
    • Lists with more than 20 off-campus subscribers
  • 4/21/2020 – Complex migration – The rest of the lists are considered “complex lists”. There are roughly 1700 of those. Once this is done, all mail routing for “” will be going to Google for all Groups.
  • Contact the Google Service Team for information for guidance or assistance.

Known Concerns

  • Current Archives – There is no way to import current Mj2 archives into Google.  We will provide current HTML archives to owner per request after shutdown.
  • Partial list white-listing of moderation – Some Mj2 lists are setup where a subset of users can post without moderation and all other posters are moderated (this is common for student lists populated based on degree program).  While you can set per-user moderation or full list moderation, there is not a simple way to replicate this on large lists, much less across multiple lists.
  • Automatic Bounce Processor – The Automatic Bounce Processor in Mj2 can remove subscribers from the list upon multiple bounces.  There is no equivalent in Google Groups.  There is a “Bouncing” tab in the Group members view, so an owner can see who is bouncing and manually remove them from the Group, but cannot take programmatic action.
  • Large External Subscriber Distribution lists – Lists that contain thousands of off-campus subscribers probably should not be using Google Groups for mass-mailing.  Services like SendGrid, Bronto, or some other mass-mailing technology should be used instead.  We have no intention to prevent Groups from being used this way, but there are message limits imposed by Google on Groups that affect the entire domain.
    • Should a large, primarily external subscriber distribution group cause the domain to be unable to send further external email from Groups, that group will be disabled.
  • A User can only have 2000 roles – Since a Group Manager is also a Member, a user can only “Own” 1000 groups.  This is only a concern for some groups that have a massive number of groups all Managed by a Google Generic account.
  • Nested Parent/Child list reply_to’s – If a unit has a simple list as a member of a complex list where the “Reply-To” is set to include the parent list as the sender, there may be odd things that happen during the during 1-week window between the “simple list” and “complex list” migrations.  Note that this is not a recommended configuration.
  • Multiple Reply-To or Reply-To set to sender – Some Mj2 lists have "$SENDER," as the default Reply-To. This behavior is not supported in Groups; you may only specify one target to receive replies. Please see the Google Group Reply-To KB Article for more details.

Post Migration

  • Group Member Automation – A number of mailing lists are currently having their list membership updated via a number of tools. We have committed to supporting integrations for Listminder and Persona for automating the membership of Google Groups.
    • The mailing lists currently using the “Subscriber Automation” via Listminder will continue to have their memberships synchronized via the daily membership synchronization from Mj2 to the Google Group even after migration.  This will be maintained until the Listminder and Persona integrations are complete and updates have been migrated to the appropriate tool.
    • For any other unit doing automation of Mj2 mailing lists that would like to pursue Group Member Automation, please consult with the Google Service Team after the migration is complete.
  • Web Registry Front End – Once the migration is complete, the changes to the Web Registry user interface will be made to allow for new requests of Groups with the “” naming format as well as retaining the option of a “group-” name.