Page MenuHomePhabricator

Ensure wikimedia.org adheres to Google's sender guidelines
Closed, ResolvedPublic

Description

Google has updated their sender guidelines and they will began enforcing the new guidelines on February 2nd 2024.

Requirements for all senders

  • ☒ Set up SPF or DKIM email authentication for your domain.
    • SPF record is broad, but seems okay
    • DKIM key present, used for signing, 1024 bit key
  • ☒ Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records.
    • Confirmed
  • ☒ Use a TLS connection for transmitting email.
    • Confirmed
  • ☒ Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.
    • Looks good
  • ☒ Format messages according to the Internet Message Format standard (RFC 5322).
    • Assume exim4 does the right thing
  • ☒ 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.
    • We don’t do this to my knowledge
  • ☒ If you regularly forward email, including using mailing lists or inbound gateways, add ARC headers to outgoing email.
    • Not applicable for wiki mail

Requirements for high-volume senders

I don’t have data on this atm but I would not be surprised if we’re over the 5k emails per day threshold.

  • ☒ Set up DMARC email authentication for your sending domain. Your DMARC enforcement policy can be set to none.
    • Confirmed, though policy is set to none at present
  • ☒ 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.

Event Timeline

jhathaway triaged this task as High priority.
$ ./mailsec-check -protocol wikimedia.org
-- Source forgery protection
[ ] DKIM: 	 _domainkey subdomain present; no DNSSEC; 
[ ] SPF: 	 present; strict; no DNSSEC; 
    Record:
	v=spf1 ip4:185.15.59.0/24 ip4:208.80.152.0/22 ip6:2620:0:860::/46 include:_spf.google.com ip4:74.121.51.111 ~all
[ ] DMARC: 	 present; no-op; no DNSSEC; 
    Record:
	v=DMARC1; p=none; sp=none; rua=mailto:dmarc-rua@wikimedia.org; ruf=mailto:dmarc-ruf@wikimedia.org;

-- TLS enforcement
[ ] MTA-STS: 	 no _mta-sts subdomain;
[!] DANE: 	 no record for mx2001.wikimedia.org.; no record for mx1001.wikimedia.org.; no DNSSEC; no validity check done; 

-- DNS consistency
[+] FCrDNS: 	 all MXs have forward-confirmed rDNS
[ ] DNSSEC: 	 A/AAAA records are not signed;

Note that we have several systems sending emails, not just MediaWiki, but also mailman, Phabricator, Gerrit, VTRS.

Note also that beta wikis use wikimedia.beta.wmflabs.org as the email domain. They probably don't send emails to many Gmail accounts though.

☒ If you regularly forward email, including using mailing lists or inbound gateways, add ARC headers to outgoing email.
Not applicable for wiki mail

Not applicable for wiki mail, but isn't it applicable to mailman?

Not applicable for wiki mail, but isn't it applicable to mailman?

yes, though that would apply to the lists.wikimedia.org subdomain.

Note that we have several systems sending emails, not just MediaWiki, but also mailman, Phabricator, Gerrit, VTRS.

Note also that beta wikis use wikimedia.beta.wmflabs.org as the email domain. They probably don't send emails to many Gmail accounts though.

For sure, thanks for bringing up the many sources of email. As you mentioned there are multiple services generating email, as well as multiple domains in use. For this ticket I was hoping to focus on our wiki's use of the wikimedia.org domain for sending email.

I don’t have data on this atm but I would not be surprised if we’re over the 5k emails per day threshold.

I realize you mentioned Phab and Gerrit are out of scope, but for the purposes of gathering data: looking at exim logs, Phab sent 10,740 emails to gmail addresses yesterday and 7195 today (since we did the phab upgrade on Saturday, I only have two days of historical data on disk there). Gerrit has hovered between 2k–3k emails to gmail addresses per day.

Further Phorge/Phab-specific details on T355691. If they really disappear those, it's going to break a lot of workflows.

Copying this here from the upstream Phorge task, since it's probably relevant to a fair amount of what we send.


From the Email sender guidelines FAQ:

Do all messages require one-click unsubscribe?

No. One-click unsubscribe is required only for marketing and promotional messages. 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.

The main sender guidelines page uses slightly different language:

Marketing messages and subscribed messages must support one-click unsubscribe, and include a clearly visible unsubscribe link in the message body.

Phabricator emails aren't promotional or marketing, but they are definitely subscribed messages.

FWIW the FAQ also says

We don’t automatically reject messages or mark messages as spam when they don’t meet the one-click unsubscribe requirements in our Email sender guidelines. However, unwanted messages that don’t use one-click unsubscribe are more likely to be reported as spam by recipients. An increase in messages marked as spam increases the chances that future messages from the same sender are delivered to spam.

We prioritize mitigation support for email delivery issues for senders that meet all requirements in our Email sender guidelines.

I think "unwanted messages that don’t use one-click unsubscribe are more likely to be reported as spam by recipients" refers to the Gmail "report spam" button behaving slightly differently when there is an unsubscribe link (the user can choose between unsubscribing and really marking it as spam).

@jhathaway is this the Task to track requirements for high-volume third party senders who impersonate our domain? Such as Shopify, Qualtrics, Acoustic? Or should each of those software titles be its own task?

@jhathaway is this the Task to track requirements for high-volume third party senders who impersonate our domain? Such as Shopify, Qualtrics, Acoustic? Or should each of those software titles be its own task?

I think subtasks of each domain task would probably work the best, so if a third party is impersonating wikimedia.org, make a subtask of this task

Hi @jhathaway -- is EmailUser within the scope of this ticket (I assume yes as it's as far as I can tell using Mediawiki mailer and the wikimedia.org domain)?

Flagging that @KCVelaga and I are planning on sending invites for the Community Insights survey in March though the EmailUser API, so there is at least one high-volume send planned (we're happy to stagger invites, but I don't know if there's a difference between us staggering or if it's all part of one big email pool).

@TAndic yes EmailUser is withing scope, @Tgr did a great job of breaking down the various mailers in mediawiki one the one-click support task, https://phabricator.wikimedia.org/T355450#9487493

jhathaway lowered the priority of this task from High to Medium.Jan 31 2024, 11:26 PM

other than one-click unsubscribe, we are in compliance