For nearly 10+ years we have discussed the same basic design issues.
Nothing has changed other than the fact it is DMARC, as it is
currently written as the replacement protocol for a DKIM POLICY
SSP/ADSP framework, is very lacking intentionally. We don't have
enough of the advocates we once had, pushing the COMPLETE DKIM POLICY
FRAMEWORK concept. Either they got tired walked away, they saw can't
beat a dead horse or realize the people in "IETF control" were pushing
other ideas that were not necessarily wrong, but they PUT barriers up
to support the AUTHOR domain framework.
We will not move forward in a major way until the 3rd party SIGNATURE
authorization methodology is worked out. It was a thorn on the side
then and it continues to be a thorn on the side today.
We have quite a few RFCs related to DKIM signature methodologies and
we never did properly resolved it (3rd party signers) because the key
folks running the show were pushing a 3rd party TRUST methodology.
They were militarily adamant about making sure the AUTHOR domain would
not be dictating anything, hence the DKIM myth the AUTHOR DOMAIN was
not related to the DKIM SIGNER AUTHENTICATION and AUTHORIZATION. That
SEPARATION was impossible to ACHIEVE because the AUTHOR was a minimal
hash binding requirement.
But today, the TRUST part has gone no where, i.e. VBR was the closest
thing to a DKIM TRUST model (we support it, do you?). It was AUTHOR
POLICY that has prevailed but DMARC crippled it by sticking with the
same problems ADSP had.
Add 3rd party POLICY extensions and we will begin to get sensible
software solutions again. We done it with ADSP/ATPS. So can large
boys too with DMARC/ATPS. Add ATPS support or similar and we will
begin to move forward with a framework for proper SOFTWARE CHANGE at
the MLM.
Wasting too much time again. Just update ATPS for DMARC and get MURRY
to support the idea and maybe we will get others to get it a try. But
if he is going to continue to block it, talk negative about it, well,
we have a technical marketing problem that is not representative of
a good technical, plug and play, easier solution for DKIM SIGNATURE
AUTHORIZATION PROTOCOL.
--
HLS
On 3/24/2015 4:38 PM, J. Gomez wrote:
On Tuesday, March 24, 2015 5:14 PM [GMT+1=CET], Stephen J. Turnbull wrote:
J. Gomez writes:
I think we are not talking about the same thing: when I said
"depends on DMARC's success", I meant "depends on DMARC's success
as an implemented technology in the real world", whereas it seems
you understood "depends on a successful DMARC check".
No, we are talking about the same thing. What I am saying is that
DMARC is already a "success as an implemented technology in the real
world" by any reasonable standard, because it *does* work for exactly
the transactional mail flows you worry about.
I do not agree. As long a major ESPs downgrade p=reject to p=quarantine or even p=none on
reception of email which fails DMARC checks from domains whose Owner has published
p=reject, DMARC is little more than a reporting protocol as Vlatko Salaj has already said
in another post to this list. Which is nice, but is not a "success as an implemented
technology in the real world" for DMARC, because DMARC aims to be more than just a
reporting tool.
I know for sure I will publish only p=none for my client's domains, and use
DMARC only as a reporting tool, as long as DMARC's p=reject cannot be reliably
relied on. But I would love to be able to reliably rely on DMARC's p=reject.
In fact, I think that if at the end of all this process we cannot find a way to
make p=reject to be reliably relied on, then p=reject should be suppressed from
the DMARC formal specification, as p=reject would effectively be equal to
p=do-whatever-who-cares.
Regard,
J.Gomez
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
