On 8/19/2017 3:48 AM, Bron Gondwana wrote:
For what it's worth, the ONLY one of these which my "fake Brandon"
email would have failed to validate for is p=reject, arc=none. A
chain of valid ARC seals is so easy to fraudulently create that it's
not funny.
Everything other than arc=all there is totally pointless - if you can
intercept and modify email, you can easily add ARC headers that
maintain a complete chain is seals.
Now arc=site2.com,site3.com,site4.com - that's valuable.
I agree. That is what the ATPS (Authorized Third Party Signature) and
the ASL (Authorized Sender List) proposals was all about.
https://tools.ietf.org/html/rfc6541
Check out this wizard that helps generate the appropriate ATPS records
and/or ASL extended DMARC tags:
http://www.winserver.com/public/wcdmarc/default.wct
But many feel it doesn't scale. We also called it a "registration"
problem, i.e. how to get that authorized list, etc. What has been
going since then is to develop a method to inherently pass this
information via the headers. Thats been hard to understand since we
are already making a DMARC DNS lookup that perpetuates all this. We
are just not getting enough information to properly work with it.
You could
say "only allow ARC through the following intermediate domains" - and
then you could add those to your allowed list for your domain as you
got reports of validation failures and user requests. Over time a
domain would build a list of mail flows that its users used. You
could even use a different selector for each sending user, and publish
a different policy for that selector, so each user got their own
allowed mail flows!
But anything that's based on count/position of seals in the chain,
that has no value.
I fully concur with the "level of "experimentations" that would give
all parties, a payoff they can realize and the capability to design a
logical integrated system and negotiate3ed protocol without kludges
and also apply some "Deep Learning" to help with the indeterminate
conditions.
We have determinate conditions with the strong policies. These MUST
be honored or nothing works. This is the DKIM POLICY LAYER MODEL. The
indeterminate conditions are the relaxed policies leaving it up to the
receiver to explore algorithms. This is the DKIM TRUST/REPUTATION
LAYER MODEL. The DKIM standard purposely removed the Policy Layer
with the hope the trust layer would prevail. Many folks did not like
this decision. It was extremely rough and we didn't have other
developers, such as yourself around.
But as expected, it didn't happen and the problems we are seeing is
due to that separation. That said, I still expect it to happen
because Policy gives us the first level automation (thanks to DMARC),
and Trust/Reputation is the 2nd level to help with the fuzzy
conditions. This is where it will be a vendor-based added value
component to DKIM, as it was designed to be and should be. But as it
was always stated, not everyone is going to use the same
"Trust/Reputation" databases. I called that the "Batteries Required"
dilemma.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
