On 6/10/2014 10:00 AM, Murray S. Kucherawy wrote:
On Tue, Jun 10, 2014 at 12:41 AM, Vlatko Salaj
<[email protected] <mailto:[email protected]>> wrote:
"introducing new ML requirements" has already been
characterised as not an ML solution. we have a few
of them already, and all much simpler than any YADAs.
The person on this list that actually represents a mailing list so far
seems to like the idea, and has explained why to some extent. I think
that's much more valuable feedback.
More valuable than other feedback?
There are also other full time mail professional folks on this list,
active, lurkers or otherwise, that are very much involved with not
only the development and production of Mailing List Software (MLS) but
include also actually using their own tools for the business and
support process. Regardless of size, they all have to work the same
with the basic protocol "list" mechanics with the minimum functional
expectations and requirements to get the job done. While volume helps
to highlight where the potential weak points may be and this is always
desirable, they are weak points nonetheless at all levels.
A proposal like this one might introduce new requirements, sure, but
if they solve a huge problem and people are willing to implement it,
then so what? They're worth the work in that case.
We do need to extract them, talk about them, but there are certain
ones that simply do not apply -- they are show stoppers, a "waste of
time," not a "global common" with cooperative competition in mind
among all parties. I think we identified a few of these already.
My understanding of the constraint is that we need to avoid new
requirements that affect common mailing list practices, like footers
and Subject field tagging.
Whatever are the design constraints, the algorithms, the automation,
it needs to include all the factors and that includes author domain
policies, as in the case with DMARC with no LSP (list service
provider) authorization provisions.
The point is that, until they were available (endorsed and
championed), we won't have the full field testing experience of what
is possible or not, or how the LSP will adapt. Right now, they are
crippled because of the lack of 3rd party signing semantics or
capabilities. So the LSP are thinking of "radical" methods to bypass
the security. That is not the solution to this.
We need to have all the parameters available in the mail process
environment to see the entire framework in action with two-way
reversible, verification methods. The DKIM-Delegate suggestion is
more complex when it comes to code change, more complex than just
doing a simple DNS lookup and honoring the policies. When ignored,
eventually problems occur as it did happen now with higher volume
impact players enabling the technology. The problem was always there.
LSP are just feeling the pains of their early ignorance of the
technology.
DKIM-Delegate establishes a requirement
that mailing lists sign the modified message in full.
Where would the requirement be established? Is it a policy lookup or
just the presences of the header signifies a higher level of
expectations? This is a change for multiple mail software components
so it needs to justify why this change is better than just doing a DNS
lookup and processing the policy. Of course, without 3rd party
semantics available, all the LSP can do is fit the 1st party policy
model by denying subscription/submissions from restrictive domains.
But certain LSPs do not want to do this even at this simpler level.
How do you stop this with DKIM-Delegate when the header is missing?
Is this a short circuit optimizer?
If DKIM-Delegate is not present then do
Author Domain Lookup
What changes are the LSP willing to accept?
You know, back in 2005/2006, I remember a good idea conversation when
Jim Fenton shortly before the ASDP post-XMAS holiday surprise.
Again, using the rule above, we wanted to reduce the need to do a
lookup by passing policy information in the signature itself,
something like this, applied to DMARC today, it may look like:
DKIM-Signature: d=example.com policy=reject
We concluded that would be an optimizer for the exclusive strong
reject/quarantine policies since no one would do this if it was
possible to reject it. Its possible to do the same thing with
DKIM-Delegage of passing the policy via this header. But if its said,
p=none, and the actual policy was reject, it means a check is needed
anyway. So the rule would be now:
If DKIM-Delegate is not present
or
DKIM-Delegate.p is not reject or quarantine
then do
Author Domain Lookup?
In a lot of cases, list software does that already; often it's
the case that other software even does that for them, so how
much of a burden is this really?
I am not sure what you mean about this, detecting a list processed
message?
The burden is actually on signers (who need to add DKIM-Delegate
fields) and on verifiers (who need to look for them and know what to
do with them), not on the lists themselves.
Right, a change is required. So why not just a lookup? A lookup
eliminates the need for additional complex mail header processing ideas.
Do you believe DKIM-delegate reduces the need to do a lookup while
still satisfying all author domain related security requirements? Can
bad guys use the DKIM-Delegate to bypass non-list related mail in an
attempt to show a valid 3rd party signer? Or is DKIM-Delegate just a
means to dynamically scale authorized 3rd party signer?
I am just wondering how do you verify it and avoid the fraudulent
facsimiles of such DKIM-Delegate stamped messages.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
