On Thursday, May 07, 2015 09:48:30 PM Hector Santos wrote: > On 5/7/2015 7:42 PM, Scott Kitterman wrote: > >> In other words, does the AUTH-RES protocol allow it itself to be > >> extended, it is flexible enough? If not, then AUTH-RES will need to > >> be updated again. > > > > A-R is certainly extensible, but there are IANA registries that need to be > > updated. > > Its not extendable (meaning its optional as well) if you can not use > the same namespace. Think flexible I/O functional interfacing with > null/default parameters. You > want to use the same I/O otherwise more updates are required.
All that goes in the DMARC part is the deader.from and the result. It doesn't need to be extended to add a new auth method. > > RFC 7489 defines DMARC. > > True, just consider per DMARC (RFC7489) section 3.1.3 > > 3.1.3. Alignment and Extension Technologies > > If in the future DMARC is extended to include the use of other > authentication mechanisms, the extensions will need to allow for > domain identifier extraction so that alignment with the RFC5322.From > domain can be verified. > > This means that AUTH-RES semantics requires to be functionally > compatible (extendable) as well from an integration standpoint. And it is. You put the new information in a phrase of the header field dedicated to the new method. It only changes the result for DMARC once DMARC has been extended to include it, which it hasn't been yet for ATPS or any other method. > >In fact, if you look at the registry [1], it points to > > > > RFC 7489 for the definition of how to use A-R for DMARC. If you are doing > > something different than that, you're doing it wrong. > > First, the work predated DMARC and second, Murray was made aware > AUTH-RES was not flexible enough for DKIM+ADSP+ATPS as it wasn't for > SPF. It may be today. I haven't checked. For SPF, it's adequate to communicate the result. It's not adequate to allow someone to independently reconstruct and assess the validity of that result, so it's less useful as a trace header field than Recieved-SPF, but given it's goals, it meets them. > > Call it something else and a comment isn't sufficient. > > So why was it acceptable by you for SPF? You get an identity and a result which is all that's absolutely needed to machine parse the SPF answer. As above, it's adequate even if not, from my PoV ideal. > > An A-R header field should be able to be automatically processed > > without reading the comments. > > I agree, but software is smart it can do a "(atps signer)" string > check, just like you accepted the "(comment) kludge to complete SPF > AUTH-RES reporting as well. No. If you make any assumptions about the contents of a comment field, that's a poor design. You can, but you shouldn't. > > Neither author.d nor signer.d are not defined. Given the use of unknown > > properties with a known method, I think any implementation might > > reasonably > > ignore this entire result. > > AUTH-RES is constantly being updated and IMO prematurely registers > stuff because it actually is a real standard in practice. But this is > all besides the point. You are going off on an tangent that has > nothing to do with this. Plus, it wasn't defined so you do what you > need. It SHOULD NOT break any current Auth-Res reader. Lets also > note the AUTH-RES is for internal consumption and actually more for > reporting because odds are good they are internal ways to do the > handling anyway. Lets not not assume it will all be done by reading > AUTH-RES, i.e. SMTP level rejection at DATA. It's true that A-R was designed for consumption inside an ADMD. It doesn't necessarily follow that all software within that ADMD is provided by a single vendor. A-R is standardized to make that internal communication easer. I think your point about internal consumption is true, but not particularly relevant. Also, people have proposed extending the structure to carry authentication information from a trusted mediator to a receiver which is at most only sort of internal to an ADMD. As long as in your experimentation you don't interfere with what's already standardized (and IMO your example did), then I'm fine with it. > > I think this should be registered (if it merits continued development and > > deployment) as its own method. Then you might have something like: > > > > dmarc-atps=pass header.from=isdg.net signer.d=ietf.org > > dmarc=fail header.from=isdg.net > > > > Consumers can then decide if they care about dmarc-atps without having to > > interpret a new authentication method's results if they don't. > > Those are details. I agree we want to a consensus on a common > nomenclature, but its all besides the point. > > I did not want to make this issue about Auth-Res, but if you ask me, > from a plug and play standpoint, if you have an DMARC handling reading > Auth-Res as it written with a > "dmarc=" namespace, I would not propose a new "dmarc-atps" namespace. > Its an extension of DMARC therefore it belongs in the same "dmarc=" > namespace. As above, no. It's an auth method that DMARC uses, not a internal part of DMARC (SPF and DKIM results are not reported inside a DMARC= namespace and this is no different). Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
