Subject: Re: [apps-discuss] draft-ietf-appsawg-email-auth-codes

From: Scott Kitterman <[email-masked]>
Date: Sun, 01 Jun 2014 14:09:59 -0400

I've reviewed the draft.  I support publication after resolution of some comments. 

RFC 7208 section 8 makes different recommendations based on SPF result.  By aggregating SPF failures into a single result code, I am afraid we're losing information not gaining it in some cases. 

If we could have a x.something for SPF verification failures and an x.something_else for SPF error results, I believe it would be useful and consistent with RFC 7208.

The former would be for verification failures that met local policy for rejection and the latter would be for SPF errors (5.x for permerror and 4.x for temperror).

This would allow for the new specificity that this is about SPF without losing the RFC 7208 distinction between verification failures and error conditions. 

I am concerned about the DKIM codes. By design, DKIM doesn't give any basis for rejection. DKIM in particular doesn't tie the signature domain to any identities in the message.  I believe the idea of author domain signed messages is foreign to DKIM.

Much of what is in the draft about DKIM could is really about either completely private out of band arrangements or DMARC.  I think the DKIM codes should probably be moved to the DMARC draft.

The others make sense.

If DKIM is covered, I think covering TLS makes sense to include too.  Closely related, I wonder about DANE SMTP verification failures.?

Scott K

---

From: Ned Freed <[email-masked]>
Date: Sun, 01 Jun 2014 16:02:52 -0700 (PDT)

> If we could have a x.something for SPF verification failures and an
> x.something_else for SPF error results, I believe it would be useful and
> consistent with RFC 7208.

> The former would be for verification failures that met local policy for
> rejection and the latter would be for SPF errors (5.x for permerror and 4.x for
> temperror).

> This would allow for the new specificity that this is about SPF without
> losing the RFC 7208 distinction between verification failures and error
> conditions.

This seems reasonable to me. Our implementation of SPF already makes the
distinction in regards to the error text that's returned.

> I am concerned about the DKIM codes. By design, DKIM doesn't give any basis
> for rejection. DKIM in particular doesn't tie the signature domain to any
> identities in the message.  I believe the idea of author domain signed messages
> is foreign to DKIM.

That may be the design and the intent. It's not the reality on the ground.
Error code assignments need to reflect the reality on the ground.

> Much of what is in the draft about DKIM could is really about either
> completely private out of band arrangements or DMARC.  I think the DKIM codes
> should probably be moved to the DMARC draft.

I used this was the right thing to do. I no longer think so. I think
these codes need to be in a general error code definition document so
that the next policy enforcment mechanism defined along these lines (we're
on our third, remember) will have them available. If you put them alongside
a specific policy mechanism it will be taken to mean that those codes
are for that mechanism specifically.

> If DKIM is covered, I think covering TLS makes sense to include too.  Closely
> related, I wonder about DANE SMTP verification failures.?

I'll first note that codes for TLS have limited utility since the usual
result of a TLS negotiation failure is a broken connection and no opportunity
to return any sort of code. That said, a subsequent policy check can fail,
in which case it may make sense to have some codes defined.

But since the entire TLS in SMTP space is in the process of being
reworked with DANE and such, I think it's best to wait for that work
to define the necessary codes.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 Jun 2014 10:46:53 -0700

On Sun, Jun 1, 2014 at 11:09 AM, Scott Kitterman <[email-masked]>
wrote:

> RFC 7208 section 8 makes different recommendations based on SPF result. By
> aggregating SPF failures into a single result code, I am afraid we're
> losing information not gaining it in some cases.
>
> rejection and the latter would be for SPF errors (5.x for permerror and 4.x
> for temperror).
>

Seems reasonable to me as well.  I'll add this for the next version.

> I am concerned about the DKIM codes. By design, DKIM doesn't give any
> basis for rejection. DKIM in particular doesn't tie the signature domain to
> any identities in the message. I believe the idea of author domain signed
> messages is foreign to DKIM.
>

That's true, but we covered this in another thread: The point of including
the DKIM codes is not to encourage non-compliant behavior, but rather to
accept the fact that some operators do it despite the fact that DKIM has a
SHOULD NOT about it, and improve interoperability with those operators.
There's text in the -01 version (second paragraph of Section 3) that talks
about this already.

