A few comments on this draft: Section 3 should probably include a sentence at the end that says "In the absence of an 'r=' tag in the SPF record, all other fields defined above MUST be ignored."
Some of the stuff in Section 6 looks like it might have been copied verbatim from [ARF] or [DSN] (though I've not confirmed this). If that's the case, I'd prefer to see them incorporated by reference rather than by value. I also wonder if any copied from draft-ietf-marf-authfailure-report and/or draft-ietf-marf-dkim-reporting should also be incorporated by reference, and normative references added accordingly. I think there's still an open question about whether Section 5.1 belongs here or in the fledgling SPFbis effort. I think we have a few choices there: 1) Do it this way, since the future and path of SPFbis is uncertain. 2) Do it as its own memo and see if APPSAWG will pick it up right away. It would only contain the "exp" and "redirect" entries just for the sake of creating the registry, and would be marked as "updates 4408". Then, this memo simply updates that registry, and SPFbis can update it as well if needed. This might be the cleanest solution. (Barry, thoughts?) 3) Replace Section 5 with text that basically says we know SPF doesn't allow unknown modifiers, but proceed anyway because people that want this will be able to make the distinction somehow. That might warrant demoting this to Experimental and upgrading it later. Then SPFbis or a separate action can create the registry and make it all formal when its future is more clear. I'm quite in favour of 1 and/or 2. In Section 4.1, PermError needs an end-quote. I think [DKIM] is an informative reference here, not a normative one. In Appendix A, my last name is spelled incorrectly. :) Finally, does anyone know of any SPF implementations under current maintenance that are entertaining the idea of implementing these extensions? -MSK
_______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
