Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: users

Issues with (gnu)tls

 

 

exim users RSS feed   Index | Next | Previous | View Threaded


nuno at aeminium

May 7, 2012, 1:54 PM

Post #1 of 10 (587 views)
Permalink
Issues with (gnu)tls

Hi,
Depending on the cipher algorithm, when a remote smtp connection is
using TLS, the spamassassin score gives the correct score or something
likes this:
X-Spam-Score: -nan
X-Spam-Score_int: -2147483648.

The same email sent using swaks without tls gives a correct
spamassassin score.
The weird thing is that looking at /var/log/spamd.log I see the correct
scoring for all the cases, but it's not being "propagated" to the
calling exim.

Is this somehow related to
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=3364 ?

I have this happening in two systems with similar configuration (ubuntu
12.04 , exim 4.76, gnutls 2.12.14, spamassassin 3.3.2).

I started exim in debug mode:

server:~# exim -d -bd -oX 5555 2>&1 |tee exim-openssl.log

and connected remotely using:

remote:~$ openssl s_client -connect server:5555 -starttls smtp -crlf \
-cipher AES256-SHA

remote:~$ openssl s_client -connect gw:5555 -starttls smtp -crlf \
-cipher RC4-SHA

The former gives:
1819 accept: condition test succeeded
1819 >>Headers added by DATA ACL:
1819 X-Spam-Score: nan
1819 X-Spam-Score_int: -2147483648
1819 X-Spam-Bar: -

and the latter:
1846 accept: condition test succeeded
1846 >>Headers added by DATA ACL:
1846 X-Spam-Score: -1.0
1846 X-Spam-Score_int: -9
1846 X-Spam-Bar: -


My relevant exim configuration:
# add the spam score to all messages.
warn message = X-Spam-Score: $spam_score\n\
X-Spam-Score_int: $spam_score_int\n\
X-Spam-Bar: $spam_bar
spam = Debian-exim:true



A grep -A 1 gnutls exim-openssl-AES256-SHA.log gives:

1819 gnutls_handshake was successful
1819 cipher: TLS1.0:RSA_AES_256_CBC_SHA1:32
--
1819 Calling gnutls_record_recv(22122400, 221274e0, 4096)
1819 SMTP<< ehlo example.org
--
1819 gnutls_record_send(SSL, 21f877d0, 117)
1819 outbytes=117
--
1819 Calling gnutls_record_recv(22122400, 221274e0, 4096)
1819 SMTP<< mail from: me [at] example
--
1819 gnutls_record_send(SSL, 21f7a998, 8)
1819 outbytes=8
1819 Calling gnutls_record_recv(22122400, 221274e0, 4096)
1819 SMTP<< rcpt to: tests [at] aeminium
--
1819 gnutls_record_send(SSL, 21f7a998, 14)
1819 outbytes=14
1819 Calling gnutls_record_recv(22122400, 221274e0, 4096)
1819 SMTP<< data
--
1819 gnutls_record_send(SSL, 21f7a998, 56)
1819 outbytes=56
--
1819 Calling gnutls_record_recv(22122400, 221274e0, 4096)
1819 Calling gnutls_record_recv(22122400, 221274e0, 4096)
1819 host in ignore_fromline_hosts? no (option unset)
1819 Calling gnutls_record_recv(22122400, 221274e0, 4096)
1819 Calling gnutls_record_recv(22122400, 221274e0, 4096)
PDKIM >> Hashed body data, canonicalized >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
--
1819 Calling gnutls_record_recv(22122400, 221274e0, 4096)
1819 Calling gnutls_record_recv(22122400, 221274e0, 4096)
1819 Calling gnutls_record_recv(22122400, 221274e0, 4096)
1819 Calling gnutls_record_recv(22122400, 221274e0, 4096)
1819 Data file written for message 1SRTuz-0000TL-Bj
--
1819 gnutls_record_send(SSL, 21f7a998, 28)
1819 outbytes=28
--
1819 Calling gnutls_record_recv(22122400, 221274e0, 4096)
1826 exec /usr/sbin/exim4 -d=0xfbbd5cfd -Mc 1SRTuz-0000TL-Bj
--
1819 gnutls_record_send(SSL, 21f7a998, 40)
1819 outbytes=40