I also agree with Ned's point about reflecting reality with these codes,
and that we've quite possibly been too strict on assigning them to date.

> completely private out of band arrangements or DMARC. I think the DKIM
> codes should probably be moved to the DMARC draft.
>
> The others make sense.
>
> If DKIM is covered, I think covering TLS makes sense to include too.
> Closely related, I wonder about DANE SMTP verification failures.?
>

I agree with Ned's response on that point as well.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 02 Jun 2014 14:59:59 -0400

> Seems reasonable to me as well.  I'll add this for the next version.

Thanks.

> There's text in the -01 version (second paragraph of Section 3) that talks

If it is going to be included, it needs to be adequately caveatted.  I'll have 
another look at it in -02.

> and that we've quite possibly been too strict on assigning them to date.

Perhaps.  As they proliferate, it's more and more likely implementations will 
process codes that are unknown to them.  Did anyone go back and check of 
behavior in that case is already adequately specified?

> I agree with Ned's response on that point as well.

Upon further reflection, so do it.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 02 Jun 2014 15:10:50 -0400

> > Seems reasonable to me as well.  I'll add this for the next version.

Would it make sense to provide a little more detail for the SPF cases since 
we're overriding specific language in 7208 (should this update 7208)?  Perhaps:

      Description:        This status code is returned when a message
                          failed an SPF check, contrary to local
                          policy requirements.  Used in place of 5.7.1 as
                          described in Section 8.4 of [RFC7208]

      Description:        This status code is returned when evaluation
                          of SPF relative to an arriving message
                          resulted in an error.  Used in place of 4.4.3/5.5.2
                         as described in Sections 8.6/8.7 of [RFC7208]  
                         respectively.

> If it is going to be included, it needs to be adequately caveatted.  I'll
> have another look at it in -02.

I looked.  I think it's fine.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 Jun 2014 13:13:02 -0700

>                           resulted in an error.  Used in place of
Sure, done for -03.  And yes, an "updates" seems right given this change.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Mon, 02 Jun 2014 18:08:48 -0400

> basis for rejection.

Not true.  Its the basic MODEL in preparation for rejection and/or 
acceptance (with added layers).  Are you just going DKIM process mail 
for no reason?  Its all in the functional description, it is by 
design, allowing software engineers to extract logic from it that ends 
up begin logic for rejection, acceptation and/or including discarding 
and quarantining.

> DKIM in particular doesn't tie the signature
> domain to any identities in the message.

As a minimum requirement, a DKIM signature MUST be hash bound to the 
5322.From identity.  How does that not tie it?

> I believe the idea of author
> domain signed messages is foreign to DKIM.

Since its initial invention with DomainKeys and its built-in author 
domain policy, then later with its derivative DKIM with its built-in 
expanded 1st and 3rd party policies called SSP which were eventually 
reduce to ADSP, it was always a fundamental part of the DKIM 
framework, despite ADSP being erroneously tossed aside by the DKIM 
project group.  That error has finally come back to haunt DKIM in the 
form of DMARC. I don't see anything foreign about the author domain 
and DKIM.

I am just noting for the archive record, I don't agree with the above 
statement. Its an confusing position to have about the total 
integrated concepts involved. What is stated above is akin to saying 
the original mail return path/sender is foreign to SPF.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Mon, 02 Jun 2014 19:06:08 -0400

On 6/2/2014 1:46 PM, Murray S. Kucherawy wrote:

> That's true, but we covered this in another thread: The point of
> including the DKIM codes is not to encourage non-compliant behavior,
> but rather to accept the fact that some operators do it despite the
> fact that DKIM has a SHOULD NOT about it, and improve interoperability
> with those operators.

I'm not going to dwell on this, but this is odd to me.  Do you really 
know of any raw DKIM-BASE only receivers that are rejecting based on 
raw DKIM-base processing results only and nothing else as part of the 
raw verification equation?  In other words, no common, open public 
proposed standard or method is being explored?

If that is the case, then it would be in violation of DKIM when a 
*LOCAL POLICY" uses RAW DKIM-BASE processing only for that 
determination.

I just think doc is still a little ambiguous about how and when to use 
these codes.  It is not clear and the first question implementers may 
probably ask is:

     "How can they use these codes without violating DKIM?"

