> > 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.) Thanks, Robert
