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.
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.
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.
Call it something else and a comment isn't sufficient.
So why was it acceptable by you for SPF?
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.
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.
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.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
