Re: Getting spamass-milter to work with postfix
Am 10.11.19 um 16:55 schrieb Linkcheck: I've tried altering things but the best I can get is the message: "warning: connect to Milter service unix:/var/run/spamass/spamass.sock: No such file or directory" This is the socket the spamass-milter daemon has to create for postfix to communicate with. No matter how I start postfix and spamassassin, /var/run/spamass remains empty but spamassassin.pid is rewritten to /var/run. I am restarting using: sudo service postfix restart sudo service spamassassin restart I suspect is not spass-milter is not being started? You did not start/restart spamass-milter? Start/Restart spamass-milter and look for the socket it has created: lsof There should be something like this in the output: spamass-m 1711 spamass-milter 4u unix 0x88003aaf0400 0t0 18591 /var/run/spamass/spamass.sock type=STREAM That's the socket for your postfix configuration (main.cf) smtpd_milters = unix:/var/run/spamass/spamass.sock [...] Best regards, Edda
Re: Problem with Horde IMP ans Spamassassin
Am 08.02.17 um 12:01 schrieb i...@lauf-forum.at: [...] What is the difference between the two mail headers? I don't see one. The only difference I can see ist, that the nonspam mail has only the IP of the sender in the header and the spam mail has also the reverse DNS entry of the IP in the header. The key difference is the transfer method: HTTP vs. HTTPS I tested it with spamassassin 3.4.0. With your original header, spamassassin parses the webmail client ip as untrusted: Feb 8 12:32:46.189 [2306] dbg: received-header: parsed as [ ip=212.186.35.163 rdns=212-186-35-163.cable.dynamic.surfer.at helo=212-186-35-163.cable.dynamic.surfer.at by=webmail.lauf-forum.at ident= envfrom= intl=0 id= auth= msa=0 ] Feb 8 12:32:46.189 [2306] dbg: received-header: do not trust any hosts from here on Feb 8 12:32:46.189 [2306] dbg: received-header: relay 212.186.35.163 trusted? no internal? no msa? no If I change only HTTPS to HTTP in the first received header, thus: Received: from 212-186-35-163.cable.dynamic.surfer.at (212-186-35-163.cable.dynamic.surfer.at [212.186.35.163]) by webmail.lauf-forum.at (Horde Framework) with HTTP; Tue, 07 Feb 2017 21:57:06 + spamassassin gets it (see the auth=HTTP): Feb 8 12:56:16.627 [2735] dbg: received-header: parsed as [ ip=212.186.35.163 rdns=212-186-35-163.cable.dynamic.surfer.at helo=212-186-35-163.cable.dynamic.surfer.at by=webmail.lauf-forum.at ident= envfrom= intl=0 id= auth=HTTP msa=0 ] Feb 8 12:56:16.627 [2735] dbg: received-header: authentication method HTTP Feb 8 12:56:16.627 [2735] dbg: received-header: relay 212.186.35.163 trusted? yes internal? yes msa? no With the correct parsing spamassassin identifies the relay correctly as trusted (ALL_TRUSTED fires for this mail) and therefore doesn't use 212.186.35.163 for IP checks. It's a parsing error in spamassassin. I don't know wether it's fixed in 3.4.1. Best regards, Edda
Re: question re/ RDNS_NONE
Am 25.11.15 um 15:56 schrieb RW:. 3. You have no test for dynamic rDNS why that when SA makes the dns request and so have a rDNS? Because, as far as I can see, the patch doesn't make the rDNS available to SA's other tests, it just supplies a stand-alone test for no-rDNS. Correct. I don't know how easy it would be to fix that *properly* because the relay information is expected to be complete very early in the scan, before any DNS results return. It should be possible to shift some of the header tests so they can identify dynamic rDNS, but until then BOTNET will do it. I thought on doing the check in Received.pm, i.e. exactly one rdns lookup, if the header of the last external lacks rdns. That would add the rdns information to the pseudo headers (like Relays-External, and Untrusted), where the SpamAssassin rules are based on. But this would also result in waiting for this request, if it must be done, before all received headers were parsed. I don't see another way, maybe someone else...? Then, I saw that all dns lookups were deleted from Received.pm in version 3.2.x, see https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5054 Reasons cited: - (a) it's slow - (b) it's the wrong place to do that; header-parsing should not incur network accesses - (c) it results in differing results, depending on if local_tests_only is on or not. Remark: 3.1.x retrieved every rDNS for all Untrusted Relays, even if they were retrieved from the headers already. They didn't trust the headers at all. Because dns checks are "not allowed" in Received.pm, I built a patch for the single check. The actually patch (in DNSEval.pm) could make the result (rdns exists or not) available for further checks, but that would result in more work on the rules ... and looks like an ugly workaround... .. I would prefer to do this ONE rdns lookup in Received.pm, and only if necessary. Opinions? Edda
Re: question re/ RDNS_NONE
Am 25.11.15 um 09:55 schrieb Matthias Apitz:
El día Tuesday, November 24, 2015 a las 08:27:45PM +0100, Edda escribió:
I have found the bug in your patch, just a spelling issue:
pop:Mail eh$ diff -u SpamAssassin/Plugin/DNSEval.pm.ORG
SpamAssassin/Plugin/DNSEval.pm
--- SpamAssassin/Plugin/DNSEval.pm.ORG2015-11-24 19:02:58.0
+0100
+++ SpamAssassin/Plugin/DNSEval.pm2015-11-24 19:25:59.0 +0100
@@ -58,6 +58,7 @@
'check_rbl_from_host',
'check_rbl_from_domain',
'check_rbl_envfrom',
+'check_dsn_rdns',
^^
'check_dns_sender',
];
@@ -373,6 +374,25 @@
}
}
+sub check_dns_rdns {
^^
Ouch, sorry, i tested it on 3.3.1 and "re-typed" that line in 3.4.1
Does the patch work for you?
Edda
Re: question re/ RDNS_NONE
Am 24.11.15 um 21:03 schrieb John Hardin: On Tue, 24 Nov 2015, Reindl Harald wrote: i would suggest when the Received header for the *first* untrusted hop Just so we're clear on first vs. last: the host that submitted the mail to the most-remote MTA whose headers you trust. don't contain a reverse dns information *and only then* do that lookup directly in SA if network tests are enabled This seems to me a reasonable approach. There's no need to check RDNS on hops prior to the final untrusted hop (chronologically speaking). Thank you both for your clarification. I agree and this is exactly what my patch does. Edda
Re: question re/ RDNS_NONE
Am 24.11.15 um 14:40 schrieb Matthias Apitz:
El día Tuesday, November 24, 2015 a las 01:47:23PM +0100, Reindl Harald
escribió:
On 24.11.15 13:24, Reindl Harald wrote:
on the other hand why can't SA not do the lookup for the IP of
"Received: from [140.211.11.3]" given that it does a lot of dns
lookups anyway?
just because of that - to limit the number of outgoing DNS requests and
focus on that haven't been done before. That's why SA uses existing
headers
like Received: and Received-SPF:
[...]
If someone would have a patch for this, I'd be happy to help testing.
Older versions performed rdns lookups for every IP in relay-untrusted
directly in Received.pm, this was deleted:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=5054
The attached patch adds one dns request, in fact that rdns is empty and
the mta is known (via Received.pm) to not always add one.
I added the check as another eval in DNSEval.pm. This seems
straightforward.
Then I realized, that Spamassassin doesn't catch the DNS responses from
its Resolver in a very generic way. It catches only RBL returns and, as
a hack for a specific rule, a special MX/A record.
Therefore I had to change Dns.pm as well, which I'm not happy with it ;)
Btw. I think it works also for __CGATE_RCVD and __DOMINO_RCVD, i.e. for
all mtas, that decline to add rdns themselves.
The BOTNET plugin performs it's reverse lookup in a primitive way on
it's own. IMO it's better to use the Spamassassin Resolver, but more
generic, for the existing NO_DNS_FOR_FROM rule and for the RDNS_NONE one.
Any suggestions are welcome.
Edda
Anyway, for the moment, here's the patch, diff is on version 3.4.1:
Rule (I tested it as a simple rule in local.cf, sure one can combine it
with RDNS_NONE):
ifplugin Mail::SpamAssassin::Plugin::DNSEval
header NO_RDNS_FOR_LAST_EXTERNAL eval:check_dns_rdns()
describe NO_RDNS_FOR_LAST_EXTERNALLast External really has no rdns
tflags NO_RDNS_FOR_LAST_EXTERNAL net
score NO_RDNS_FOR_LAST_EXTERNAL 1.00
endif
pop:Mail eh$ diff -u SpamAssassin/Plugin/DNSEval.pm.ORG
SpamAssassin/Plugin/DNSEval.pm
--- SpamAssassin/Plugin/DNSEval.pm.ORG2015-11-24 19:02:58.0
+0100
+++ SpamAssassin/Plugin/DNSEval.pm2015-11-24 19:25:59.0 +0100
@@ -58,6 +58,7 @@
'check_rbl_from_host',
'check_rbl_from_domain',
'check_rbl_envfrom',
+'check_dsn_rdns',
'check_dns_sender',
];
@@ -373,6 +374,25 @@
}
}
+sub check_dns_rdns {
+ my ($self, $pms, $rule) = @_;
+
+ my $lasthop = $pms->{relays_external}->[0];
+ return 0 unless defined $lasthop;
+
+ # Perform reverse lookup only, if empty and mta is known to not
always insert rdns
+ return 0 unless (! $lasthop->{rdns} && $lasthop->{rdns_not_in_headers});
+
+ return 0 unless $pms->is_dns_available();
+ $pms->load_resolver();
+
+ dbg("dns: checking rDNS for last external ip $lasthop->{ip}");
+
+ $pms->do_dns_lookup($rule, 'PTR', $lasthop->{ip});
+
+ return 0;
+}
+
sub check_dns_sender {
my ($self, $pms, $rule) = @_;
pop:Mail eh$ diff -u SpamAssassin/Dns.pm.ORG SpamAssassin/Dns.pm
--- SpamAssassin/Dns.pm.ORG2015-11-24 19:01:59.0 +0100
+++ SpamAssassin/Dns.pm2015-11-24 19:02:39.0 +0100
@@ -257,6 +257,12 @@
for my $rule (@{$rules}) {
$self->got_hit($rule, "DNS: ", ruletype => "dns");
}
+ } elsif ($question->qtype =~ /^(PTR)$/ &&
+ $packet->header->rcode =~ /^(?:NXDOMAIN|SERVFAIL)$/)
+ {
+for my $ptr_rule (@{$rules}) {
+ $self->got_hit($ptr_rule, "DNS: ", ruletype => "dns");
+}
}
# DNSBL tests are here
Re: question re/ RDNS_NONE
Am 23.11.15 um 10:33 schrieb Matthias Apitz: What should I fix exactly if apache.org triggers this RDNS_NONE: $ fgrep RDNS_NONE /tmp/apache.d nov 23 08:30:06.666 [2204] dbg: rules: ran header rule __RDNS_NONE ==> got hit: "[ ip=140.211.11.3 rdns= " you can find the full -D output of such a mail here: http://www.unixarea.de/apache.d.txt Just looked at your -D output. Your configuration is correct as 140.211.11.3 is correctly identified as Last External. RDNS_NONE uses the pseudo header X-Spam-Relays-External and the pseudo headers are filled up with information from the Received headers, not from real DNS lookups. Take a look at the "dbg: received-header" and "dbg: metadata" lines in your debug output or at Received.pm. nov 23 08:30:06.182 [2204] dbg: received-header: parsed as [ ip=140.211.11.3 rdns= helo=mail.apache.org by=ms-10.1blu.de ident= envfrom=users-return-110371-guru=unixarea...@spamassassin.apache.org intl=0 id=1a0c7H-0003WU-3m auth= msa=0 ] ... nov 23 08:30:06.187 [2204] dbg: metadata: X-Spam-Relays-External: [ ip=140.211.11.3 rdns= helo=mail.apache.org by=ms-10.1blu.de ident= envfrom=users-return-110371-guru=unixarea...@spamassassin.apache.org intl=0 id=1a0c7H-0003WU-3m auth= msa=0 ] ... The received header added by your ISP misses the hostname, therefore RDNS_NONE hits on every mail: Received: from [140.211.11.3] (helo=mail.apache.org) by ms-10.1blu.de with smtp (Exim 4.76)