The 5.7.21 description is still ambiguous:

       Code:               X.7.21
       Sample Text:        No valid author DKIM signature found
       Description:        This status code is returned when a message
                           did not contain a valid DKIM signature
                           matching the domain(s) found in the From
                           header field, contrary to local policy
                           requirements.  (Note that this violates the
                           advice of Section 6.1 of RFC6376.)

You can have a valid signature. Its just not authorized.  Unless you 
mean x.7.20 folds missing and invalid, and x.7.21 implies valid but 
unauthorized, you might need a third code:

       Code:               X.7.22
       Sample Text:        No AUTHORIZED DKIM signature found
       Description:        This status code is returned when a message
                           contains a valid DKIM signature but it is
                           not authorized by the matching the domain(s)
                           found in the From header field.

I hope you don't fast track this.  You got DMARC and also 3rd party 
Protocols to finish and all this needs to be review then too as well. 
  It may change.

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 4 Jun 2014 23:00:55 -0000

Section 4 says:

   By the nature of the Simple Mail Transfer Protocol (SMTP), only one
   enhanced status code can be returned for a given exchange between
   client and server. ...

Is that true?  When I read RFC 3463 and RFC 5321, I don't see any
advice about when or where to present the status codes other than a
largely implicit assumption that they go in the reply string.

I don't see why this wouldn't be valid: 

550 Your mail stinks (5.7.25) because it has no DKIM (5.7.20) and no SPF (5.7.22).

There are practical issues, like whether recipient MTAs are likely to
do anything useful with multiple status codes, but that's a separate
question.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Wed, 4 Jun 2014 16:23:41 -0700

> do anything useful with multiple status codes, but that's a separate

RFC 2034 says enhanced status codes must appear at the beginning
of each response line. I'm not sure they're anything other than human
readable text if they appear elsewhere.

Cheers,
  Steve

---

From: "John Levine" <[email-masked]>
Date: 4 Jun 2014 23:58:16 -0000

>readable text if they appear elsewhere.

Oh, look at that.  "Never mind".  Sure would have been nice if 3463 or
5321 had a reference to it.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Wed, 04 Jun 2014 22:25:20 -0700 (PDT)

> largely implicit assumption that they go in the reply string.

Wrong RFCs. Try RFC 2034.

> 550 Your mail stinks (5.7.25) because it has no DKIM (5.7.20) and no SPF (5.7.22).

It's "valid" but those codes have no defined meaning. They might be
enhanced status codes. Or something else entirely.

				Ned

---

From: Dave Warren <[email-masked]>
Date: Thu, 05 Jun 2014 23:31:00 -0700

> enhanced status codes. Or something else entirely.

Since it doesn't conflict with existing behaviour, it possibly enables 
creation of a formal standard without breaking backward compatibility.

Also helpful is that such a standard would be human-readable (both the 
text and the Googleable error codes), so it would be beneficial to 
generate such information even if senders don't use it at all.

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

---

From: Ned Freed <[email-masked]>
Date: Fri, 06 Jun 2014 01:11:36 -0700 (PDT)

> creation of a formal standard without breaking backward compatibility.

First of all, unless you have insight into all the strings exchanged by the
SMTP servers of the world, you have no way of knowing whether or not this
conflicts with existing behavior.

Second, a formal standard for what? We've had a standard in place for
negotiating the use of enhanced status codes in SMTP replies since 1996.
(RFC 2034). It's widely and successfully deployed.

If you're talking about allowing multiple codes, it would be a very simple
matter to specify a similar extension for that. An extension to the DSN format
would also be in order; it's not as obvious how to do that.

The sticking point is I've yet to  see anyone advance a use-case for this that
would justify standardizaing or implementing any of this.

> generate such information even if senders don't use it at all.

I'm afraid I have no idea what you're proposing here.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 6 Jun 2014 07:01:41 -0700

> would justify standardizaing or implementing any of this.
The only case I've seen is the ability to report that the message failed
for multiple reasons, and the desire to report all of those reasons to the
client.  "SPF and DKIM" is the common example.  The benefit of doing so is
that the sending agent doesn't have to fix one problem and try again, only
to be denied for some other reason.

Two solutions to this have been suggested.  One, admittedly the simpler
one, is what we have now, which is to have a separate code to mean "This
failed for more than one reason."  It has the benefit of requiring
approximately zero changes to the deployed base.

