Eric Allman wrote:
<https://rt.psg.com/Ticket/Display.html?id=1365>
Issue 1365 (Subject: SSP: typos) includes this brief comment from Frank:
5.3 (2): IIRC we've identified "never send mail" as a special
case of "strict", and then just not sending mail, let
alone signing it. IMO you can delete this point.
Based on the notes we seem the WG seems to be favoring dropping the
"never send mail" indication because it's redundant, but we never seem
to have gotten final consensus.
It makes sense to me. Does anyone want to argue that it needs to stay?
(Foolish me, I meant to say "Who wants to argue...".)
In my technical opinion, this will be probably among the highest
benefits that can be offered to the domain. People need to remember how
they are going to sell this concept to their customers. To me, its
about DOMAIN protection and that includes protecting the "no-mail"
domain which is currently among the top abusive scenarios.
But then again, I'm already settled on a SSP concept and a FIRST lookup
at all times.
This is our flow diagram:
Figure 2: DKIM Signature Authorization Protocol Outline
+-----------+
| PAYLOAD |
+-----------+
|
v
+----------------+
| | +------------+
| DKIM |--------------------------->| CONTINUE |
| Signature | UNSIGNED: OPTIONAL +------------+
| Authorization |
| Protocol |
| | +------------+
| |--------------------------->| |
| | SIGNED: EXPIRED (1) | |
| |--------------------------->| |
| | NO MAIL EXPECTED (4) | FAILURE/ |
| |--------------------------->| CLASSIFY |
| | UNSIGNED: REQUIRED (5) | |
| |--------------------------->| |
| | SIGNED: NOT EXPECTED (6) | |
| |--------------------------->| |
| | 3P SIGNED: NOT ALLOWED (7) | |
+----------------+ +------------+
|
|
SIGNED
MESSAGE
|
v +------------+
+--------------+ | CONTINUE/ |
| |--------------------------->| CLASSIFY |
| | INVALID SIGNATURE +------------+
| DKIM |
| SIGNATURE |
| VERIFICATION | +------------+
| (8) |--------------------------->| PASS |
| | VALID SIGNATURE +------------+
+--------------+
Dropping a NO-MAIL provisions is simply a BAD idea and yet another
reason to make DKIM unusable and more abusive to receivers and certainly
less marketable.
33 years of project and product engineering gives me the right to my
opinion. :-)
Thanks
---
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html