Spam Detection Around 55%

[Julian Field]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Matt Kettler wrote:
> 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? :)
>   
No, just the last bit. Mind you, the whole point of all my "sleep" 
statements in the installer is to give you a chance to read at least the 
end of what it just printed. Rather better than most autoconf installers 
which just spew out unintelligible text faster than you can see. At that 
rate, why bother printing it at all?
> That said, what if they don't have DCC at all on their system? Make em load the
> plugin anyway?
>   
The end of the installer tells them where to get DCC, as they indeed 
won't have DCC on their system at that point. At that point, if they 
bother to read the licence and realise they can't use it without paying, 
I assume they have the brainpower to realise they don't want to enable 
support for it if they can't use it.
> Any chance you might consider adding an ifplugin statement to frame the dcc_path
> command?
>
> ifplugin Mail::SpamAssassin::Plugin::DCC
> dcc_path <whatever>
> endif
>   
As above, they won't have DCC installed yet. That's what reading the 
instructions tells them to do: go and install it.
> 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?
>   
But it's an installer for the latest version of SA. If they are running 
it at all, they won't have SA 3.0.x. So I don't need to handle SA 3.0.x. 
If they managed to run the whole installer and end up with 3.0.x 
installed, I would dearly like to know how, seeing as it installs 3.1.x !!

>   
>>>> 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?
>   
Ok, you got me there, I don't tell them to go and fetch RDJ from 
fsl.com. But other bits of the wiki etc do. I must add an instruction to 
the Clam+SA installer to fetch RDJ from fsl.com.
> And what about the folks that don't go the the fsl.com website?
>   
They will when I tell them to...
> 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.
>   
Agreed. I have just added a line to the ClamAV+SA installer to go and 
install RDJ from fsl.com. I should add a link on support.html to point 
them to fsl.com/support as well.
>
>   
>> 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"
>   
Agreed.

Jules

- -- 
Julian Field MEng CITP
www.MailScanner.info
Buy the MailScanner book at www.MailScanner.info/store

MailScanner customisation, or any advanced system administration help?
Contact me at Jules at Jules.FM

PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654
For all your IT requirements visit www.transtec.co.uk



-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.5.0 (Build 1112)
Comment: Fetch my public key foot-print from www.mailscanner.info
Charset: ISO-8859-1

wj8DBQFFSR/uEfZZRxQVtlQRAvX+AJwMiSxoJOkyqEwYbhYwAHY93QXR6wCgytCR
0EgnFhejXvApaAHXfuUBq/Q=
=l0wQ
-----END PGP SIGNATURE-----

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
For all your IT requirements visit www.transtec.co.uk