and grep -A 1 gnutls exim-openssl-RC4-SHA.log:

1846 gnutls_handshake was successful
1846 cipher: TLS1.0:RSA_ARCFOUR_SHA1:16
--
1846 Calling gnutls_record_recv(223fc400, 224014e0, 4096)
1846 SMTP<< EHLO example.org
--
1846 gnutls_record_send(SSL, 222617d0, 117)
1846 outbytes=117
--
1846 Calling gnutls_record_recv(223fc400, 224014e0, 4096)
1846 SMTP<< mail from: me [at] example
--
1846 gnutls_record_send(SSL, 22254998, 8)
1846 outbytes=8
1846 Calling gnutls_record_recv(223fc400, 224014e0, 4096)
1846 SMTP<< rcpt to: tests [at] aeminium
--
1846 gnutls_record_send(SSL, 22254998, 14)
1846 outbytes=14
1846 Calling gnutls_record_recv(223fc400, 224014e0, 4096)
1846 SMTP<< data
--
1846 gnutls_record_send(SSL, 22254998, 56)
1846 outbytes=56
--
1846 Calling gnutls_record_recv(223fc400, 224014e0, 4096)
1846 Calling gnutls_record_recv(223fc400, 224014e0, 4096)
1846 host in ignore_fromline_hosts? no (option unset)
1846 Calling gnutls_record_recv(223fc400, 224014e0, 4096)
1846 Calling gnutls_record_recv(223fc400, 224014e0, 4096)
PDKIM >> Hashed body data, canonicalized >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
--
1846 Calling gnutls_record_recv(223fc400, 224014e0, 4096)
1846 Calling gnutls_record_recv(223fc400, 224014e0, 4096)
1846 Calling gnutls_record_recv(223fc400, 224014e0, 4096)
1846 Data file written for message 1SRTwa-0000Tm-O1
--
1846 gnutls_record_send(SSL, 22254998, 28)
1846 outbytes=28
--
1846 Calling gnutls_record_recv(223fc400, 224014e0, 4096)
1855 Exim version 4.76 uid=105 gid=113 pid=1855 D=fbbd5cfd
--
1846 gnutls_record_send(SSL, 22254998, 40)
1846 outbytes=40



Any thoughts?
Nuno


--
http://aeminium.org/nuno/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


exim-users at spodhuis

May 8, 2012, 1:39 AM

Post #2 of 10 (562 views)
Permalink
Re: Issues with (gnu)tls [In reply to]

On 2012-05-07 at 16:54 -0400, Nuno Sucena Almeida wrote:
> Depending on the cipher algorithm, when a remote smtp connection is
> using TLS, the spamassassin score gives the correct score or something
> likes this:
> X-Spam-Score: -nan
> X-Spam-Score_int: -2147483648.

> Any thoughts?

What's the ACL logic involved? The relevant stanzas from your
configuration file would be useful to see here.

I suspect that the spam() call is failing, because it's not getting a
response within the timeout (two minutes, hardcoded), but you're setting
the headers in a different ACL, so that the failure isn't being caught.

But I have no evidence for this, as I can't see the configuration logic
in use, and I've no idea why SpamAssassin would timeout for one cipher
and not for another.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


nuno at aeminium

May 8, 2012, 7:44 AM

Post #3 of 10 (566 views)
Permalink
Re: Issues with (gnu)tls [In reply to]

On 05/08/2012 04:39 AM, Phil Pennock wrote:
> What's the ACL logic involved? The relevant stanzas from your
> configuration file would be useful to see here.

Hi Phil,
I'm not sure I understand what you mean by the ACL logic, I thought the
"My relevant exim configuration" on my previous message would be enough.
Anyway, I post here the complete acl_check_data spamassassin part, let
me know if you refer to something else.

