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

From: Eric Allman <[email-masked]>
Date: Tue, 27 Feb 2007 14:20:48 -0800

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

eric

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Tue, 27 Feb 2007 17:52:24 -0500

Eric Allman wrote:
> Issue 1365 (Subject: SSP: typos) includes this brief comment from Frank:
> 
> "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

---

From: Eric Allman <[email-masked]>
Date: Tue, 27 Feb 2007 15:09:06 -0800

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 
<[email-masked]> wrote:

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

---

From: <[email-masked]>
Date: Tue, 27 Feb 2007 18:45:34 -0500

Heres my 5 quid :-)
If my policy is that I(I) never send mail
But I do sign a bunch of mail for other entities, that has different
meaning than I never touch an smtp conversation,
Thanks, 

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eric Allman
Sent: Tuesday, February 27, 2007 5:21 PM
To: IETF DKIM WG
Subject: [ietf-dkim] Issue 1365: drop "never send mail"?

eric

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Feb 2007 17:40:57 -0800

Eric Allman wrote:
> 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.

I'm pretty sure that I'd be willing to drop a piece of mail from a 
source that says "I don't send mail" out of hand. I definitely wouldn't
do that for an unsigned message with "I sign everything" because it
might have been damaged in transit. So the semantics are not the same.

So the scope argument is definitely the better question. One other thing
to consider is that the volume of traffic this corresponds to is pretty
small, so we're probably already wasted too many cycles arguing about it :)

		Mike

---

From: Steve Atkins <[email-masked]>
Date: Tue, 27 Feb 2007 17:54:51 -0800

On Feb 27, 2007, at 5:40 PM, Michael Thomas wrote:

> Eric Allman wrote:
>> 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.

If you believe the semantics are not the same, then what does the  
statement
"I sign everything" actually mean to a recipient when associated with  
unsigned
mail?

> small, so we're probably already wasted too many cycles arguing  

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Feb 2007 19:06:15 -0800

Steve Atkins wrote:
> If you believe the semantics are not the same, then what does the statement

It means just what it says. It doesn't say anything about what could
happen after it signs it. A receiver ought to take that sort of thing
into account if it doesn't want a boatload of false positives.

		Mike, I hope people aren't of the mindset that
		  dkim alone is sufficient to accept/reject messages
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html