Giampaolo Tomassoni schrieb: > AFAIK, Amavis is not involved: the Mail::SpamAssassin::Plugin::DKIMrep only > uses DKIM signatures "passed" by Mail::SpamAssassin::Plugin::DKIM, which in > turn uses Mail::DKIM to validate them. > > I believe Amavis do have independent DKIM code, which I would exclude is > somehow involved in the process. > > Note, in example, that I'm testing DKIMrep by directly invoking SA on test > messages and it seems to work to me. No "scent of amavis" around, then... > > Giampaolo > Correct, there is only a dependency on the results of the DKIM.pm module. There are DKIM verifiers that add a "Authentication-Results" header to an email, these results would suffice to request data from dkim-reputation.org as well; duplicate DKIM checks (in a dkim proxy, in amavisd, in spamassassin, ...) should be avoided (well, the public keys for verification should be available in local DNS caches but anyway ...). @Mark: several equal DKIM checks can be automatically avoided if admins define trusted server-ids when configuring amavisd and/or spamassassin; if there is a trusted Authentication-Results header the results are copied to script internal DKIM result variables instead of running an additional verification (?).
--- Let me summarize the small changes I plan to add to the dkim-reputation system (those won't affect running implementations): - the effective TLD rewriting at the client side will be removed, so clients ask for md5(local-part).md5(originator-domain).md5(signing-domain) only --> easier to implement and no regular updates of TLD lists necessary - to prevent that spammers always get a neutral reputation for the same effective domain if they start to use a new subdomain for signing I would do the effective TLD calculation on my side (only) and add the worst value of an effective TLD to an unknown signing domain, e.g. a.domain.tld has reputation x worse than neutral, so b.domain.tld will get this reputation as well --> two records would be published (instead of one like it is today) - I want to clarifiy the use of user specific request parts below the signing domain: it's necessary to stress that the content of i= has clear priority. Signers should include an i= parameter to their mails (unfortunately the existing DKIM signer implementations don't support this sufficiently). The fallback is the use of addresses in the From header (no combination with Sender header values for the ease of use). Best regards, Florian
