On 8/2/11 11:43 PM, Michael Deutschmann wrote:
On Mon, 1 Aug 2011, Douglas Otis wrote:
This would be a safe method to extend policy without requisite two
party coordination as currently expected by DKIM.
The problem is that for the majority of From: domains claimed in incoming
mail, the TPA approach is just as unfeasable as "two party
coordination". The problem is not the lack of a language for the
alleged-sender to express detailed policy -- it is that the alleged-sender
doesn't have a fully detailed policy to express. The real communication
barrier is between the DNS admin for a domain, and the end users who have
mailboxes on that domain. An end-user would have to be exceptionally
computer literate in order to help his admin publish a correct TPA policy.
The concept behind the TPA scheme was to enable services on behalf of
senders that lack requisite staffing to support this level of policy
effort when using open-ended third-party services. The list of open
third-party services where exceptions are desired could be centrally
managed. Senders would be allowed to delegate the task to those
services having requisite staffing. For the sender, it would be a
single one-time delegation. A service that would need to be tailored to
different categories of senders.
While *phishers* may see no point in forging that class of domain, a
layered protocol (ADSP or successor/replacement) that makes no attempt to
defend those domains is not worthwhile for me to deploy *as an MX admin*.
Which means blatant phish with a single From: and no signature could sail
right through.
This effort would only be suitable for enterprises wanting to better
defend email as a service to their customers. Just as person to person
communications are often secured by buddy-lists, a similar scheme could
better defend an open-ended email notification schemes likely to become
phishing targets. DKIM could support a service that offers a form of
third-party service buddy-list to assist in anti-phishing policies of
targeted domains without disrupting use of these open third-party services.
The best that the administration of such domains can offer, is a claim
that the end-users have been trained to always use the official
smarthost, and thus every non-mailing-list mail will be signed.
It's weak, but it's far better than nothing. For some recipients, such as
myself, it would be as useful as discardable. I know that anything that
smells enough like a mailing list to invoke the loophole, yet hasn't
already been diverted by my whitelists, is junk.
Why should white-listing mailing-lists or open third-party services
become a burden for the recipient or their administrator? Better
management of these lists directly benefits senders. While it might
represent too much effort for the average sender, this would not be too
much effort for most email reputation services to handle. The cost and
management of this anti-phishing service should fall on the sender, not
the recipient.
For this to make any sense with respect to anti-phishing, Double From
header fields must not produce valid DKIM signatures. While DKIM can
potentially support enhanced policies aimed at mitigating phishing, it
lacks a basis for gauging spam reputations. DKIM lacks any assurance
who the sender intended to receive a message. This limitation in DKIM
makes holding a signer accountable for unsolicited commercial email
problematic.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html