Btw, I just got this when in gmail's web UI to mark them not as spam:

Anyone else?

I am not certain the 'lack of identity' is what's causing these emails to be marked as spam.

What exactly do you mean by that?

Cheers,

Joel

In T115416#1723824, @JKrauska wrote:

I am not certain the 'lack of identity' is what's causing these emails to be marked as spam.

What exactly do you mean by that?

The gmail web UI is linking to https://support.google.com/mail/answer/81126?hl=en#authentication for "why is this being marked as spam?".

All replies to this task have ended up in gmail's spam folder for me as well:

Well, gerrit and Phabricator emails are certainly very bad. Multiple bugs have been reported in the last few years with actionable suggestions (some of which can also be acted upon by WMF on the configuration side), but they all were ignored.

In T115416#1723815, @greg wrote:

Btw, I just got this when in gmail's web UI to mark them not as spam:

Anyone else?

Didn't get that pop-up so far.

New fun today, one message from T115440: Phabricator email notifications marked as spam by GMail marked as a possible phishing scam.

FWIW, I also had a ton of Shinken alerts in my spam folder as well.

I filed a similar ticket[0] back in August for Phabricator and mailing list messages. The issue actually seemed to have resolved itself for the past month or so but it appears to be back as of yesterday.

[0] https://wmf.zendesk.com/requests/8235

In T115416#1725915, @Niedzielski wrote:

I filed a similar ticket[0] back in August for Phabricator and mailing list messages. The issue actually seemed to have resolved itself for the past month or so but it appears to be back as of yesterday.

[0] https://wmf.zendesk.com/requests/8235

Only you and WMF OIT can see that

You can whitelist mails from wikimedia.org via gmail's web interface:
http://email.about.com/od/gmailtips/qt/et_whitelist.htm

In T115416#1724286, @Nemo_bis wrote:

Well, gerrit and Phabricator emails are certainly very bad. Multiple bugs have been reported in the last few years with actionable suggestions (some of which can also be acted upon by WMF on the configuration side), but they all were ignored.

Can you be a little more specific?

FWIW, we haven't changed anything recently - @JKrauska, this is probably something you should contact Google Apps about, we're customers after all.

I seem to recall that WMF Office IT enabled 'aggressive' spam filtering on @ wikimedia.org Gmail on August 27. I understand that they have the option to whitelist mail from certain domains to bypass the spam filters.

In T115416#1726149, @daniel wrote:

You can whitelist mails from wikimedia.org via gmail's web interface:
http://email.about.com/od/gmailtips/qt/et_whitelist.htm

If you do this, and you also use googlehangout/chat at all, Then do also checkmark the "Don't include chats" box. (Otherwise your email inbox will become a mess)

In T115416#1731857, @faidon wrote:

In T115416#1724286, @Nemo_bis wrote:

Well, gerrit and Phabricator emails are certainly very bad. Multiple bugs have been reported in the last few years with actionable suggestions (some of which can also be acted upon by WMF on the configuration side), but they all were ignored.

Can you be a little more specific?

Not really, I'm not going to waste time triaging Phabricator and Gerrit reports; I already spent enough time filing them. Perhaps the maintainers of those components should retriage the mail-related reports.

