Subject: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt

From: [email-masked]
Date: Wed, 04 Jan 2012 14:43:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF.

	Title           : Authentication Failure Reporting using the Abuse Report Format
	Author(s)       : Hilda L. Fontana
	Filename        : draft-ietf-marf-authfailure-report-09.txt
	Pages           : 21
	Date            : 2012-01-04

   This memo registers an extension report type to the Abuse Reporting
   Format (ARF), affecting multiple registries, for use in generating
   receipt-time reports about messages that fail one or more email
   message authentication checks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-09.txt

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 04 Jan 2012 18:11:27 -0500

I'm sorry I didn't notice this before, but I think that:

   spf:  The evaluation of the author domain's SPF record produced a
      "fail", "softfail", "temperror" or "permerror" result.

should also include "none".  For some policy scenarios that would be 
considered a failure, so we ought to be able to express it.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Jan 2012 15:16:40 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Wednesday, January 04, 2012 3:11 PM
> To: [email-masked]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-
> 09.txt
> 

Wouldn't you assert "fail" in that case?

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 04 Jan 2012 18:20:49 -0500

On Wednesday, January 04, 2012 03:16:40 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Scott Kitterman Sent: Wednesday, January 04, 2012 3:11 PM
> > To: [email-masked]

No.  I'm describing a case where from a policy perspective any SPF result 
!pass would be considered a failure of authentication (a mail stream that is 
expected to be 100% authenticated).  In this case the SPF result = none, but 
it's still a failure of authentication (and yes, such mail streams do exist in 
production).

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Jan 2012 15:26:03 -0800

> Sent: Wednesday, January 04, 2012 3:21 PM
> To: [email-masked]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-authfailure-report-09.txt
> 
> No.  I'm describing a case where from a policy perspective any SPF
> result !pass would be considered a failure of authentication (a mail
> stream that is expected to be 100% authenticated).  In this case the
> SPF result = none, but it's still a failure of authentication (and yes,
> such mail streams do exist in production).

Right, so what I'm saying is that for the case where a "typical" installation might report "none", for policy reasons you could instead report "fail".  It's not a change to the SPF evaluation mechanism, just how you report it.

The one case where this breaks down is where you want to be able to detect the difference yet treat them the same way.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Jan 2012 16:09:56 -0800

> considered a failure, so we ought to be able to express it.

Maybe a simpler thing to say overall is:

spf: The evaluation of the author domain's SPF record produced a failing result, meaning either an actual SPF failure (e.g., "fail", "softfail", "temperror", or "permerror") or any other result that was not acceptable for local policy reasons.

?

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 04 Jan 2012 19:12:13 -0500

"Murray S. Kucherawy" <[email-masked]> wrote:

>> Subject: Re: [marf] I-D Action:
>draft-ietf-marf-authfailure-report-09.txt
>> 
>Right, so what I'm saying is that for the case where a "typical"
>installation might report "none", for policy reasons you could instead
>report "fail".  It's not a change to the SPF evaluation mechanism, just
>how you report it.
>
>The one case where this breaks down is where you want to be able to
>detect the difference yet treat them the same way.

Then there's also no way to tell which case it is from the header. I don't think that solves the problem.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 05 Jan 2012 13:57:40 +0100

On 05.01.2012 01:09, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Scott Kitterman
>
> spf: The evaluation of the author domain's SPF record produced a failing
> result, meaning either an actual SPF failure (e.g., "fail", "softfail",
> "temperror", or "permerror") or any other result that was not acceptable
> for local policy reasons.

That may work for me.  I'd keep it even more generic, e.g.

  spf: The evaluation of the author domain's SPF (or TXT) record produced a
     result that was not acceptable, unusual, or anyhow conspicuous under the
     provisions of the relevant reporting agreement.

Either way, I think that can cover any future SPF extension as well.

jm2c

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 5 Jan 2012 09:10:30 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Thursday, January 05, 2012 4:58 AM
> To: [email-masked]

Even simpler:

spf: The evaluation of the author domain's SPF record produced something other than a "pass" result, which the report generator considers to be a reportable incident.  This can include the usual set of failure results, or any result that is considered a failure under local policy constraints.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 05 Jan 2012 17:40:37 -0500

On Thursday, January 05, 2012 09:10:30 AM Murray S. Kucherawy wrote:
> > Alessandro Vesely Sent: Thursday, January 05, 2012 4:58 AM
> > To: [email-masked]
> >   spf: The evaluation of the author domain's SPF (or TXT) record
> >   produced a>   
> >      result that was not acceptable, unusual, or anyhow conspicuous
> >      under the provisions of the relevant reporting agreement.
> 
> Even simpler:
> 
> spf: The evaluation of the author domain's SPF record produced something
> other than a "pass" result, which the report generator considers to be a
> reportable incident.  This can include the usual set of failure results, or
> any result that is considered a failure under local policy constraints.

I think it's a mistake to report non-SPF results as SPF result.  This includes 
policy overrides or the results of some hypothetical SPF extension.  

