Subject: [apps-discuss] Registering email status codes for authentication failures

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 May 2014 14:32:15 -0700

A while ago I did this short draft:

https://datatracker.ietf.org/doc/draft-kucherawy-email-auth-codes/

...and then promptly forgot about it.  Given that email authentication is
front-and-center these days, is it worth updating it and then pushing it
through?  Given its size, does anyone have thoughts about processing it
through APPSAWG?

-MSK, not in any particular role this time

---

From: Ned Freed <[email-masked]>
Date: Wed, 07 May 2014 15:01:12 -0700 (PDT)

> through?  Given its size, does anyone have thoughts about processing it

First, there needs to be a discussion about whether DKIM-specific or
DMARC-specific codes are what's called for. I can argue this either way

Second, regardless of the outcome of that discussion, this needs to be at least
referenced by the DMARC specification, if not incorporated into it.

Third, doing this in appsawg seems like as good a place as any.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 May 2014 15:26:33 -0700

> DMARC-specific codes are what's called for. I can argue this either way

I was thinking the DMARC draft, since it's active, could be adjusted to
include such a definition rather than doing that here.  This one can then
proceed while the DMARC debate resolves.

> referenced by the DMARC specification, if not incorporated into it.

Sure.

> Third, doing this in appsawg seems like as good a place as any.

Thanks.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 May 2014 23:12:58 -0400

> > Third, doing this in appsawg seems like as good a place as any.

Does anyone have information on how MTAs handle unknown result codes?  For RFC 
4408/7208 we stayed with existing ones.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 May 2014 21:38:40 -0700

> 4408/7208 we stayed with existing ones.
Are there any that pay attention to them at all, other than to present them
in DSNs and logs?   For example, I don't think there's much difference
between 554 and 554 with a status code in terms of what an MTA is likely to
do with the message.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Thu, 08 May 2014 01:27:18 -0700 (PDT)

> between 554 and 554 with a status code in terms of what an MTA is likely to

First, mailing list managers most certainly do parse DSNs and pay attention to
the codes they find in them.

Second, this is getting to be seriously annoying. You can't on the one hand
claim mailing list managers are unwilling to change things while failing to
provide the information that would, you know make it worth their while to
actually make some changes.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 8 May 2014 10:41:53 +0200

> actually make some changes.

+1

Publish, please.

Arnt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 May 2014 06:26:22 -0700

> the codes they find in them.

Maybe, and that's good to hear if so, but the question Scott asked was
about MTAs, not MLMs.  I don't remember any code in sendmail, for example,
that acted on enhanced status codes specifically.  That was the nature of
my question.

> actually make some changes.

As far as I know, I ever claimed that MLMs are unwilling to change.  In
fact, I was the one who challenged their immutability.  I'm also the one
offering to do the work on both documents to make these codes available.
So really, what's the problem here?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 8 May 2014 20:31:09 -0000

>between 554 and 554 with a status code in terms of what an MTA is likely to

The conventional MTAs I know do little beyond looking at the first digit.

ESPs, on the other hand, do all sorts of mind reading games with
status codes and messages to try and guess whether the bounce was a
"real" one.

R's,
John

---

From: Terry Zink <[email-masked]>
Date: Thu, 8 May 2014 22:26:22 +0000

Could we include the following:

      Code:               X.7.22
      Sample Text:        SPF validation failed and DKIM validation failed
      Associated basic status code:  5
      Description:        This status code is returned when a message
                          failed an SPF check, and also failed to validate DKIM
                          for any reason, contrary to local policy requirements.

The reason for this is that there are some policy requirements (e.g., sending email over IPv6) that require both conditions, and none of the codes in the existing draft say that both are required. Without it, it could give an incomplete message back to the sender.

-- Terry

-----Original Message-----
From: apps-discuss [mailto:[email-masked]] On Behalf Of John Levine
Sent: Thursday, May 8, 2014 1:31 PM
To: [email-masked]
Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures

R's,
John

