On Wed, Mar 11, 2009 at 4:41 PM, Steve Atkins
<steve(_at_)wordtothewise(_dot_)com>wrote:
On Mar 11, 2009, at 1:38 PM, HLS wrote:
On Wed, Mar 11, 2009 at 3:33 PM, Steve Atkins
<steve(_at_)wordtothewise(_dot_)com> wrote:
This was touched upon back in 2007/2008 holidays with a WG
suggestion to add a DKIM-Signature tag thats says *first party only,
neutral, etc* which can be viewed as an optimization.
I think it is a great idea. But the issue is legacy mail. The
issue is not the good mail. The issue is the bad mail - the one that
don't have the "extra" DNA genes to detect.
If the flaw is bad mail being sent to recipients who have never
received good mail, what's the threat that's being defended against?
Bad mail?
Caching and recording is good. But what if you never saw this before and
don't have information recorded?
An example:
corp.xyz.com is a company that would like to do online commerce or billing
with their customers (B2U). A rare market scenario <g>
They use "customer-support.xyz.com" as a special 2822.From address in all
their correspondence to their user base.
Pre-DKIM: Legacy mail
From: Customer_service(_at_)customer-support(_dot_)xyz(_dot_)com
To: layman_user @ someisp.com
As we know, this is subject to spoofing and phishing. There are
indeterminate results that simply ends up getting passed to the users. I
think we can all agree this one the motives and reasons why we are here.
DKIM: 1st party signature
DKIM-Signature: d=customer-support.xyz.com
From: Customer_service(_at_)customer-support(_dot_)xyz(_dot_)com
To: layman_user @ someisp.com
And a ADSP DKIM=DISCARDABLE record is available.
Now, with immediate short-term and long term benefits, this company will be
protected at all ADSP compliant receivers. No more or a greatly diminished
legacy spoofing problem for this domain. Domains, receivers and users
benefits.
So the concern is, "is this too much DNS overhead?"
Well, we already covered two aspects for optimization per SSP design
requirements guide and the TA (threats analysis) guide.
1) Valid 1st party signatures do no not policy lookups.
2) Only with no signatures (invalid), is ASDP recommended.
This is where the issue regarding the 4871 "Failure = No Signature" comes to
play Not trying to rehash it. Just analyzing it from an implementation
standpoint:
For #2 above, it means two things:
2) Only with no signatures (invalid), is ASDP recommended.
2.1 No (physical) signature exist
2.2. An failure signature promoted to no signature.
Well, the in-band policy tag idea will only work for 2.2 and in this vain, I
think it is a good idea as we move into the long term operations of
DKIM/ADSP.
But you still need to deal with 2.1 when there is no recording information,
no signature. This is the only way to protect corp.xyz.com with its
vendor/user communications.
The idea discussed is that this ADSP policy would need to be duplicated in
the DKIM-SIGNATURE as an optimized long term operation.
Jim Fenton pointed out that this is good, but it may further complex DNS
key/policy management.
--
hls
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html