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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 8 Aug 2006 10:54:16 -0700

The way to do this (if it should be done) would be to use the SMTP extension mechanism.

For example. Define a command option SDATA, Reciever advertises it in response to EHLO, sender uses it to present signed data in place of DATA. 

Might be a better implementation but the point is we should use the SMTP extension mechanism not invent our own.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, August 08, 2006 1:31 PM
> To: [email-masked]
> Subject: [ietf-dkim] Signalling DKIM support before DATA
> 
> 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
> 
> 

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 8 Aug 2006 11:13:44 -0700

On Aug 8, 2006, at 10:54 AM, Hallam-Baker, Phillip wrote:

> For example. Define a command option SDATA, Receiver advertises it  
> in response to EHLO, sender uses it to present signed data in place  
> of DATA.
>
> Might be a better implementation but the point is we should use the  
> SMTP extension mechanism not invent our own.

Something a bit simpler that would not require changing the MTA  
code.  Use a host-name convention.  This would be apparent at the  
EHLO without requiring negotiations.  In essences,  
_dkim.mx01.example.com makes an assurance that:
  1) this host-name will authenticate
  2) a DKIM client policy can be applied

In conjunction with the DKIM client policy, there could also be  
MAIL_FROM policies that offer name relationships.  For example, this  
list might be a PTR RRset of names.  This might be a lookup of the  
(_DKIM-MP.<mail-from-domain>, PTR)
If a truncation occurs, a subsequent lookup of the (<query- 
domain>._DKIM-MP.<mail-from-domain>, PTR) extends this list  
indefinitely.

A domain name of "." might signal that the list is closed.

-Doug

---

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

> For example. Define a command option SDATA, Reciever advertises it in
> response to EHLO, sender uses it to present signed data in place of DATA.
>
I guess that would be one way to do it.  It might also play nicely with the 
sometimes discussed idea of breaking DATA into header and message:

http://isdg.net/public/ietf/drafts/draft-santos-smtphead-00.txt

Then it would be possible to receive the header and check if a signature using 
an appropriate domain is present before having to commint bandwidth and CPU 
to the actual message.

The downside of this approach is that, I think,  it would require core MTA 
libraries to be updated which would significantly impact deployability.  

I had been thinking of just doing a lookup on the policy record and if one 
finds a list of singing domains checking to see if the Mail From domain was 
on the list.  My thought had been that if a receiver is already doing DNS 
intensive work such as RBL lookups, one more check for a policy record 
wouldn't be significant.  The downside, of course, is that for forged e-mail 
an innocent bystander gets additional DNS traffic.

Scott K

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 08 Aug 2006 21:15:17 +0200

Hallam-Baker, Phillip wrote:
 
> For example. Define a command option SDATA, Reciever
> advertises it in response to EHLO, sender uses it to
> present signed data in place of DATA.

If the client sifts his outbound into "signed DATA" and
"unsigned DATA", it could also use a MAIL FROM parameter
to indicate what it's going to be.  

> the point is we should use the SMTP extension mechanism
> not invent our own.

An example is RFC 4405.

  [Scott wrote:]
>> Such a hint would, I imagine, only be useful when From =
>> Mail From.

Why ?  Your scenario is apparently mail where you're about to
reject it before DATA, unless it promises a DKIM signature,
and you're willing to check this.  

If you intend to check the signature after you've accepted the
mail you'd need a no-nonsense MAIL FROM, but why the same as
the 2822-From ?

>> IIRC, that accounts for about 80% of mail.

It would be interesting if somebody can confirm this.  I've
seen it elsewhere, but can't tell anymore if it was about the
2822-From or the PRA.

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

Yes, but I miss two clues here.  First party signatures are
created somewhere between MSA and "mailout" (= MTA talking
to an MX), and that MTA does not necessarily know what it's
sending, signed or unsigned mails.

In the cases of a list / moderated newsgroup / etc. (Dave
mentioned other cases) the MAIL FROM is not the same as the
2822-From.

Frank

---

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

> and you're willing to check this.
I was thinking in terms of using the policy record as a hint rather than 
something directly in the SMTP exchange.  If an SMTP client tells me 
something in order to convince me to accept it's mail, I am extremely 
unlikely to believe it without outside confirmation.

