On 29 Oct 2009, at 16:11, Dave CROCKER wrote:
First blank line after DATA.
Whether that affords sufficient value-add is an open question to me
and probably others.
d/
There's no opportunity to do anything other than drop the connection
there, is there? Not without modifying the SMTP spec. The only benefit
is that you don't have to read the body into memory, but bodies are
limited in size, so I can't think of much advantage.
A DKIM sig that only signed message headers would have a better chance
of surviving mailing lists redistribution. It'd be available for re-
use though, wouldn't it?
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
--
Ian Eiloart
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html