Re: [marf] Change request for AS, was Working Group Last Call on draft-ietf-marf-as-05

[Steve Atkins <[e-mail]>]

On Feb 4, 2012, at 11:27 PM, Murray S. Kucherawy wrote:

>> Is the thought to add them to the AS document as a section on how to
>> craft and send an ARF message that's being used for SPF or DKIM failure
>> feedback? Or as something that's more generally applicable to all ARF
>> usage? Or something in-between - FBL best practices, say?
>> 
>> (Also, if we're going to do that, should we reference 3834 - Auto-
>> Submitted and all that - as well / instead?)
>> 
>> It does seem to make more sense to have them both referencing a base
>> "reporting auth failures" document that covers the common requirements
>> rather than referencing each other, whether that base doc is draft-
>> ietf-marf-as or not.
> 
> It seems to me what's in Section 6 is good advice for any ARF generation case.

6.3 isn't bad advice, but the justification of some of it is rather specific to authentication failure reporting. Do we want to mandate that anyone sending ARF reports of any sort MUST also publish SPF records or send them with a NULL envelope sender? That requirement isn't unreasonable in the case where you're talking about reports sent in response to an authentication failure, where avoiding an authentication failure in response to a report of authentication failure is a reasonably belt-and-braces way to help avoid a mail loop - but beyond that narrow scope it seems a bit of a reach. There are people who consider SPF irrecoverably broken, yet still offer feedback loops.

> What's in DKIM reporting's 8.4-8.6 would go under a section that talks about any kind of automated reporting, with authentication failure reporting as the prime example.  

Some of it is specific to authentication failure reporting. As for the rest of it, are they security concerns that should be discussed in marf-as regardless of whether the DKIM/SPF docs want to reference them? I'm thinking yes.

And (I'm going to regret asking this, I'm sure) where does draft-ietf-marf-authfailure come into this? It has much the same security statements and is already referenced by the SPF and DKIM failure drafts, I think.

> The two reporting drafts would then reference the AS instead of including those sections themselves, and the AS could reference them as use cases.  That would turn them into a document cluster, but that's not a big deal; it just means they are published simultaneously with sequential RFC numbers.

Cheers,
  Steve