If the Mail From domain has a DKIM policy record that says it signs mail, then 
that's an external source that is at least somewhat more believable.

> mail you'd need a no-nonsense MAIL FROM, but why the same as
In order to know what policy record to look at.

> seen it elsewhere, but can't tell anymore if it was about the
I've probably seen it the same places.  I'd be interested if someone had some 
current statistics too.

> sending, signed or unsigned mails.

Yes, but Mail From and signing will usually be generated at the MSA, so as 
long as the policy record is correct for the signing domain, I don't think 
that matters.
> mentioned other cases) the MAIL FROM is not the same as the
Yes.  I don't think this can solve all problems, but it might have general 
enough utility to be worth specifying.  I'm not sure.  I throw this out as an 
idea for consideration by the group, not something that I am certain is 
worthwhile.

Scott K

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 08 Aug 2006 21:41:50 +0200

Douglas Otis wrote:

> Use a host-name convention.  This would be apparent at the

Some minimal negotiation might be still necessary, the server
could reject the underscore in the EHLO as 2821 syntax error,
based on "sub-domain = Let-dig [Ldh-str]", an underscore is no
<Let-dig>.  Depending on how the server does this the client
might have to start the conversation from scratch.

Hang on, now I see that your example says _dkim.mx01.example,
is it the server using an underscore, in MX records ?  Or in
the greeting ?  It's not that I'm against any "updates: 2821",
but I'd like to know if it's the direction you talk about.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 08 Aug 2006 23:13:48 +0200

Scott Kitterman wrote:
 
> If the Mail From domain has a DKIM policy record that says it
> signs mail, then that's an external source that is at least
> somewhat more believable.

Okay, let's assume that the MAIL FROM somehow indicated "the
domain in the RHS of the MAIL FROM publishes a DKIM SSP".  The
server could then get and cache this SSP.  If that fails the
indication was wrong (or there's an obscure DNS problem).

>> why the same as the 2822-From ?

Before DATA two "sending" domains are in play, EHLO and the
RHS of MAIL FROM.  Or three if the client supports RFC 4405.
Not necessarily related to the domain in a later 2822-From.

I'm still trying to figure out what you're getting at.  Let's
say the client promised that a SSP for the MAIL FROM domain
exists, the server got this policy, and accepts the MAIL FROM.

In the DATA it might find mail with a different 2822-From, and
that might be DKIM-signed or not.  In that case an unrelated
MAIL FROM SSP does not help.  And if "the" 2822-From domain is
the same as in the MAIL FROM the server already has an SSP, see
above.  We heard that this might be the case for about 80% of
all mails.

Is this so far what you have in mind ?  I wonder why the DKIM-
aware server doesn't use this approach always, even without any
indication in the SMTP session.

> Mail From and signing will usually be generated at the MSA,

The one MSA I knew (in the MARID days :-) implementing RFC 2476
6.1 verified that my MUA used an appropriate MAIL FROM, it did
not go so far as to _generate_ it.  Another MSA I knew set both
MAIL FROM and 2822-From no matter what my MUA said, but that's
not directly covered by anything in 4409 (was 2476).

JFTR, it's clear what you mean.

> as long as the policy record is correct for the signing
> domain, I don't think that matters.

For proposals to signal DKIM support in the SMTP session it's
relevant.  The two MSAs mentioned above had separate "mailouts"
behind them, sending mails to foreign MXs.  Senders wishing to
support such ideas have to upgrade their "mailouts", too, not
only their MSAs.

Frank

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 9 Aug 2006 00:23:08 -0400

----- Original Message -----
From: "Hallam-Baker, Phillip" To: "Scott Kitterman"

> For example. Define a command option SDATA, Reciever advertises
> it in response to EHLO, sender uses it to present signed data
> in place of DATA.
>
> Might be a better implementation but the point is we should use
> the SMTP extension mechanism not invent our own.

I think that is what Scott had in mind.

On a related note, early this year, I had written an I-D that address future
PAYLOAD based technology considerations in this area, but never published
it:

SMTP Service Extension for Command HEAD
http://isdg.net/public/ietf/drafts/draft-santos-smtphead-00.txt
http://isdg.net/public/ietf/drafts/draft-santos-smtphead-00.html

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com