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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 27 Feb 2007 15:28:41 -0800

There is an important difference in deciding not to do 'never send' because it is out of scope and because we are defering to the SPF scheme in this matter.

I would prefer to rule it out of scope.

> -----Original Message-----
> From: Jon Callas [mailto:[email-masked]] 
> Sent: Tuesday, February 27, 2007 5:33 PM
> To: Hallam-Baker, Phillip
> Cc: Eric Allman; IETF DKIM WG
> Subject: Re: [ietf-dkim] Issue 1365: drop "never send mail"?
> 
> 
> On Feb 27, 2007, at 2:28 PM, Hallam-Baker, Phillip wrote:
> 
> > I thought we would be dropping this as out of scope, not redundant.
> >
> > What mechanism is there for 'never send mail today'?
> >
> 
> You can say that you never send mail from a domain with SPF.
> 
> 	Jon
> 
> 

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 28 Feb 2007 08:16:35 -0800

> [mailto:[email-masked]] On Behalf Of Stephen Farrell

> But even if SPF doesn't provide the exact thing that 1365 
> requests, we still have to address whether or not this 
> feature is in-scope for DKIM (which is different from wanting 
> it done somewhere).

I think that as with 'I am a phishing target' and other interesting policy statements it is outside our current charter.

I don't like the SPF/SenderID use of a naked TXT record for policy signalling and I would like to see a 'NO-SEND' policy attribute within the record used for DKIM defined at some time. At this point it is out of discussion scope and out of charter scope so we can't.

What I would like to do however is to leave open the option of revisiting this at a later date. This might be through a DKIM draft, an informational RFC or whatever. The reason I mention informational here is that we might see the Antiphishing Working Group or MAAWG or whatever define best sending practices.

The significance here is that we might use a different prefix for the policy record if we are anticipating extensions of this kind. This is only relevant if we end up changing the policy prefix. What it would mean is:

_outbound._smtp.example.com  TXT "DKIM NO-SEND"

vs

_dkim.example.com            TXT "DKIM NO-SEND"

Since the only DKIM policies we need are 'I always sign' and 'I always sign with a key selector *.x' I think that the more general policy prefix is more appropriate.

This also leads naturally to the use of IANA keyword tags rather than UNIX style single letter command line flags which are confusing and error prone in my view.

So drop the requirement by all means but leave in the ability to extend the policy to include other statements.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 28 Feb 2007 11:23:44 -0500

On Wed, 28 Feb 2007 07:51:17 +0000 Graham Murray <[email-masked]> 
wrote:
>Jon Callas <[email-masked]> writes:
>
>SPF operates on the RFC2181 envelope, so with SPF you can state that a
>domain will never legitimately appear in the SMTP MAIL FROM: (or
>EHLO). It offers no mechanism to say that the domain will not be used
>in any RFC2822 From:, Sender:, Resent-From: etc.

Good point.  I think the equivalent SenderID PRA scope never sends mail 
record is more relevant here.

As I've said before, I think this type of SPF/SenderID record avoids most 
of the risks associated with these protocols that some find concerning and 
I think it would be useful to standardize these record types as string 
literals separate from the more complex semantics of the protocols in which 
they are currently defined.

I may do it as an individual submission if I get the time.

Scott K