RE: [IMail Forum] Recommended Actions

[RMilner]

you have multiple problems   1) Trusted Domains do not work with IMail though I was promised a fix by last Friday close of business and heard nothing since.   2) Companies such as AA.com use outside companies to deliver their confirmations. You will notice the return address is aa.globalnotifications.com on an email ticket, but check the headers to find an even bigger pyramid:   Received: from prodmx01.prod.appriss.com [63.126.72.183] by mydomain.com   (SMTPD32-8.03) id A4EE2301D8; Sun, 12 Oct 2003 03:38:22 -0400 Received: from prodmx01 (prodmx01.prod.appriss.com [10.10.100.166])   In most cases, one of these other domains/ips are on the rbl lists and forget about Valhelo Valfrom working on a pyramid like this.   If Ipswitch EVER gets trusted IPs to work, the solution should be easy to keep these from continually going to spam, no matter which checks you use.     -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Ted Sorrells Sent: Thursday, October 16, 2003 10:13 AM To: [EMAIL PROTECTED] Subject: [IMail Forum] Recommended Actions Gang --   Using IMail 8.03HF1, I'm still trying to get a handle on how to limit the number of false positives.  Out of about 3000 messages a day, I'm getting about 7-10.  Most of them are from commercial operations, however, such as flight confirmations from aa.com, etc., while others are from mailing lists at yahoogroups.com   Based upon the recommendations of this group, I've disabled the use of:   FIVETEN blackholes.five-ten-sg.com YBL ybl.megacity.org   and I'm using:   v6net   spammers.v6net.org SpamCop    bl.spamcop.net DSBL  list.dsbl.org DSBL-Multi   multihop.dsbl.org DSBL-Unconfirmed   unconfirmed.dsbl.org ORDB   relays.ordb.org  MAPS   blackholes.mail-abuse.org   I also use:   VERIFY MAIL FROM VERIFY HELO/EHLO DELETE AFTER 4 MATCHES   I'm using these provided by IMail in their default state:   antispam-table.txt url-domain-bl.txt   The main problem I'm having with this setup is that anything labelled spam is delivered to a mailbox called spam.  If I find a false positive in the spam mailbox and forward it to the intended recipient, and then that recipient responds to the message, they're actually responding to the "spam" mailbox instead of the original sender.   I used to use Declude Junkmail in tandem with Spam Review.  This worked nicely because you could return a false positive to the message queue and deliver the message without the headers getting changed.    Is there such a utility that'll work directly with an IMail mailbox?  Also, rather than having spam redirected to a spam mailbox, should I be inserting X-Headers into the messages and then running delivery rules on them?  What "condition" statements would you recommend?   Certainly, I understand everyone has a different level of acceptable false positives and varying setups for controlling spam, so I'm ready for a myriad of possibilities.  For me, I don't really have a problem culling through a spambox on a daily basis in search of false positives but I'd like a more effective way of putting them back into the delivery cycle without them taking on the appearance of having come through another mailbox.   Your advice (and examples) are appreciated.   Ted