Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt

From: SM <[email-masked]>
Date: Sat, 01 Oct 2011 16:38:34 -0700

At 12:58 13-09-2011, Barry Leiba wrote:
>Let's say that this now officially starts working-group last call on
>draft-ietf-marf-authfailure-report-02 (

In the Abstract:

   "This memo registers an extension report type to ARF to be used for
    reporting forensic information about messages that fail one or more
    message authentication schemes in use by the purported sender of the
    message."

The term purported sender sounds like one borrowed from SPF.  DKIM 
does not use such a term.  I suggest reusing some wording from ARF 
such as "to report feedback about received email" or use the text 
from the Introduction section.

In Section 3:

   "The current report format defined in [ARF] lacks some specific
    features required to do effective sender authentication reporting."

I don't think that "sender authentication reporting" is the 
appropriate term.  Please let me know if the comment is unclear and I 
will expand on it.

   "Authentication-Results:  This field MUST be formatted as defined in
       [AUTH-RESULTS], except that it MUST include explicit results for
       both DKIM and SPF."

John Levine already commented on this.

   "Reported-Domain:  As specified in [ARF].  This field MUST appear
       exactly once."

This is an optional field in ARF which can appear more than once.

   "If this information is either not available at the time the
    report is generated, or the generating ADMD's policy requires it
    be redacted, a value of 0.0.0.0 MUST be used."

Why must 0.0.0.0 be used?
In Section 3.2.1:

   "policy:  The message was not delivered to the intended inbox due
          to authentication failure.  The specific action taken is not
          specified."

The term "policy" is confusing.  is this a "discard"?

In Section 3.3:

   "The DKIM-ADSP-DNS field MUST be included in the report."

What is the DKIM-ADSP-DNS field?

Section 7.4 discusses about Envelope Sender Selection.  I suggest 
reusing the idea from Section 5 of RFC 5965 as it is easier to build upon ARF.

The DKIM reference should be updated to RFC 6376.  MAIL should be 
updated to RFC 5322.

In Appendix B:

Please point to the relevant RFC instead of http://www.mipassoc.org/arf/

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 2 Oct 2011 23:01:15 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Saturday, October 01, 2011 4:39 PM
> To: [email-masked]
> Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt
> 
> In Section 3:
> 

Yes, please.  In particular, do you have an alternate suggestion?

> This is an optional field in ARF which can appear more than once.

Indeed, but this is essentially creating a profile of ARF (by creating a new feedback type) for the purpose of reporting messages that fail authentication checks.  I don't think there's anything wrong with saying "for this profile, Reported-Domain is mandatory".

> The term "policy" is confusing.  is this a "discard"?

It's not specified what actually happened.  The term is recycled from RFC5451, where "policy" basically means "other, per local policy configuration", such as rejecting a signature because "l=" is in use (i.e., not required by DKIM, but certainly legal at the discretion of the receiver).

> What is the DKIM-ADSP-DNS field?

It's defined in 6.2.

-MSK

---

From: SM <[email-masked]>
Date: Mon, 03 Oct 2011 09:51:53 -0700

Hi Murray,
>Yes, please.  In particular, do you have an alternate suggestion?

The draft is an extension of ARF which uses the 
Authentication-Results header field.  I suggest reusing the RFC 5451 
approach to avoid problematic terms:

   This memo registers an extension report type to ARF to be used for
   reporting forensic information about messages that fail one or more
   message authentication effort.

BTW, you used "effort" and "checks".

I noticed that Authentication-Results (Section 3.1) can appear only 
once.  A message may have one or more such header fields.

>Indeed, but this is essentially creating a profile of ARF (by 
>creating a new feedback type) for the purpose of reporting messages 
>that fail authentication checks.  I don't think there's anything 
>wrong with saying "for this profile, Reported-Domain is mandatory".

There may be more than one "Reported-Domain".  It is about the same 
problem as Authentication-Results.  Do you want one report for each 
occurrence or do you want one report per message?  In the first case, 
we are reporting failures whereas the second case is about delivery 
status (Section 3.2.1).

>It's not specified what actually happened.  The term is recycled 
>from RFC5451, where "policy" basically means "other, per local 
>policy configuration", such as rejecting a signature because "l=" is 
>in use (i.e., not required by DKIM, but certainly legal at the 
>discretion of the receiver).

RFC 5451 states that:

   "The message was signed but the signature or signatures were
    not acceptable to the verifier."

This is not an authentication failure (Section 3.2.1).

BTW, ARF was initially designed as a format for reporting email 
abuse.  This draft seems to be tackling deliverability even though 
that is not mentioned explicitly.  If I understood the charter 
correctly, the aim was to specify integration of ARF in DKIM-aware 
environments and to generate phishing reports.  For example, if 
someone is generating a "fake" DKIM-Signature header, the domain 
being "phished" can receive reports of such occurrences.  There are 
times when it may a technical glitch instead of a phish, e.g. DKIM 
signature not verifying.  The report can convey debugging information 
to identify such issues.

There isn't any discussion in the draft about the problem being 
addressed.  The document comes out as trying to report back as much 
information as possible without any explanation.

Regards,
-sm

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 4 Oct 2011 20:05:57 +0200

On 2 October 2011 01:38, SM wrote:

> The term purported sender sounds like one borrowed from SPF.

Not really, did you confuse this with the "PRA" in Sender-ID?

The "PRA" concept was not adopted or acknowledged in the later
RFCs 4409bis and 5321.  My somewhat irregular summary would be
that nobody was thrilled by the fine print of a "Resent-Sender".

> DKIM does not use such a term.

IIRC at some point in time DKIM tackled "authors" (5322-From),
and whatever that is, it is certainly not always the "sender",
let alone the PRA.  But for ordinary humans not knowing these
infamous terminology difficulties "purported sender" might be
vague enough to cover the different concepts (?).

BTW, the draft does not mention Sender-ID at all.  I take this
as another indication that this "experiment" is now obsolete;
RFC 4407 (PRA) was cute, but RFC 4405 (SUBMITTER) was a "FUSSP".

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Oct 2011 11:59:32 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Frank Ellermann
> Sent: Tuesday, October 04, 2011 11:06 AM
> To: SM
> Cc: [email-masked]

I don't think MARF is in a position to be able to make that statement explicitly.  Further, since we appear to be in agreement that the authentication results reported by this draft should include only those things that were actually tested, and not a fixed set, it seems including a "sender-id" result is on the table.

---

From: SM <[email-masked]>
Date: Tue, 04 Oct 2011 12:01:06 -0700

Hi Frank,
>Not really, did you confuse this with the "PRA" in Sender-ID?

Yes, it could be.

>vague enough to cover the different concepts (?).

It is difficult to cover different concepts like SPF and DKIM.  The 
former is a test on the reverse-path whereas the latter provides a 
means to verify the hash affixed to a message.  I focused on the 
Authentication-Results angle as it is simpler to take its results as 
input instead of getting into the details of what SPF, DKIM or any 
other mechanism does or does not do.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Oct 2011 14:21:46 -0500

On Tuesday, October 04, 2011 11:59:32 AM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Frank Ellermann Sent: Tuesday, October 04, 2011 11:06 AM
> > To: SM
> > Cc: [email-masked]
> > Subject: Re: [marf] Comments on
> > draft-ietf-marf-authfailure-report-01.txt
> > 
> I don't think MARF is in a position to be able to make that statement
> explicitly.  Further, since we appear to be in agreement that the
> authentication results reported by this draft should include only those
> things that were actually tested, and not a fixed set, it seems including a
> "sender-id" result is on the table.

Does it have a constituency?  There are quite a number of auth methods covered 
in auth-results that we don't cover and I don't think we should extend beyone 
SPF/DKIM unless someone needs it.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Oct 2011 12:25:29 -0700

> Scott Kitterman
> Sent: Tuesday, October 04, 2011 12:22 PM
> To: [email-masked]

If we're insisting that we not say you have to report specific ones, then being completely agnostic seems the right path to me.

---

From: Dotzero <[email-masked]>
Date: Tue, 4 Oct 2011 15:29:19 -0400

> If we're insisting that we not say you have to report specific ones, then being completely agnostic seems the right path to me.

+1

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Oct 2011 14:48:09 -0500

On Tuesday, October 04, 2011 12:25:29 PM Murray S. Kucherawy wrote:
> > Does it have a constituency?  There are quite a number of auth methods
> > covered in auth-results that we don't cover and I don't think we should
> > extend beyone SPF/DKIM unless someone needs it.
> 
> If we're insisting that we not say you have to report specific ones, then
> being completely agnostic seems the right path to me.

I don't see how that follows.

Perhaps the method specific stuff needs to move to the method specific draft so 
that if someone wants to (later) do a sender-id draft then the can do it.  I'd 
rather ignore it, but I think making it easier for someone who cares enough 
about sender-id (or method foo) can do so works too.  I don't think 
overcomplicating the current effort is a good idea.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Oct 2011 13:02:13 -0700

> Sent: Tuesday, October 04, 2011 12:48 PM
> To: [email-masked]

With the changes you and John proposed to the document in WGLC, the requirement to report DKIM and SPF results even if you don't check them is gone, and furthermore you don't have to include the other fields that are irrelevant to what you did check.  It seems to me that leaves us in an agnostic place with respect to which message authentication methods you're choosing to execute and report, which satisfies what you and John were after while also enabling one to report a "sender-id" result.

What am I missing with this thinking?

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Oct 2011 15:39:38 -0500

On Tuesday, October 04, 2011 01:02:13 PM Murray S. Kucherawy wrote:
> > > If we're insisting that we not say you have to report specific ones,
> > > then being completely agnostic seems the right path to me.
> > 
> > Perhaps the method specific stuff needs to move to the method specific
> > draft so that if someone wants to (later) do a sender-id draft then the
> > can do it.  I'd rather ignore it, but I think making it easier for
> > someone who cares enough about sender-id (or method foo) can do so
> > works too.  I don't think overcomplicating the current effort is a good
> > idea.
> 
> With the changes you and John proposed to the document in WGLC, the
> requirement to report DKIM and SPF results even if you don't check them is
> gone, and furthermore you don't have to include the other fields that are
> irrelevant to what you did check.  It seems to me that leaves us in an
> agnostic place with respect to which message authentication methods you're
> choosing to execute and report, which satisfies what you and John were
> after while also enabling one to report a "sender-id" result.
> 

I'm not understanding who plans to use sender-id and why add that and not all 
the other auth-results?

Wd do need to define what to do with results for auth-methods one doesn't 
implement or understand (ignore them).  I don't want to force implementers to 
deal with having to write code for methods they aren't interested in.

It's been 5 years since I took a serious look at the Sender ID specs.  I do 
not know how well the SPF modifier proposed in a Sender ID record.  There are 
some subtle differences between the two record types and someone who was 
interested enough in Sender ID to investigate it should take a look before we 
move forward on it.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Oct 2011 13:47:09 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, October 04, 2011 1:40 PM
> To: [email-masked]

By removing the limitation on which results get reported, we are in effect adding all the other ones, at the option of the reporting site.  That's what I meant by "agnostic".

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 5 Oct 2011 00:11:34 +0200

On 4 October 2011 20:59, Murray S. Kucherawy wrote:

 [Sender-ID obsolete]
> I don't think MARF is in a position to be able to make that
> statement explicitly.

I was only surprised how the draft managed this *implicitly*.

> it seems including a "sender-id" result is on the table.

Maybe the IESG will add one of their interesting notes about
the (in)compatibilities of STD 4409bis "MAY add sender" and
RFC 4407 "PRA".

SPF FAIL reports are also weird, SPF FAIL should be rejected,
getting rid of the backscatter is the main point of SPF FAIL.

There SHOULD NOT be a way how the "purported senders" could
"opt-in" to SPF FAIL reports, because that is the point of
SPF SOFTFAIL.  The [CFWS] in the ABNF makes me also nervous
for the known reasons.

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Oct 2011 15:14:26 -0700

> From: Frank Ellermann [mailto:[email-masked]]
> Sent: Tuesday, October 04, 2011 3:12 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

I doubt it.  I think the notes affixed to RFCs 4406-4408 are sufficient, or they would've also added the same note to RFC5451.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 04 Oct 2011 16:56:22 -0700

> interested enough in Sender ID to investigate it should take a look before we
First, the term authentication does not describe what can be deduced 
from the application of either DKIM or SPF.

DKIM verifies a domain signed a portion of a message.  DKIM verification 
does not confirm the domain submitted the message to the unsolicited 
recipient, the common reason for issuing feedback.

Some view SPF as a method for domains to authorize the return path to 
ensure DSNs.

Some receivers extend this authorization as a potentially inaccurate 
method for assessing accountability.  While accountability could be 
safely extended to the EHLO, it might be inaccurately extended to the 
Mail From (return path), or the PRA.

When based upon the Mail From or the PRA, SPF verification will not 
reliably select domains accountable for messages.  It is fairly common 
for domains to share common outbound MTAs.  Disputes about whether SPF 
applies to the Mail From or to the PRA as delineated from an SPF address 
list confound the accuracy of the deductions.

Feedback should attempt to report what the purported domain intended.  
After all, SPF syntax often fails to exclude possible mis-interpretations.

Did the purported domain expect their authorization to apply to the:
  1 - EHLO
  2 - Return Path
  3 - PRA

If so, how was such intent confirmed?

Critical aspects related DKIM/SPF feedback should clarify any remaining 
ambiguity within the reporting scheme.  To better assure against any 
remaining ambiguity, there should be some type of indication whether the 
MARF source-IP address was used in the SPF confirmation.  This 
information is not normally included in the Authentication-Results 
headers.  SPF allows for non-address confirmation methods, but 
disambiguating this issue has been missed in the MARF report details.  
There should also be confirmation what message element was used to 
confirm the purported domain as well.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 05 Oct 2011 00:05:50 -0500

On Tuesday, October 04, 2011 01:47:09 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Tuesday, October 04, 2011 1:40 PM
> > To: [email-masked]
> > I'm not understanding who plans to use sender-id and why add that and
> > not all the other auth-results?
> 
> By removing the limitation on which results get reported, we are in effect
> adding all the other ones, at the option of the reporting site.  That's
> what I meant by "agnostic".

No.  I think not.  Both paragraph 3.2 and 3.3 have DKIM and SPF specific 
requirements that are not sufficient for other authentication types.  Yes, the 
actual header might refer to other types, but without the additional 
diagnostic information in from 3.2/3.3.

At the very least sender-id would have to be added to the list of 
authentication failure types in 3.3 (I propose we not do this and just focus 
on DKIM/SPF).

BTW, looking at this again has caused me to notice that spf-dns isn't referred 
to anywhere in 3.2/3.3.  There should be a 3.2.3 for SPF reports that requires 
spf-dns fields for all SPF records used to process the message.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Oct 2011 22:15:56 -0700

> Sent: Tuesday, October 04, 2011 10:06 PM
> To: [email-masked]

Right.  So if you're reporting for DKIM, there are extra provisions included to allow relaying of meta-data specific to that method.  If you want don't want to report on DKIM, you leave out the relevant fields.  If you want to report on something else, you'd have to craft an update to this document.

For SPF, I don't think there's any meta-data that needs its own field in this kind of report, since Authentication-Results would carry that information already.  So we're already there.

> authentication failure types in 3.3 (I propose we not do this and just focus

If we want to be complete about it, perhaps 3.3 should become an IANA action to create a registry for authentication failure types.  Then someone wanting to add support for Sender-ID or some other method could register a new failure mode and all the various extra fields that it requires (if any).

But you're probably right (as is John) that "spf" should probably be broken out, since there are more than one DKIM failure mode enumerated already.

Does that sound right?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 5 Oct 2011 13:01:11 -0000

>For SPF, I don't think there's any meta-data that needs its own field in
>this kind of report, since Authentication-Results would carry that
>information already.  So we're already there.

I would want the included DNS records.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Oct 2011 07:27:03 -0700

> From: John Levine [mailto:[email-masked]]
> Sent: Wednesday, October 05, 2011 6:01 AM
> To: [email-masked]
> Cc: Murray S. Kucherawy

Ah, right, but that's already in the draft too.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 05 Oct 2011 09:42:15 -0500

On Tuesday, October 04, 2011 10:15:56 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Tuesday, October 04, 2011 10:06 PM
> > To: [email-masked]
> > requirements that are not sufficient for other authentication types.
> > Yes, the actual header might refer to other types, but without the
> > additional diagnostic information in from 3.2/3.3.
> 
> Right.  So if you're reporting for DKIM, there are extra provisions included
> to allow relaying of meta-data specific to that method.  If you want don't
> want to report on DKIM, you leave out the relevant fields.  If you want to
> report on something else, you'd have to craft an update to this document.
> 

Providing the DNS records is what would make this really useful.    I'd like 
to see that required for this report type (as I tried to put in my last mail 
and John suggested).

> > authentication failure types in 3.3 (I propose we not do this and just
> > focus on DKIM/SPF).
> 
> If we want to be complete about it, perhaps 3.3 should become an IANA action
> to create a registry for authentication failure types.  Then someone
> wanting to add support for Sender-ID or some other method could register a
> new failure mode and all the various extra fields that it requires (if
> any).

I think this document could be made more generic pretty easily by leveraging 
the IANA registries that were created by RFC 5451.  I think it's reasonable to 
allow for reports for any authentication type listed in:

http://www.iana.org/assignments/email-auth/email-auth.xml

And then result codes would come from:

http://www.iana.org/assignments/email-auth/email-auth.xml

There is a bit of a problem here that the registry doesn't match the RFC 4408 
results exactly (fail versus hardfail).  That's a bit unfortunate, but the 
train has left the station.  I think this draft should match 5451 terminology.

The only SPF faliure type that I think needs to be broken out is temperror.  
For that type you want the DNS RCODE and query type (TXT versus SPF) and the 
domain name being looked up to support trouble shooting.  I think that this is 
probably true for all DNS based auth methods.

I don't think another IANA registry is needed.

I'd like to see this draft add a method independent response for temperror (as 
above) that should serve for any auth method.

I'd like to see 3.2 have an SPF specific requirement for including the 
record(s) used to process the message.

Later RFCs could deal with other methods listed in the registry and add method 
specific requirements.  Since they would encapsulate the method they were 
dealing with, I don't think a registry is needed.

> But you're probably right (as is John) that "spf" should probably be broken
> out, since there are more than one DKIM failure mode enumerated already.
> 
> Does that sound right?

Only for temperror (and I don't think that's actually SPF specific) as the DNS 
record(s) and IP address is what you want for all the other failure types.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 05 Oct 2011 09:48:19 -0500

> Ah, right, but that's already in the draft too.

It's in the ABNF, but no where referenced, so sort of.  We should make it 
required.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 5 Oct 2011 15:43:29 -0000

>It's in the ABNF, but no where referenced, so sort of.  We should make it 

I see SPF-DNS: "something"

Let's say you were reporting an SPF failure for microsoft.com.  There
is a TXT record at microsoft.com which is an SPF record that has four
include's.  There is another TXT record that looks like some base64.

Can you show what the DNS part of the ARF report would look like?

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 5 Oct 2011 15:51:35 -0000

>The only SPF faliure type that I think needs to be broken out is temperror.  

Given the complexity of the rules for interpreting SPF records, it's not
out of the question that a reported failure could be due to the reporter
interpreting them wrong.  For example, each of the included SPF records
at microsoft.com ends with ~all, which isn't supposed to end the SPF
check, but I wouldn't be surprised if there were some code somewhere that
gets it wrong.

If you're going to return a different result for tempfail, what reason
is there not to return whatever result the SPF checker returned, rather
than combining the other various kinds of failures?

>probably true for all DNS based auth methods.

You're probably right, but it's starting to feel like feature creep.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 05 Oct 2011 13:15:04 -0500

> than combining the other various kinds of failures?

I think temperror for all the relevant auth methods refers to some kind of DNS 
error, so it's different.  Other than that, I think the SPF results all need 
the same information (result and record(s)), so I don't think they need to be 
broken out.

> >For that type you want the DNS RCODE and query type (TXT versus SPF) and
> >the domain name being looked up to support trouble shooting.  I think
> >that this is probably true for all DNS based auth methods.
> 

Agreed.  It would be nice, but it's not essential.  If we don't provide DNS 
information for temperror, then there's no need to break out the different 
types of SPF failures the information you want is the same, the record (and 
what domain it was from).  I think it would be generally useful, but it is 
added complexity.  I'm not sure if it's worth it.

Which brings up another point:

 spf-dns = "SPF-DNS:" [CFWS] quoted-string [CFWS] CRLF

should probably be:

 spf-dns = "SPF-DNS:" [CFWS] domain ":" [CFWS] quoted-string [CFWS] CRLF

so in the case of multiple records being returned it's clear where they came 
from.

Scott K

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 5 Oct 2011 21:20:08 +0200

On 5 October 2011 15:01, John Levine wrote:

 [SPF report]
> I would want the included DNS records.

You're supposed to know what included policies in your SPF policy
do.  I have no problem with adding the info in the reports, but I
don't see the point yet.  Are you talking about unexpected or even
temporary changes of included 3rd party policies?

-Frank

---

From: "John R Levine" <[email-masked]>
Date: 5 Oct 2011 15:43:54 -0400

> do.

Of course, but you cannot always assume that the SPF records that people 
see are the ones you think you published.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 5 Oct 2011 13:44:07 -0700

> SPF SOFTFAIL.  The [CFWS] in the ABNF makes me also nervous

Some sites don't reject on SPF FAIL alone, preferring to add that datum to a scoring or reputation system to determine what to do with the message.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 6 Oct 2011 03:37:51 +0200

On 5 October 2011 22:44, J.D. Falk wrote:

> Some sites don't reject on SPF FAIL alone, preferring to add that
> datum to a scoring or reputation system to determine what to do
> with the message.

That's their choice.  I'd still claim that this is "lossy" (sender
with a broken policy will never know that his mail rots in some
junk folder and will be eventually purged.)  If the sender wants to
debug such issues they can use SOFTFAIL, and hopefully get reports.

The concept of a FAIL report confuses me, because it's at odds with
the SPF FAIL semantics.  As you said this would anyway only affect
receivers accepting FAIL.

BTW, SPF already permits a kind of tracking based on its "exists:"
mechanism not directly depending on the receiver policy. (Unless
"we never evaluate 'exists:'" is a part of this receiver policy.)

I'm no fan of these baroque SPF features, but they exist, and the
draft should mention that SPF FAIL reports are a rather odd idea.

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Oct 2011 22:34:15 -0700

> Sent: Wednesday, October 05, 2011 7:42 AM
> To: [email-masked]

I agree.

> train has left the station.  I think this draft should match 5451

An erratum was opened against RFC5451 about this too.  Maybe this would be a good time to update the registry accordingly.

> I don't think another IANA registry is needed.

Agree here too.

> record(s) used to process the message.

Can you propose some text changes?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Oct 2011 22:34:48 -0700

> Sent: Wednesday, October 05, 2011 7:48 AM
> To: [email-masked]

Yeah, I just noticed that.  Agreed.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Oct 2011 22:37:26 -0700

While discussing all of these points, can we start providing specific text changes for Hilda to incorporate?  The next version is going to be a pretty substantial set of changes, so we may as well start trying to reach consensus on specific text.

I'll prepare some tomorrow and send it along while I'm on a cross-country flight.  Hopefully others can do the same.

-MSK, wearing both hats for this one

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 05 Oct 2011 18:02:59 -0500

In
<[email-masked]>,
on 10/05/2011
   at 09:20 PM, Frank Ellermann

>You're supposed to know what included policies in your SPF policy

If you never change them. If you change them then you'd want to know
whether the reporter had seen the old version or the new.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: Hfontana <[email-masked]>
Date: Thu, 6 Oct 2011 07:36:40 -0700

Thanks Murray that would be very helpful.

On Oct 5, 2011, at 10:37 PM, "Murray S. Kucherawy" <[email-masked]> wrote:

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

---

From: "John Levine" <[email-masked]>
Date: 7 Oct 2011 02:43:59 -0000

I'm still a little unclear about what's supposed to happen if you're
reporting multiple failures, but here's some suggestions for the
single failure case:

In 3.1:

   Authentication-Results:  This field MUST be formatted as defined in
      [AUTH-RESULTS].  This field MUST appear at least once, and it
      is RECOMMENDED that the corresponding header fields be copied
      directly from the message about which a report is being generated.

   Original-Envelope-Id:  As specified in [ARF].  This field SHOULD appear
      if the relevant data are available.

   Original-Mail-From:  As specified in [ARF].  This field SHOULD appear
      if the relevant data are available.

   Source-IP:  As specified in [ARF].  This field SHOULD appear if
      the relevant data are available.

Delete Message-ID section

   Delivery-Result:  As specified in Section 3.2.1.  This field is
      optional and MUST NOT appear more than once.

Add DKIM-DNS.

   DKIM-DNS: A copy of the DKIM key record retrieved from the DNS.
   This field SHOULD be present if the relevant data are available.
   Note that the record name can be deduced from the DKIM-Domain
   and DKIM-Selector values.

   SPF-DNS: Copies of the DNS records used to evaluate an SPF result.
   This field SHOULD appear at least once for SPF results, unless
   the result was due to no records were available and MAY occur
   multiple times if the primary SPF record included other records.

In 3.3, take out the failures that don't happen in the current DKIM,
granularity I think.  Replace the "spf" result with the list of
results in section 2.5 of RFC 4408.

Section 4, change the spf-dns to include the record name:

       spf-dns = "SPF-DNS:" [CFWS] quoted-string [CFWS] quoted-string [CFWS] CRLF

Section 6, update to reflect changed names and values.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 06 Oct 2011 21:45:53 -0500

On Wednesday, October 05, 2011 10:34:15 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Wednesday, October 05, 2011 7:42 AM
> > To: [email-masked]
> > I think this document could be made more generic pretty easily by
> > leveraging the IANA registries that were created by RFC 5451.  I think
> > it's reasonable to allow for reports for any authentication type listed
> > in:
> > 
> > There is a bit of a problem here that the registry doesn't match the RFC
> > 4408 results exactly (fail versus hardfail).  That's a bit unfortunate,
> > but the train has left the station.  I think this draft should match
> > 5451 terminology.
> 
> An erratum was opened against RFC5451 about this too.  Maybe this would be a
> good time to update the registry accordingly.

I think so.  The difference will won't get better with age.

> > The only SPF faliure type that I think needs to be broken out is
> > temperror. For that type you want the DNS RCODE and query type (TXT
> > versus SPF) and the domain name being looked up to support trouble
> > shooting.  I think that this is probably true for all DNS based auth
> > methods.
> > 
> > I'd like to see this draft add a method independent response for
> > temperror (as above) that should serve for any auth method.
> > 

Here's a crack at changes for 3.2.

Scott K

--- draft-ietf-marf-authfailure-report-02.txt	2011-09-08 21:14:14.000000000 -0500
+++ draft-ietf-marf-authfailure-report-02.txt.new	2011-10-06 21:40:35.161212801 -0500
@@ -256,11 +256,6 @@
    Arrival-Date:  As specified in [ARF].  This field MUST appear exactly
       once.
 
-   Source-IP:  As specified in [ARF].  This field MUST appear exactly
-      once.  If this information is either not available at the time the
-      report is generated, or the generating ADMD's policy requires it
-      be redacted, a value of 0.0.0.0 MUST be used.
-
    Message-ID:  As specified in [ARF].  This field MUST appear exactly
       once.
 
@@ -349,6 +344,18 @@
    DKIM-Selector:  The selector of the signature that failed
       verification, taken from the "s=" tag of the signature.
 
+3.2.3.  Required for SPF Reports
+
+   SPF-DNS:  The domain(s) and related SPF record(s) used to make the
+      SPF evalutation.  MUST appear one or more times.  In addition to
+      the primary record used, additional records used due to make the
+      evaluation due to include mechanisms or redirect modifiers MUST
+      also be included.
+
+   Source-IP:  As specified in [ARF].  This field MUST appear exactly
+      once unless the IP address is not available
+
+
 3.3.  Authentication Failure Types
 
    The list of defined authentication failure types, used in the "Auth-
@@ -427,7 +434,7 @@
        dkim-selector-dns = "DKIM-Selector-DNS:" [CFWS]
                            quoted-string [CFWS] CRLF
 
-       spf-dns = "SPF-DNS:" [CFWS] quoted-string [CFWS] CRLF
+       spf-dns = "SPF-DNS:" [CFWS] domain [CFWS] ":" [CFWS] quoted-string [CFWS] CRLF

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 08 Oct 2011 12:50:06 +0200

> receivers accepting FAIL.

There seems to be a semantic crossover here.  On the one hand, some
operators understand SPF as a means to ensure proper deliverability of
any bounce that might occur, avoiding backscatter.  On the other hand,
ARF can be understood as an extension of DSN designed to overcome its
restrictions, both target address and content.

If an MTA rejects a message because of SPF FAIL, this may result in a
bounce issued by the relay.  OTOH, the same MTA may notice that domain
owners are providing a fixed bounce address for SPF FAIL, and thus may
safely issue the bounce itself.

That is to say, we may alter the semantics of FAIL so as to allow both
choices on equal standing.  For example, some domain owners might be
interested in tracking abuse of their domain name for forensic
purposes, which may result in a stronger anti-spam effect than just
avoiding the delivery.