> > So far I see that the after-queue content filter mechanism > > (FILTER_README) forces you to write the email to disc again. (And > > for no good reason, unfortunately: pipe should pass a read-only > > file descriptor of the queue file to filter?s stdin. The filter > > can use lseek() on that.) > > That would do you no good. > > (1) The queue file contains both message metadata and message > content, formatted as TLV records (type-length-value). There are > no text lines separated with CRLF or LF amywhere.
I see. > (2) Non-Postfix programs that depend on the queue file format are > unsupported. Makes total sense in that case. > > 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. ? Maybe some expert here knows if the milter API can avoid > > that and if both milter sides, i.e. Postfix and e.g. opendkim > > indeed do avoid these pitfalls. > > The Postfix Milter implementation edits the file in place. Instead > of writing the file multiple times, it "prepends" the DKIM signature > using in-file pointer flipping (some TLV records specify jumps). Nice to hear that the message is not in RAM. And the storage format seems smarter than I expected. Thanks, Robert
