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. Mail is still being handled by our backup server but the primary is now back in situ Well the server was sitting on our dining table last week having the RAID1 array kicked. I took the time while that was going on to yum remove spamassassin and build from source which reported optional module out of date IO::Socket::IP but given that it wasn't connected to the world I didn't try anything at that time. FWIW sa-update -D shows Nov 22 04:23:02.139 [8364] dbg: diag: [...] module installed: IO::Socket::IP, version 0.32 and- yum search perl | grep -i io-socket perl-IO-Socket-INET6.noarch : Perl Object interface for AF_INET|AF_INET6 domain perl-IO-Socket-SSL.noarch : Perl library for transparent SSL -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgpSHtQl8AX0C.pgp Description: PGP signature
Re: DNS checks not being performed-
Hello Reindl, Tuesday, November 11, 2014, 7:52:10 PM, you wrote: RH perl-5.8.8-43.el5_11.x86_64 is part of 5.11 RH this is completly untested and unsupported CentOS 5.11 Axb's yum update -y was done and I'm seeing- Package 4:perl-5.8.8-43.el5_11.x86_64 already installed and latest version but I see- -- Running transaction check --- Package perl.i386 4:5.8.8-43.el5_11 set to be updated -- Finished Dependency Resolution Should I accept this install? -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgp2H1MrJwzDB.pgp Description: PGP signature
Re: Honeypot email addresses
On 22.11.2014 22:05, Ted Mittelstaedt wrote: That's a lot of work, there's a much easier way Just search your /var/log/maillog for user unknown messages, and create email addresses for the unknown users which are showing up multiple times over multiple days. It's a great trick because it gets spammers who already have email addresses in their spamlists and who are too lazy to remove them when they get a user unknown message from the mailserver. I have a pretty old domain - I've seen user unknown messages for users who cancelled mailboxes on the domain over a decade ago. I figure 10 years of getting user unknown messages is long enough for any real humans and for legitimate mailing lists to remove those entries. 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! -- Aban Dokht aban.do...@abando.de system administrator of 0 day abusers DNSBL bl.dbrs.de -- pgpVnKwYd7_9s.pgp Description: PGP signature
Re: DNS checks not being performed-
Am 23.11.2014 um 10:58 schrieb Niamh Holding: Hello Reindl, Tuesday, November 11, 2014, 7:52:10 PM, you wrote: RH perl-5.8.8-43.el5_11.x86_64 is part of 5.11 RH this is completly untested and unsupported CentOS 5.11 Axb's yum update -y was done and I'm seeing- Package 4:perl-5.8.8-43.el5_11.x86_64 already installed and latest version but I see- -- Running transaction check --- Package perl.i386 4:5.8.8-43.el5_11 set to be updated -- Finished Dependency Resolution Should I accept this install? *lease* start to post complete outputs instead pack them in your own words to help others helping you signature.asc Description: OpenPGP digital signature
Re: Honeypot email addresses
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. -- Aban Dokht aban.do...@abando.de system administrator of 0 day abusers DNSBL bl.dbrs.de -- pgpOQC7Hzd4xM.pgp Description: PGP signature
Re: DNS checks not being performed-
Hello Axb, Wednesday, November 12, 2014, 12:38:00 PM, you wrote: A yum install A http://pkgs.repoforge.org/perl-Net-DNS/perl-Net-DNS-0.71-1.el5.rfx.x86_64.rpm yum install perl-Net-DNS shows- Loading mirror speeds from cached hostfile * base: repo.bigstepcloud.com * epel: mirror.bytemark.co.uk * extras: anorien.csc.warwick.ac.uk * rpmforge: mirror.vit.com.tr * updates: mirror.as29550.net Setting up Install Process Package perl-Net-DNS-0.59-3.el5.x86_64 already installed and latest version So do we have a unanimous opinion on installing v0.71 from repoforge? 10 days ago I'd have just gone and done it, but with so many differing opinions... -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgpUTgyNVcxD_.pgp Description: PGP signature
Re: DNS checks not being performed-
Hello Reindl, Sunday, November 23, 2014, 10:15:50 AM, you wrote: RH *lease* start to post complete outputs instead pack them in your own RH words to help others helping you The missing stuff! Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: repo.bigstepcloud.com * epel: mirror.bytemark.co.uk * extras: anorien.csc.warwick.ac.uk * rpmforge: mirror.vit.com.tr * updates: mirror.as29550.net Setting up Install Process Resolving Dependencies -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgp6T7rCisQf0.pgp Description: PGP signature
Re: Honeypot email addresses
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! signature.asc Description: OpenPGP digital signature
Re: DNS checks not being performed-
Am 23.11.2014 um 11:28 schrieb Niamh Holding: Hello Reindl, Sunday, November 23, 2014, 10:15:50 AM, you wrote: RH *lease* start to post complete outputs instead pack them in your own RH words to help others helping you The missing stuff! Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: repo.bigstepcloud.com * epel: mirror.bytemark.co.uk * extras: anorien.csc.warwick.ac.uk * rpmforge: mirror.vit.com.tr * updates: mirror.as29550.net Setting up Install Process Resolving Dependencies i am out of this thread - you continue to strip the context out of quotes and this is *not* a complete, uncutted console input/output this would start and end with a prompt signature.asc Description: OpenPGP digital signature
Re: DNS checks not being performed-
Hello Reindl, Sunday, November 23, 2014, 10:15:50 AM, you wrote: RH pack them in your own RH words Further the original quotes are cut and paste and not IN MY OWN WORDS -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgp2PUIRR_mwv.pgp Description: PGP signature
Re: DNS checks not being performed-
Hello Reindl, Sunday, November 23, 2014, 10:32:36 AM, you wrote: RH i am out of this thread - you continue to strip the context out of RH quotes and this is *not* a complete, uncutted console input/output There is no point in posting superfluous stuff! Yum has clearly stated that Package 4:perl-5.8.8-43.el5_11.x86_64 already installed and latest version but -- Running transaction check --- Package perl.i386 4:5.8.8-43.el5_11 set to be updated -- Finished Dependency Resolution Now how does this crap help you, given that by asking the original question I obviously declined == Package Arch Version Repository Size == Installing: perl i386 4:5.8.8-43.el5_11updates 12 M Transaction Summary == Install 1 Package(s) Upgrade 0 Package(s) Total download size: 12 M Is this ok [y/N]: Exiting on user Command Complete!? -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgp4jkMdjG3YD.pgp Description: PGP signature
Re: DNS checks not being performed-
Am 23.11.2014 um 11:30 schrieb Niamh Holding: Hello Reindl, Sunday, November 23, 2014, 10:15:50 AM, you wrote: RH pack them in your own RH words Further the original quotes are cut and paste and not IN MY OWN WORDS you don't get it - the *context* is important and only visible by *any* output between enter yum whetever and the final prompt - you may think something is not important of that output and strip it - well, if you could say that you would not need to ask about signature.asc Description: OpenPGP digital signature
Re: DNS checks not being performed-
Am 23.11.2014 um 11:41 schrieb Niamh Holding: Hello Reindl, Sunday, November 23, 2014, 10:32:36 AM, you wrote: RH i am out of this thread - you continue to strip the context out of RH quotes and this is *not* a complete, uncutted console input/output There is no point in posting superfluous stuff! Yum has clearly stated that Package 4:perl-5.8.8-43.el5_11.x86_64 already installed and latest version but -- Running transaction check --- Package perl.i386 4:5.8.8-43.el5_11 set to be updated -- Finished Dependency Resolution Now how does this crap help you, given that by asking the original question I obviously declined == Package Arch Version Repository Size == Installing: perl i386 4:5.8.8-43.el5_11updates 12 M Transaction Summary == Install 1 Package(s) Upgrade 0 Package(s) Total download size: 12 M Is this ok [y/N]: Exiting on user Command Complete!? ah look how important the full output is - it's still missing the first line with the prompt but better (and yes i do not trust any user not strip some maybe helpful output until i see the prompt and command on top) looking 2 seconds on the output below (you stripped originally) and i see you system want to install i386 packages on a x86_64 setup and the question is: why what says rpm -qa | grep -i perl | sort and rpm -qa | grep i386? signature.asc Description: OpenPGP digital signature
Re: DNS checks not being performed-
Hello Reindl, Sunday, November 23, 2014, 10:49:01 AM, you wrote: RH looking 2 seconds on the output below (you stripped originally) The original pst included- Package perl.i386 4:5.8.8-43.el5_11 set to be updated RH i RH see you system want to install i386 packages on a x86_64 setup That information was there all along! RH the question is: why That's what promted me to ask whether to accept the offering! # rpm -qa | grep -i perl | sort mod_perl-2.0.4-6.el5 newt-perl-1.08-9.2.2 perl-5.8.8-43.el5_11 perl-Archive-Tar-1.39.1-1.el5_5.2 perl-BSD-Resource-1.28-1.fc6.1 perl-Compress-Zlib-1.42-1.fc6 perl-Convert-ASN1-0.20-1.1 perl-DBD-MySQL-3.0007-2.el5 perl-DBI-1.52-2.el5 perl-Digest-HMAC-1.01-15 perl-Digest-SHA1-2.11-1.2.1 perl-HTML-Parser-3.55-1.fc6 perl-HTML-Tagset-3.10-2.1.1 perl-IO-Socket-INET6-2.57-2.el5.rfx perl-IO-Socket-SSL-1.01-2.el5 perl-IO-Zlib-1.04-4.2.1 perl-libwww-perl-5.805-1.1.1 perl-NetAddr-IP-4.027-5.el5_6 perl-Net-DNS-0.59-3.el5 perl-Net-IP-1.25-2.fc6 perl-Net-SSLeay-1.30-4.fc6 perl-Socket6-0.19-3.fc6 perl-String-CRC32-1.4-2.fc6 perl-URI-1.35-3 # # rpm -qa | grep i386 # And I have stripped the IDs from the prompt! -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgpJUZ7mlhEDj.pgp Description: PGP signature
Re: DNS checks not being performed-
Hello Reindl, Sunday, November 23, 2014, 10:44:09 AM, you wrote: RH you don't get it - the *context* is important You don't get it in your own words is stating that I have rewritten the output myself and what I quoted was not was was on the screen! -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgpDWrVH6pfAb.pgp Description: PGP signature
Re: DNS checks not being performed-
Am 23.11.2014 um 12:03 schrieb Niamh Holding: Hello Reindl, Sunday, November 23, 2014, 10:49:01 AM, you wrote: RH looking 2 seconds on the output below (you stripped originally) The original pst included- Package perl.i386 4:5.8.8-43.el5_11 set to be updated i am working for a decace now with YUM and understand it's output RH i RH see you system want to install i386 packages on a x86_64 setup That information was there all along! honestly i stop to read if someone comes with fragemnts of yum output RH the question is: why That's what promted me to ask whether to accept the offering! the damage is already done if it's an update # rpm -qa | grep -i perl | sort mod_perl-2.0.4-6.el5 newt-perl-1.08-9.2.2 perl-5.8.8-43.el5_11 perl-Archive-Tar-1.39.1-1.el5_5.2 perl-BSD-Resource-1.28-1.fc6.1 perl-Compress-Zlib-1.42-1.fc6 perl-Convert-ASN1-0.20-1.1 perl-DBD-MySQL-3.0007-2.el5 perl-DBI-1.52-2.el5 perl-Digest-HMAC-1.01-15 perl-Digest-SHA1-2.11-1.2.1 perl-HTML-Parser-3.55-1.fc6 perl-HTML-Tagset-3.10-2.1.1 perl-IO-Socket-INET6-2.57-2.el5.rfx perl-IO-Socket-SSL-1.01-2.el5 perl-IO-Zlib-1.04-4.2.1 perl-libwww-perl-5.805-1.1.1 perl-NetAddr-IP-4.027-5.el5_6 perl-Net-DNS-0.59-3.el5 perl-Net-IP-1.25-2.fc6 perl-Net-SSLeay-1.30-4.fc6 perl-Socket6-0.19-3.fc6 perl-String-CRC32-1.4-2.fc6 perl-URI-1.35-3 # rpm -qa | grep i386 And I have stripped the IDs from the prompt! uhm looks like the old RHEL5 don't not include the arch in rpm outputs like perl-5.18.4-291.fc20.x86_64 or perl-Class-Singleton-1.4-16.fc20.noarch difficult to say - i fear you installed some incompatible stuff (educated guess by seeing even fc6 packages - that is FEDORA CORE) which pulled i386 deps, that happens when yum is out of ideas how to solve deps maybe you downloaded the i386 version of perl-Net-SSLeay and the other mess was the result - that's not a noarch package since here is perl-Net-SSLeay-1.55-4.fc20.x86_64 *maybe* you can try yum remove \*.i386 and note the complete outputs for safety and history to verify the setup and start again with correct packages signature.asc Description: OpenPGP digital signature
Re: DNS checks not being performed-
Am 23.11.2014 um 12:05 schrieb Niamh Holding: Hello Reindl, Sunday, November 23, 2014, 10:44:09 AM, you wrote: RH you don't get it - the *context* is important You don't get it in your own words is stating that I have rewritten the output myself and what I quoted was not was was on the screen! you missed *uncutted input and output* in your first reply today - that selective quoting is practically the same as own wording frankly your whole quoting style is just *rude* because your damned stripping anything away forces people to read the whole thread to understand posts (i even needed to go back to the archive of todays mails two times) but after seeing the mess with Fedora packages on CentOS and i386 nobody knows in wich context you confirmed a yum action normally evreyone would have crid NO i tell you something: * hire somebody with CentOS expierience * realize that this is *not* the mailing list for OS problems signature.asc Description: OpenPGP digital signature
Re: DNS checks not being performed-
Hello Reindl, Sunday, November 23, 2014, 11:21:56 AM, you wrote: RH frankly your whole quoting style is just *rude* That's damn rich! RH but after seeing the mess with Fedora packages on CentOS As you well know that was suggested by another list member! RH in wich context you confirmed a yum action I've already posted several times that I did as Axb suggested!, and it should be perfectly clear that by asking whether to accept perl.i386 4:5.8.8-43.el5_11 that I di not confirm that action! RH realize that this is *not* the mailing list for OS problems I guess only a dumb blonde would think it appropriate to ask about spamassassin not performing DNS checks on the spamassassin list -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgpRC366OmViN.pgp Description: PGP signature
Re: Emails with extremely long URLs
On Sat, Nov 22, 2014 at 07:16:38PM -0800, John Hardin wrote:
On Sat, 22 Nov 2014, Igor Chudov wrote:
I receive spam emails that contain extremely long URLs, about 2,400
characters. I wanted to know if spamassassin has a rule that I can
turn on to flag such URLs. I do not think that I ever receive
legitimate emails with URLs that long.
I don't think there's anything in the base rules but that should be
pretty simple:
uri URI_ABSURDLY_LONG /.{2000}/
Care to post a spample to pastebin?
Thanks. I do not currently have a sample. I will keep an eye on
them. They are MIME emails with junk plaintext content, and enormous
URLs in the html part.
Igor
Re: DNS checks not being performed-
Hello Reindl, Sunday, November 23, 2014, 11:15:27 AM, you wrote: RH he old RHEL5 CentOS 5 doesn't go end of life until 2017 RH seeing even fc6 packages Only if offered by- base: repo.bigstepcloud.com * epel: mirror.bytemark.co.uk * extras: anorien.csc.warwick.ac.uk * rpmforge: mirror.vit.com.tr * updates: mirror.as29550.net I do note that http://mirror.centos.org/centos/5/os/x86_64/CentOS/ has several FC6 rpms including http://mirror.centos.org/centos/5/os/x86_64/CentOS/perl-BSD-Resource-1.28-1.fc6.1.x86_64.rpm for example. So it seems that the suggestion that I have deliberately chosen to install bits of FC6 from a non-CentOS5 source in might be jumping to conclusions. RH maybe you downloaded the i386 version of perl-Net-SSLeay Or it's http://mirror.centos.org/centos/5/os/x86_64/CentOS/perl-Net-SSLeay-1.30-4.fc6.x86_64.rpm Not wasting bandwidth with the full output but yum list installed shows- perl-Net-SSLeay.x86_64 1.30-4.fc6 installed p -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgpM4SIFXnivR.pgp Description: PGP signature
Re: .co.at
On 22.11.14 20:22, Igor Chudov wrote: I have a special perl script, that I wrote, that scans emails, makes a WHOIS query via a perl WHOIS module, and looks at the creation date. this was already discussed and discouraged - you may get blocked at whois servers. DOB is a RBL created for this use. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I intend to live forever - so far so good.
Re: DNS checks not being performed-
Am 23.11.2014 um 14:11 schrieb Niamh Holding: RH realize that this is *not* the mailing list for OS problems I guess only a dumb blonde would think it appropriate to ask about spamassassin not performing DNS checks on the spamassassin list the spamassassin part of the issue was explained and anything above that is clearly off-list and frankly i have seen in the past very clear and hostile responses after SA-off-topic but at least spam relevant posts and even on a CentOS list that thread leads nowhere because a mailing list is simply the wrong medium for your issues - find somebody in IRC or so or even somebody offering you helping directly via SSH combined with a chat is for sure a better way signature.asc Description: OpenPGP digital signature
Re: DNS checks not being performed-
Hello Reindl, Sunday, November 23, 2014, 4:54:44 PM, you wrote: RH the spamassassin part of the issue was explained But no fix provided, as far as I'm concerned everything that follows is in pursuit of working DNS checks and when that is achieved then further discussion would indeed be off topic., Suggestions that one should have started from somewhere different are not exactly helpful in solving the original problem! -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgpVMKBf8ZxD0.pgp Description: PGP signature
Re: DNS checks not being performed-
Hello Reindl, Is you message supposed to contain some hidden meaningful information given that all it does it give some details of your setup? Tuesday, November 11, 2014, 2:55:41 PM, you wrote: RH Bignum.pm RH Am 11.11.2014 um 15:48 schrieb Niamh Holding: Hello Axb, Tuesday, November 11, 2014, 2:29:19 PM, you wrote: A SPAMDOPTIONS=-d -c -m5 -H -D dns A should do the trick... And a message logs- Nov 11 14:42:41 nitrogen spamd[29405]: logger: removing stderr method Nov 11 14:42:41 nitrogen spamd[29407]: Can't locate Crypt/OpenSSL/Bignum.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.8.8 /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/site_perl /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8) at /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/Crypt/OpenSSL/RSA.pm line 17. RH [root@localhost:~]$ rpm -q --file RH /usr/lib64/perl5/vendor_perl/Crypt/OpenSSL/Bignum.pm RH perl-Crypt-OpenSSL-Bignum-0.04-19.fc20.x86_64 Nov 11 14:42:42 nitrogen spamd[29407]: spamd: server started on IO::Socket::INET6 [127.0.0.1]:783, IO::Socket::INET6 [::1]:783 (running version 3.4.0) RH [root@localhost:~]$ rpm -qa | grep perl | grep -i socket RH perl-IO-Socket-SSL-1.955-2.fc20.noarch RH perl-IO-Socket-INET6-2.71-3.fc20.noarch RH perl-Socket6-0.25-1.fc20.x86_64 RH perl-Socket-2.016-1.fc20.x86_64 RH perl-IO-Socket-IP-0.30-2.fc20.noarch RH [root@mail-gw:~]$ yum info perl-IO-Socket-IP RH Geladene Plugins: protectbase, tsflags RH 0 packages excluded due to repository protections RH Installierte Pakete RH Name : perl-IO-Socket-IP RH Architektur : noarch RH Version: 0.30 RH Ausgabe: 2.fc20 RH Größe : 88 k RH Quelle : installed RH Zusammenfassung: Drop-in replacement for IO::Socket::INET supporting RH both IPv4 and IPv6 RH URL: http://search.cpan.org/dist/IO-Socket-IP/ RH Lizenz : GPL+ or Artistic RH Beschreibung: This module provides a protocol-independent way to use RH IPv4 and IPv6 RH : sockets, as a drop-in replacement for IO::Socket::INET. RH Most constructor RH : arguments and methods are provided in a RH backward-compatible way. -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgp9spV2DV_zc.pgp Description: PGP signature
Re: .co.at
On 24/11/2014 01:18, Matus UHLAR - fantomas wrote: On 22.11.14 20:22, Igor Chudov wrote: I have a special perl script, that I wrote, that scans emails, makes a WHOIS query via a perl WHOIS module, and looks at the creation date. this was already discussed and discouraged - you may get blocked at whois servers. DOB is a RBL created for this use. Some people just enjoy re-inventing wheels :) The fact its worked this long tells me his server aint all that busy.
Re: Emails with extremely long URLs
On 24/11/2014 00:07, Igor Chudov wrote:
On Sat, Nov 22, 2014 at 07:16:38PM -0800, John Hardin wrote:
On Sat, 22 Nov 2014, Igor Chudov wrote: I receive spam emails that contain
extremely long URLs, about 2,400 characters. I wanted to know if spamassassin
has a rule that I can turn on to flag such URLs. I do not think that I ever
receive legitimate emails with URLs that long. I don't think there's anything
in the base rules but that should be pretty simple: uri URI_ABSURDLY_LONG
/.{2000}/ Care to post a spample to pastebin?
Thanks. I do not currently have a sample. I will keep an eye on
them. They are MIME emails with junk plaintext content, and enormous
URLs in the html part.
Igor
As dumb, stupid, and ridiculous as it sounds, 2K chars is actually a
perfectly valid URL value
IIRC, most browsers accept up to 2100 or there abouts, but to put such a
URL in an email, would be asking for spam :)
Re: Honeypot email addresses
On 23/11/2014 20:12, Aban Dokht wrote: On 22.11.2014 22:05, Ted Mittelstaedt wrote: domain - I've seen user unknown messages for users who cancelled mailboxes on the domain over a decade ago. I figure 10 years of getting user unknown messages is long enough for any real humans and for legitimate mailing lists to remove those entries. 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! Surely though that is the senders problem. Also any sender - SOHO, medium or large business, government, or mass mailing specialists, who have no, poor, or broken bounce management, do deserve to be listed, to prompt them into getting their act together and fixing their code. Yes it happens, VMware are a perfect example of this incompetence, they still try send to an old list address of mine before I consolidated the 2 into this one, they have been getting user unknowns for about 8 years.
Re: Emails with extremely long URLs
On 11/22/2014 07:16 PM PST, John Hardin wrote:
On Sat, 22 Nov 2014, Igor Chudov wrote:
I receive spam emails that contain extremely long URLs, about 2,400
characters. I wanted to know if spamassassin has a rule that I can
turn on to flag such URLs. I do not think that I ever receive
legitimate emails with URLs that long.
I don't think there's anything in the base rules but that should be
pretty simple:
uri URI_ABSURDLY_LONG /.{2000}/
There was a similar request on Stack Overflow
https://stackoverflow.com/questions/26478828/spamassassin-regex-to-catch-long-url
recently. It had the extra requirement of satisfying TLDs that SA uri
rules cannot yet extract from bodies, but the stats I gave are actually
based on uri rules.
An excerpt from my answer on 2014/11/13:
That will technically work, though I'm sure you'll find it fires on a
LOT of non-spam, marketing mail in particular [...]
No size range is going to have a terribly good spam:ham ratio (an S/O
https://wiki.apache.org/spamassassin/HitFrequencies#The_S.2FO_Ratio,
aka precision https://en.wikipedia.org/wiki/Precision_and_recall, of
0.900 is possibly acceptable, but you really want to be closer to
1.000). By my tests, the best range is 192-256 characters, but even
that is too weak (S/O of 0.862 in my data) to be terribly useful.
There is almost no spam using a link with over 1024 characters (S/O of
0.057 for me).
That S/O is still true (it's S/O is now 0.054 and its spam hit rate
remains below 0.01%). At 2000+ chars, the S/O is still quite low, as
are the independent volumes of spam and ham. Volume of all mail
containing 1024+ character URLs has increased slightly in the past few
months, from roughly 0.10% to 0.15%. This increase has been slightly
more among ham than spam.
signature.asc
Description: OpenPGP digital signature
Re: Honeypot email addresses
On 11/23/2014 2:12 AM, Aban Dokht wrote: On 22.11.2014 22:05, Ted Mittelstaedt wrote: That's a lot of work, there's a much easier way Just search your /var/log/maillog for user unknown messages, and create email addresses for the unknown users which are showing up multiple times over multiple days. It's a great trick because it gets spammers who already have email addresses in their spamlists and who are too lazy to remove them when they get a user unknown message from the mailserver. I have a pretty old domain - I've seen user unknown messages for users who cancelled mailboxes on the domain over a decade ago. I figure 10 years of getting user unknown messages is long enough for any real humans and for legitimate mailing lists to remove those entries. 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! Who are you I've never seen you post on this list before. You sound like a spammer who is scared to death that more people will be putting up honeypots. A bulk sender with no bounce management is a spammer, PERIOD. I'll gladly invite any customer of mine who insists on receiving email from bulk senders who don't do bounce management to go find another email provider. Strange that I have NEVER had a customer complain about this. I am VERY familiar with Gmails rules and Hotmail/Microsoft's rules for bulk senders to send mail into their network. They mandate that anyone sending bulk mail to them IS REQUIRED to do bounce management or they will block them, end of story. I am quite willing to accept mail from bulk mailers who follow CAN-SPAM act in the United States - which by the way REQUIRES bounce management - bulk mailers who do NOT do bounce management are committing a felony in the United States. Ted
Re: Honeypot email addresses
On 11/23/2014 2:17 AM, Aban Dokht wrote: 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. If a bulk mailer is legitimate then they will do 2 things, first they will verify that the email listed in the unsubscribe request exists on their mailing list, (and if not, ignore it) and second when they get a de-list request they should IMMEDIATELY honor it. They should NEVER send a confirmation email. Sending an email saying we just de-listed you because of your de-list request is perfectly fine and if it was an accidental de-list the user can merely resubscribe. But a de-list request should be honored immediately. If they can't do that, then they are just setting up barriers to unsubscribe email addresses from their lists, and that is what a spammer does. We have a saying in the United States, Aban. If it looks like a duck, walks like a duck, and quacks like a duck, it's a duck. Ted
