Just saw this in a message tonight. No idea if this is a transient error or not.
In article <alpine.DEB.2.00.1401141859270.4083@orbital.burn.net> you write:
Just saw this in a message tonight. No idea if this is a transient error
or not.
I saw the same thing, on an IP that has forward and reverse DNS and
mail that passes SPF. Burp, I guess.
I have been running into these a lot also and have so far concluded that
it is an error within Google. The PTR/AAAA, SPF and DKIM are all matched
up and tested as working. It also occurring on domains using google apps
to handle their email so it is platform wide. All of the emails are
personal emails, but coming from multiple domains/senders.
The exact same email will be rejected when sent to any google IPv6
server for minutes/hours, but 3-4 hours later it will be accepted
without error.
The fact that it is being hard rejected is really quite annoying and
generating a lot more support work.
Unfortunately, my only fix at present is to turn off IPv6 delivery for
all google hosted domains as I encounter them. It would be really nice
if it was fixed.
My theory is that they are failing PTR lookups.
Off-list replies are fine to minimize noise, and if there is an answer
or any meaningful correlation I will reply on-list. Thanks in advance
for any info/feedback.
brandon, I didn't get your original... but could you ping me off-list
and maybe I can get some data about what it is you're seeing? 
FWIW I do know there was a MASSIVE failure last night around 0800 UTC with
Google's DNS system, and it caused their routing to not only go bat shit
insane, but also for the edge nodes that serve their content to return
largely 503 errors (service unavailable) for several hours.
It wasn't until a few hours ago that the BGP table stabilized. It was a
horrific mess last night...not sure if perhaps there's still problems
unresolved from that same incident.
Possibly related, a lot of 503 errors are starting to show up in the
javascript served by Google inside Gmail...reminds me of the issue in the
early morning hours (US time)...very similar to what I'm starting to see on
the front end. I've not had any IPv6 emails bounce, but I do have some
that are MIA from Google Apps. They were sent from one GApps domain to
another, but they haven't materialized on the other end...but they also
haven't bounced back to me.
As a matter of curiosity, I also sent my personal Gmail account email over
v6, and it's doing the same thing...either it's delayed or it's going to
bounce.
The front-end of Gmail is starting to behave weirdly, as well, spitting out
bizarre errors like "technical code: undefined", and saying it wasn't able
to send a message, but the message going through. There's a fair amount of
chatter about this on Twitter, so I know it's not just me.
It also thinks it's offline in one tab, when an account in another is
perfectly fine. Maybe a DC somewhere is having trouble again?
Just saw this in a message tonight. No idea if this is a transient error
or not.
Got one too for AS197422 at "Tue, 14 Jan 2014 23:59:01 +0100", resent
the mail at "Wed, 15 Jan 2014 00:03:12 +0100" and it worked so probably
transient.
Laurent
host
gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1a] said: 550-5.7.1
[2a01:6600:80xxx] Our system has detected that this message
550-5.7.1 does not meet IPv6 sending guidelines regarding PTR
records and
550-5.7.1 authentication. Please review 550-5.7.1
Email sender guidelines - Google Workspace Admin Help for
more 550
5.7.1 information. hg12si1854476wib.39 - gsmtp (in reply to end of
DATA
command)
Arrival-Date: Tue, 14 Jan 2014 22:59:01 +0000 (UTC)
I saw a number of these as well but in my case the bracketed IP addresses were malformed. For example:
host gmail-smtp-in.l.google.com[2607:f8b0:4002:c01::1a] said: 550-5.7.1 [2607:fc50:1000:1f00::2 16] Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines...
https://support.google.com/mail/answer/81126?hl=en#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.
The sending domain should pass either SPF check or DKIM check. Otherwise, mail might be marked as spam.
My point was that Google told me it rejected "2607:fc50:1000:1f00::2 16". In this case, 2607:fc50:1000:1f00::2 is the correct address, but it appeared (to me) that Google's data was somehow corrupt.
I'm pretty sure the IPv6 address format doesn't allow spaces. 
Ah yes, the confusion with the separator between IP and ports.
IPv4:port
IPv6.port
That gets a lot of regex confused...
I could not reproduce the error during a telnet test.
However, I see a substantial number of outgoing 550 5.7.1 rejects that
look just like that, mixed in with accepted mail to gmail.com.
So it would appear to be transient, but ongoing.
And more than a bit troublesome, since it is shown as a 550 reject, and
delivery therefore will not be deferred and retried appropriately.
Jan 15 15:41:29 [...] Failed "Site gmail.com (2607:f8b0:4002:c01::1a) said
after data sent: 550 5.7.1 more information. q48si1281225yhb.127 - gsmtp
550-5.7.1 [2607:f360:0:1f0::40:2f00 12] Our system has detected that
this"
Ah yes, the confusion with the separator between IP and ports.
IPv4:port
IPv6.portThat gets a lot of regex confused...
Especially since IPv4:port works, while IPv6:port usually does not and you usually need [ipv6]:port.
Owen
It occurs to me, you may have sent a bounce, where the envelope from is empty, therefore SPF would work on the domain in the helo/ehlo. People often forget to put a SPF record there... So there may be no SPF in fact...
https://dmarcian.com/spf-survey/orbital.burn.net
http://trac.tools.ietf.org/html/draft-ietf-spfbis-4408bis-21#section-10.1.3
It occurs to me, you may have sent a bounce, where the envelope from is empty, therefore SPF would work on the domain in the helo/ehlo. People often
forget to put a SPF record there... So there may be no SPF in fact...
Nope. In this case, Google was just messed up.
R's,
John