# add the spam score to all messages.
warn message = X-Spam-Score: $spam_score\n\
X-Spam-Score_int: $spam_score_int\n\
X-Spam-Bar: $spam_bar
spam = Debian-exim:true

# if spam score higher than 4.5 set Status flag
warn message = X-Spam-Status: Yes\n\
X-Spam-Flag: Yes
spam = Debian-exim:true
condition = ${if >{$spam_score_int}{45}{true}{false}}

# if spam higher than 0, add spam report
warn message = X-Spam-Report: $spam_report
spam = Debian-exim:true
condition = ${if >{$spam_score_int}{0}{true}{false}}

# if spam score higher than 10 deny message
deny message = This message scored $spam_score spam points.
spam = Debian-exim:true
condition = ${if >{$spam_score_int}{100}{true}{false}}


> I suspect that the spam() call is failing, because it's not getting a
> response within the timeout (two minutes, hardcoded), but you're setting
> the headers in a different ACL, so that the failure isn't being caught.

spamassassin is not timing out, it takes less than a few seconds for the
message to go through and I don't see any error from exim part.

Nuno

--
http://aeminium.org/nuno/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


nuno at aeminium

May 15, 2012, 5:31 AM

Post #4 of 10 (542 views)
Permalink
Re: Issues with (gnu)tls [In reply to]

On 05/08/2012 10:44 AM, Nuno Sucena Almeida wrote:
> On 05/08/2012 04:39 AM, Phil Pennock wrote:
>> What's the ACL logic involved? The relevant stanzas from your
>> configuration file would be useful to see here.
>
> Hi Phil,
> I'm not sure I understand what you mean by the ACL logic, I thought the
> "My relevant exim configuration" on my previous message would be enough.
> Anyway, I post here the complete acl_check_data spamassassin part, let
> me know if you refer to something else.

Hi Phil,
any thoughts on how should I approach debugging this problem?
Thanks,
Nuno

--
http://aeminium.org/nuno/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


exim-users at spodhuis

May 15, 2012, 6:12 AM

Post #5 of 10 (538 views)
Permalink
Re: Issues with (gnu)tls [In reply to]

On 2012-05-15 at 08:31 -0400, Nuno Sucena Almeida wrote:
> On 05/08/2012 10:44 AM, Nuno Sucena Almeida wrote:
> > On 05/08/2012 04:39 AM, Phil Pennock wrote:
> >> What's the ACL logic involved? The relevant stanzas from your
> >> configuration file would be useful to see here.
> >
> > Hi Phil,
> > I'm not sure I understand what you mean by the ACL logic, I thought the
> > "My relevant exim configuration" on my previous message would be enough.
> > Anyway, I post here the complete acl_check_data spamassassin part, let
> > me know if you refer to something else.
>
> Hi Phil,
> any thoughts on how should I approach debugging this problem?

I looked at it, I can't see anything in Exim to explain it. I checked
through various code-paths and spent some time picking through things.

Sorry I can't help further,
-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


wbh at conducive

May 16, 2012, 9:09 PM

Post #6 of 10 (532 views)
Permalink
Re: Issues with (gnu)tls [In reply to]

Nuno Sucena Almeida wrote:
> On 05/08/2012 10:44 AM, Nuno Sucena Almeida wrote:
>> On 05/08/2012 04:39 AM, Phil Pennock wrote:
>>> What's the ACL logic involved? The relevant stanzas from your
>>> configuration file would be useful to see here.
>>
>> Hi Phil,
>> I'm not sure I understand what you mean by the ACL logic, I thought the
>> "My relevant exim configuration" on my previous message would be enough.
>> Anyway, I post here the complete acl_check_data spamassassin part, let
>> me know if you refer to something else.
>
> Hi Phil,
> any thoughts on how should I approach debugging this problem?
> Thanks,
> Nuno
>