The other is to do something more fancy.  There have now been two proposals
for this: (a) Make the third number in the enhanced status code a bit mask
so it can indicate multiple failures of the same type (e.g., 5.8.5 would
mean 5.8.1 and 5.8.4 at the same time; or (b) create a mechanism to send
and receive multiple distinct status codes.  In either case, there's quite
a bit more work to do.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Sun, 08 Jun 2014 14:22:12 -0700 (PDT)

> to be denied for some other reason.

In other words, it's a "nice to have". So the question is whether the cost of a
given solution is worth the benefit.

> approximately zero changes to the deployed base.

The cost here is pretty low - of course the code itself is essentially free,
but this does require validators to not stop at the first error they detect.

The benefit is correspondingly limited to covering the current use case.

> and receive multiple distinct status codes.  In either case, there's quite

Exactly. The bit encoding scheme has much lower cost overall since it doesn't
require upgrades to the transport infrastructure.

But I still don't think it's worth it.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Mon, 9 Jun 2014 11:05:40 -0400

> given solution is worth the benefit.
...
> The benefit is correspondingly limited to covering the current use case.

Indeed.  The reason I supported that code, though, is that the current
use case is, at least for now, extremely common.  Very many systems
check both SPF and DKIM, usually in that order, and they don't stop
when one of them fails, because we know that they're complementary,
and that it's often the case that one of them fails and the other
validates.  And there aren't other, comparable domain-validation
systems ("sender authentication", we unfortunately have come to call
it) for now, so in this case "more than one" means two, and
specifically means SPF and DKIM.

Should we eventually have a third, and should that third become as
widely deployed, we'll have to decide then whether this code is enough
to meet that use case or not.

> But I still don't think it's worth it.

I agree that it's not worth it, but I might think otherwise if/when we
develop another such domain-validation system.

Barry

---

From: Hector Santos <[email-masked]>
Date: Mon, 09 Jun 2014 12:24:31 -0400

On 6/9/2014 11:05 AM, Barry Leiba wrote:
> validates.

Barry, I disagree with the notion that there isn't a significant 
amount of systems with optimized short circuiting on the SMTP level 
before the DATA payload is reached.

If you want to be specific and suggest that there is a 
multi-technology protocol (DMARC) that requires the SPF process to be 
delayed or results handling delayed until the PAYLOAD is reached, I 
think that would be ok to say, but not demanding it be the required 
mode of operation.

There will be existing SPF sites that do reject at the SMTP-PRE-DATA 
state and when they migrate to add DMARC support, there might be new 
design change pressures to alter/offer new modes of operation.  For 
example, there could be two options added to our configuration tool:

   [X] Enable SPF Support
       [_] Delay SPF -ALL rejection until DMARC is processed  (NEW)

   [X] Enable DMARC support (NEW)

Or to make it an easy Plug and Play solution, or just exploratory as 
many will most likely do first and learn what are all the options are, 
their new DMARC implementation would naturally only apply to relaxed 
SPF results (~ALL, ?ALL) transactions that would allow the payload to 
be reached.

Many sites will find that for SPF -ALL results, a majority would fail 
anyway at the PAYLOAD level. Therefore, it would be a major overhead 
performance, higher scale issue if this redundancy was allowed.   So 
you must take into account that this optimization will most likely occur.

Also, its not just SPF, but you got other dynamic rejection SMTP 
filters too and popular one is DNS-based RBL (Runtime Black List).

That is what we found with the Microsoft CEP proposal, the XML version 
of SPF for the 5322 payload which eventually became:

    RFC4405  SUBMITTER SMTP Service Extension
    RFC4406  Sender ID: Authenticating E-Mail
    RFC4407  Purported Responsible Address (PRA)

SUBMITTER allows for the 5322 PRA to be passed via the 5321 MAIL FROM 
command.

    C: EHLO client.example.com
    S: 250 SUBMITTER
    c: MAIL FROM:<return-path> SUBMITTER=pra

I bring this up because to dot/cross all the engineering eyes/tees, 
it is clear that a similar ESMTP level DMARC optimizer could apply if 
the author domain can be passed to the SMTP MAIL FROM command:

    C: EHLO client.example.com
    S: 250 DMARC
    c: MAIL FROM:<return-path> DMARC=5322.From.domain

This would allow for SPF extended reply codes to apply for DMARC 
policy reasons at the SMTP level without processing the payload.

-- 
HLS