ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM on envelope level

2009-10-29 13:23:40

On Oct 29, 2009, at 9:11 AM, Dave CROCKER wrote:

First blank line after DATA.

Whether that affords sufficient value-add is an open question to me  
and probably
others.

DKIM already lets you verify the headers before you've seen the body, if
I recall the algorithm correctly. There's no need for anything to change
there.

Any rejection of a message that's dominated by reputation, rather than
body content, can be performed after you've seen the headers and
before seeing the body.

In this brave new world of multi-megabyte MIME attachments the
resources consumed by the body (bandwidth, temporary storage,
CPU and concurrency) far outweigh the resources consumed by
the headers.

But if you've made a decision by the time you've seen the headers,
what do you do then? There's not any clean, in-band way to respond
to just the headers (leading to all sorts of ugly workarounds like
dropping the connection and then rejecting anything that looks
kinda like the same message before DATA when it's retried).

It would be very, very nice to have an ESMTP extension that
allowed sending just the headers of an email, waiting for a
2xx or 5xx response, then sending the body. And that's the
general solution to this sort of problem, though a little broader
in scope than is really appropriate for the DKIM forum alone.

Cheers,
   Steve




d/

Ian Eiloart wrote:


--On 29 October 2009 09:45:31 -0400 Dave CROCKER 
<dhc(_at_)dcrocker(_dot_)net>  
wrote:



Rolf E. Sonneveld wrote:
... if they can do so, you accept the entire email.

In either case you accept the entire email,

Not necessarily. ....

....
I was just at a session at an industry trade association where the
question of  doing DKIM during SMTP came up.  There were  
operations folk
who very much liked  the idea of being able to obtain some DKIM  
benefit
during the SMTP session,  before the dot...

No one suggested modifying SMTP or DKIM specifications.

What /was/ discussed was the possibility of doing a signature that  
would
validate before DATA.  This merely requires a signature that does  
not
cover the  body.

I can't say that anyone sounded hugely enthusiastic about this,  
but given
that  there was interest in SMTP-time benefit, I think they just  
needed
to think about  this more.

Having two signatures, with one covering the body and relevant  
parts of
the  message header, and the other only covering the header,  
strike me as
a plausible  use of DKIM, worth considering.  I've no idea whether  
it
would provide any or  enough value-add.  However it is only a  
stylized
use of the existing standard,  and so the cost of experimenting  
with it
is reasonable.

So, how do you get the headers without the body?


d/




-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
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