Hector,
Dropping the "never send mail" statement doesn't mean you can't still
express the concept. Say "this domain always signs email" and then
have no selectors --- all mail that claims to originate from that
domain will have an invalid signature.
There may however be a good argument that there is a difference
between a message with a bad signature and a message that "cannot
exist" in the first place. That might make retaining the concept
worthwhile from an expressive standpoint, although there are some
feelings (not mine) that such a declaration is out of scope.
eric
--On February 27, 2007 5:52:24 PM -0500 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
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