(I've also been getting translatewiki.net discussions' notifications in my Spam folder for a while. I remember bringing this up on IRC but can't remember what I was told about it.)

Just for observation purposes: so far, it seems the only people confirming this on this task are WMF employees, ie, those with their email being filtered for their @wikimedia.org account hosted by g-apps. Is this overly simplistic?

@Nemo_bis: can you cross reference the 'bad'ness of the emails that's been reported?

All of the messages in my Spam box have this..

"Why is this message in Spam? It is in violation of Google's recommended email sender guidelines. Learn more"

Where Learn more links to this.
https://support.google.com/mail/answer/81126?hl=en#authentication

Which is quite lengthly -- but I'll try to dive deeper.

Spam classification

Authentication & Identification
To ensure that Gmail can identify you:

Use a consistent IP address to send bulk mail.
JK: Mail is coming from iridium, directly to mx1001
JK: Received: from iridium.eqiad.wmnet ([2620:0:861:103:10:64:32:150]:61963 helo=localhost.localdomain)
by mx1001.wikimedia.org with esmtp (Exim 4.84)

Keep valid reverse DNS records for the IP address(es) from which you send mail, pointing to your domain.
JK: IPv6 listed above, looks ok.

Use the same address in the 'From:' header on every bulk mail you send.
JK: From: greg <no-reply@phabricator.wikimedia.org>
JK: address stays the same, friendly name will change, not sure if that'll cause grief..

We also recommend the following:

Sign messages with DKIM. We do not authenticate messages signed with keys using fewer than 1024 bits.
JK: No DKIM sig on the message I looked at. Perhaps we could add this.

Publish an SPF record.
JK: There's no SPF for phabricator.wikimedia.org
JK: Since we're using a subdomain here, a more restrictive/explicit SPF might help?
JK: Received-SPF: neutral (google.com: 2620:0:861:103:10:64:32:150 is neither permitted nor denied by best guess record for domain of no-reply@phabricator.wikimedia.org) client-ip=2620:0:861:103:10:64:32:150;

Publish a DMARC policy.
JK: We have one. https://dmarcian.com/dmarc-inspector/wikimedia.org
Learn more about email authentication.

Additional guidelines for IPv6

The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected.
JK: We have this for 2620:0:861:103:10:64:32:150
JK: 0.5.1.0.2.3.0.0.4.6.0.0.0.1.0.0.3.0.1.0.1.6.8.0.0.0.0.0.0.2.6.2.ip6.arpa name = iridium.eqiad.wmnet.

The sending domain should pass either SPF check or DKIM check. Otherwise, mail might be marked as spam.

Subscription
Each user on your distribution list should opt to receive messages from you in one of the following ways (opt-in):

Through an email asking to subscribe to your list.
By manually checking a box on a web form, or within a piece of software.
We also recommend that you verify each email address before subscribing them to your list.
JK: I don't think phabricator has explicit opt-in policies, it seems you just get the mail..

The following methods of address collection are not considered 'opt-in' and are not recommended:

Using an email address list purchased from a third-party.
Setting a checkbox on a web form or within a piece of software to subscribe all users by default (requiring users to explicitly opt-out of mailings).

Unsubscribing
A user must be able to unsubscribe from your mailing list through one of the following means:

A prominent link in the body of an email leading users to a page confirming his or her unsubscription (no input from the user, other than confirmation, should be required).
JK: THIS WE DO NOT HAVE, AND SEEMS TO BE A GOOD IDEA

By replying to your email with an unsubscribe request.
Because Gmail can help users automatically unsubscribe from your email, we strongly recommend the following:

Provide a 'List-Unsubscribe' header which points to an email address or a URL where the user can unsubscribe easily from future mailings. (Note: This is not a substitute method for unsubscribing.)
To help ensure that your messages aren't flagged as spam, we also recommend that you:
JK: WE DON'T HAVE THIS EITHER

Automatically unsubscribe users whose addresses bounce multiple pieces of mail.
JK: NOT SURE IF WE DO THIS

Periodically send confirmation messages to users.
Include each mailing list they are signed up for, and offer the opportunity to unsubscribe from those in which they are no longer interested.
It's possible that your users forward mail from other accounts, so we recommend that you:

Explicitly indicate the email address subscribed to your list.
Support a URL method of unsubscribing from your mailing list (this is beneficial if your mailing list manager can't tell who is unsubscribing based on the 'Reply-to:' address).

Format
All messages must be formatted according to RFC 5322 and, if using HTML, HTML standards.

Messages must have a valid 'Message-ID:' header field.
JK: Seems they do.

Messages should indicate that they are bulk mail, using the 'Precedence: bulk' header field.
JK: Precedence: bulk (YEP)

Attempts to hide the true sender of the message or the true landing page for any web links in the message may result in non-delivery.

The subject of each message should be relevant to the body's content and not be misleading.

The authenticating domain, envelope From domain, payload From domain, reply-to domain, and sender domain should not violate the highly-restrictive Unicode Security Profile guidelines for international domain names.

Delivery
While Gmail works hard to deliver all legitimate mail to a user's inbox, it's possible that some legitimate messages may be marked as spam. Gmail does not accept 'whitelisting' requests from bulk senders, and we can't guarantee that all of your messages will bypass our spam filters. To make sure our users receive all the mail they'd like to, we've provided them with a method for sending us feedback about messages flagged as spam -- users have the option of clicking a 'Not spam' button for each message flagged by our spam filters. We listen to users' reports, and correct problems in order to provide them with the best user experience. As long as our users don't consider your mail as spam, you shouldn't have inbox delivery problems.

There are two important factors that, under normal circumstances, help messages arrive in Gmail users' inboxes:

The 'From:' address is listed in the user's Contacts list.
A user clicks 'Not Spam' to alert Gmail that messages sent from that address are solicited.
If you send both promotional mail and transactional mail relating to your organization, we recommend separating mail by purpose as much as possible. You can do this by:

Using separate email addresses for each function.
Sending mail from different domains and/or IP addresses for each function.
By using these tips, it's more likely that the important transactional mail will be delivered to a user's inbox. Our guidelines are meant to help you build a good reputation within the Gmail system, resulting in continual delivery to Gmail inboxes.

Third-Party Senders
If others use your service to send mail (for example: ISPs), you are responsible for monitoring your users and/or clients' behavior.

You must have an email address available for users and/or clients to report abuse (abuse@yourdomain.com).
You must maintain up-to-date contact information in your WHOIS record, and on abuse.net.
You must terminate, in a timely fashion, all users and/or clients who use your service to send spam mail.

Affiliate Marketing Programs
Affiliate marketing programs reward third-parties for bringing visitors to your site. Unfortunately, these programs are attractive to hard-core spammers and can potentially do more harm than good. Please note the following:

If your brand becomes associated with affiliate marketing spam, it can affect the mail sent by you and your other affiliates.
It is your responsibility to monitor your affiliates and remove them if they send spam.

If you are sending mail in accordance with our guidelines and Gmail continues to mark your messages as spam, troubleshoot further.

(and I ran out of steam)

Hrm.

Not sure if this is a big deal, but we don't seem to have forward records for
iridium.eqiad.wmnet
or
iridium.wikimedia.org

This address
2620:0:861:103:10:64:32:150
I assume references an internal ipv4 addressing
10.64.32.150?

Should we be using an 'external' address when sending mail from iridium to mx1001 for better SPF handling?

--J

Thanks @JKrauska!

I'm only replying to a subset of your investigation:

In T115416#1735435, @JKrauska wrote:

Unsubscribing
A user must be able to unsubscribe from your mailing list through one of the following means:

A prominent link in the body of an email leading users to a page confirming his or her unsubscription (no input from the user, other than confirmation, should be required).
JK: THIS WE DO NOT HAVE, AND SEEMS TO BE A GOOD IDEA

By replying to your email with an unsubscribe request.
Because Gmail can help users automatically unsubscribe from your email, we strongly recommend the following:

Provide a 'List-Unsubscribe' header which points to an email address or a URL where the user can unsubscribe easily from future mailings. (Note: This is not a substitute method for unsubscribing.)
To help ensure that your messages aren't flagged as spam, we also recommend that you:
JK: WE DON'T HAVE THIS EITHER

Automatically unsubscribe users whose addresses bounce multiple pieces of mail.
JK: NOT SURE IF WE DO THIS

I think doing the first and the last (of those above) make sense (and I can do some leg work with upstream on them):

• Having a "Stop receiving emails for this task" and/or "Stop receiving all $host Phabricator emails" links is good.
• Auto-unsubing addresses that bounce multiple times

The middle one (list-unsubscribe header) doesn't make sense to my pedantic brain (they aren't mailing lists); anyone know if other non-mailing lists implement this?

The other things you went through someone else should respond to :)

I haven't been seeing any more of my phab+gerrit mails going into spam.

Anyone else?

In T115416#1755565, @greg wrote:

I haven't been seeing any more of my phab+gerrit mails going into spam.

Anyone else?

Me neither, works fine now.

In T115416#1735775, @greg wrote:

The middle one (list-unsubscribe header) doesn't make sense to my pedantic brain (they aren't mailing lists); anyone know if other non-mailing lists implement this?

MediaWiki... ;) T58315: Set List-Unsubscribe header for email notifications (and maybe List-Help, List-Subscribe etc.).

I filed the standard DKIM/SPF tasks we (eventually) do for all domains, but I'm not going to file the defects in Phabricator itself.

In T115416#1735322, @JKrauska wrote:

@Nemo_bis: can you cross reference the 'bad'ness of the emails that's been reported?

No, sorry. See:

In T115416#1732681, @Nemo_bis wrote:

I'm not going to waste time triaging Phabricator and Gerrit reports; I already spent enough time filing them. Perhaps the maintainers of those components should retriage the mail-related reports.