_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Ned Freed <[email-masked]>
Date: Thu, 08 May 2014 09:52:13 -0700 (PDT)

> about MTAs, not MLMs.

Our MTA includes extensive MLM and gateway functionality, some of which pays
attention to enhanced status code values. (And it handles unknown codes just
fine.)

More generally, there's a big difference between the MTA abstration and actual
MTA implementations.

And I assume Scott was talking about the latter, not the former. If he was
talking about the former, then the question is essentially vacuous since the
abstract model is defined by the standards and essentially says that (1) MTAs
only act on the first digit of the primary status code and (2) Any agent
looking at an extended status code is supposed to fall back to the more general
part of the code if it doesn't recognize a specific value.

> I don't remember any code in sendmail, for example,

> So really, what's the problem here?

I ended up conflating a more general, and much more pernicious issue into this
discussion. Let me try again.

My issue is the implied double standard. SPF and DMARC have harmed existing
deployed agents despite the fact that that those agents, are, AFAICT, operate
entirely within the scope of what our standards allow and even condone. And we
allowed one of these to be published as an RFC and it seems the other is about
to be.

Now we're considering defining a couple of error codes with the express purpose
of trying and mitigate a bit of the damage that's been done. And this is being
done in a way which, as I noted above, is not only allowed, an agent would have
to incompliant to have an issue. Yet now we seem to be asking, "Do such
incompliant agents exist", with the clear implication that it would be a
problem for this proposal if they do.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 May 2014 20:46:16 -0700

On Thu, May 8, 2014 at 3:26 PM, Terry Zink <[email-masked]>wrote:

> The reason for this is that there are some policy requirements (e.g.,
> sending email over IPv6) that require both conditions, and none of the
> codes in the existing draft say that both are required. Without it, it
> could give an incomplete message back to the sender.

This seems slippery slope-ish to me.  When DKIM comes out, do we also need
to register a set for each of the possible {SPF, DKIM, DMARC} combinations?

Seems to me you should pick the most serious or comprehensive one, or worst
case pick any one that applies, and return that.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 09 May 2014 00:54:23 -0400

On Thursday, May 08, 2014 09:52:13 Ned Freed wrote:
> attention to enhanced status code values. (And it handles unknown codes
> just fine.)
> 
> More generally, there's a big difference between the MTA abstration and
> actual MTA implementations.
> 
> abstract model is defined by the standards and essentially says that (1)
> MTAs only act on the first digit of the primary status code and (2) Any
> agent looking at an extended status code is supposed to fall back to the
> more general part of the code if it doesn't recognize a specific value.
> 
> I ended up conflating a more general, and much more pernicious issue into
> this discussion. Let me try again.
> 
> deployed agents despite the fact that that those agents, are, AFAICT,
> operate entirely within the scope of what our standards allow and even
> condone. And we allowed one of these to be published as an RFC and it seems
> the other is about to be.
> 
> Now we're considering defining a couple of error codes with the express
> purpose of trying and mitigate a bit of the damage that's been done. And
> this is being done in a way which, as I noted above, is not only allowed,
> an agent would have to incompliant to have an issue. Yet now we seem to be
> asking, "Do such incompliant agents exist", with the clear implication that
> it would be a problem for this proposal if they do.

My question was nothing so nefarious.  This is the first time I've run across 
adding new codes, so I didn't know how it would work out.  I'm not familiar 
with what the standards say about new/unknown codes.  If it shouldn't be an 
issue, then that's great.

It would have been nice to have this conversation before RFC 7208 was finished, 
but you can't have everything.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 9 May 2014 05:02:18 -0000

>to register a set for each of the possible {SPF, DKIM, DMARC} combinations?

