[ietf-dkim] Issue 1365: drop "never send mail"?

[Eric Allman]

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.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
>
>
>