On Wednesday, October 05, 2011 10:34:15 PM Murray S. Kucherawy wrote:
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf Of
> > Scott Kitterman Sent: Wednesday, October 05, 2011 7:42 AM
> > To: [email protected]
> > Subject: Re: [marf] Comments on
> > draft-ietf-marf-authfailure-report-01.txt
> >
> > 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
>
> I agree.
>
> > 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 don't think another IANA registry is needed.
>
> Agree here too.
>
> > 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.
>
> Can you propose some text changes?
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
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
