Re: DNS checks not being performed-
Hello Axb, Wednesday, November 12, 2014, 12:21:19 PM, you wrote: A is your SA 3.4 working now? A after all this noise it would be rewarding to see some success. Yes... as of this morning- [root@nitrogen tmp]# cd /usr/lib/perl5/site_perl/5.8.8/IO/Socket/ [root@nitrogen Socket]# ls INET6.pm IP.pm [root@nitrogen Socket]# mv IP.pm IP.pm.bak [root@nitrogen Socket]# service spamassassin restart Stopping spamd:[ OK ] Starting spamd:[ OK ] [root@nitrogen Socket]# tail -F /var/log/maillog Nov 24 09:35:51 nitrogen spamd[27412]: spamd: connection from 127.0.0.1 [127.0.0.1]:55728 to port 783, fd 5 Nov 24 09:35:51 nitrogen spamd[27412]: spamd: setuid to spamtest succeeded Nov 24 09:35:51 nitrogen spamd[27412]: spamd: processing message 3010060773.20141124093...@gmail.com for spamtest:1028 Nov 24 09:35:51 nitrogen spamd[27412]: dns: checking RBL bl.spamcop.net., set spamcop Nov 24 09:35:51 nitrogen spamd[27412]: dns: IPs found: full-external: 74.125.82.43, 46.33.145.131, 74.125.82.43 untrusted: 74.125.82.43, 46.33.145.131 originating: 74.125.82.43 Nov 24 09:35:51 nitrogen spamd[27412]: dns: only inspecting the following IPs: 74.125.82.43 Nov 24 09:35:51 nitrogen spamd[27412]: dns: bgsend, DNS servers: [127.0.0.1]:53 Nov 24 09:35:51 nitrogen spamd[27412]: dns: attempt 1/1, trying connect/sendto to [127.0.0.1]:53 Nov 24 09:35:51 nitrogen spamd[27412]: dns: connect_sock, resolver: yes Nov 24 09:35:51 nitrogen spamd[27412]: dns: LocalAddr: 0.0.0.0, name server(s): [127.0.0.1]:53 Nov 24 09:35:51 nitrogen spamd[27412]: dns: 53959 configured local ports for DNS queries Nov 24 09:35:51 nitrogen spamd[27412]: dns: resolver socket rx buffer size is 129024 bytes, local port 43431 Nov 24 09:35:51 nitrogen spamd[27412]: dns: providing a callback for id: 819/IN/TXT/43.82.125.74.bl.spamcop.net Nov 24 09:35:51 nitrogen spamd[27412]: dns: checking RBL rbl.holtain.net., set holtrbl-lastexternal Nov 24 09:35:51 nitrogen spamd[27412]: dns: IPs found: full-external: 74.125.82.43, 46.33.145.131, 74.125.82.43 untrusted: 74.125.82.43, 46.33.145.131 originating: 74.125.82.43 Nov 24 09:35:51 nitrogen spamd[27412]: dns: only inspecting the following IPs: 74.125.82.43 Nov 24 09:35:51 nitrogen spamd[27412]: dns: bgsend, DNS servers: [127.0.0.1]:53 Nov 24 09:35:51 nitrogen spamd[27412]: dns: attempt 1/1, trying connect/sendto to [127.0.0.1]:53 Nov 24 09:35:51 nitrogen spamd[27412]: dns: providing a callback for id: 63936/IN/A/43.82.125.74.rbl.holtain.net Nov 24 09:35:51 nitrogen spamd[27412]: dns: checking RBL zen.spamhaus.org., set zen-lastexternal Nov 24 09:35:51 nitrogen spamd[27412]: dns: IPs found: full-external: 74.125.82.43, 46.33.145.131, 74.125.82.43 untrusted: 74.125.82.43, 46.33.145.131 originating: 74.125.82.43 Nov 24 09:35:51 nitrogen spamd[27412]: dns: only inspecting the following IPs: 74.125.82.43 Nov 24 09:35:51 nitrogen spamd[27412]: dns: bgsend, DNS servers: [127.0.0.1]:53 Nov 24 09:35:51 nitrogen spamd[27412]: dns: attempt 1/1, trying connect/sendto to [127.0.0.1]:53 Nov 24 09:35:51 nitrogen spamd[27412]: dns: providing a callback for id: 32738/IN/A/43.82.125.74.zen.spamhaus.org Nov 24 09:35:51 nitrogen spamd[27412]: dns: checking RBL dnsbl.sorbs.net., set sorbs-lastexternal Nov 24 09:35:51 nitrogen spamd[27412]: dns: IPs found: full-external: 74.125.82.43, 46.33.145.131, 74.125.82.43 untrusted: 74.125.82.43, 46.33.145.131 originating: 74.125.82.43 Nov 24 09:35:51 nitrogen spamd[27412]: dns: only inspecting the following IPs: 74.125.82.43 Nov 24 09:35:51 nitrogen spamd[27412]: dns: bgsend, DNS servers: [127.0.0.1]:53 Nov 24 09:35:51 nitrogen spamd[27412]: dns: attempt 1/1, trying connect/sendto to [127.0.0.1]:53 Nov 24 09:35:51 nitrogen spamd[27412]: dns: providing a callback for id: 28967/IN/A/43.82.125.74.dnsbl.sorbs.net Nov 24 09:35:51 nitrogen spamd[27412]: dns: checking RBL dnsbl.sorbs.net., set sorbs Nov 24 09:35:51 nitrogen spamd[27412]: dns: IPs found: full-external: 74.125.82.43, 46.33.145.131, 74.125.82.43 untrusted: 74.125.82.43, 46.33.145.131 originating: 74.125.82.43 Nov 24 09:35:51 nitrogen spamd[27412]: dns: only inspecting the following IPs: 74.125.82.43 Nov 24 09:35:51 nitrogen spamd[27412]: dns: checking RBL bl.mailspike.net., set mspikeb-lastexternal Nov 24 09:35:51 nitrogen spamd[27412]: dns: IPs found: full-external: 74.125.82.43, 46.33.145.131, 74.125.82.43 untrusted: 74.125.82.43, 46.33.145.131 originating: 74.125.82.43 Nov 24 09:35:51 nitrogen spamd[27412]: dns: only inspecting the following IPs: 74.125.82.43 Nov 24 09:35:51 nitrogen spamd[27412]: dns: bgsend, DNS servers: [127.0.0.1]:53 Nov 24 09:35:51 nitrogen spamd[27412]: dns: attempt 1/1, trying connect/sendto to [127.0.0.1]:53 Nov 24 09:35:51 nitrogen spamd[27412]: dns: providing a callback for id: 14193/IN/A/43.82.125.74.bl.mailspike.net Nov 24 09:35:51 nitrogen spamd[27412]: dns: checking RBL
Re: Honeypot email addresses
On Sat, 22 Nov 2014 15:32:26 -0600 (CST) Dave Funk wrote: Another way to seed spamtrap addresses is to make up some and then feed them into unsubscribe links in spam sent to regular users. I've got some of those I started that way 15 years ago and they're still going strong. Isn't there a danger that you get lower-grade spam that way, if spammers avoid unsubscribed addresses in their snowshoe lists.
Re: Honeypot email addresses
Am 24.11.2014 um 13:51 schrieb RW:
On Sat, 22 Nov 2014 15:32:26 -0600 (CST)
Dave Funk wrote:
Another way to seed spamtrap addresses is to make up some and
then feed them into unsubscribe links in spam sent to regular
users. I've got some of those I started that way 15 years ago
and they're still going strong.
Isn't there a danger that you get lower-grade spam that way, if spammers
avoid unsubscribed addresses in their snowshoe lists.
?php
$file = file(__DIR__ . '/unsub.txt');
foreach($file as $line)
{
$line = trim($line);
if(!empty($line))
{
$line = str_replace('[email]', md5(microtime() . $line) .
'@honeypot-domain.tld', $line);
echo $line;
usleep(1000);
$out = @file_get_contents($line);
if(!empty($out))
{
echo ': OK' . \n;
}
else
{
echo ': FAILED' . \n;
}
}
}
?
signature.asc
Description: OpenPGP digital signature
Re: could not create IO::Socket::IP socket on [127.0.0.1]:783: Address already in use
Tom Schulz wrote: Here is my debug output. It looks like the socket is created for 127.0.0.1 and then an attempt is also made for ::1. That fails as expected. But in my case that failure causes a retry that includes retrying for 127.0.0.1. This now fails because the port has already been created (as noted in the error message). Retries then continue until the retry limit is reached. dbg: spamd: socket module of choice: IO::Socket::IP 0.32, Socket 2.013, have PF_INET, have PF_INET6, using Socket::getaddrinfo, AI_ADDRCONFIG is supported dbg: spamd: socket specification: localhost, IP address: localhost, port: 783 dbg: spamd: attempting to listen on IP addresses: 127.0.0.1, ::1, port 783 dbg: spamd: creating IO::Socket::IP socket: Listen: 128, LocalAddr: 127.0.0.1, LocalPort: 783, Proto: tcp, ReuseAddr: 1, Type: 2, V6Only: 1 dbg: spamd: creating IO::Socket::IP socket: Listen: 128, LocalAddr: ::1, LocalPort: 783, Proto: tcp, ReuseAddr: 1, Type: 2, V6Only: 1 server socket setup failed, retry 1: spamd: could not create IO::Socket::IP socket on [::1]:783: Cannot assign requested address dbg: spamd: attempting to listen on IP addresses: 127.0.0.1, ::1, port 783 dbg: spamd: creating IO::Socket::IP socket: Listen: 128, LocalAddr: 127.0.0.1, LocalPort: 783, Proto: tcp, ReuseAddr: 1, Type: 2, V6Only: 1 server socket setup failed, retry 2: spamd: could not create IO::Socket::IP socket on [127.0.0.1]:783: Address already in use dbg: spamd: attempting to listen on IP addresses: 127.0.0.1, ::1, port 783 dbg: spamd: creating IO::Socket::IP socket: Listen: 128, LocalAddr: 127.0.0.1, LocalPort: 783, Proto: tcp, ReuseAddr: 1, Type: 2, V6Only: 1 server socket setup failed, retry 3: spamd: could not create IO::Socket::IP socket on [127.0.0.1]:783: Address already in use Thanks, that explains how we get to 'Address already in use'. This opens up a couple of questions: - creating a socket listening on '::' apparently does work (it is tested in the BEGIN phase, and reported by 'have PF_INET6'), but creating a socket listening on '::1' (i.e. a loopback address) fails. Are you running spamd in jail? Does a loopback interface have an IPv6 address assigned? Is it '::1'? Or if you think the IPv6 is not supported on that host, why then does creating a socket listening on '::' succeed? - why did it work with older versions of perl and modules - this chain of events shows that the logic in server_sock_setup_inet() and/or its caller is flawed. When multiple sockets are to be created and not all succeed, we'd need to undo the successfully created sockets before bailing out on error - or alternatively, make do with partially fulfilling the request. Please open up a ticket on the bugzilla. Mark
Re: Honeypot email addresses
On Sun, 23 Nov 2014 11:12:58 +0100 Aban Dokht ml...@abando.de wrote: From my opinion, this is not a good idea as you are going to put those servers onto your list. This way you'll blacklist bulk senders, with badly configured or even not bounce management, but they are not all spammers! Oh, sure! Let's tolerate incompetent mass mailers. While we're at it, let's tolerate sites that can't properly manage their mail servers. And don't forget open relays, too! Just because they can't figure out how to make it work or are too lazy to do it right, we must excuse them. And, Free Speech, right? No, let's not accomodate incompetent bulk mailers. It has never worked before. All it does is allow them to continue to make excuses to fail to do their job properly and it attracts spammers, politicians and other such ilk. Spammers always take advantage of negligent and incompetent mail admins. Blacklist, blocklist badly behaving mailservers, whether known spammers or not. That is the standard policy everywhere. You really should try admin-ing a internet facing mail server for a while. You'll quickly realize that what you are saying here is totally insane. Hopefully before YOU go insane. jd
Re: Honeypot email addresses
Am 24.11.2014 um 18:49 schrieb jdebert: On Sun, 23 Nov 2014 11:12:58 +0100 Aban Dokht ml...@abando.de wrote: From my opinion, this is not a good idea as you are going to put those servers onto your list. This way you'll blacklist bulk senders, with badly configured or even not bounce management, but they are not all spammers! Oh, sure! Let's tolerate incompetent mass mailers. While we're at it, let's tolerate sites that can't properly manage their mail servers. And don't forget open relays, too! Just because they can't figure out how to make it work or are too lazy to do it right, we must excuse them. And, Free Speech, right? nobod said that but you need to draw a line between catch spam and force to catch any sender you don't know why and how the address went to the RCPT that's far from the reality i see again and again *living humans* continue to send to their outdated best-friends list from the MUA just because they don't understand a bounce, don't care enough or even be afraid remove somebody from his address book based on *not* understood automatic mail (bounce) as tech user i don't understand that users behavior at the same time i, we and our server did *nothing* wrong and if you setup a spam trap to catch that senders you just blacklist for no good reason *frankly* a lot of reject messages are just too stupid for a automated bounce mamagement because some smart ass felt good by use non.default messages where even persons like me sit there wit no clue if this is a temporary local error at the RCPT too stupid reply with a 4xx code and so better *not remove it* automated the world is not black and white and by *blindly* blacklist you gain nothing than damage signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
On 25/11/2014 03:49, jdebert wrote: No, let's not accomodate incompetent bulk mailers. It has never worked before. All it does is allow them to continue to make excuses to fail to do their job properly and it attracts spammers, politicians and other such ilk. Spammers always take advantage of negligent and incompetent mail admins. Blacklist, blocklist badly behaving mailservers, whether known spammers or not. That is the standard policy everywhere. Exactly, those that care, quickly realise their error and correct their setup, those that don't, clearly don't care, so we don't care about them, why should we. Just like vmware in my case, it's only to me as far as I know, so I ignore it, but one day I might just have a few too many beers and change that ;)
Re: Honeypot email addresses
On Sun, 23 Nov 2014, Reindl Harald wrote:
Am 23.11.2014 um 11:17 schrieb Aban Dokht:
On 22.11.2014 22:32, Dave Funk wrote:
Another way to seed spamtrap addresses is to make up some and
then feed them into unsubscribe links in spam sent to regular
users. I've got some of those I started that way 15 years ago
and they're still going strong.
Also no good idea, as some of them will send an unsubscribe mail to the
trap then. The risk of false positives is very high
using real addresses as a honeypot is wrong, dangerous and reckless
also there is no need for playing with firebecause by use virgin addresses
and not promote them visible or even subcribe them to porn newsletters (don't
laugh i heard proposals register a address to all porn newsletters you can
find and then start blacklisting)
if you want to block all newsletters then just do it, you don't need to play
honeypot-games for that!
I guess I need to elaborate to make it clear exactly what I do and why there
is little to no danger of FPs.
When I said to make up some (spamtrap addresses) I mean make up some -new-
addresses that can -never- be used as legitmate user addresses.
In our organization we have some specific address formats that we use for
various purposes (first-l...@domain.name shortn...@sub.domain.name
service_addr...@domain.name ). However we also have some reserved address
spaces within those formats (which are administrativly enforced) so I can
create some addresses that look like first-l...@domain.name but which I know
will never be used for real purposes (but the spammers won't know which they
are). I use those addresses for spamtrap addresses. (no danger of FPs there).
I then feed those particular spamtrap addresses into the unsubscribe links of
hand-verified spam. So only spammers will ever see those addresses anyplace
outside of our infrastructure. Thus they should almost never FP.
The only way that I can see any possibility of FPs is if a spammer is using
a semi-legit MSP and that MSP sends an unsubscribe-verify message to that
spam-trap address. That should only happen a few times at most and should -not-
have any new spam assocated with it.
So any spam sent to that spamtrap address is fair game.
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