That the message is intended to communicate some kind of failure is implicit 
in the message type.  The data element we are discussing is for SPF results 
and should only include those (and it should include all of them).

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 5 Jan 2012 14:58:20 -0800

> Sent: Thursday, January 05, 2012 2:41 PM
> To: [email-masked]
> > spf: The evaluation of the author domain's SPF record produced
> > something other than a "pass" result, which the report generator
> > considers to be a reportable incident.  This can include the usual set
> > of failure results, or any result that is considered a failure under local policy constraints.
> 
> I think it's a mistake to report non-SPF results as SPF result.  This
> includes policy overrides or the results of some hypothetical SPF
> extension.

I'm specifically trying to enable your "none" case without calling it out, because I don't want to have to add another non-pass code later.  "pass" is really the only case that isn't reportable, so the above language seems to cover all the possibilities without enumerating them.

> That the message is intended to communicate some kind of failure is
> implicit in the message type.  The data element we are discussing is
> for SPF results and should only include those (and it should include
> all of them).

The data element we're talking about is the Auth-Failure field, which is only used to indicate which module reported some kind of result that is reportable.  The specific result reported will be carried in the Authentication-Results: field.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 05 Jan 2012 18:07:48 -0500

On Thursday, January 05, 2012 02:58:20 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Thursday, January 05, 2012 2:41 PM
> > To: [email-masked]
> > > of failure results, or any result that is considered a failure under
> > > local policy constraints.> 
> I'm specifically trying to enable your "none" case without calling it out,
> because I don't want to have to add another non-pass code later.  "pass" is
> really the only case that isn't reportable, so the above language seems to
> cover all the possibilities without enumerating them.

Except you've got all the other non-pass SPF results already, so the list 
would be complete (it's not an open ended list).   It seems far simpler to me 
to add the one missing one than dance around it.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 5 Jan 2012 15:09:56 -0800

> Sent: Thursday, January 05, 2012 3:08 PM
> To: [email-masked]

True, but that presumes the list will never be extended.

You're more of an SPF expert than I am, so I'm happy to concede the point if you agree with that presumption.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 05 Jan 2012 18:15:52 -0500

On Thursday, January 05, 2012 03:09:56 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Thursday, January 05, 2012 3:08 PM
> > To: [email-masked]
> > would be complete (it's not an open ended list).   It seems far simpler
> > to me to add the one missing one than dance around it.
> 

Assuming (and I think it's a safe assumption) that SPFbis sticks with 
interoperability with current deployments as a goal, it can't change.  
Fundamentally, if the results codes codes change now, it's not really SPF v1 
anymore.  I think it's a safe presumption for the next 5 - 10 years and 
probably much longer.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 5 Jan 2012 15:30:24 -0800

> Scott Kitterman
> Sent: Thursday, January 05, 2012 3:16 PM
> To: [email-masked]
> Fundamentally, if the results codes codes change now, it's not really
> SPF v1 anymore.  I think it's a safe presumption for the next 5 - 10
> years and probably much longer.

Then how about:

spf: The evaluation of the author domain's SPF record produced a "none", "fail", "softfail", "temperror" or "permerror" result.  ("none" is not strictly a failure per [SPF], but a service that demands successful SPF evaluations of clients could treat it like a failure.)

?

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 05 Jan 2012 18:37:10 -0500

"Murray S. Kucherawy" <[email-masked]> wrote:

>"none", "fail", "softfail", "temperror" or "permerror" result.  ("none"
>is not strictly a failure per [SPF], but a service that demands
>successful SPF evaluations of clients could treat it like a failure.)
>
>?

Looks good.

Thanks,

Scott K

---

From: Hfontana <[email-masked]>
Date: Thu, 5 Jan 2012 20:25:53 -0800

>> successful SPF evaluations of clients could treat it like a failure.)
+1

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

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 07 Jan 2012 12:57:07 +0100

>>> interoperability with current deployments as a goal, it can't change.

Julian's SPF scope adds no results, but I think they'll have to be
reported with a different method.  For a shot in the dark:

   Authentication-Results: authserv-id.example;
     spf=pass smtp.mailfrom=example.org;
     spf-scope=fail scope-id=hdr-from header.from=example.com

To clarify, spf-scope would have to be registered at IANA's for the
above to be correct.  By contrast, the values of the Auth-Failure
field, such as the "spf" we're talking about, don't have a IANA register.

>>successful SPF evaluations of clients could treat it like a failure.)

I liked better Murray's previous text.  This one is acceptable as long
as it doesn't imply that "SPF evaluations" have to be carried out
according to [SPF] only.  Thus a report could set the following in its
2nd part:

   Feedback-Type: auth-failure
   Auth-Failure: spf
   Authentication-Results: authserv-id.example;
     spf-scope=fail scope-id=hdr-from header.from=example.com

(Note that the value "spf" is in a different field than keywords
listed in its definition.)