Nuno,

Before I did ANYTHING else I'd rename all of the 'X-Spam <wotever>'
headers you add to something unique to your own server.

Many a Sysadmin has chased ghosts that turned out to be the same
header-names already present on the *incoming* traffic - either added by
the submitting server - or even spoofed.

Might not solve the problem - but at least you'll know if it IS your
problem.

Bill
--
韓家標

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


snabb at epipe

May 16, 2012, 11:33 PM

Post #7 of 10 (533 views)
Permalink
Re: Issues with (gnu)tls [In reply to]

On 2012-05-17 11:09, W B Hacker wrote:

> Before I did ANYTHING else I'd rename all of the 'X-Spam <wotever>'
> headers you add to something unique to your own server.
>
> Many a Sysadmin has chased ghosts that turned out to be the same
> header-names already present on the *incoming* traffic - either added by
> the submitting server - or even spoofed.

IMHO the best solution is to add the X-Spamwhatever headers in the
system filter based on ACL variables. In system filter it is possible to
remove pre-existing header lines first, but in ACL it is not possible. I
have something such as the following in my system filter:

# Exim filter

if first_delivery then
headers remove X-Spam-Score:X-Spam-Report:X-Spam-Flag

if $acl_m_spam_score is not "" then
headers add "X-Spam-Score: $acl_m_spam_score ($acl_m_spam_bar)"

if $acl_m_spam_score_int is not below 50 then
headers add "X-Spam-Flag: YES"
headers add "X-Spam-Report: $acl_m_spam_report"
endif
endif
endif

For some reason all the spamd ACL examples add the headers in the ACL.

--
Janne Snabb / EPIPE Communications
snabb [at] epipe - http://epipe.com/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


wbh at conducive

May 17, 2012, 12:26 AM

Post #8 of 10 (535 views)
Permalink
Re: Issues with (gnu)tls [In reply to]

Janne Snabb wrote:
> On 2012-05-17 11:09, W B Hacker wrote:
>
>> Before I did ANYTHING else I'd rename all of the 'X-Spam<wotever>'
>> headers you add to something unique to your own server.
>>
>> Many a Sysadmin has chased ghosts that turned out to be the same
>> header-names already present on the *incoming* traffic - either added by
>> the submitting server - or even spoofed.
>
> IMHO the best solution is to add the X-Spamwhatever headers in the
> system filter based on ACL variables. In system filter it is possible to
> remove pre-existing header lines first, but in ACL it is not possible. I
> have something such as the following in my system filter:
>
> # Exim filter
>
> if first_delivery then
> headers remove X-Spam-Score:X-Spam-Report:X-Spam-Flag
>
> if $acl_m_spam_score is not "" then
> headers add "X-Spam-Score: $acl_m_spam_score ($acl_m_spam_bar)"
>
> if $acl_m_spam_score_int is not below 50 then
> headers add "X-Spam-Flag: YES"
> headers add "X-Spam-Report: $acl_m_spam_report"
> endif
> endif
> endif
>
> For some reason all the spamd ACL examples add the headers in the ACL.
>

I've always preferred to use acl_m's, add as few headers as possible,
strip as many as practical in router/transport sets.

Tradeoffs, as always....

That said, we're drifting off-topic.

I'm still waiting for better evidence that the original problem is
actually GNUTLS driven.

Haven't needed or used SA for several years now, but ISTR it did now and
then get its knickers caught in the geartrain..

Bill
--
韓家標

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


nuno at aeminium

May 17, 2012, 2:11 PM

Post #9 of 10 (525 views)
Permalink
Re: Issues with (gnu)tls [In reply to]

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.
How can I debug the exim-spamassassin interaction ?

Regards,
Nuno
--
http://aeminium.org/nuno/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


wbh at conducive

May 17, 2012, 5:28 PM

Post #10 of 10 (531 views)
Permalink
Re: Issues with (gnu)tls [In reply to]

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
---
韓家標

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

exim users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.