Spam Detection Around 55%

[Matt Kettler]

Julian Field wrote:


> But if you read the instructions printed at the end of the install, it 
> tells you to uncomment the DCC statement in init.pre. It doesn't do it 
> automatically as this would break the licence.

You mean we're supposed to read the 6 miles of text spit out by your installer? :)

That said, what if they don't have DCC at all on their system? Make em load the
plugin anyway?

Any chance you might consider adding an ifplugin statement to frame the dcc_path
command?

ifplugin Mail::SpamAssassin::Plugin::DCC
dcc_path <whatever>
endif

That might cause DCC to break for someone making a new setup using SA 3.0.x and
the latest MailScanner, but who's going to get the latest MailScanner while
using an old version of SA?

>>> Which is of course, what triggered my reply in the first place. The dcc_path
>>> statement was causing parse errors. That's bad. It breaks RDJ.
>>>   
> And, as the RDJ setup instructions from www.fsl.com/support tell you to 
> do, you should run the RDJ once by hand to get the initial rulesets and 
> check everything's okay.

Really? where? Inside the installer tarball?

And what about the folks that don't go the the fsl.com website?

I'm not a FSL user. I'm a MailScanner user. I don't go to fsl.com/support. I go
to mailscanner.info/support.html

Perhaps you might consider adding a link to fsl.com/support to that page? Right
now it mentions FSL, but only as a commercial support option. It might be worth
pointing to all the free good FAQs fsl has created from the MailScanner website.


> If you didn't follow the earlier instructions, 
> this will highlight the dcc_path error for you, allowing you to either 
> comment out the dcc_path line or re-read the earlier instruction 
> printing by my install script.
> 
> Maybe we should have a wiki page that lists all the things that you and 
> I disagree on :-)
> Just I've never had a complaint sent to me by a user who's really had 
> problems figuring out my instructions and has been badly bitten by all 
> these things. 

Ok... I'd agree none have mentioned being badly bitten. However, some HAVE been
bitten. After all, that's how this conversation started. Someone got bit by the
dcc_path bit.

I just put my feet in the shoes of a particular kind of
> user, one that barely knows what they are doing, who runs a little box 
> for him/herself and a few customers/friends and who loves to have 
> instructions telling them what to do.

I'd agree. It's just my perspective while in these shoes is a bit different.
When I put my feet in those shoes, I think "what can I do to make this work for
the broadest variety of scenarios?" ie: "works no matter what". You appear to
think "What can I do to make this work best for the most common scenario?" ie:
maximal performance and ease for the typical small-box user.

Neither of these views is outright incorrect, it's just a different approach to
what's important when dealing with the "less knowledgeable"







> 
> Jules
>