----- Original Message -----
From: <Bill(_dot_)Oxley(_at_)cox(_dot_)com>
Requirements,
What do I sign
Who does my signing
When does my DKIM Public Key expire
Who do I sign for
Who shall I never sign for (I sign no mail)
What receiver expectation shall I set (perhaps dodgy)
What else should be on the list?
Signer POV. Cool. :-)
Now lets look at a "Lean Fly Squatting" Verifier POV:
First Stage: Incoming Mail:
- Does he ever distribute mail? (Never Send Mail)
- Does he expect the mail to be unsigned? (Never Sign)
- Does he expect the mail to be sign? (Always Sign)
- Does he care? (Neutral)
- Does he allow others to sign? (Allow 3PS w/o Allow List)
- SSP Result Disposition based on Local Policy (Default Reject)
This is a low overhead, highly efficient DKIM consideration, where the need
for verification overhead is short circuited - this helps comply with the
discovery requirements of a DKIM-SSP design.
Second Stage:
- Ok, got something, it is expired?
- Ok, got something, does it hash out (signature verify)?
- DKIM Result Disposition based on Local Policy (Default Reject)
Remember, we have to do the dissemination of all the mail traffic coming our
way.
I (verifier, traditional SMTP receiver) really does not care for:
- "What" kind of mail you sign, and
- "Who" signed for you (as long as you said its ok)
This WHAT/WHO is really none of my business. That could be moved to a
trusted layer or mail content heuristic system.
But for this particular DKIM-BASE model? The above questions are items I
would like to know before I even bother with the DKIM-BASE signature
verification overhead.
To me, this is simple and lean and it adds a tremendous benefit in securing
the DKIM signing practices and expectations.
This simple and lean model, helps the signer by adding weight to his
signature validity by eliminating the most obvious of potential
inconsistencies and by doing that, I am helping my own system by getting rid
of the most obvious unauthorized DKIM-based abuse.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html