Meng, skip to the bottom. db.
>SpamAssassin is utterly blind to the IMail SMTP32/QUEUEMGR delivery
mechanismwhile SPAMC32 is purpose-built to integrate SPAMD with Declude
If there is an interaction between Declude and QUEUEMGR, it's not documented
(anywhere I could find). I'd be interested in seeing what other hooks into
IMail might be available. I'd assumed (oops!<g>) it simply followed the
20000517-DM01 doc.
>So you're going to write a custom delivery application.
Yes, this does sound like fun, but let me summarize.
o SpamAssassin "out of the box" is a pretty nice Antispam system, and the
price is right.
o There may be many small IMail users who would like this system, but don't
want to pay for the full-blown Declude or whatever.
o A trivial program can make IMail use Spamassassin (with ActivePerl).
o A non-trivial program (but still just a few hundred lines) can make IMail
use SPAMC.
Test program:
Proof-of-concept using the ActivePerl version which is a single thread
executable which:
Parse arg
if it's an email to be tested (initially, it must be to me only)
Rename Q file (Lock)
Redirect STDOUT to a file
CreateProcess for SA
un-Redirect STDOUT
Wait for SA to finish
Copy selected SA headers from SA output into original D-file.
Unlock
Call SMTP32
Exit.
Assuming successful results (and unacceptable performance - almost a given),
we'd move to a stub-program, with most of the steps moved into an NT service
or resident DLL. The stub would simply:
Parse
Lock
Wait (SAThreadCount) << Don't want to run too many at once
Signal the master task to fire off another thread (and the filespec to
filter)
Exit.
The master would:
Increment SAThreadCount
Spawn thread to
Redirect
CreateProcess SPAMC
un-Redirect
Wait SPAMC
Copy selected...
Unlock
Call SMTP32
Decrement SAThreadCount
Exit thread
Yawn, go back to sleep.
Maybe I don't need the semaphore. Could be Queuemgr handles this. I'll need
to test if multiple processes start, and how many.
> In order to have _only_ this test result returned from SPAMD
No, I'd use all the features I desired. But I'd _have_ this result. To make
SPF work, people need to know about it. I want to send-bounce-like messages
to users, not postmasters, for SPFNone. SPFUnknown and SPFSoftfail indicate
their respective Sysadminas already know about SPF, and are working towards
a solution (ie, deploying SPF records). They aren't finished, but they
aren't SPF-ignorant.
To do these "bounce" messages politely, they need to return a message such
as (edited nicely, of course, and with links to supporting doc pages):
"Your email system has failed to identify it's proper users via SPF records.
Please contact your sysadmin and get them on the stick! Your message was
actually delivered, but with this warning. To avoid further warnings of this
nature, get your act together. Following 31 December, 2004 (pick your date
here), the messages will NOT be delivered until/unless you get with the
program."
If everybody does this, then we'll go from 150K DNS records fixed, to
millions.
The non-compliant systems need not implement SPF Checking on inbound
messages, they simply must provide us the one-liner to identify themselves.
If they want to reduce the spam, then they need the SPF lookups inbound of
course. We'd make all this clear in the bounce message.
Furthermore, on the politeness front, we'd only send this message:
a) to emails identified (sigh, later) as Non-Spam,
b) only once per 24 (or 168 or whatever) hours.
Sounds to me like post-processing the logs is a better way than a
delivery-time hack, but to date, I've been unable even to get an SPFNone
result (Declude doesn't support it and says it won't for a while). Might do
it real-time for better impact, anyhow. Meng says [in
[EMAIL PROTECTED] On Behalf Of Meng Weng Wong, October 10, 2004
12:14 PM:] "If you would like to try it, I'm sure I wouldn't be the only one
interested in hearing the results :)"
And finally, I don't know anything [yet] about per-user and per-domain
settings, but if I find a use for such, I imagine SPAMC/Spamassassin allow
that flexibility, and the ruleset to use should be distinguishable from data
in the Q-file.
I'll keep the list posted on my results. As soon as I add the
[EMAIL PROTECTED] filter to the POC version, I'm lighting it for a
while! We shall see...
Dan Barker
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
