https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6155
--- Comment #82 from Mark Martinec <mark.marti...@ijs.si> 2009-10-07 15:56:36 PDT --- (In reply to comment #81) > > The following also looks fishy: > > grep -c DKIM_ADSP_DISCARD ham*.log > > ham-bayes-net-wt-en6.log 35 > > These are all legitimate looking paypal mail delivered to a Yahoo account > from mid-2008 through recently. I'm not sure since when paypal is signing their mail. They were certainly signing it with DomainKeys signatures in 2006, and with DKIM in 2008. So for very old ham mail from paypal (or ebay) it is quite possible the signature is missing or somehow broken or unverifiable, but this shouldn't be the case for current mail from these domains. > What is DKIM_ADSP_DISCARD supposed to mean? It means two things: - that the message does not have a valid author's domain DKIM or DomainKeys signature (e.g. there is no signature at all, or that the signature does not match the mail contents, or that it does not match the domain name in the From header field); - and that the domain claims that any mail claiming to be from that domain and failing on signature verification, should be discarded. This claim is made by publishing a DNS record (RFC 5617), or through 'adsp_override' configuration directive in SpamAssassin's .cf file. So, if your mail samples are younger than a year, they do have a DKIM-Signature in the header, and they appear to be genuine, the only explanation for a failed signature verification is that the message got somehow corrupted or transformed on its way to SpamAssassin in such a way that the signature no longer matches the mail contents, or that SA could not fetch the domain's public key, perhaps due to DNS resolver failing or some firewall trouble. Depending on your where and how SpamAssassin is called from your mail delivery system, and how you collected your samples (e.g. from a MTA, from a mailbox, from some kind of a quarantine), there are different possible reasons for mail corruption. For example, saving a mail message source from some MUA (e.g. kmail) can rewrite/reformat some header fields. Running some virus scanner in the mail path may add its verdict to the mail body. Fetching it from some POP3 server or even from a webmail service offers their own challenges to mail integrity. In some cases even a 'friendly' MTA thinks it is doing a favour by rewriting some header fields, perhaps in belief that they would look 'prettier'. One way to find out is to describe a path the mail is making through your infrastructure (firewall, MTA, virus scanners, mailbox server) before it reaches SpamAssassin, and by carefully examining one or two such mail samples. If you have a choice, you may mail me some samples, preferably as a gzip or tar.gz attachment, to make sure it won't get transformed in transition. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
