Google has updated their sender guidelines and they will began enforcing the new guidelines on February 2nd 2024.
Determine whether this task is on the mediawiki's team radar and whether they have the time to complete it before February.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T355712 Ensure Wikimedia complies with Google's new email sender guidelines | |||
| Resolved | jhathaway | T355449 Ensure wikimedia.org adheres to Google's sender guidelines | |||
| Open | None | T355450 mediawiki support for one-click unsubscribe |
More specifically it says
Starting February 1, 2024, senders who send more than 5,000 messages per day to Gmail accounts must meet the requirements in this section.
- Set up SPF and DKIM email authentication for your domain.
- Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records. Learn more
- Use a TLS connection for transmitting email. For steps to set up TLS in Google Workspace, visit Require a secure connection for email.
- Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher. Learn more about spam rates.
- Format messages according to the Internet Message Format standard (RFC 5322).
- Don’t impersonate Gmail From: headers. Gmail will begin using a DMARC quarantine enforcement policy, and impersonating Gmail From: headers might impact your email delivery.
- If you regularly forward email, including using mailing lists or inbound gateways, add ARC headers to outgoing email. ARC headers indicate the message was forwarded and identify you as the forwarder. Mailing list senders should also add a List-id: header, which specifies the mailing list, to outgoing messages.
- Set up DMARC email authentication for your sending domain. Your DMARC enforcement policy can be set to none. Learn more
- For direct mail, the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain. This is required to pass DMARC alignment.
- Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link in the message body. Learn more
There are five ways we send mass email, I think: old-style MediaWiki mails (e.g. watchlist), Echo, Special:EmailUser, mailman, and fundraising emails. Maybe also Phabricator and Gerrit, no idea whether they reach the 5000/day limit.
The relevant bits from the Gmail policy:
To set up one-click unsubscribe, include both of these headers in outgoing messages:
List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: <https://solarmora.com/unsubscribe/example>When a recipient unsubscribes using one-click, you receive this POST request:
POST /unsubscribe/example HTTP/1.1 Host: solarmora.com Content-Type: application/x-www-form-urlencoded Content-Length: 26 List-Unsubscribe=One-ClickLearn more about List-Unsubscribe: headers in RFC 2369 and RFC 8058.
The first RFC isn't very relevant. The second says
The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the "h=" tag of a valid DKIM-Signature header field.
Is this something the mail server will take care of automatically if MediaWiki adds the headers, or is it more complicated than that?
We currently sign the default headers recommended by RFC4781, which does not include List-Unsubscribe-Post so that header will need to be added to our email server config. I'll create a task.
As pointed out in the parent task, it's not quite clear what these policies apply to. The main guidelines page says
Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link in the message body.
but the FAQ page says
One-click unsubscribe is required only for marketing and promotional messages.
which is quite the difference.
The FAQ also says
Transactional messages are excluded from this requirement. Some examples of transactional messages are password reset messages, reservation confirmations, and form submission confirmations.
Senders that already include an unsubscribe link in their messages have until June 1, 2024 to implement one-click unsubscribe in all commercial, promotional messages.
Here is a list of email sending functionality in MediaWiki core and Wikimedia-deployed extensions (based on the assumption that all email goes through UserMailer::send() - codesearch):
| Component | Link | Transactional | Promotional | Has unsubscribe link | Email text | Notes |
|---|---|---|---|---|---|---|
| core signup and email & password management | User (1, 2), TemporaryPasswordPrimary... (1, 2) | yes | no | no | one of these | |
| Special:EmailUser | EmailUser | no | sometimes | yes (to Special:Mute) | user-controlled but appends these | sometimes used as a mechanism for central communication |
| MediaWiki-Watchlist | EmailNotification (1, 2) | no | no | yes (to prefs, watchlist, unwatch dialog) | enotif_body | |
| Notifications | Notifier, EmailBatch | sometimes | sometimes | yes (to Echo prefs) | varies, but appends one of these | |
| MediaWiki-extensions-BounceHandler | ProcessUnRecognizedBounces | Irrelevant, only sent to site admins | ||||
| CampaignEvents | EmailUsersJob | no | yes | no? | email content seems entirely user-controlled | |
| MediaWiki-extensions-CentralAuth | SpecialGlobalRenameQueue | yes | no | no | one of these | rename success / failure notification |
| MediaWiki-extensions-CentralAuth | EmailableUser | maybe? | no | no | this | SUL globalization email, not used anymore |
| MediaWiki-extensions-ContactPage | SpecialContact (1, 2) | irrelevant, only sends to site admins | ||||
| MediaWiki-extensions-DonationInterface | minfraud | irrelevant, only sends to site admins | ||||
| MediaWiki-extensions-SecurePoll | wm-scripts/sendMail.php | no | yes | email content controlled by sender | ||
| TranslationNotifications | TranslationNotificationsEmailJob | no | yes | yes (to Special:TranslatorSignup) | one of these | |
| MediaWiki-extensions-WikimediaMaintenance | sendBulkEmails.php | no | yes | email content controlled by sender | ||
| MediaWiki-extensions-WikimediaMaintenance | addWiki.php | irrelvant, sent to site admins only | ||||
| MediaModeration | MediaModerationEmailer | irrelvant, sent to site admins only | ||||
| Incident-Reporting-System | ReportIncidentMailer | irrelvant, sent to site admins only | ||||
All of these are either clearly transactional (ie. triggered by user action and being essential to that user action) or have some sort of unsubscribe functionality or are only sent to a small set of users hard-coded in site configuration, with the exception of CampaignEvents, SecurePoll and sendBulkEmails.php. The latter two are maintenance scripts that take the address list from a file or wiki page, so there isn't really a way to automate unsubscribing, but they are only available to trusted users with shell access who hopefully know what they are doing and include some sort of unsubscribe process. CampaignEvents uses a database of campaign participants and email sending isn't very restricted; it should probably have some sort of unsubscribe link.
The non-transactional, non-internal emails should probably support one-click unsubscription to comply with Gmail's sender guidelines. These are:
But since all but CampaignEvents have (non-one-click) unsubscribe links, the relevant deadline for these is June 1. CampaignEvents is in beta and not used that much, and probably won't get marked as spam a lot, and for now Gmail doesn't seem to be enforcing it that much, I don't think it needs an emergency fix (but adding a footer is easy and should be done).
Filed T355855: CampaignEvents emails should have a footer for CampaignEvents. (edit: dupe of T348043: Add footer text to emails from organizers)
Proposed a mechanism for easy-to-use, easy-to-customize one-click unsubscribe support in core: T355916: One-click email unsubscribe service in MediaWiki core