Re: Setting up DKIM and DomainKeys mail signing and verification
At 12:32 28-09-2006, Henrik Ostergaard wrote: This sounds promissing! But I have distributed, moving users and therefore uses pop-before-smtp for authentication, which means that my IP list is in a hash table, which is not in CIDR format. :-( dk-filter and dkim-filter support pop-before-smtp. Regards, -sm
Re: Setting up DKIM and DomainKeys mail signing and verification
Henrik, My users ARE identifyied by either locally trusted IPS or pop-before-smtp, i.e. thery end up in mynetworks, but they are STILL verified by the incoming filter.. And I'm using your suggested setup very strictly..?! As far as I can see, the incoming milter(s) DOES get invoked for ALL incoming mail on port 25.. Am I missing something? I see, you are quite right. I haven't noticed it because no header fields are inserted by these two verifying milters when there is no signature present and dk policy does not claim that a domain is signing all mail. A solution would be to separate mail submission from MX, e.g. by providing another dedicated IP alias address on a mailer for mail submission (or keeping existing address for submission, and pointing MX to a new IP alias). But I have found out that adding -d mydomain.net to the incoming filter actually solved this issue, as this means that my own mail does not get verified.. But neither will anyone spoofing being from my own doamin.. Good. A waste of resources is still there, but at least the verification does not fail. Something still needs to be done to prevent SA plugins DK and DKIM from complaining about non-signed mail from local users. Mark
Re: Setting up DKIM and DomainKeys mail signing and verification
Thanks for a splendid howto! I do however have a small problem: My usesrs submit their messages for relaying on port 25 like normal incoming messages - meaning that they will be verified before they are signed, causing the verification to fail. If I set up the DNS record to enforce signing, this will most probably be a problem - otherwise I just have an innoying 'verification failed' header field. Is there a way to skip verification for authorized users/users in mynetworks? Or could the verification be performed AFTER the signing (as only mails from trusted users are send through signing anyway)? Regards Henrik ?stergaard -- View this message in context: http://www.nabble.com/Setting-up-DKIM-and-DomainKeys-mail-signing-and-verification-tf2259401.html#a6541418 Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Setting up DKIM and DomainKeys mail signing and verification
On 9/28/06, Henrik Ostergaard [EMAIL PROTECTED] wrote:
My usesrs submit their messages for relaying on port 25 like normal incoming
messages - meaning that they will be verified before they are signed,
The same dk-filter command usually provides both signing and
verification, deciding which to do based on {client IP or
authenticated user} -AND- the correct domain name. You must specify
IPs to sign and the domain name.
Use the -i option of dk-filter to specify which IPs should be signed
rather than verified, this usually corresponds what is listed in
postfix mynetworks. When mail arrives from one of those clients, AND
the domain matches, the mail will be signed rather than verified. See
man dk-filter for more info.
My command line (which works here but may not be correct for everyone)
looks something like this (all one line - replace example.com with
your domain name, adjust paths as appropriate):
# dk-filter -H -S mailgate -M {auth_author} -o Received -s
/var/db/certificates/domainkey.private -d example.com -i
/var/db/domainkey.clients -u milter -l -p inet:[EMAIL PROTECTED]
and the /var/db/domainkey.clients file is a list of networks that
should be signed, in CIDR notation:
# cat /var/db/domainkey.clients
127.0.0.1
192.168.0.0/16
10.0.0.0/8
--
Noel Jones
Re: Setting up DKIM and DomainKeys mail signing and verification
Noel Jones wrote:
# dk-filter -H -S mailgate -M {auth_author} -o Received -s
/var/db/certificates/domainkey.private -d example.com -i
/var/db/domainkey.clients -u milter -l -p inet:[EMAIL PROTECTED]
and the /var/db/domainkey.clients file is a list of networks that
should be signed, in CIDR notation:
# cat /var/db/domainkey.clients
127.0.0.1
192.168.0.0/16
10.0.0.0/8
This sounds promissing! But I have distributed, moving users and therefore
uses pop-before-smtp for authentication, which means that my IP list is in a
hash table, which is not in CIDR format. :-(
I could maybe hack pop-before-smtp to trick generating a flat table each
time there is any changes - but then I will probably have to restart
dk-filter (and dkim-filter)..
I came to think of something else - the approach described in the original
post suggests all mails are verified, but only authenticated mails are
signed. It could probably rather easily be changed to sending the
non-locally submitted mails through the verification AFTER the content
filter. Ie in master.cf moving the lines
-o milter_default_action=accept
-o milter_macro_daemon_name=MTA
-o smtpd_milters=inet:127.0.0.1:4442,inet:127.0.0.1:4443
from the section
smtp inet n - - - - smtpd
to the section
localhost:10025 inet n - n - 10 smtpd
Will this approach break the signatures if (when) the content filter
(amavis) adds headers?
Regards
Henrik ?stergaard
--
View this message in context:
http://www.nabble.com/Setting-up-DKIM-and-DomainKeys-mail-signing-and-verification-tf2259401.html#a6553221
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Setting up DKIM and DomainKeys mail signing and verification
On 9/28/06, Henrik Ostergaard [EMAIL PROTECTED] wrote: This sounds promissing! But I have distributed, moving users and therefore uses pop-before-smtp for authentication, which means that my IP list is in a hash table, which is not in CIDR format. :-( Your best choice is to set up SASL authentication. I don't think these milters will play nice with pop-before-smtp. At best you would have to restart the milter evertime someone checked their mail. I came to think of something else - the approach described in the original post suggests all mails are verified, but only authenticated mails are signed. No, the program chooses which to do based on parameters already discussed. Authorized clients get signed, all others get verified. It could probably rather easily be changed to sending the non-locally submitted mails through the verification AFTER the content filter. Ie in master.cf moving the lines -o milter_default_action=accept -o milter_macro_daemon_name=MTA -o smtpd_milters=inet:127.0.0.1:4442,inet:127.0.0.1:4443 from the section smtp inet n - - - - smtpd to the section localhost:10025 inet n - n - 10 smtpd This looses the client information, and thinks localhost submitted all the mail. Mail with forged sender address (or from a mail list) would be signed. Will this approach break the signatures if (when) the content filter (amavis) adds headers? Amavisd-new adds the headers on top so as to not break signatures. Also using the -H option when signing tells dk-filter which headers to use when verifying. But you shouldn't sign mail after the content_filter, mail should only be signed at the point it first enters your network. This is way off topic for this list, post any followup questions to the amavis-users or postfix-users list. -- Noel Jones
Re: Setting up DKIM and DomainKeys mail signing and verification
Henrik,
I do however have a small problem:
My usesrs submit their messages for relaying on port 25 like normal
incoming messages - meaning that they will be verified before they are
signed, causing the verification to fail.
No, if you follow my setup. Mail from mynetworks and from authenticated
users (preferably SASL, possibly pop-before-smtp or other method) will
follow a separate path from other (incoming) mail. It will not be seen
by a verifying milter, but will given to the signing milter after a
content filter.
Is there a way to skip verification for authorized users/users
in mynetworks?
If you are talking about verifying by milter, then yes: either
the milter would not even be invoked by MTA (my suggested setup),
or alternatively, it could base its decision on client IP address
if available (as Noel Jones had in mind).
If you are talking about verifying by a SpamAssassin plugins
for DK and DKIM, then avoiding verification for authorized
or local users is a bit more involved, and not covered in my
text. Ideally I think the SA should use or not use DK/DKIM plugins
based on the same decision as it does for invoking SPF and DUL
check, i.e. skip these checks for locally originating mail.
Alternatively, DK/DKIM rules could be conditionalized.
Or could the verification be performed AFTER the signing (as
only mails from trusted users are send through signing anyway)?
Verification should be performed as early as possible/convenient.
It could probably rather easily be changed to sending the
non-locally submitted mails through the verification AFTER the content
On Thursday September 28 2006 21:58, Noel Jones wrote:
This looses the client information, and thinks localhost submitted all
the mail. Mail with forged sender address (or from a mail list) would
be signed.
Not necessarily. If mail path through the system is kept separate
for incoming mail and mail originating from local users (mynetworks
or authenticated), then milters need not have the information about
original client's IP address - just invoking the required milters
on each path suffices, or the information may be passed as
milter macros.
But you shouldn't sign mail after the content_filter,
mail should only be signed at the point it first enters your network.
I disagree. If mail processing within our site is trustworthy (presumably
we know what we are doing to mail originating at our site, perhaps adding
some headers, maybe converting to 7bit and fixing some common problems
in mail header introduced by some submitting MUAs), then mail should be
signed as a last stage before it leaves the site, otherwise local processing
could break a signature.
In http://www.ijs.si/software/amavisd/amavisd-new-docs.html#dkim I state:
Verifying signatures should be performed early, before any local mail
transformations get a chance of invalidating signature, e.g. by performing
MIME conversions to quote-printable, by fixing syntactically invalid mail
header, by editing/inserting/removing certain header fields, or by a local
mailing list modifying mail text, e.g. by appending footnotes.
Signing outgoing mail should be performed late, after mail sanitation, after
conversion to 7-bit characters (to avoid later uncontrollable changes by a
relaying or receiving MTA), and after adding header fields by a content
filter. Similar applies to local mailing lists, which may be rewriting
messages, requiring them to be re-signed by the domain hosting a mailing
list, just before being sent out.
Btw, the document has been updated since being posted here.
(new version of dkim-milter 0.5.2 came out meanwhile, updated FreeBSD
ports for both milters came out meanwhile, added more example SA rules).
My command line (which works here but may not be correct for everyone)
looks something like this
# dk-filter -H -S mailgate -M {auth_author} -o Received -s ...
I wouldn't exempt Received header fields from signature,
after all these are vital pieces of information to the recipient
when investigating problems.
Mark
Re: Setting up DKIM and DomainKeys mail signing and verification
On Sun, September 17, 2006 21:48, SM wrote: At 04:32 17-09-2006, Benny Pedersen wrote: how does one do signing multible domains ? man 8 dk-filter says to make a internal domain file and add this as -i internal.file You can use the -d parameter ( -d example.com,example.net) or thanks that solved it but can domains still have same domain keys or is one domain need to have there own ? The domains can have the same public and private keys. yes makes sense to not use diff selector and keys, thanks now i wait to dkim commes on gentoo -- This message was sent using 100% recycled spam mails.
Re: Setting up DKIM and DomainKeys mail signing and verification
now i wait to dkim commes on gentoo Btw, dkim-milter 0.5.2 just came out http://sourceforge.net/projects/dkim-milter/ It fixes: - compatibility with Postfix milter environment; - verifies that the body hash in a signature matches the actual body hash; - fixes relaxed body canonicalization of a message which has trailing spaces on its last nonempty line. Big thanks to Murray S. Kucherawy! Mark
Re: Setting up DKIM and DomainKeys mail signing and verification
On Tue, September 12, 2006 16:59, Mark Martinec wrote: I'm finishing up writing what I have learned in the last couple of weeks on setting up a DKIM/DK signing/verifying thanks Mark how does one do signing multible domains ? man 8 dk-filter says to make a internal domain file and add this as -i internal.file but can domains still have same domain keys or is one domain need to have there own ? -- This message was sent using 100% recycled spam mails.
Re: Setting up DKIM and DomainKeys mail signing and verification
On Tue, September 12, 2006 16:59, Mark Martinec wrote: I'm finishing up writing what I have learned in the last couple of weeks on setting up a DKIM/DK signing/verifying sorry i need to know more: # Local config options needing unique settings MTA_NAMES=local KEYFILE=/etc/dkfilter/dk1.key.pem SELECTOR_NAME=dk1 # Might want to change, but no need to PORT=inet:[EMAIL PROTECTED] USER=dkfilter DKFILTER=/usr/bin/dk-filter REJECTION=bad=r,dns=t,int=t,no=a,miss=r SIGNED_DOMAINS_LIST=/etc/dkfilter/signed-domains PEER_HOSTS_LISTS=/etc/dkfilter/peer-hosts INTERNAL_HOSTS_LIST=/etc/dkfilter/internal-hosts EXTERNAL_HOSTS_LIST=/etc/dkfilter/external-hosts DOMAINKEYS_ARGS=-l -a $PEER_HOSTS_LISTS -i $INTERNAL_HOSTS_LIST \ -I $EXTERNAL_HOSTS_LIST -m $MTA_NAMES -p $PORT -C $REJECTION \ -d $SIGNED_DOMAINS_LIST -u $USER -s $KEYFILE -S $SELECTOR_NAME above is snipped from dk-filter mail list what is the format of the signed_domains_lists ? and for peer_hosts_lists ? what is defined in other lists ? should all domains use a single selector ? if yes how does one name the private keys then ? -- This message was sent using 100% recycled spam mails.
Re: Setting up DKIM and DomainKeys mail signing and verification
At 04:32 17-09-2006, Benny Pedersen wrote: how does one do signing multible domains ? man 8 dk-filter says to make a internal domain file and add this as -i internal.file You can use the -d parameter ( -d example.com,example.net) or but can domains still have same domain keys or is one domain need to have there own ? The domains can have the same public and private keys. Regards, -sm
Re: Setting up DKIM and DomainKeys mail signing and verification
SM, and others: Both milters are being maintained and are similar in reliability. dk-milter is not fading in oblivion as there are more domains signing with DomainKeys than DKIM. Usage of dk-milter may not be fading, but the interest in fixing standing bugs seems to be lost (contrary to dkim-milter, where MSK is there, willing to fix flaws - thanks Murray!). Three of my dk-milter bug reports (a month old) are about broken signatures, and nobody seems to care. Don't know how serious other older unresolved problem reports are. I can only conclude that, either it is not widely used, or people do not care if certain types of mail messages are incorrectly handled. An 'it works for me' attitude I guess. I'd be delighted if proven wrong! | score DK_VERIFIED -1.5 Note that some spam is DK signed. True, there is a paragraph about that by the end of my text. Nevertheless, I think it is worth giving a little global motivation for people to start signing their mail - both to spammers and to regular users alike. We may lose 1.5 score points to some spam (which may let through a few more marginal spam messages below the gate), but we gain a bit more information about spammer - is a mail was signed, we know the sender is a current owner of the domain, not just an anonymous controller of an army of spambots. This may bring more pressure to registrars to trim down domain kiting practices, and to bigISPs to better control their user base or risk being given few blacklist points. And the 1.5 points is not always a loss, in many cases it saves a legitimate message from being treated as false positive. It is easier to steer a river flow to where we want it to go, than to be shuffling water in few month's time. Or taken another analogy, in words of a flower (Antoine de Saint-Exupery): Well, I must endure the presence of two or three caterpillars if I wish to become acquainted with the butterflies. It seems that they are very beautiful. * both the dkim-milter 0.5.1 and the dk-milter 0.4.1 need a patch as described in the Postfix documentation file MILTER_README. IIRC, the Workarounds section of the Postfix documentation file is being read incorrectly. Dkim-milter and dk-milter do not require any patch. Well, the word 'needs' may be too strong, both milters work without the patch as well, but the log is ugly: without patch: dkim-filter[76335]: Sendmail DKIM Filter v0.5.1 starting ... dkim-filter[76335]: WARNING: sendmail symbol 'i' not available dkim-filter[76335]: (unknown-jobid): no signature data dkim-filter[76335]: (unknown-jobid): no signature data dkim-filter[76335]: (unknown-jobid): no signature data dkim-filter[76380]: (unknown-jobid): can't parse From: header dkim-filter[76335]: (unknown-jobid): no signature data with the patch (taken from its repository at SourceForge): dkim-filter[74857]: Sendmail DKIM Filter v0.5.1 starting ... dkim-filter[66366]: 11D2117B8F2: no signature data dkim-filter[66366]: 9748F17B8E8: no signature data dkim-filter[66366]: 5A9A017B8E1: no signature data Mark
Setting up DKIM and DomainKeys mail signing and verification
I'm finishing up writing what I have learned in the last couple of weeks on setting up a DKIM/DK signing/verifying mail system using Postfix, milters, amavisd-new and SpamAssassin. The following text will be part of the documentation for amavisd-new (text is also available at http://www.ijs.si/software/amavisd/amavisd-new-docs.html ), but may be general enough so I hope it can be of interest to the SpamAssassin community. Comments, experience, suggestions and further discussion on the topic is most welcome. If considered off-topic, off-list mail would be welcome too. Mark Setting up DKIM and DomainKeys mail signing and verification The goals of DKIM and DomainKeys are: * assurance of sender identities * protection against message tampering. A DKIM draft states the following, which applies to its predecessor DomainKeys as well: DomainKeys Identified Mail (DKIM) defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. Message recipients can verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain. A gentle introduction and deployment guide is available at: http://antispam.yahoo.com/domainkeys. Except for some minor details, it applies to DKIM system as well. With added support in Postfix 2.3 for a milter protocol, it became possible to use with Postfix many of existing milters (mail filters) that were originally developed with sendmail in mind. It was hoped that a widespread use of milters with sendmail offered a fertile ground for software development, producing software of sufficient quality to be able to use it with Postfix. It remains to be seen whether quality of freely available milters comes anywhere close to high standards we are accustomed to with Postfix, but with a bit of luck and reasonable expectations, some of it can be put to good use. Two of such milters are dkim-milter offering support for DomainKeys Identified Mail (DKIM) Signatures, and dk-milter, offering support for Domain-based Email Authentication (DomainKeys). The DomainKeys (DK) is a predecessor of DKIM, as recognized by draft-delany-domainkeys-base-06: The DomainKeys specification was a primary source from which the DomainKeys Identified Mail [DKIM] specification has been derived. The purpose in submitting this document is as an historical reference for deployed implementations written prior to the DKIM specification. At the time of this writing it appears the dkim-milter is more reliable and better maintained than dk-milter, which is slowly fading into oblivion. Similar holds true in the world of Perl modules: there are modules Mail::DomainKeys and Mail::DKIM, both of which can be used by SpamAssassin. Again the Mail::DKIM seems to be of higher quality than an older Mail::DomainKeys. SpamAssassin makes it very easy to use each or both of them (for verification only), just by enabling the already provided plugins. Despite DomainsKeys slowly giving grounds to DKIM, the DomainsKeys is currently still in use by several large players in the Internet world, so this section will describe how to integrate both of them with Postfix and amavisd-new (an after-queue content filter) into a mail system. Mail signing and verification is a two-part job: signing of originating mail (or mail being redistributed) from our domain, and verifying signatures of incoming mail. Both tasks can be done by the same program, or they can be performed by separate entities. Traditionally with sendmail, both tasks are performed by the same milter, which may be easier to maintain, but has certain disadvantages. Verifying signatures should be performed early, before any local mail transformations get a chance of invalidating signature, e.g. by performing MIME conversions to quote-printable, by fixing syntactically invalid mail header, by editing/inserting/removing certain header fields, or by a local mailing list modifying mail text, e.g. by appending footnotes. Signing outgoing mail should be performed late, after mail sanitation, after conversion to 7-bit characters (to avoid later uncontrollable changes by a relaying or receiving MTA), and after adding header fields by a content filter. Similar applies to local mailing lists, which may be rewriting messages, requiring them to be re-signed by the domain hosting a mailing list, just before being sent out. Since SpamAssassin only provides signature verification but not signing, one obvious choice for signing is to use dkim-milter and dk-milter in signing-only mode, invoked by a Postfix smtpd service which is receiving content-checked mail from a content filter such as amavisd-new. As this second-stage smtpd service does
Re: Setting up DKIM and DomainKeys mail signing and verification
Good article -- and thanks for posting it! For what it's worth, I think it's likely that DomainKeys will be around for quite a while yet, with plenty of inertia regarding switching to DKIM; but currently the text makes it sound like DK is already obsolete. It might be worth de-emphasising that. Someday I'll have the tuits to set up signing on our server ;) --j. Mark Martinec writes: I'm finishing up writing what I have learned in the last couple of weeks on setting up a DKIM/DK signing/verifying mail system using Postfix, milters, amavisd-new and SpamAssassin. The following text will be part of the documentation for amavisd-new (text is also available at http://www.ijs.si/software/amavisd/amavisd-new-docs.html ), but may be general enough so I hope it can be of interest to the SpamAssassin community. Comments, experience, suggestions and further discussion on the topic is most welcome. If considered off-topic, off-list mail would be welcome too. Mark Setting up DKIM and DomainKeys mail signing and verification The goals of DKIM and DomainKeys are: * assurance of sender identities * protection against message tampering. A DKIM draft states the following, which applies to its predecessor DomainKeys as well: DomainKeys Identified Mail (DKIM) defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. Message recipients can verify the signature by querying the signer's domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain. A gentle introduction and deployment guide is available at: http://antispam.yahoo.com/domainkeys. Except for some minor details, it applies to DKIM system as well. With added support in Postfix 2.3 for a milter protocol, it became possible to use with Postfix many of existing milters (mail filters) that were originally developed with sendmail in mind. It was hoped that a widespread use of milters with sendmail offered a fertile ground for software development, producing software of sufficient quality to be able to use it with Postfix. It remains to be seen whether quality of freely available milters comes anywhere close to high standards we are accustomed to with Postfix, but with a bit of luck and reasonable expectations, some of it can be put to good use. Two of such milters are dkim-milter offering support for DomainKeys Identified Mail (DKIM) Signatures, and dk-milter, offering support for Domain-based Email Authentication (DomainKeys). The DomainKeys (DK) is a predecessor of DKIM, as recognized by draft-delany-domainkeys-base-06: The DomainKeys specification was a primary source from which the DomainKeys Identified Mail [DKIM] specification has been derived. The purpose in submitting this document is as an historical reference for deployed implementations written prior to the DKIM specification. At the time of this writing it appears the dkim-milter is more reliable and better maintained than dk-milter, which is slowly fading into oblivion. Similar holds true in the world of Perl modules: there are modules Mail::DomainKeys and Mail::DKIM, both of which can be used by SpamAssassin. Again the Mail::DKIM seems to be of higher quality than an older Mail::DomainKeys. SpamAssassin makes it very easy to use each or both of them (for verification only), just by enabling the already provided plugins. Despite DomainsKeys slowly giving grounds to DKIM, the DomainsKeys is currently still in use by several large players in the Internet world, so this section will describe how to integrate both of them with Postfix and amavisd-new (an after-queue content filter) into a mail system. Mail signing and verification is a two-part job: signing of originating mail (or mail being redistributed) from our domain, and verifying signatures of incoming mail. Both tasks can be done by the same program, or they can be performed by separate entities. Traditionally with sendmail, both tasks are performed by the same milter, which may be easier to maintain, but has certain disadvantages. Verifying signatures should be performed early, before any local mail transformations get a chance of invalidating signature, e.g. by performing MIME conversions to quote-printable, by fixing syntactically invalid mail header, by editing/inserting/removing certain header fields, or by a local mailing list modifying mail text, e.g. by appending footnotes. Signing outgoing mail should be performed late, after mail sanitation, after conversion to 7-bit characters (to avoid later uncontrollable changes by a relaying or receiving MTA), and after adding header fields by a content filter. Similar
Re: Setting up DKIM and DomainKeys mail signing and verification
Hi Mark, At 07:59 12-09-2006, Mark Martinec wrote: At the time of this writing it appears the dkim-milter is more reliable and better maintained than dk-milter, which is slowly fading into oblivion. Similar holds true in the world of Perl modules: there are Both milters are being maintained and are similar in reliability. dk-milter is not fading in oblivion as there are more domains signing with DomainKeys than DKIM. The following SpamAssassin rules (in local.cf) work fairly well, giving verified mail a little bit of advantage and slightly favourize mail from some popular domains, and encourage people to start signing their mail. Possible signed spam can be counterbalanced by other measures (see below). score DK_VERIFIED -1.5 score DK_POLICY_SIGNSOME 0 score DK_POLICY_TESTING 0 score DKIM_VERIFIED -1.5 Note that some spam is DK signed. # DKIM and DK-based whitelisting may be used reliably: score USER_IN_DKIM_WHITELIST -3.0 whitelist_from_dkim [EMAIL PROTECTED] whitelist_from_dk [EMAIL PROTECTED] This approach is better. * both the dkim-milter 0.5.1 and the dk-milter 0.4.1 need a patch as described in the Postfix documentation file MILTER_README. The dkim-milter already supplies a required patch in its bug tracking system under [1537905] delayed queue ID; which will be included in the next release; IIRC, the Workarounds section of the Postfix documentation file is being read incorrectly. Dkim-milter and dk-milter do not require any patch. Regards, -sm