I'm not at all sure this is a rathole we want to go down, but if we do
it seems to me it would be more useful to describe the failures at a
policy rather than mechanism level, e.g. "not enough authentication
for channel" or "not enough authentication for sender policy."  The
details can be in the text, but the point of carving it up this way is
that the former tells the MTA that it might be worthwhile to send it a
different way, while the latter says there's something wrong with the
message (from the receiver's point of view.)

---

From: S Moonesamy <[email-masked]>
Date: Thu, 08 May 2014 23:03:28 -0700

Hi Terry,
At 15:26 08-05-2014, Terry Zink wrote:
>The reason for this is that there are some policy requirements 
>(e.g., sending email over IPv6) that require both conditions, and 
>none of the codes in the existing draft say that both are required. 
>Without it, it could give an incomplete message back to the sender.

The above suggestion looks practical.  The downside is that it is a 
path leading to a list of codes to describe local policy 
requirements.  There is a combination of two IETF technologies.  It 
looks odd to express the failure through one code.

Regards,
S. Moonesamy

---

From: t.petch <[email-masked]>
Date: Fri, 9 May 2014 10:07:29 +0100

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "Terry Zink" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, May 09, 2014 4:46 AM
> >                           failed an SPF check, and also failed to
validate
> > DKIM
(e.g.,
> to register a set for each of the possible {SPF, DKIM, DMARC}
combinations?

No, we just use the traditional programmer's technique of coding it in
binary, 1 for SPF, 2 for DKIM, 4 for DMARC, 8 for the next iteration in
what is, has been and looks likely to remain a major issue in Internet
traffic.  If needed, you can add these values to a base, to lift them
out of any existing range.

And we are talking of fairly substantial protocols, SPF, DKIM, worth
treating as distinct.

Tom Petch

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 9 May 2014 11:32:39 +0200

There's always been cases where several status codes were possible, e.g.
5.2.x+5.4.y. AFAICT servers generally report whichever issue they notice 
first, which is perhaps not perfect but has been good enough for a long 
time. Why does SPF+DKIM warrant more protocol treatment?

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Fri, 9 May 2014 10:48:50 +0100

On 9 May 2014 10:32, Arnt Gulbrandsen <[email-masked]> wrote:

> There's always been cases where several status codes were possible,

I wonder if it's worthwhile allowing multiple codes to be reported? Should
be trivial to specify.

---

From: Terry Zink <[email-masked]>
Date: Fri, 9 May 2014 16:48:33 +0000

> Why does SPF+DKIM warrant more protocol treatment?

For clarity to the end user. If a message is rejected because neither Condition 1 nor Condition 2 is met, then it is more accurate to say to the end user that neither condition was met. Saying only Condition 1 wasn't met misleads the sender into thinking that either Condition 2 was met, or that it isn't a requirement. This is incorrect and a bounce should reflect that.

-- Terry

-----Original Message-----
From: apps-discuss [mailto:[email-masked]] On Behalf Of Arnt Gulbrandsen
Sent: Friday, May 9, 2014 2:33 AM
To: [email-masked]
Subject: Re: [apps-discuss] [ietf-smtp] Registering email status codes for authentication failures

Arnt

---

From: Ned Freed <[email-masked]>
Date: Sat, 10 May 2014 16:10:42 -0700 (PDT)

> message (from the receiver's point of view.)

Bingo. This is what I was referring to when I said that I was unsure whether
we want to record a DKIM or DMARC failure.

Unless we're now attaching DKIM signature failures exclusively to DMARC - and I
don't think we are - telling me that the message was rejected due to a DKIM
failure doesn't tell an MLM anything useful. What if it was some other DKIM
signature on the message? What if the list itself attached a signature and
a problem at the receving end caused the signature to fail to verify?

Contrast this with saying "Rejected because of DMARC policy". This tells a MLM
something useful: It says that domain shown in the From: field of that message
has a policy that is incompatible with the list. In this situation a list
could, given sufficient failures of this sort, revoke that sender's right to
post. Or all senders in that domain. Instead of revoking the recipient's right
to receive list mail.

The more I think about it the more convinced I am that DMARC-specific codes
(or if you prefer, a "policy attached to the domain in the from field" code)
is the right way to go here.

				Ned

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 10 May 2014 19:36:49 -0400

On Saturday, May 10, 2014 16:10:42 Ned Freed wrote:
> Unless we're now attaching DKIM signature failures exclusively to DMARC -
> and I don't think we are - telling me that the message was rejected due to
> a DKIM failure doesn't tell an MLM anything useful. What if it was some
> other DKIM signature on the message? What if the list itself attached a
> signature and a problem at the receving end caused the signature to fail to
> verify?
> 
> Contrast this with saying "Rejected because of DMARC policy". This tells a
> MLM something useful: It says that domain shown in the From: field of that
> message has a policy that is incompatible with the list. In this situation
> a list could, given sufficient failures of this sort, revoke that sender's
> right to post. Or all senders in that domain. Instead of revoking the
> recipient's right to receive list mail.
> 

Do you think there should be SPF specific codes too since, unlike DKIM, it has 
it's only policy function (and currently recommends what codes one should 
use)?

Scott K

---

From: Ned Freed <[email-masked]>
Date: Sat, 10 May 2014 17:22:57 -0700 (PDT)

> it's only policy function (and currently recommends what codes one should

Sorry, I meant to address that and forgot to. The answer is yes, since SPF
implements a different policy it deserves its own policy codes.

That said, this isn't as urgent since DMARC is the a case where automatic
actions are facilitated by using the codes. I don't see a comparable case for
SPF. 

But of course on something like this I could easily be missing something. We
all to some extent see this stuff through the prism of our own implementations
and experiences.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 10 May 2014 18:03:02 -0700

> all to some extent see this stuff through the prism of our own

I think this document should register distinct codes for DKIM and SPF, for
operators that don't do DMARC but might reject for either of those.

Registering a DMARC code is also certainly a good idea, but wouldn't it be
better to handle that as part of the DMARC document itself?  Otherwise, to
what normative thing would a DMARC code registration refer?

-MSK

---

From: Ned Freed <[email-masked]>
Date: Sat, 10 May 2014 18:13:49 -0700 (PDT)

> operators that don't do DMARC but might reject for either of those.

And as always use the most specific code available... that works for me.

> what normative thing would a DMARC code registration refer?

Quite right. If that's possible it's definitely the way to go.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Sun, 11 May 2014 00:34:46 -0400

> through?  Given its size, does anyone have thoughts about processing it

Murray asked me about this separately, after posting it here.  As I
was a bit behind on following this list, I didn't know he'd started a
discussion here until I'm catching up now.

Apart from a few editorial things, here's what I said to Murray.
Some, but not all of this has been discussed here already, so add this
as strong support for addressing it:

On a broader level, keep in mind that 6376 says this (Section 6.3):

   In general, modules that consume DKIM verification output SHOULD NOT
   determine message acceptability based solely on a lack of any
   signature or on an unverifiable signature; such rejection would cause
   severe interoperability problems.

and this (Section 6.3):

   If the email cannot be verified, then it SHOULD be treated the same
   as all unverified email, regardless of whether or not it looks like
   it was signed.

The two DKIM codes seem to encourage, or at least support, violation
of both of these.

Further, what code do I return if I check both SPF and DKIM, and both
checks fail?  Does it really make sense to have these as three
different extended codes?  Or might it makes sense to have one code
that says "sender verification failed," with a description that says
that no sender verification mechanism succeeded, and policy requires
successful verification?  It might then go on to explain that the
requirement could come from local policy or from some communication of
sender policy to the receiving domain.

This point's a complicated one, and I'm happy if you don't address it
now, and we address it on the mailing list.

Barry, Applications AD

---

From: Ned Freed <[email-masked]>
Date: Sat, 10 May 2014 23:08:01 -0700 (PDT)

> The two DKIM codes seem to encourage, or at least support, violation

That's a fair point.

> different extended codes?

It's always been possible for there to be multiple failures happening
at the same time. Which code gets returned in such cases is an implementation
judgement call. (Or perhaps more likely, it's what gets checked first.)

> Or might it makes sense to have one code
> successful verification?

No, because "sender" means two different thing with DKIM and SPF, and
a big part of the reason for having these code is to distinguish the
From: header field verification failure case.

> It might then go on to explain that the

Explanations can't be parsed by MLMs and used to take distinct action.
(Well, actually they can, and regrettably it's sometimes necessary,
but we shouldn't be encouraging it.)

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 10 May 2014 23:39:11 -0700

> > The two DKIM codes seem to encourage, or at least support, violation

Indeed.  The example that stands out to me is a receiver that always
expects mail from a particular author domain to have a valid signature, and
suddenly it doesn't.  This might be through ADSP, through some heuristic,
or through some private arrangement with the author domain's ADMD.

There might be something in the mix here about DMARC too, perhaps to
indicate that DKIM failed and SPF was neutral, so report the failure.
(Until there's a DMARC code, of course.)

It shouldn't happen in typical DKIM operation, however, so I've got no
problem reminding readers of this draft of the citations you made above.

> judgement call. (Or perhaps more likely, it's what gets checked first.)

+1.

-MSK

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 11 May 2014 14:29:13 +0200

Terry Zink answers me:
> For clarity to the end user. If a message is rejected because 
> neither Condition 1 nor Condition 2 is met, then it is more 
> accurate to say to the end user that neither condition was met. 
> Saying only Condition 1 wasn't met misleads the sender into 
> thinking that either Condition 2 was met, or that it isn't a 
> requirement. This is incorrect and a bounce should reflect that.

Clarity is desirable, but... the DNS generators I know generally take 
either a short-circuit approach where they stop as soon as they know the 
result of one test (e.g. "DKIM failed, SPF would fail too but I stopped 
before learning so"), or a scoring approach ("score=-4.8, required=12.0, 
dkim=passed, spf=failed, ..").

So the approach you want is clear, yes, but one group doesn't have the 
information and the other has much more. That group can mix 2.a.b with 
5.c.d to form either 2.e.f or 5.e.f, so reporting that in a usefully 
parsable way will be challenging. More bother than it's worth, IMO.

Arnt

---

From: Barry Leiba <[email-masked]>
Date: Tue, 13 May 2014 13:54:23 -0400

> Indeed.  The example that stands out to me is a receiver that always expects
> mail from a particular author domain to have a valid signature, and suddenly
> it doesn't.  This might be through ADSP, through some heuristic, or through
> some private arrangement with the author domain's ADMD.
>

I'm concerned about more than "reminding readers".  The issue here is
that the message was not bounced because of a broken DKIM signature or
a missing one.  It was bounced because of a policy that was triggered
by the lack of a valid DKIM signature, and that policy is something
that's outside of DKIM entirely.  I'm very unhappy with the idea of
returning a code that's explicitly documented to mean "there was no
DKIM signature on the message", without being tied to the policy.

I would be much happier with a code that was defined to mean "I
bounced this because I have a policy that requires a valid DKIM
signature from the From domain, and this message lacks such a
signature."

The situation for SPF is somewhat different, because SPF does have
policy information as part of it.

>> judgement call. (Or perhaps more likely, it's what gets checked first.)

That's a facile answer, and not a very helpful one.  Perhaps this
would/will all be made better when DMARC adds a similar code that says
"bounced because DMARC checks failed," and those who implement DMARC
would then never return one of these, but would instead return that
one.

The point here, I guess, is that if I'm really bouncing this because
the SPF check failed, regardless of what happened with DKIM, then
returning the SPF code is fine.  But if I'm bouncing this because the
combination of SPF *and* DKIM checks failed, then I'm giving
incomplete information about the bounce -- and I contend that it's
sufficiently incomplete as to be seriously misleading (because SPF
failures and DKIM failures happen for different reasons, if I care at
all I need to see the whole picture.

Here: SPF checks will *always* fail when you send mail to me at
<[email-masked]>.  So we're relying on the DKIM signature.
If there's no valid DKIM signature and you bounce it with the SPF
code, that's not useful information: we *know* SPF will fail.  If you
don't (also?) give the DKIM information, it's of no help.

Barry

---

From: Ned Freed <[email-masked]>
Date: Tue, 13 May 2014 18:15:44 -0700 (PDT)

> > some private arrangement with the author domain's ADMD.

But the point is this is a failure due to policy. The fact that the policy
was implemented via DKIM is secondary and not really of interest to an
automatic processor.

> that's outside of DKIM entirely.

Exactly.

> I'm very unhappy with the idea of

For my part, I think we worry excessively about defining codes, and end up with
far too few codes available. I don't care if this gets defined  as long as
DMARC and similar policy schemes specify the codes that are to be used
preferentially in such cases.

> signature from the From domain, and this message lacks such a

Exactly.

> policy information as part of it.

It's a different situation, but not for this reason. Mitigating SPF issues is
not something which, AFAIK, is amenable to automatic processing. Whereas
mitigating DMARC policy failures is. This makes codes for SPF policy failures a
"nice to have", but DMARC codes are more important.

> would then never return one of these, but would instead return that

Well, it's a statement of reality, facile or not, helpful or not. You might as
well worry about the agents that refuse to implement any specific codes and
always return 5.0.0 for everything. Or return the wrong codes. Yes, people are
lazy and such implementations exist. It's not an argument against defining new
codes, especially when those codes have real utility.

There always has to be some degree of trust that server implementors will
either know to use, or can be persuaded to use, codes that help clients do the
right thing.

> don't (also?) give the DKIM information, it's of no help.

This example makes no sense to me. You seem to be conflating an  incidental SPF
failure with reporting actual errors. If the SPF failure does not, in fact,
cause the message to fail to be delivered due to whatever SPF policy is in
effect, then it has no business being reported. And if SPF policy is what
causes the failure, it's likely to cause a failure at the MAIL FROM, before
DKIM evaluation can occur.

Or perhaps you're talking about a failure of DMARC policy, where the underlying
failure can be either an SPF or DKIM check or even - if my understanding is
correct - a cross check between the From: and MAIL FROM having nothing to do
with DKIM or SPF failures per se. In such a case I don't see why an automatic
processor would care: It knows that whatever policy is linked to the From:
header field, and can act accordingly.

Remember: The utility of having detail in enhanced status codes is primarily
for automatic processing. (And yes, I'm aware of the stuff in NOTARY that says
they're to be used for internationalization. I'll pay attention to that the
minute someone shows me a widely deployed client that actually does this, along
with the use-case where reporting a specific translated code to an end user had
some actual value.)

Nothing prevents elaboration of what failed in the text message associated with
the code. So unless you can explain why an autoamatic processor dealing with a
DMARC failure would care about the failure being because of SPF, DKIM,
something else, or a combination of those factors, I fail to see the point.

Now there are admittedly cases where more complex things happen, such as with
SpamAssassin where a wide variety of checks are done, each contributing to an
overall score, and the message is rejected if that score exceeds some
thresshold. (Or more likely, silently discarded, making error reporting moot.)
While it might conceivably have been nice to somewhat align such schemes with
enhanced status codes, I think that ship has sailed.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 May 2014 00:42:20 -0700

On Tue, May 13, 2014 at 6:15 PM, Ned Freed <[email-masked]> wrote:

> [...]

Sure, that's fine with me.

-MSK

---

From: t.petch <[email-masked]>
Date: Wed, 14 May 2014 14:17:51 +0100

I am seeing
X-Google-DKIM-Signature
in the headers of some of the mail I get on IETF lists but struggle to
see how it can be being used.  Who is going to verify a Google
proprietary signature?

Can anyone clarify this for me?  I am familiar with DKIM and its various
policy RFC.

To all intents and purposes, it looks like a regular DKIM signature,
v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=...
        bh=...
        b=...
etc

Tom Petch

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 May 2014 11:43:55 -0700

> see how it can be being used.  Who is going to verify a Google

As I understand it, that's an internally generated signature that's given
different handling of some kind by other internal agents.  It's not meant
to be consumed by anyone outside of Gmail, though it is otherwise a valid
DKIM signature.

-MSK