On Saturday, January 15, 2022 8:08:51 PM EST Robert Siemer wrote: > > > Conceptually DKIM needs to go over the email twice: once to calculate > > > and sign the checksum and once to write it out with the result of the > > > previous step in the headers.¹ > > > > Prepending a header does not require rewriting the message body. > > Postfix queue files support efficient header insertion. > > So I read. Good to know. > > > > A DKIM signer can do this by either keeping the message in memory (a > > > no-go for me) or write it to a file. > > > > Neither is necessary, just compute a streaming checksum, and emit the > > signature as a prepended header. > > With milter it can indeed. With pipe-like filtering it could not, I believe. > > > So far I see that the after-queue content filter mechanism > > > (FILTER_README) forces you to write the email to disc again. > > > > Yes, it forces you to buffer the message content if you want to make > > body-dependent header modifications. But do you really need to optimise > > this to avoid making a copy? Writing 150MB to (SSD) disk or a tmpfs with > > a few GB of space is quite fast, and the file can be pre-removed aiding > > cleanup. > > Yes, doable. To be honest, I just feared that there is a flat mail file in > queue and no way to get it. That looked wrong in my head. > > > The alternative, the before-queue milter (MILTER_README), is > > > insufficiently documented for me to see if it avoids keeping the > > > message in memory and avoids writing the original mail to file twice. > > > > A milter can compute the desired header in a streaming manner, and then > > respond with a "prepend header" action. > > > > Find some good milter API documentation... > > ...does not reveal how it is implemented in Postfix. But reading Wietse’s > and your reply I believe it does a smart job here. And I see the advantage > of a milter solution. > > I guess I go with opendkim. I wish it would support ec25519. Python dkimpy > and the milter version of it support it, but keep the mail in memory. > Something I really want to avoid. (An extra write out of an email to file > is probably less of an issue.)
Newer versions of opendkim do have some support for ed25519, but I think the interface is clunky. This is discussed in a bug report I filed a while ago: https://github.com/trusteddomainproject/OpenDKIM/issues/6 It might be easier to run two instances, one for RSA signing and one for ed25519 signing. Not keeping the mail in memory for to better support large mails is on my TODO list for dkimpy-milter. Scott K
