Dave Crocker wrote:
> Among the various discussions I've had today, one
> comment about SSP struck me as worth wider consideration:
>
> SSP is one organization's attempt to tell another
> what it should do with mail that is from a third
> organization.
We can always get in trouble with the semantics David.
I would rather view it as an organization's exposure using an world wide
database (DNS) of its DIM policy on how its domain is being used with DKIM.
Please try to consider this, not saying you have to agree, just please
do take some of your time to consider these points. I apologize for the
length, but I hope I can summarize many of the key issues, discussions
and consensus which included specifically addressing your statement
above. Of course, this is all my opinion, but I hope I am on par with
the major issues and consensus reached.
Consider the following:
- Organization ABC may desire that its email domain property is
exclusively used only by the organization. There is no
outsourcing, no clearing house, and it has a company policy
with provisions that mandates domain brand protections
by restricting employee external usage of its domain for
non-company related communications.
All mail is DKIM signed by the domain. No exception.
- Organization XYZ may desire that its email domain property is
exclusively used only by the organization and exclusively
with a 3rd party service (3PS) vendor for distributing special
mail as well. The company policy mandates its domain
brand be protected by restricting employee external usage
of its domain for non-company related communications, and that
all mail with the company domain must be signed by its internal
mail operations or by the exclusive 3PS service vendor.
All mail is DKIM signed by the domain or by the 3PS vendor.
No exception.
- Such organizations, with the available technology, have a
expectation that implementing this technology would help in
reduction the today's obvious problematic fraudulent usage.
They would prefer that any compliant receiver able to detect
fraudulent usage with 0% false positives, and *classified" it
for rejection.
Now, please consider these two very important points. They are vital
considerations:
- Consider that RFC 4871 places a new "responsibility" on the
domain owner for signing mail with DKIM. As such, there is
also inherent and expected equal responsibility on the DKIM
receiver to assist in the disseminating process.
- The key general industry problem is the handling unauthenticated
x821 anonymous, unsolicited message transactions. If there is no
information about the sender, it is currently difficult, with no
standard protocol, to make any assessment, good or bad, about
the sender and/or domain.
So what does that mean?
It means, at least for a system like us, and I believe many work in the
similar manner, if the 2821 session is authenticated, there we skip most
or all filtering concepts. DKIM is very likely to fall in this category
as well. I believe the main reason is because we have more faith in the
legitimacy of an x821 authentication based transaction. That faith is
increased with local white listing. There is still methods to detect
abuse by compromised authenticated users, but for the most part, these
additional filters are generally skipped or reduced to possibly only AVS
scanning with authenticated sessions.
So this is mostly about dealing with the anonymous sender.
How do we change the anonymity of the sender?
Well, first we need to decide "who is the sender?" This seems to be a
source of contention in this group.
Regardless of who or what is the sender, the commonality is the
fundamental concept of finding the "anchor" for the discovery process.
We, as a group, decided the established universal entity for the
authorship of the message is the x822.From address domain and that would
be the "anchor.". I believe a main reason is that required by x822 to
be present, especially when there no other markers, such as a DKIM
signature, in the message.
We can not guarantee the Sender: address will be there and if we wanted
to use this, then I believe we are forced back to a x821 design because
if missing, the only reasonable substitute is the Return-Path:.
Note: In past SPF/Sender-ID analysis input for the FCC, I
found for ~80-84% of the time, the following domain
association holds true in non-list server environments:
x821.MailFrom == x822.From [== x822.Sender if present]
With such a result, it reflected the potentially higher
payload overhead with Sender-ID vs SPF operations with
no payload overhead.
So the From: address is the most reasonable and most practical anchor
available to today for an unsolicited, anonymous, including unsigned
transaction to perform a SSP lookup.
If a domain has a SSP policy that says "No 3rd party" i.e., no tampering
is expected, then IMO, that should be view as a 0% false positive
indicator for the receiver to use to help protect the domain while also
helping itself in eliminating the flow of fraudulent mail.
Overall, SSP should answer these basic questions:
* Does the domain ever distribute mail?
* Do you expect the mail to be unsigned?
* Do you expect to sign all mail?
* Is your domain the exclusive signer?
* Are 3rd party signers or signatures allowed?
* Are 3rd party signers allowed to strip your original signatures?
[BONUS READING MATERIAL: Reputation Considerations]
If the receiver had "reputation" information about the domain, then most
of this, SSP and DKIM itself becomes a mute point.
Fundamentally, Reputation comes in two forms:
- Some local policy white or black list.
- 3rd party service bureaus such as DNSRBL or some TRUST SERVICE.
So there are two issues here for DKIM signers and receivers:
1) In lieu of DKIM TRUST SERVICE (DTS) (100% linked with DKIM
with no exception), both the DKIM domain and DKIM receiver
are at risk for potential fraud. The most information that
can be gathered is:
- No signature present
- Valid Signature present
- Invalid Signature present
and with no augmenting assessment technology, both the
DKIM signer and receiver are left in limbo. The only
benefit gain here is valid signatures, but there is
protocol for protecting against fraud.
2) Even with a DTS in place, there is still risk with those DKIM
receiver systems who are a) not participating in DTS, or b) is
participating in another DTS where the DKIM domain is not a
member of. The most information that can be gathered is:
- No signature present
- Valid Signature present
- Invalid Signature present
- Domain has no TRUST relationship
- Domain has a TRUST relationship
- Domain has a TRUST relationship, but no discovery process.
For the receiver, the only reliable result for factors in a
decision making process in increasing confidence order:
- valid signature, no trust established
- Trust Established for invalid signature
- Trust Established for no signature
- Trust Established for valid signature
So even with a reputation system we are still vulnerable for abuse, and
please note I decided to leave out vendor/user service agreement issues,
the commercialization aspect of all this that has a risk as well.
Nonetheless, I believe many, here and outside, have genuine concerns
with any centralized TRUST services requirements in order to make DKIM
work for a score of many reasons, including the basic idea that DKIM
should remain to be a separate open technology with protocol flexibility
to augment new reputation concepts.
In the short term, is history has any meaning here, you end up with the
"batteries not included" dilemma many, including my company, had
experienced with non-standard technical operations, customer support
issues and public relations problems (The DTS may be very customer
friendly and begins to pick and choose who can be members by using a
multi-tier pricing model), when new technology (such as eCommerce
automated credit card processing) in its early stages of development
provide little options to consumers. I think it would extremely
unfortunate if DKIM becomes a "batteries not included" commodity.
Therefore, with all that said, I believe SSP provides that first level
protection for domains who prefer to operate in whole or in part with an
exclusive or strict signing practice. The design dilemma has always
been on why should an open ended 3PS signer be restricted or controlled
by providing (by some means) to authorize 3PS to sign on behalf of the
original domain.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html