Re: [exim] Issues with (gnu)tls

Góra strony
Delete this message
Reply to this message
Autor: W B Hacker
Data:  
Dla: exim users
Temat: Re: [exim] Issues with (gnu)tls
Nuno Sucena Almeida wrote:
> On 05/17/2012 12:09 AM, W B Hacker wrote:
>> Might not solve the problem - but at least you'll know if it IS your
>> problem.
>
> Hi Bill,
> I do have my own specific site headers and check through them, I just
> removed them from the post since it's just a minor change.
> As you can see from my first message on the subject, I used a manual
> openssl client remote connection with a bare message to test the
> different encryption cyphers, and the only(?) one giving trouble is
> RC4-SHA.
> I didn't have time to check this further, but if you can point me in a
> way to debug it in some other way besides using 'exim -d -bd' I would
> appreciate, since from the log files generated I don't see any errors
> using any cipher, including RC4-SHA.


Not much help here. I've always been *BSD based ergo OpenSS*, regarded
GNUTLS as a curiosity, and can't understand why it has had such a
troubled path to the dinner table.

> How can I debug the exim-spamassassin interaction ?
>
> Regards,
> Nuno


Largely by first 'stripping' SA to about 15% of its full functionality.

A) 50% or more of its test suite are down in the noise, point-score AND
usefulness-wise. They just don't pay their way.

Some - Bayesian, for example - can generate more falsing than utility
when run on the broad menu of incoming a multi-user server sees.
Bayes-anything is better left to 'learn' spam/ham on a single-user's
MUA. If at all.

B) SA's most-effective tests are duplicates of those Exim can do better,
faster - and EARLIER than SA can do. rDNS for example.

Same again with header construction, spoofing, syntax errors, RFC
violations. Exim doing these inline in complied 'C', and often as not
already having the info the test needs in memory, beats all Hell out of
invoking an external running under a capable, but rahter inefficient
interpreted language.

Wot's left? Subject and body content scanning. ONLY.

SA is better at that than most alternatives.

And with fewer marginally useful distractions or duplications, SA doing
content-scanning-only is easier to debug and keep tuned.

But those are primarily SA issues, not Exim ones, so 'how to' is, and
belongs elsewhere.

Our experience was that once we got Exim blocking the SOURCES of
garbage, eg: 100% of the 'bots and commercial UCE sources, and the much
less resource-hungry than SA 'ClamAV' checking for phish and malware, we
no longer needed to scan 'surviving' content AT ALL. Nor give a damn
about SPF, DK, DKIM.

Just LBL the odd surviving free range rude arrivals, (sometimes whole
networks or even <tld>) and be done with it.

A short LWL that has never needed more than 16 entries grants a pass to
the few mixed-bag purveyors that look dirtier than they really are.
Harvard U Alumni and the Royal St. Andrews Golf Club running w/o proper
PTR and DNS entries for example.

All dependent on the makeup of YOUR clients, and THEIR regular
correspondents, of course.

No easy cut-and-paste configs for those LWL/LBL.

Bill
---
韓家標