Subject: [ietf-dkim] Signalling DKIM support before DATA

From: Scott Kitterman <[email-masked]>
Date: Tue, 08 Aug 2006 13:31 -0400

I think this new...

If there is a reasonable way to do it, it might be useful for receivers to 
be able to get a hint before going to DATA if the message is going to be 
DKIM signed.  I can envision looking for such a hint when evaluating a 
message from an IP address listed in an RBL and perhaps going to DATA to 
look for the promised signature.

Such a hint would, I imagine, only be useful when From = Mail From.  IIRC, 
that accounts for about 80% of mail.

If the information (such as the policy record perhaps) contained a list of 
authorized signing domains then a receiver could go to DATA and find out if 
it was worth expending the CPU cycles to verify.

I can see some potential for this to make signing more attractive to small 
senders who are more likely to be blocked due to RBLs.  It may be 
attractive to receivers as a way to reduce false positives from spam 
filtering techniques used on the envelope.

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

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 08 Aug 2006 11:30:14 -0700

> look for the promised signature.

This would break on forwarding -- so the positive ("yes, I signed this 
message") is good, but the negative ("no, I don't sign") can't be 
trusted without knowing a whole lot more about the sending site's 
technical configuration and/or business practices.

Plus, spammers could easily start using this same technique to try to 
bypass envelope security in hopes of then fooling DATA filters.

> filtering techniques used on the envelope.

Sounds like false hope to me; as a big receiver, I can't imagine that 
I'd ever want to blindly trust assertions made by an unknown sender.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 8 Aug 2006 14:43:25 -0400

On Tuesday 08 August 2006 14:30, J.D. Falk wrote:
> > If there is a reasonable way to do it, it might be useful for receivers
> > to be able to get a hint before going to DATA if the message is going to
> > be DKIM signed.  I can envision looking for such a hint when evaluating a
> > I can see some potential for this to make signing more attractive to
> > small senders who are more likely to be blocked due to RBLs.  It may be

As both you and John L point out, this is a big issue.  That's why I was 
thinking about it being something in DNS related to the policy record so that 
it would be at least slightly harder to lie about it.  It's also why I 
started with IF...  I recognized that if it can be trivially spoofed, then 
there's no reason to do it.

Scott K

Scott K

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 08 Aug 2006 12:25:31 -0700

> there's no reason to do it.

We can accomplish that much without any changes to SMTP:

- SMTP conversation happens as per usual
- receiver looks up MAIL FROM domain, checks SSP
- receiver decides whether to accept the message and check the 
signature, or reject based on non-DKIM-related criteria

Or am I missing something?

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 8 Aug 2006 15:43:44 -0400

On Tuesday 08 August 2006 15:25, J.D. Falk wrote:
> > thinking about it being something in DNS related to the policy record so
> > that it would be at least slightly harder to lie about it.  It's also why
> > I started with IF...  I recognized that if it can be trivially spoofed,
> > then there's no reason to do it.
>

That's the lines I'd been thinking along.

Scott K

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 8 Aug 2006 12:45:51 -0700 (PDT)

On Tue, 8 Aug 2006, J.D. Falk wrote:

>> that it would be at least slightly harder to lie about it.  It's also why I 
> - receiver decides whether to accept the message and check the signature, or 
> reject based on non-DKIM-related criteria

Why would receiver check SSP for MAIL FROM domain when it is not the
same identity as the one DKIM SSP is based on? Don't mix things up
if you expect correct results.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Tue, 8 Aug 2006 12:55:32 -0700

On Aug 8, 2006, at 12:25 PM, J.D. Falk wrote:

>> As both you and John L point out, this is a big issue.  That's why  
>> I was thinking about it being something in DNS related to the  
>> policy record so that it would be at least slightly harder to lie  
>> about it.  It's also why I started with IF...  I recognized that  
>> if it can be trivially spoofed, then there's no reason to do it.
>

By SSP you mean the First-Party-Policy.  A check subsequent to  
receiving the entire message could verify there is an association  
between the First-Party-Address and the Signing-Domain, but this is  
not assured to match the MAIL_FROM.  This implies that MAIL_FROM will  
always have the same domain as that of the Signing-domain.  A  
separate MAIL_FROM policy could avoid this constraint.  A MAIL_FROM  
policy would offer greater value when it corresponds to the SMTP  
client issuing the message rather than the signing domain.

Imagine a message signed by your domain is replayed from a system  
controlled by a bad actor.  How is this detected?  A MAIL_FROM policy  
could confirm there is a relationship with that of the client before  
the message is accepted.  Authenticating the client allows policy  
(relationships) to be established between both the MAIL_FROM and the  
Signing_Domain.

-Doug

---

From: [email-masked]
Date: Tue, 8 Aug 2006 20:56:20 +0100 (IST)

Folks,

Can we try to talk in terms of ssp requirements?

If there are none arising, then perhaps this isn't
relevant at this time?

(Personally, I don't claim to know, but it seems odd to
be messing with 2821.)

Thanks,
Stephen.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 8 Aug 2006 16:18:19 -0400

> (Personally, I don't claim to know, but it seems odd to
I agree it's odd, but I think it might be useful.

If the concept is deemed to be useful there would be a small impact to SSP 
requirements.  It would at the very least be an additional use case for the 
list of signing domains requirement currently tagged as provisional in the 
requirements draft.

Finally, I started writing the message that started this thread before the 
requirements draft was announced.  I thought it might be worthwhile while we 
were waiting...  

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 8 Aug 2006 16:23:41 -0400

> if you expect correct results.

As a general rule they wouldn't.  If this is useful at all, it's as a failsafe 
to reduce undesirable rejections of messages that would otherwise be 
rejected.  In my view, even if correct some significant fraction of the time 
(it will be if Mail From domain = From domain) then whatever that fraction is 
is a percentage of undesired rejections averted.

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Aug 2006 22:47:09 +0100

> list of signing domains requirement currently tagged as provisional in the 

So I suggest writing it up in a form that could be added to that part
of the document and then seeing if it gets support.

Stephen.