On 10/14/2015 5:04 PM, ned+dm...@mrochek.com wrote:
If the installed base can legally ignore a new feature, then it is not
mandatory.
The nature of DKIM is such that many signatures end up getting ignored as
part of normal operation. That doesn't make any aspect of the various
mandatory aspects of processing those signatures any less mandatory.
Its the same old theory since the original conception -- Only the ones
with a policy will have any payoff, the more stronger, the higher the
payoff will be. The more relaxed policies are still exploitable making
it a high waste and overhead in processing.
The only way to make a feature mandatory in a new version is to provide
it in a fashion that makes it only available to folks adhering to the
new set of mandatory features.[*]
FWIW, this is equivalent to saying that adding new
mandatory features is equivalent to creating a new
protocol.
I suppose you can define it that way if you like, but doing so ignores
the substantive overlap both in terms of syntax, processing semantics, and
most important of call, usage.
For my package, we have to modify the C/C++ signing engine. If ALT-N
does not make the change, we have to do it ourselves. In any case,
any change requirement will allow the opportunity for the drastic
changes to be done. So just get it defined correctly. Right now, v2
signatures will fail. Any we also have to change our C/C++ List
server code and also our current official release DKIM+ASDP+ATPS based
package to a DKIM+DMARC+ATPS. We are not even covering the ATPS
part. So I have to clean that mess up too perhaps and somehow tie it
into this !FS= v2 thing.
I don't understand why if we have to make so many changes, we can just
easily get it right with straight policy logic. Look up the 3rd party
authorization. We should be allowed the opportunity to open that door
now and allow people to explore it.
Allowed = 3rdPartyFunction(domain)
and that 3rd party function can anything, including !FS and/or a
policy lookup.
Whatever. If the IETF is going to ask people to change their stuff,
lets make it work this time around. Levine proposed ADSP before and
it failed. Now he has this !FS= thing. I'm willing to give it one
more shot.
Thanks.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc