As reported on meta.trac it appears that smtp-fwd is lacking the rDNS which might explain why we’re seeing a higher level of slack invite failures of recent.
Could we add a reverse DNS for that mail forwarder please?
FYI; SPF and DKIM appear to be succeeding according to gmail.
One of the servers seems to not be updating for planet.wordpress.org. Every once in a while you can refresh the site and will get a page from December. Like one of the webservers isn’t updating properly or otherwise not running the process.
I have no visibility into the production servers, so can somebody take a look and see if one of them is “stuck” somehow?
Kathryn Presner has notified us that she is not receiving some emails from Themes Trac. I’ve been investigating this issue and found that the emails do get sent out, but they are sometimes broken – they are sometimes missing the ‘To’ header.
I’ve tried to find the root cause of this, but with no luck. Our trac install has plenty of custom modules, and a few local patches. One of them does modify the notification.py file, but i couldn’t locate any code that could cause this issue.
I’ve looked through the themes mailbox for automattic user, and found around ~1100 emails since 2014 that did not contain the To header (and were from themes trac), which is quite a big number as there’s not that many emails coming from themes trac.
Can somebody who has worked with customising / writing patches for wporg Trac have a look at this issue? I know @nacin did some, not sure who else.
An example comment for which the To header was missing is this one. I can find more if needed.
Example raw content of a broken email:
Received: from localhost (localhost.localdomain [127.0.0.1])
by smtp1.lax.automattic.com (Postfix) with ESMTP id 4D01C16C605A;
Tue, 3 Jan 2017 20:25:43 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at wordpress.com
X-Spam-Status: No, score=0.072 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
REPLYTO_WITHOUT_TO_CC=1.552, RP_MATCHES_RCVD=-0.5, SPF_PASS=-0.001]
Authentication-Results: smtp1.lax.automattic.com (amavisd-new);
dkim=pass (1024-bit key) header.d=wordpress.org;
domainkeys=pass (1024-bit key) firstname.lastname@example.org
Received: from smtp1.lax.automattic.com ([127.0.0.1])
by localhost (smtp1.lax.automattic.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id mji5gHMhfkVq; Tue, 3 Jan 2017 20:25:42 +0000 (UTC)
Received: from mail.wordpress.org (lb2.lax.wordpress.org [22.214.171.124])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by smtp1.lax.automattic.com (Postfix) with ESMTPS id D818016C6094
for <email@example.com>; Tue, 3 Jan 2017 20:25:42 +0000 (UTC)
Received: from mail.wordpress.org (localhost.localdomain [127.0.0.1])
by mail.wordpress.org (Postfix) with ESMTP id BA70D214159;
Tue, 3 Jan 2017 20:25:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=wordpress.org; h=
:reply-to:subject:message-id:references:in-reply-to; s=wp1; bh=4
DomainKey-Signature: a=rsa-sha1; c=nofws; d=wordpress.org; h=
:reply-to:subject:message-id:references:in-reply-to; q=dns; s=
Content-Type: text/plain; charset="utf-8"
From: "WordPress Themes" <firstname.lastname@example.org>
X-Mailer: Trac 1.0.1, by Edgewall Software
X-Trac-Project: WordPress Themes
Date: Tue, 03 Jan 2017 20:25:13 -0000
Requesting a sandbox for @goldsounds, so he can help debug a Jetpack sync issue. Meta commit access is not needed. You can use his Automattic ssh key.
git.develop is being mirrored by GitHub, but their mirror process only checks every few hours, which is way too slow to be useful. Instead, we want to replace it with a
To do that, we need a deploy key created, per GitHub’s docs.
The private key needs to live on the git server, either in ssh agent, or with a reference in the ssh config file:
The push command then needs to be added to the
git push -f --mirror email@example.com:WordPress/wordpress-develop.git
I’d like to get this done quickly, so we can get GitHub integrations up and running. Thanks!
Hi, can you please setup proxy access for @kimhustad? She’ll be helping out with bookkeeping and will need access to the WordCamp.org budgeting tools.
Her public key is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCY5whCd2F7ZDsomK6yFJO4hlGo3iqxVJM/k2MVP31oXlusv2/KVFAtkawNKLaGk6SsSst2UZTTxJF76w4gQJiDSVlGZk54E5p+VR3jIv5api4LqbYwL7ibb12aaaq1a9l1qrW0faMIdJGZNXjpncPnjGSBbGM+gXXpV91s1LC/BzkL2dbog1AzwVW5aoplWJAj473klpSPzTnHK+/KAHYHmLN/v5P3XdRuC7LzdWSphaT7L413pe+BrjHSxlgZWHbFscMyv2VAjNwE6e3XJqwhC6XVz/IOtkmTQK/gqWgxA4W8nIW3FjmVmW4VbSEOH41FRergEJlH6K4SfC3ir2+9 automatticaccounting@Automattics-MacBook-Pro.local
As wp.org is now a WordPress.org domain, can we please get SSL enabled for it?
ref https://wordpress.slack.com/archives/meta/p1480801420000002 / https://wordpress.slack.com/archives/meta/p1480909161000077
Can we please disable the ticket update module on plugins.trac?
Since plugins.trac is mostly unusable, many plugin authors use Github and sync over changes. Unfortunately many of these include commit messages which includes “closes #123” or “fixes #123” which ends up with many people subscribed to tickets on trac, for example:
https://plugins.trac.wordpress.org/ticket/1 & https://plugins.trac.wordpress.org/ticket/2
It looks like we can simply disable the
Commit Ticket Updater trac module?
$ curl -I https://downloads.wordpress.org/release/wordpress-4.6.1.zip
HTTP/1.1 200 OK
Date: Thu, 24 Nov 2016 09:33:22 GMT
Content-Disposition: attachment; filename=wordpress-4.6.1.zip
Last-Modified: Wed, 07 Sep 2016 14:59:22 GMT
X-nc: HIT lax 189
The header was added 5 years ago in [dotorg5308]. [dotorg7078] added
X-Accel-Redirect which may be the reason for the missing header now. To quote @dd32:
IIRC even when sent by PHP, when it’s a X-Accel-Redirect it needs to be whitelisted in nginx.. I think we’ve enabled it and never pushed a change into nginx..
As reported in https://meta.trac.wordpress.org/ticket/1860 W.org is responding incorrectly for certain requests, I’m unsure what the cause is and whether it’s a nginx config or not.
Here’s a cURL command to reproduce:
$ curl -v 'https://wordpress.org/plugins/search.php?page=2&q=plugin'
* Trying 126.96.36.199...
* Connected to wordpress.org (127.0.0.1) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.wordpress.org
* Server certificate: Go Daddy Secure Certificate Authority - G2
* Server certificate: Go Daddy Root Certificate Authority - G2
> GET /plugins/search.php?page=2&q=plugin HTTP/1.1
> Host: wordpress.org
> User-Agent: curl/7.43.0
> Accept: */*
* Empty reply from server
* Connection #0 to host wordpress.org left intact
curl: (52) Empty reply from server
This is lowest of the low priorities, more as a FYI. The plugin directory will hopefully retire soon and this isn’t reproducible against the new directory, most likely due to the change from query variables to rewrites. If this is a
wontfix I don’t think anyone will mind.