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
