> -----Original Message-----
> From: John Levine [mailto:[email protected]]
> Sent: Friday, September 30, 2011 11:58 AM
> To: [email protected]
> Cc: Murray S. Kucherawy
> Subject: Re: [marf] Comments on draft-ietf-marf-authfailure-report-01.txt
>
> Sorry not to get to this sooner. This draft has problems. It's
> not ready to ship.
>
> Sec 3.1 says a report MUST include explicit auth results for both DKIM
> and SPF. Well, no. I don't check SPF, so if people are only going to
> accept DKIM failure reports if they also say something about SPF,
> they're not going to get any reports from me. I expect people who
> check SPF but not DKIM feel the same way, particularly for the large
> fraction of mail that has no DKIM signatures to check. Suggest just
> removing this clause, and let people report what they're reporting.
I'm gently kicking myself now for not having included reporting result codes in
RFC5451 for "not checked".
I think the intent here (as I mentioned to SM) is that this is really a
specific profile for ARF use, creating a new feedback type, that originates
with sites that do check both; if you don't check both, you simply wouldn't use
this feedback type. It didn't occur to me when I crafted the original versions
of this work that there might be sites that don't, and that there's no way to
say explicitly "I don’t check {DKIM,SPF}."
I realize now that approach was maybe a bit limiting.
Perhaps one solution might be to go register "not-checked" under RFC5451 for
both SPF and DKIM, and then this could be mandatory. That seems overkill
though, unless we can decide we really want that (or that it would be a good
idea to do regardless).
Failing that, it does seem to make sense to reduce this to "MUST report at
least one of..."
> Original-Envelope-ID and Original-Mail-From: same issue, they're not
> relevant to DKIM, and by the time I check DKIM, it's often after SMTP
> is over and the envelope isn't directly available. Suggest it say
> they SHOULD be included if they are available.
That makes sense to me, or SHOULD if you're reporting SPF.
> Source-IP: same problem. If you don't have the source IP, just leave
> it out, don't lie. (And 0.0.0.0 is totally oldthink. The value I'm
> not going to include is ::.)
I agree with this one.
> Message-ID: this is just wrong, RFC 5965 does not report it.
I don't agree with this one. What's wrong with adding this here even though
RFC5965 doesn't include it?
To me the stronger argument is that RFC5322 doesn't require it, so this can't
either.
> 3.2.1: Delivery-result: what I do with my mail is none of your business.
> This field has to be optional.
Agree.
> 3.3: Why just spf rather than spf-fail, spf-softfail, spf-temperror,
> or spf-permerror? If you're reporting an SPF problem, you presumably
> know what your SPF checker returned.
Seems reasonable, though the applications for this I can think of don't
necessarily care, and so the detail of the failure could be included in a
comment.
> 4: SPF-DNS. If you're going to return a snapshot of the SPF record,
> shouldn't you also return all the records it included?
Agree.
-MSK (as participant)
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
