Brett,
IMV, the topic of DKIM DNS management or who is saying is really a
moot point because at the end of the day, it goes back to your initial
posting here:
How does the general public get protected from potential
PAYPAL abuse when using the public list servers promiscuously?
That has been the issue and basis for the philosophical differences
regarding policy for a very long time.
This has all been researched, debated, etc. See the Security Threats
RFC 4686:
http://tools.ietf.org/html/rfc4686
The problem is that even with all that, we had out of scope influences
that watered down the security concerns, namely because the List
Administators wanted unrestricted DKIM resigning capabilities. But
since MLM is a natural breaker of integrity, some wanted their legacy
software to continue working as is. I still don't understand why one
would consider DKIM for a MLM and not filter the restricted policy mail.
I'm afraid there is nothing you could do to protect your consideration
of using a domain (low or high) outside a direct 1 to 1 mail transaction.
At best today, you can do:
- Declare a "My Mail is always sign", with the reduced version of
SSP called ADSP, that appears to be "DKIM=ALL"
- Inform, suggest (mandate?) to your employees that with the
new domains specially for employee usage outside the corporation
that they only permitted to use it on KNOWN LIST SERVERS with
DKIM signing support.
Note: It might be useful for an advertisement of what a list
server is capable of to first time subscribers
With this, what do you protect against? At best:
- Legacy Bad Guys who don't sign
- Bad Guys using broken DKIM-Signature headers.
You won't be protected against:
- DKIM Adapted Bad Guys signing as a 3rd party with valid signatures.
Thats it! Thats the best we can do expect at deterministic level.
After that it is indeterminate environment which the wide spread of
reputation people are trying to address.
- Hope that the majority of the end users seeing paypal submitted
list distributed mail are hitting receivers that are registered
subscribers of reputation vendors (Batteries required syndrome).
Thats it!
No gathered statistics data will fundamentally change this long
understood issue. The data will most likely prove the above which
doesn't regard proof.
On another related note:
We long understood that a centralized repository or server for
reputation and/or certification would be ideal where everyone would be
able to use as a single source lookup system. But no one likes a "one
vendor" to have this control. Yet, there are vendors that offer a
free API or method for verifiers.
Maybe that is what is needed is a standard for a "reputation lookup.'
Crocker, Otis, Leslie drafted the CSV-CSA proposal which is at the
SMTP level.
http://tools.ietf.org/html/draft-crocker-csv-csa-00
It was the first time that a "reputation" model was introduced for
standard mail (during the MARID working group discussions, where
SPF/SenderID was worked out as well for RFC draft standards) .
But it still had the "one vendor" and "batteries required" issue which
no one really wanted (at the time) for a wide open standard across the
network. I always thought CSV-CSA was a good idea and eventually
would be useful, but it wasn't ready for prime time.
Finally, maybe it is at this point it (the idea) is ready for prime
time, but we don't have a reputation standard for DKIM which is a RFC
5322 technology (not RFC 5321 level technology).
Suggestions were made (by me and Otis) where somehow we can pass the
5322.From domain to the CSV/CSA layer like we wanted that for
Sender-ID at the time discussed for MARID, and also useful for
reputation services to offer a POLICY as part of their attributes for
a domain records:
[X] This domain requires mail to be signed.
That way, when an SMTP receiver does CSV/CSA, it can get the bits to:
- Use it for Sender-ID at SMTP level
- At the payload DATA level for DKIM Policy
But again, this requires batteries and its not a self-asserting policy
design which would be ideal to cover the receivers that don't have
batteries or the same batteries others are using to get that "Policy
Bit" from the domain reputation/certification record.
As you can see, it all boils down to how can a domain, like a paypal,
can make policy visible, practically, feasibly and scales in a way
that doesn't hurt the DNS network.
We all have different ideas, some base of their current operations,
some based on making a profit, some based trying to do it in a way
that fits the current framework, some that want to make simple by
SIGNING first and then figure it all out later.
That latter is simple and great for pure DKIM adoption, but its can be
also dangerous to create a new relaxed environment where it might be
too late to protect DKIM signatures deterministically. I don't feel
we are there yet but it ain't going to happen until the concept of
POLICY is better accepted especially by the reputation advocates.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
McDowell, Brett wrote:
Here is why a paper should be written (BCP or not, IETF or not)..
On Sep 13, 2010, at 6:08 PM, J.D. Falk wrote:
They say the former scenario where ESPs sign with their own domains is still
more common, because in general ESPs are more authentication-savvy than
their clients tend to be.
Ah, a deployment decision driven primarily by ignorance... that's an
opportunity for us to educate.
The ESP domain wasn't chosen because anyone thinks it's a better practice,
however.
Ah, even worse, a deployment decision that is not even considered a better
decision, driven by ignorance.
It's because otherwise, they'd be sending unauthenticated mail
So these less sophisticated senders aren't acting as if they are aware of
their options and they are defaulting to a deployment configuration simply
because they don't understand or are not prepared to deploy the alternative.
-- and many in the ESP world fear disastrous deliverability consequences if
they aren't fully buzzword-compliant.
If the ESP's are worried about the sophistication of their clients then they
may not be on the front lines trying to educate their clients of this key
management alternative that more sophisticated senders are deploying.
So, I don't want to argue over whether or not this group (or IETF DKIM)
should publish a BCP around this, I just want to find out sooner than later
whether or not their is a rough consensus to pursue it here or not (then I'll
know what I have to do next).
-- Brett
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops