please provide debug data for such a message and sample to test against or take this to the SA user's mailing list.

Yes we can show you all header from an email.
But how can we send you these information not in "public" mode ?
We don't want to publish information about client and server used

(In reply to Michaël from comment #2)
> Yes we can show you all header from an email.
> But how can we send you these information not in "public" mode ?
> We don't want to publish information about client and server used

So can obfuscate server names and rDNS provided you leave it clear what's going on. It's the IP addresses that matter; and you previously wrote that they are all from the private ranges.

(In reply to Michaël from comment #0)
> We have email send by local exchange to an other local server (Zimbra)
> protected by SpamAssassin
> But these mails are tag as SPAM

This is almost certainly a configuration error, not a SpamAssassin bug.

> When we check header, we can see that rules RCVD_IN_BRBL_LASTEXT is matched
> On Wiki (http://wiki.apache.org/spamassassin/Rules/RCVD_IN_BRBL_LASTEXT) 

As the name suggests, that rule checks the last "external" Received header. The parsing of Received to decide whether a they are internal or external and whether a they can be trusted as accurate is governed by 3 configuration options that you MUST set correctly to get correct characterization of Received headers by SpamAssassin: 

internal_networks
trusted_networks
msa_networks

To be certain of what address SpamAssassin is checking you need to check a misidentified message using the SpamAssassin configuration which misidentified it, with the option '-D metadata,received-header' so that you get SpamAssassin's debug messages regarding its classification of Received headers.

The most likely problem is that the IP address of your Exchange server needs to be included in *all three* of those network lists. If it is not, SpamAssassin may detect the submission of mail to the Exchange server as an 'external' transport step and check the address from that Received header against the BRBL and other DNSBLs.

I think this is a configuration problem and no email has been attached to test the possible bug.
Time to close this bz ?

The Reporter never followed up with adequate data to even demonstrate that the problem existed. This is and always has been OBVIOUSLY a local configuration problem, grounded in a failure to correctly define the 3 *_networks parameters that are REQUIRED to enable SA to determine the correct Received header to parse for DNSBL checks. 

This is, AT MOST, an issue to be resolved by a more careful reading of the documentation and/or consultation with more expert SA users, e.g. the spamassassin-users mailing list. 

Simply put: 

"I don't know how to follow detailed documentation"  IS NOT A BUG