In article <4AE9BEA0(_dot_)3000002(_at_)dcrocker(_dot_)net> you write:
First blank line after DATA.
Whether that affords sufficient value-add is an open question to me and
probably others.
I must be missing something.
SMTP does not allow you to read the message headers without also reading
the body, unless you're planning to use something like BDAT (RFC 3030)
which sends the message in chunks.
Once the server has responded to DATA, the client starts sending the
message header. As soon as the DKIM-Signature: header field arrives,
the server can send off a DNS request for the key record. As soon as
the blank line at the end of the header arrives, the server can compute
the header hash, and as soon as the DNS response arrives, check if the
b= hash signature is valid.
Assuming the b= signature is valid, the server then computes the body
hash as the body arrives, and at the end of data, it can check the
hash it just computed against the bh= body hash. If the b= and bh=
both validate, congratulations, you have a valid DKIM signature. If
the b= hash wasn't valid, there's no point in computing the body hash,
although I suspect that in most cases the amount of computing saved
would be insignificant.
Given that you can pipeline the DKIM verification as the message
arrives, and you have to receive the entire message anyway, what do
people want that they can't already do? If you want the client to
prove who it is before sending the mail, it can use STARTTLS with a
client certificate signed by someone the server knows.
R's,
John
PS: For anyone who's forgotten, if the server disconnects part way
through the data, e.g., after the header, any legitimate client will
treat it as a soft failure and retry later.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html