spamassassin and rbl checks in SuSE V9.2
I am trying to get rbl filtering of my incoming mail. I tried to configure sendmail to do rbl checks, but since I dislike opening the smtp port on my router, I decided to use fetchmail to periodically poll my external mail sources, and use spamassassin for rbl checks. Unfortunately this doe not work for me for some reason. spamassassin -D --lint reports: debug: config: read file /usr/share/spamassassin/20_dnsbl_tests.cf ... debug: is Net::DNS::Resolver available? yes debug: Net::DNS version: 0.48 so I conclude that the rbl test are available as are the perl dns modules are available to spamassassin. Yet mail messages originating from sources which are listed in sorbs as spam-sources, pass through, I never get any RCVD_IN_SORBS results, i.e. the following received header should trigger RCVD_IN_SORBS_DUL Received: from unknown (HELO keatingjones.com) (84.97.25.132) by anchovy2.45ru.net.au with SMTP; 9 Jul 2006 13:36:23 -0000 because the dns reverse lookup returns a result # nslookup 132.25.97.84.dnsbl.sorbs.net Server: 192.168.1.186 Address: 192.168.1.186#53 Non-authoritative answer: Name: 132.25.97.84.dnsbl.sorbs.net Address: 127.0.0.10 What am I overlooking? Peter My /usr/share/spamassassin/20_dnsbl_tests.cf contains the following # SORBS # transfers: both axfr and ixfr available # URL: http://www.dnsbl.sorbs.net/ # pay-to-use: no # delist: $50 fee for RCVD_IN_SORBS_SPAM, others have free retest on request header __RCVD_IN_SORBS eval:check_rbl('sorbs', 'dnsbl.sorbs.net.') describe __RCVD_IN_SORBS SORBS: sender is listed in SORBS tflags __RCVD_IN_SORBS net header RCVD_IN_SORBS_HTTP eval:check_rbl_sub('sorbs', '127.0.0.2') describe RCVD_IN_SORBS_HTTP SORBS: sender is open HTTP proxy server tflags RCVD_IN_SORBS_HTTP net header RCVD_IN_SORBS_SOCKS eval:check_rbl_sub('sorbs', '127.0.0.3') describe RCVD_IN_SORBS_SOCKS SORBS: sender is open SOCKS proxy server tflags RCVD_IN_SORBS_SOCKS net header RCVD_IN_SORBS_MISC eval:check_rbl_sub('sorbs', '127.0.0.4') describe RCVD_IN_SORBS_MISC SORBS: sender is open proxy server tflags RCVD_IN_SORBS_MISC net header RCVD_IN_SORBS_SMTP eval:check_rbl_sub('sorbs', '127.0.0.5') describe RCVD_IN_SORBS_SMTP SORBS: sender is open SMTP relay tflags RCVD_IN_SORBS_SMTP net # delist: $50 fee #header RCVD_IN_SORBS_SPAM eval:check_rbl_sub('sorbs', '127.0.0.6') #describe RCVD_IN_SORBS_SPAM SORBS: sender is a spam source #tflags RCVD_IN_SORBS_SPAM net header RCVD_IN_SORBS_WEB eval:check_rbl_sub('sorbs', '127.0.0.7') describe RCVD_IN_SORBS_WEB SORBS: sender is a abuseable web server tflags RCVD_IN_SORBS_WEB net header RCVD_IN_SORBS_BLOCK eval:check_rbl_sub('sorbs', '127.0.0.8') describe RCVD_IN_SORBS_BLOCK SORBS: sender demands to never be tested tflags RCVD_IN_SORBS_BLOCK net header RCVD_IN_SORBS_ZOMBIE eval:check_rbl_sub('sorbs', '127.0.0.9') describe RCVD_IN_SORBS_ZOMBIE SORBS: sender is on a hijacked network tflags RCVD_IN_SORBS_ZOMBIE net header RCVD_IN_SORBS_DUL eval:check_rbl('sorbs-notfirsthop', 'dnsbl.sorbs.net.', '127.0.0.10') describe RCVD_IN_SORBS_DUL SORBS: sent directly from dynamic IP address tflags RCVD_IN_SORBS_DUL net
Peter Sutter wrote:
I am trying to get rbl filtering of my incoming mail. I tried to configure sendmail to do rbl checks, but since I dislike opening the smtp port on my router, I decided to use fetchmail to periodically poll my external mail sources, and use spamassassin for rbl checks.
Unfortunately this doe not work for me for some reason.
The reason is that RBL checks can only be done on the first Server that accepts Mails for your domain. In your case this is the Server of your provider. Unless you decide to accept Mail on your suse server, you don't need to bother with RBL checks.
spamassassin -D --lint reports: debug: config: read file /usr/share/spamassassin/20_dnsbl_tests.cf ... debug: is Net::DNS::Resolver available? yes debug: Net::DNS version: 0.48 so I conclude that the rbl test are available as are the perl dns modules are available to spamassassin.
Yet mail messages originating from sources which are listed in sorbs as spam-sources, pass through, I never get any RCVD_IN_SORBS results, i.e. the following received header should trigger RCVD_IN_SORBS_DUL
RBL only checks the current IP of the client. In your case this would be fetchmail on localhost! A lot of mail originates from dynamic IPs, practically every private mail send by a mailclient. The relevant lookup though will only check the current ip of the client.
Received: from unknown (HELO keatingjones.com) (84.97.25.132) by anchovy2.45ru.net.au with SMTP; 9 Jul 2006 13:36:23 -0000
because the dns reverse lookup returns a result
# nslookup 132.25.97.84.dnsbl.sorbs.net Server: 192.168.1.186 Address: 192.168.1.186#53
Non-authoritative answer: Name: 132.25.97.84.dnsbl.sorbs.net Address: 127.0.0.10
What am I overlooking?
The basic understanding how smtp communication and restrictions work. You can't have fetchmail and RBLs both. Either you use fetchmail, accept all mail and discard or mark and deliver the mail, or you accept mails directly submitted to your server and then you can use RBLs, Postfix restrictions and all the luxury of your own smtp server. You can't have the cake and eat it at the same time. (^-^) Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-07-12 at 18:28 +0200, Sandy Drobic wrote:
The basic understanding how smtp communication and restrictions work. You can't have fetchmail and RBLs both. Either you use fetchmail, accept all mail and discard or mark and deliver the mail, or you accept mails directly submitted to your server and then you can use RBLs, Postfix restrictions and all the luxury of your own smtp server.
You can't have the cake and eat it at the same time. (^-^)
That can't be completely true: I'm using fetchmail and my spamassassin is using some rbl tests and catching spam that way. Look at a report (edited to avoid false triggers - I hope): pts rule name description - ---- ---------------------- -------------------------------------------------- 0.9 URI_NOVOWEL URI: URI hostname has long non-vowel sequence 5.0 BAYES_99 BODY: Bayesian spam probability is 99 to 100% [score: 1.0000] 1.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [169.207.88.67 listed in dnsbl.sorbs.net] 1.0 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP [169.207.88.67 listed in combined.njabl.org] 1.6 URIBL_SBL Contains an URL listed in the SBL blocklist [URIs: emerseddm dot com] 4.1 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist [URIs: emerseddm dot com] 2.1 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: emerseddm dot com] 3.0 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist [URIs: emerseddm dot com] 4.5 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist [URIs: emerseddm dot com] Notice that the scoring is a bit unfair: one url is scoring several times for the same motive. Notice also that I have downgraded some scores, like the one for dynamic addresses: after all, I use one myself. The thing is, the IP that SA checks is the one in the "Return-Path" header: <taxqlnsu at as14.nwbl1.wi.core.com>. The absurd thing is that it is not in fact a dynamic address: cer@nimrodel:~> host as14.nwbl1.wi.core.com as14.nwbl1.wi.core.com has address 169.207.80.56 cer@nimrodel:~> host 169.207.80.56 56.80.207.169.in-addr.arpa domain name pointer as14.nwbl1.wi.core.com. It has correct reverse DNS, can't be dynamic. But dnsbl.sorbs.net says it is. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEtY3utTMYHG2NR9URAnPuAJ90gJJFeS8uDgBhy1LTAOsOFtOvCQCfQp0b sI35i2Pm1f2SnbVTpkYvaIM= =DUIh -----END PGP SIGNATURE-----
On 7/12/06 8:03 PM, "Carlos E. R."
The thing is, the IP that SA checks is the one in the "Return-Path" header: <taxqlnsu at as14.nwbl1.wi.core.com>. The absurd thing is that it is not in fact a dynamic address:
cer@nimrodel:~> host as14.nwbl1.wi.core.com as14.nwbl1.wi.core.com has address 169.207.80.56 cer@nimrodel:~> host 169.207.80.56 56.80.207.169.in-addr.arpa domain name pointer as14.nwbl1.wi.core.com.
It has correct reverse DNS, can't be dynamic. But dnsbl.sorbs.net says it is.
Why not? I _know_ that I'm on a dynamic address, and yet... igloo:~ # host -a 209.6.158.239 Trying "239.158.6.209.in-addr.arpa" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3109 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;239.158.6.209.in-addr.arpa. IN PTR ;; ANSWER SECTION: 239.158.6.209.in-addr.arpa. 300 IN PTR 209-6-158-239.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com. Received 110 bytes from 10.0.0.1#53 in 24 ms igloo:~ # host -a 209-6-158-239.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com Trying "209-6-158-239.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55218 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;209-6-158-239.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com. IN ANY ;; ANSWER SECTION: 209-6-158-239.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com. 300 IN A 209.6.158.239 Received 86 bytes from 10.0.0.1#53 in 2 ms igloo:~ #
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-07-12 at 20:09 -0400, Ian Marlier wrote:
It has correct reverse DNS, can't be dynamic. But dnsbl.sorbs.net says it is.
Why not? I _know_ that I'm on a dynamic address, and yet... igloo:~ # host -a 209.6.158.239
cer@nimrodel:~> host 209.6.158.239 239.158.6.209.in-addr.arpa domain name pointer 209-6-158-239.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com. Yes, right, but if you had a domain name it would not match the reverse DNS, being dynamic. And, the spammer has not only a domain name, but an MX entry. He is a spammer, but IMO, the IP is fixed. Or, that's not the spammer address, but a hijacked server. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEtZZAtTMYHG2NR9URAhApAJ99rSHrelsZcTwqI20l16qf4q9ngwCdEMUQ S0kw/A00/FwU3kPHqgqgQgI= =1xo2 -----END PGP SIGNATURE----- -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Wednesday 2006-07-12 at 18:28 +0200, Sandy Drobic wrote:
The basic understanding how smtp communication and restrictions work. You can't have fetchmail and RBLs both. Either you use fetchmail, accept all mail and discard or mark and deliver the mail, or you accept mails directly submitted to your server and then you can use RBLs, Postfix restrictions and all the luxury of your own smtp server.
You can't have the cake and eat it at the same time. (^-^)
That can't be completely true: I'm using fetchmail and my spamassassin is using some rbl tests and catching spam that way. Look at a report (edited to avoid false triggers - I hope):
The problem with those RBL tests is always which hop in the received lines they use to look up. Often they use the wrong one. Some people have complained that they were rejected because the received lines had a dynamic ip from the time when the user submitted the mail with smtp auth, and in the end they were forced to delete the received lines from the mails to get through. You could probably better write a little script to check the received lines, since you know which lines are from your server and then evaluate the correct line. The use of RBLs in Postfix though can only happen if you accept mails directly.
pts rule name description - ---- ---------------------- -------------------------------------------------- 0.9 URI_NOVOWEL URI: URI hostname has long non-vowel sequence 5.0 BAYES_99 BODY: Bayesian spam probability is 99 to 100% [score: 1.0000] 1.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [169.207.88.67 listed in dnsbl.sorbs.net] 1.0 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP [169.207.88.67 listed in combined.njabl.org]
Now, the question is which hop this ip was. (^-^)
1.6 URIBL_SBL Contains an URL listed in the SBL blocklist [URIs: emerseddm dot com] 4.1 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist [URIs: emerseddm dot com] 2.1 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: emerseddm dot com] 3.0 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist [URIs: emerseddm dot com] 4.5 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist [URIs: emerseddm dot com]
Notice that the scoring is a bit unfair: one url is scoring several times for the same motive.
Notice also that I have downgraded some scores, like the one for dynamic addresses: after all, I use one myself.
Especially the sorbs dul list has stirred up some bad feedback due to their policy.
The thing is, the IP that SA checks is the one in the "Return-Path" header: <taxqlnsu at as14.nwbl1.wi.core.com>. The absurd thing is that it is not in fact a dynamic address:
cer@nimrodel:~> host as14.nwbl1.wi.core.com as14.nwbl1.wi.core.com has address 169.207.80.56 cer@nimrodel:~> host 169.207.80.56 56.80.207.169.in-addr.arpa domain name pointer as14.nwbl1.wi.core.com.
It has correct reverse DNS, can't be dynamic. But dnsbl.sorbs.net says it is.
sorbs doesn't care about reverse DNS records, they list blocks as dynamic that they figured are dynamic or which at some time have been reported as dynamic. If the use of that ip block has changed in the meantime it's just your bad luck. :-( Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-07-13 at 02:37 +0200, Sandy Drobic wrote:
That can't be completely true: I'm using fetchmail and my spamassassin is using some rbl tests and catching spam that way. Look at a report (edited to avoid false triggers - I hope):
The problem with those RBL tests is always which hop in the received lines they use to look up.
True enough. In the case I quoted, it used the return address (not the from header).
Often they use the wrong one. Some people have complained that they were rejected because the received lines had a dynamic ip from the time when the user submitted the mail with smtp auth, and in the end they were forced to delete the received lines from the mails to get through.
SpamAssassin is pretty clever, but I also have doubts.
You could probably better write a little script to check the received lines, since you know which lines are from your server and then evaluate the correct line.
I think there is some configuration somewhere to tell SA, but I'm not clear on this.
The use of RBLs in Postfix though can only happen if you accept mails directly.
Makes sense. It takes place during the negotiation, not parsing the headers.
1.0 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP [169.207.88.67 listed in combined.njabl.org]
Now, the question is which hop this ip was. (^-^)
It matches the "Return-Path" header in the email, which (at least in my system) is also the envelope from. But it also matches the first received header in the chain, that happens also to be the one before my provider. Mmm... it could be using any of both sources.
Notice also that I have downgraded some scores, like the one for dynamic addresses: after all, I use one myself.
Especially the sorbs dul list has stirred up some bad feedback due to their policy.
I can understand that.
It has correct reverse DNS, can't be dynamic. But dnsbl.sorbs.net says it is.
sorbs doesn't care about reverse DNS records, they list blocks as dynamic that they figured are dynamic or which at some time have been reported as dynamic. If the use of that ip block has changed in the meantime it's just your bad luck. :-(
Right. I just chanced to pick a spam email where that happened. So, that score should not be trusted. I was right to downgrade it to 1.0 points instead of the default. Now I know that it is even less to be trusted that I thought, or for different reasons. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEtZyytTMYHG2NR9URAm25AJ9a0sd4CR+ejO9yzG0I/VOYB923cwCgh3O5 l2mQCYt5vkf/+qGpTJKEL/o= =0Shg -----END PGP SIGNATURE----- -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
* Carlos E. R.
Right. I just chanced to pick a spam email where that happened. So, that score should not be trusted. I was right to downgrade it to 1.0 points instead of the default. Now I know that it is even less to be trusted that I thought, or for different reasons.
Nice thing about postfix, allows you to specify which rbl lists you use. ie: I do *not* use sorbs. I guess you can do that with spamassassin also, but tooooo many things to remember. Procmail is .. straight forward, er.. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-07-12 at 21:12 -0400, Patrick Shanahan wrote:
I guess you can do that with spamassassin also, but tooooo many things to remember. Procmail is .. straight forward, er..
But I prefer to use a weighted method like SA does. I mean, I don't want to reject an email because it triggers a single hit with an RBL list. I want more checks done. Thus, SA is safer. Also, I'm too lazy to design those procmail rules :-p - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEtidTtTMYHG2NR9URAtB4AJ0Xi0JVXwc2lbnmCH43/RbhiH67KgCgin8/ BoW2e7CePJrBnq/7y/+IB2g= =fY7s -----END PGP SIGNATURE----- -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
* Carlos E. R.
That can't be completely true: I'm using fetchmail and my spamassassin is using some rbl tests and catching spam that way. Look at a report (edited to avoid false triggers - I hope):
But you are *still* downloading the mail rather than rejecting it prior. I have routed all my list mail thru gmail. Of the mail still being sent to my own server, 75-80% is rejected by procmail rbl checks. I still get 10-15 a day that pass and 3/4 of those are caught by spamassassin and I have never noticed an rbl rule being applied. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2 -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-07-12 at 20:45 -0400, Patrick Shanahan wrote:
But you are *still* downloading the mail rather than rejecting it prior.
True enough. My machine uses resources, but I don't waste time reading the email, that's all. Not a small "all", IMO ;-)
I have routed all my list mail thru gmail. Of the mail still being sent to my own server, 75-80% is rejected by procmail rbl checks. I still get 10-15 a day that pass and 3/4 of those are caught by spamassassin and I have never noticed an rbl rule being applied.
Well, my SA does - but don't ask me how I did it, I don't remember ;-) I get few false positives/negatives. But I don't trust it fully, I check periodically. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEtZpDtTMYHG2NR9URAtbeAKCPbpiUBWzijGE1pgWkMPu9G8x91gCfeWvV dguU2dZWC6x19XBxBqR9AKU= =yePI -----END PGP SIGNATURE----- -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Thursday 13 July 2006 08:03, Carlos E. R. wrote:
The Wednesday 2006-07-12 at 18:28 +0200, Sandy Drobic wrote:
The basic understanding how smtp communication and restrictions work. You can't have fetchmail and RBLs both. Either you use fetchmail, accept all mail and discard or mark and deliver the mail, or you accept mails directly submitted to your server and then you can use RBLs, Postfix restrictions and all the luxury of your own smtp server.
You can't have the cake and eat it at the same time. (^-^)
Yes, I understand that, and from the logs, quite clearly, fetchmail retrieves the mail, hands it to procmail, which hands it to spamassassin (actually spamd) which then returns either spam or not spam to sendmail. Therefore the mail is always from the local server, which is trusted by sendmail. I have to download the message first before I can analyse it, I don't mind doing that, I just don't want to deliver it to the mailboxes if it is spam. Spamassassin actually works and filters out spam emails. It is only the RBL part of spamassassin that is not working, the rest is all working fine. Spamassassin/spamd is most likely looking at the wrong header line.
That can't be completely true: I'm using fetchmail and my spamassassin is using some rbl tests and catching spam that way. Look at a report (edited to avoid false triggers - I hope):
pts rule name description ---- ---------------------- -------------------------------------------------- 0.9 URI_NOVOWEL URI: URI hostname has long non-vowel sequence 5.0 BAYES_99 BODY: Bayesian spam probability is 99 to 100% [score: 1.0000] 1.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [169.207.88.67 listed in dnsbl.sorbs.net] 1.0 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP [169.207.88.67 listed in combined.njabl.org] 1.6 URIBL_SBL Contains an URL listed in the SBL blocklist [URIs: emerseddm dot com] 4.1 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist [URIs: emerseddm dot com] 2.1 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist [URIs: emerseddm dot com] 3.0 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist [URIs: emerseddm dot com] 4.5 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist [URIs: emerseddm dot com]
Notice that the scoring is a bit unfair: one url is scoring several times for the same motive.
Notice also that I have downgraded some scores, like the one for dynamic addresses: after all, I use one myself.
The thing is, the IP that SA checks is the one in the "Return-Path" header: <taxqlnsu at as14.nwbl1.wi.core.com>. The absurd thing is that it is not in fact a dynamic address:
cer@nimrodel:~> host as14.nwbl1.wi.core.com as14.nwbl1.wi.core.com has address 169.207.80.56 cer@nimrodel:~> host 169.207.80.56 56.80.207.169.in-addr.arpa domain name pointer as14.nwbl1.wi.core.com.
It has correct reverse DNS, can't be dynamic. But dnsbl.sorbs.net says it is.
The reverse lookup and spam listing of sorbs are two different kettle of fish. #nslookup 56.80.207.169.dnsbl.sorbs.net Server: 192.168.1.186 Address: 192.168.1.186#53 ** server can't find 56.80.207.169.dnsbl.sorbs.net: NXDOMAIN Not listed in sorbs and nslookup 169.207.80.56 Server: 192.168.1.186 Address: 192.168.1.186#53 Non-authoritative answer: 56.80.207.169.in-addr.arpa name = as14.nwbl1.wi.core.com. vs # nslookup 132.25.97.84.dnsbl.sorbs.net Server: 192.168.1.186 Address: 192.168.1.186#53 Non-authoritative answer: Name: 132.25.97.84.dnsbl.sorbs.net Address: 127.0.0.10 Listed in sorbs and Reverse lookup: nslookup 84.97.25.132 Server: 192.168.1.186 Address: 192.168.1.186#53 Non-authoritative answer: 132.25.97.84.in-addr.arpa name = 132.25.97-84.rev.gaoland.net the reverese lookup of both addresses succeeds, one is listed in sorbs, the other is not. This helped me understanding the problem better, but I still don't know how to fix it, how to force spamassassin to look at the very first received line like Received: from unknown (HELO keatingjones.com) (84.97.25.132) by anchovy2.45ru.net.au with SMTP; 9 Jul 2006 13:36:23 -0000 I know this was actually accepted by my ISP but I still would like spamassassin to look at it. Thanks Peter
Peter Sutter wrote:
On Thursday 13 July 2006 08:03, Carlos E. R. wrote:
The Wednesday 2006-07-12 at 18:28 +0200, Sandy Drobic wrote:
The basic understanding how smtp communication and restrictions work. You can't have fetchmail and RBLs both. Either you use fetchmail, accept all mail and discard or mark and deliver the mail, or you accept mails directly submitted to your server and then you can use RBLs, Postfix restrictions and all the luxury of your own smtp server.
You can't have the cake and eat it at the same time. (^-^)
Yes, I understand that, and from the logs, quite clearly, fetchmail retrieves the mail, hands it to procmail, which hands it to spamassassin (actually spamd) which then returns either spam or not spam to sendmail. Therefore the mail is always from the local server, which is trusted by sendmail. I have to download the message first before I can analyse it, I don't mind doing that, I just don't want to deliver it to the mailboxes if it is spam.
Spamassassin actually works and filters out spam emails. It is only the RBL part of spamassassin that is not working, the rest is all working fine. Spamassassin/spamd is most likely looking at the wrong header line.
Okay, do you see any other networked part of Spamassassin work? In other words, is Spamassassin set to use local tests only? I am not using Spamassassin directly, it is called from within amavisd-new, and the setting responsible for network tests is: $sa_local_tests_only = 0; # default in Suse 9.2 If you are using amavisd-new, then it would help a lot to see what settings you have defined for amavisd-new: grep -v ^# /etc/amavisd.conf | egrep -v ^$ | egrep -v "^ +#" Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Thursday 13 July 2006 10:24, Sandy Drobic wrote:
Peter Sutter wrote:
On Thursday 13 July 2006 08:03, Carlos E. R. wrote:
The Wednesday 2006-07-12 at 18:28 +0200, Sandy Drobic wrote:
The basic understanding how smtp communication and restrictions work. You can't have fetchmail and RBLs both. Either you use fetchmail, accept all mail and discard or mark and deliver the mail, or you accept mails directly submitted to your server and then you can use RBLs, Postfix restrictions and all the luxury of your own smtp server.
You can't have the cake and eat it at the same time. (^-^)
Yes, I understand that, and from the logs, quite clearly, fetchmail retrieves the mail, hands it to procmail, which hands it to spamassassin (actually spamd) which then returns either spam or not spam to sendmail. Therefore the mail is always from the local server, which is trusted by sendmail. I have to download the message first before I can analyse it, I don't mind doing that, I just don't want to deliver it to the mailboxes if it is spam.
Spamassassin actually works and filters out spam emails. It is only the RBL part of spamassassin that is not working, the rest is all working fine. Spamassassin/spamd is most likely looking at the wrong header line.
Okay, do you see any other networked part of Spamassassin work? In other words, is Spamassassin set to use local tests only?
I am not using Spamassassin directly, it is called from within amavisd-new, and the setting responsible for network tests is:
$sa_local_tests_only = 0; # default in Suse 9.2
If you are using amavisd-new, then it would help a lot to see what settings you have defined for amavisd-new:
grep -v ^# /etc/amavisd.conf | egrep -v ^$ | egrep -v "^ +#"
Sandy
Thanks, Sandy I am not using amavisd-new, I could never get it to work under SuSE 9.2. I invoke spamc via procmailrc. I guess, the RBL part of spamassassin is actually working, since running spamassassin -D --lint produces debug: all '*To' addrs: debug: RBL: success for 1 of 1 queries debug: running meta tests; score so far=2.077 at the very end of the report. Peter -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-07-13 at 18:41 +0800, Peter Sutter wrote:
I am not using amavisd-new, I could never get it to work under SuSE 9.2. I invoke spamc via procmailrc.
In 9.3 it was activated in /etc/mail/spamassassin/v310.pre, I think: loadplugin Mail::SpamAssassin::Plugin::Pyzor loadplugin Mail::SpamAssassin::Plugin::SpamCop But I think there was some configuration somewhere else :-? Ah, yes! Look at /etc/sysconfig/spamd, variable SPAMD_ARGS or SPAMD_OPTS. By default it has "-d -c -L", and the "L" stands for local tests only. Remove it, and restart spamd. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEtis0tTMYHG2NR9URAtlnAJ9POsfabHrVbznN1fSxgYpN1SRUWACfX2rA 71UvnD0yXk/ny4ihVu9tkdw= =xByg -----END PGP SIGNATURE----- -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Thursday 13 July 2006 19:14, Carlos E. R. wrote:
The Thursday 2006-07-13 at 18:41 +0800, Peter Sutter wrote:
I am not using amavisd-new, I could never get it to work under SuSE 9.2. I invoke spamc via procmailrc.
In 9.3 it was activated in /etc/mail/spamassassin/v310.pre, I think:
loadplugin Mail::SpamAssassin::Plugin::Pyzor loadplugin Mail::SpamAssassin::Plugin::SpamCop
But I think there was some configuration somewhere else :-?
Ah, yes! Look at /etc/sysconfig/spamd, variable SPAMD_ARGS or SPAMD_OPTS. By default it has "-d -c -L", and the "L" stands for local tests only. Remove it, and restart spamd.
-- Cheers, Carlos E. R. Thanks Carlos,
This is the setting that I overlooked. spamassassin -D --lint reported debug: RBL: success for 1 of 1 queries So this is working in spamassassin, but when spamd is instructed by the -L switch to do local test only, no wonder that it does not do RBL lookups. Thank you very much for the solution of my problem Peter -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Peter Sutter wrote:
I am trying to get rbl filtering of my incoming mail. I tried to configure sendmail to do rbl checks, but since I dislike opening the smtp port on my router, I decided to use fetchmail to periodically poll my external mail sources, and use spamassassin for rbl checks.
Unfortunately this doe not work for me for some reason.
As which user does spamd daemon run (check your /etc/sysconfig/spamd, look for -u parameter)? This was the reason for my many sleepless nights recently. My spamd runs as user "nobody". When the daemon is started, it tries to write a "spamd.pid" file to /var/run. But since user "nobody" cannot write to this directory, everything worked OK, except for RBLDNS checking. To solve this I had to edit /etc/rc.d/spamd and change PIDFILE parameter to /var/tmp/spamd.pid. The interesting part is that if I started spamd in debug mode (-D) as user "nobody", RBLDNS worked, problem only occures when running spamd as a daemon. HTH robert -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
participants (6)
-
Carlos E. R. -
Ian Marlier -
Patrick Shanahan -
Peter Sutter -
Robert Manfreda -
Sandy Drobic