[ietf-dkim] DKIM on envelope level
iane at sussex.ac.uk
Fri Oct 30 03:12:40 PDT 2009
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.
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.net>
>>> 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
>>> 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
>>> validate before DATA. This merely requires a signature that does
>>> 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
>>> 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
>>> would provide any or enough value-add. However it is only a
>>> 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?
> Dave Crocker
> Brandenburg InternetWorking
More information about the ietf-dkim