Thank you for the comments, Paul.  So far, I have always found the last X-Originating-IP header (i.e. the earliest chronologically) to be a reliable indicator .... checking such headers manually with a DNSBL look-up tool, e.g. at whatismyipaddress.com has always confirmed my residual SPAM messages to be blacklisted on several DNSBLs.

In fact my earlier statement about currently having 2% residual SPAM was wrong.  It seems to be much lower than that, avegaing one message a day, when I am receiving over 300 SPAM messages a day.  So, I am not left with much to clean up.  This small amount is hardly necessary to worry about, though I am interested to see how close to 0% I can get, without introducing any false positives.

Gordon

As I understand it, to make use of DNSBLs with Mercury, it is necesary (as with Graywall) to run MercuryS SMTP server so that origniating hosts are connecting directly to Mercury (if this assumption is incorrect, perhaps someone could let me know).  I am currently using my ISP for the SMTP server function and all mail is picked up by MercuryD and distributed to users on my home network as appropriate.  I don't really want to change this configuration at the moment, as it will involve me in a great deal of notification about changed e-mail addresses, going to numerous web-sites to which I and other users are subscribed, and changing several hundred "disposable" e-mail addresses that are currently set up through my ISP.

So, my question is about the practicality of using DNSBLs and querying them using a Policy, linked to a script outside of Mercury.  At that stage in the mail process, very few meassages should be left as about 98% (my current experience) have been dealt with by various other SPAM filetering means.  False postives from DNSBLs should be very small as a percentage of total incoming mail throughput,  Has anyone had any experience of using this approach?

Thank you

GordonM

It is possible to use DNSBLs retrospectively on the 'received' headers in an email downloaded by POP3.  I used to run that way some years ago with one mailbox using a tool called Spamscan developed by a Mercury user.

Although useful, it had more false positives than other methods partly because it looked at all the IP addresses in the headers, and not just the final SMTP delivery.  In the end I stopped using it and went over to Bayesian techniques.

Let me know if you want any more information.