Re: blacklists
--On Saturday, December 11, 2004 10:50 +1100 Craig Sanders <[EMAIL PROTECTED]> wrote: diff -u ??? I'll attach privately the diff's from your version ( CVS) Now that's a heck of a tactic LOL :) oh yes, i forgot the most amusing thing about it. it not only sent it to a subset of the spammer database, it also used random addresses out of that db as the envelope and header sender addresses, so that they'd complain at each other. So it's your fault they figured out the forged MAIL FROM trick! Bad craig, no donut! ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: blacklists
--On Friday, December 10, 2004 17:01 -0700 Michael Loftis <[EMAIL PROTECTED]> wrote: --On Saturday, December 11, 2004 10:50 +1100 Craig Sanders <[EMAIL PROTECTED]> wrote: diff -u ??? I'll attach privately the diff's from your version ( CVS) Actually as it turns out I can't send mail directly to you, something about my @modwest.com address is apprently offensive to your mailserver... 550 Sender access denied for [EMAIL PROTECTED] -- I sent a second one from my home address but it won't get delivered or bounced for a while since I'm not likely being blocked at your firewall ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: blacklists
On Fri, Dec 10, 2004 at 05:01:33PM -0700, Michael Loftis wrote: > So it's your fault they figured out the forged MAIL FROM trick! Bad > craig, no donut! ;) no, many of them already knew that. it was obvious anyway. craig -- craig sanders <[EMAIL PROTECTED]> (part time cyborg) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: blacklists
On Fri, Dec 10, 2004 at 11:20:28AM -0700, Michael Loftis wrote: > >i certainly wouldn't recommend running it on a large installation. > >i'm surprised you even tried. > > Well, we're very anti-spam, and willing ot try anything to help...I > had to disable it after we got around ~8K rules in the tables on that > box, that ended up causing the system CPU time to go through the roof. > Though it was very effective. :) i guess what it needs is something that can merge addresses into a CIDR range. e.g. if it sees x.y.z.1 through to .8, it should merge them all into a /29. delete the individual /32 rules and replace them with the /29. managing that would get fairly complicated, especially when it has to later merge a few /29s and /32s into larger blocks. but it should be doable. if i get time, i'll think about how that might be implemented. the simpler thing is to just uncomment the /24 stuff that's already in there, and block the entire /24 rather than just the offending host. heavy-handed but it should reduce the number of entries in iptables. hmmm. one useful optimisation here would be to use Net::DNS to find out whether the IP is in a DUL - and if it is, then block the entire /24. i reject all mail direct from dynamic/dialups anyway so it wouldn't hurt anything. (and remember to add your own dialup pools to @whitelist :) another thing it should do is add the rules to a SPAMMERS table, rather than to the main INPUT table. that would be a trivial change, only a few minutes work. ...done. new version now published: # v1.8 - changed to use SPAMMERS table rather than INPUT. # use --syn when adding iptables rules, to avoid hanging smtpd processes # # the SPAMMERS table should be set up like this (BEFORE this script is run): # # # create SPAMMERS table # iptables -F SPAMMERS # iptables -X SPAMMERS # iptables -N SPAMMERS # # # send all INPUT & FORWARD packets to the SPAMMERS table # iptables -I INPUT -j SPAMMERS # iptables -I FORWARD -j SPAMMERS # # FORWARD rule needed only on gateway/router boxes, not normal hosts. # # you could optionally create a SPAMDROP table too, which logged the packet # with a "SPAMMERS" prefix before dropping itbut that kind of defeats the # purpose of this script which is to remove spammer noise from the logs. > I've made a few modifications already, including making everything > persistent and making it purge SEEN entries after not seeing a host > for 24hrs (this also effectively caps any block time to being 24hrs). > I might just set it so that it only watches our MailScanner and blocks > the IPs it reports as sending virii. That would probably help to > shrink the number of reports a lot, and help with my virus load. > That'd be a good site-wide table to share (we use central mysql maps a > lot). diff -u ??? > >one of the things i wrote was a script which i could bounce spam to. > >it would then parse the sender addresses and add it to a database of > >spammersand sent copies of each spam to a random subset of the > >database. that infuriated them and amused me no end. my intention > > Now that's a heck of a tactic LOL :) oh yes, i forgot the most amusing thing about it. it not only sent it to a subset of the spammer database, it also used random addresses out of that db as the envelope and header sender addresses, so that they'd complain at each other. craig -- craig sanders <[EMAIL PROTECTED]> (part time cyborg) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: blacklists
Am 2004-12-09 19:04:49, schrieb Richard Zuidhof: > Michelle Konzack wrote: > cbl.abuseat.org is included in xbl.spamhaus.org so it is not needed to > use both. If you use sbl.spamhaus.org I do not see why not to use sbl-xbl.spamhaus.org had never FP > bl.spamcop.net as well. Both have some collateral damage and false I had used spamcop.net but gotten to much FP. > Richard Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: blacklists
--On Friday, December 10, 2004 22:48 +1100 Craig Sanders <[EMAIL PROTECTED]> wrote: On Thu, Dec 09, 2004 at 11:18:16PM -0700, Michael Loftis wrote: --On Friday, December 10, 2004 16:43 +1100 Craig Sanders <[EMAIL PROTECTED]> wrote: > DoS is a huge exaggeration. a few smtpd processes waiting to timeout > does not constitute a DoS. neither does a few dozen. I had about 800 waiting around in just a few minutes on the one server I began testing it on, but this is a large installation. And this isn't peak time...It's holding at around 1000 blocked hosts, most of them for blacklist infractions. i certainly wouldn't recommend running it on a large installation. i'm surprised you even tried. Well, we're very anti-spam, and willing ot try anything to help...I had to disable it after we got around ~8K rules in the tables on that box, that ended up causing the system CPU time to go through the roof. Though it was very effective. :) i run it on my home system at the moment. i wouldn't run it at work. I've made a few modifications already, including making everything persistent and making it purge SEEN entries after not seeing a host for 24hrs (this also effectively caps any block time to being 24hrs). I might just set it so that it only watches our MailScanner and blocks the IPs it reports as sending virii. That would probably help to shrink the number of reports a lot, and help with my virus load. That'd be a good site-wide table to share (we use central mysql maps a lot). i experiment with lots of things on my home system that i wouldn't even think of doing at work. some of them, very few, actually turn out to be worthwhile and safe enough to use at work. Same here. try dropping only SYN smtp packets if you still want to experiment with it, adding "--syn" to the end of the iptables args in the scripts. that should stop the hanging processes. Yeah. Last night when I wrote back my brain was a bit mushy, couldn't think of the right option so I just said it should probably be changed :) unfortunately, my domain seems to attract a lot of junk. i've had my domain for over 10 years, and kept the same email address all along. and i've been joe-jobbed many times over the last decade by spammers who don't like me (or my anti-spam methods, or the fact that i share them openly), and i've had thousands of bogus, non-existant addresses in my domain added to spam lists also by spammers who don't like me. the current crop of spammers probably don't even notice or care, but in the early days of spam it was different. spammers got very offended and took it personally...which, of course, was excellent incentive to keep on blocking them :) I'm glad you share them. Spammers are criminals, pure and simple, they're stealing our time, resources, and our users time and resources and money. They have no place in the world. Heck, I'm all for capitol(or is it al? I can't remember) punishment for spammers. (see short disclaimer.h at the bottom of this message) i pissed off quite a few in the very early days, when spammers didn't hide their identities and hadn't yet learned not to use their own address. one of the things i wrote was a script which i could bounce spam to. it would then parse the sender addresses and add it to a database of spammersand sent copies of each spam to a random subset of the database. that infuriated them and amused me no end. my intention was to annoy them at least as much as their MMF or green card or whatever spam had annoyed me. unfortunately that stopped being a viable tactic fairly quickly, and it certainly wouldn't scale to anything like the spam load of today (back then 1 or 2 spams every few days was a lot. now i wouldn't even notice it). Now that's a heck of a tactic LOL :) too bad I didn't' think of it back then...although I had a firewall setup for the longest time at home that automatically did counter-recon of offenders, and if it determined common open holes would get in and attempt shut the system off. It was always satisfying to watch a zombie get halfway through a portscan, then just disappear. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EHLO/HELO [was blacklists]
On Friday 10 December 2004 09:36, Mark Bucciarelli wrote: > (1) If SPF HELO checking is on and lookup matches connecting IP > --> PASS [..] > Otherwise, return 517 HELO $hostname does not match $remote-ip Sorry to reply to myself, but this sequence is more complicated if SPF checking is turned on and the SPF lookup fails. You can choose to softfail (417) or hardfail (517). I wanted to set the record straight. Regards, Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EHLO/HELO [was blacklists]
[CC'ing Bill Taroli who has been helping me with this on courier-user] On Friday 10 December 2004 07:08, Russell Coker wrote: > On Friday 10 December 2004 00:39, Mark Bucciarelli > <[EMAIL PROTECTED]> > > wrote: > > I've recently turned on EHLO/HELO validation and am encouraged by how > > effective it is. WIth RBL's (spamcop and dnsbl) and SpamAssassin 3, > > only 88% of spam was stopped. So far, it's 100%. (This is a _very_ > > small > > What exactly do you mean by EHLO/HELO validation? The courier man page just says "verify the hostname provided in the ESTMP EHLO/HELO statement." From reading the code, here's what it does: (0) If connecting IP addresses is in the checkhelo whitelist --> PASS (1) If SPF HELO checking is on and lookup matches connecting IP --> PASS (2) If HELO host name is a numeric IP and it matches connecting IP --> PASS (3) Lookup MX records for HELO hostname. If one matches connecting IP --> PASS (4) Lookup A records for hostname. If one matches connecting IP --> PASS Otherwise, return 517 HELO $hostname does not match $remote-ip If there is an RFC1035_MX_HARDERR or RFC1035_MX_BADDNS when looking up the MX record, return a 517. If the MX or A DNS lookup fails, return a 417. > In my postfix configuration I have: > smtpd_helo_restrictions = permit_mynetworks, > reject_non_fqdn_hostname, reject_unknown_sender_domain > > I tried out "reject_unknown_hostname" but had to turn it off, too many > machines had unknown hostnames. I find it interesting that postfix defaults the response code to 450 instead of a 5XX for this failure. This is along the lines that I have been thinking. > For example a zone foo.com has a SMTP server named postfix1 and puts > postfix1.foo.com in the EHLO command but has an external DNS entry of > smtp.foo.com. Such a zone is moderately well configured and there are > too many such zones to block them all. The other helo restrictions get > enough non-spam traffic. > > Using reject_unknown_hostname would get close to blocking 100% of spam, > but that's because it would block huge amounts of non-spam email. So I guess the questions are: (1) Given a log entry (hostname and connecting IP) of an EHLO reject, can I reliably figure out if the host was valid? (2) Can I do this quickly enough that my whitelist will be updated before their MTA stops retrying and customers start complaining? (3) Will the whitelist stabilize enough over time to make this worth it. (4) Would it be possible to build a secure data pool where a group of like-minded and trusted admins could share whitelisted connecting IP's. Regards, Mark
Re: EHLO/HELO [was blacklists]
On Fri, Dec 10, 2004 at 11:08:53PM +1100, Russell Coker wrote: > I tried out "reject_unknown_hostname" but had to turn it off, too many > machines had unknown hostnames. > > For example a zone foo.com has a SMTP server named postfix1 and puts > postfix1.foo.com in the EHLO command but has an external DNS entry of > smtp.foo.com. Such a zone is moderately well configured and there are > too many such zones to block them all. The other helo restrictions get > enough non-spam traffic. actually, it's not "moderately well configured". it's trivial to add a DNS entry for "postfix1.foo.com" (preferably an A record and not a CNAME - doesn't matter for HELO/EHLO but it does matter for $myorigin). it's even more trivial to make the postfix server announce itself with a real hostname, one that actually exists in the DNS - "smtp.foo.com" would be perfect. that's all it takes to get past reject_unknown_hostname. it's unusual to see this level of cluelessness with someone running a unix MTA - i thought it was reserved to Exchange and Groupwise users. > Using reject_unknown_hostname would get close to blocking 100% of > spam, nowhere near that much. it helps a little, but it's not even remotely close to the final solution to spam. > but that's because it would block huge amounts of non-spam email. that's not the case in my experience (but that depends on exactly what kind of mail traffic is received). but it's your server, you get to choose what rules are on it. craig ps: yes, this is another rule i use at home but not at work. there are lots of windows MTAs out there run by the clueless. fortunately, at home i don't need or have to communicate with them, but at work there are many people who might. -- craig sanders <[EMAIL PROTECTED]> (part time cyborg) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: EHLO/HELO [was blacklists]
On Friday 10 December 2004 00:39, Mark Bucciarelli <[EMAIL PROTECTED]> wrote: > I've recently turned on EHLO/HELO validation and am encouraged by how > effective it is. WIth RBL's (spamcop and dnsbl) and SpamAssassin 3, only > 88% of spam was stopped. So far, it's 100%. (This is a _very_ small What exactly do you mean by EHLO/HELO validation? In my postfix configuration I have: smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_sender_domain I tried out "reject_unknown_hostname" but had to turn it off, too many machines had unknown hostnames. For example a zone foo.com has a SMTP server named postfix1 and puts postfix1.foo.com in the EHLO command but has an external DNS entry of smtp.foo.com. Such a zone is moderately well configured and there are too many such zones to block them all. The other helo restrictions get enough non-spam traffic. Using reject_unknown_hostname would get close to blocking 100% of spam, but that's because it would block huge amounts of non-spam email. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MailScanner with Sendmail
Penbrock wrote: > Thanks alot I now have MailScanner scanning all my messages :). How ever I > have one minor(?) problem, sendmail movers messages to the mqueue.in , > MailScanner scans them and moves them to the /mqueue like it should,... > but the messages just sit there. Do I now need to change procmail? You need to start a queuerunner on that particular queuedirectory. Something like: sendmail -oQ/var/spool/mqueue -q (assuming that mqueue is in /var/spool). Try running this manually first and add the -v flag to see what's happening. After that you can either do queueruns from cron using the same command line or start another sendmail daemon (-bd -q15m) process. Regards, Henk > > > > -Original Message- > From: Matt Collier [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 07, 2004 5:22 AM > To: [EMAIL PROTECTED] > Subject: Re: MailScanner with Sendmail > > > On Tuesday 07 December 2004 00:23, Penbrock wrote: > > I am a newbie trying to learn our office servers so I have put a system > up > > at home just like the ones our office uses for the ISP servers. I am > > trying to play around to find better ways to work things and I have come > > across MailScanner. I think I have it all installed on my testing system > > how ever I can not find any Doc's on how to tell Sendmail to start > calling > > MailScanner. Can anyone help me out here or direct me to some doc's on > > using it on a Debian server with Sendmail? > > > > Thanks for any direction you can give this old MS user trying to learn > > Linux > > > > Ken > > You'll need to tell sendmail to just queue the mail for delivery, not > actually > deliver it. > > in /etc/mail/sendmail.conf, you'll something like: > DAEMON_PARMS="-bd -OPrivacyOptions=noetrn -ODeliveryMode=queueonly > -OQueueDirectory=/var/spool/mqueue.in"; > > then get Mailscanner to pick up the mail from the queue, scan it, and put > it > back into sendmail's delivery queue. > > in /etc/MailScanner/MailScanner.conf: > Incoming Queue Dir = /var/spool/mqueue.in > Outgoing Queue Dir = /var/spool/mqueue > > sendmail doesn't directly call mailscanner, both run as separate processes > and > just put the necessary files where the other can find them, > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- Henk Roose - [EMAIL PROTECTED] CWI - Centrum voor Wiskunde en Informatica Centre for Mathematics and Computer Science Amsterdam (NL) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: blacklists
On Thu, Dec 09, 2004 at 11:18:16PM -0700, Michael Loftis wrote: > --On Friday, December 10, 2004 16:43 +1100 Craig Sanders > <[EMAIL PROTECTED]> wrote: > > >DoS is a huge exaggeration. a few smtpd processes waiting to timeout > >does not constitute a DoS. neither does a few dozen. > > I had about 800 waiting around in just a few minutes on the one server > I began testing it on, but this is a large installation. And this > isn't peak time...It's holding at around 1000 blocked hosts, most of > them for blacklist infractions. i certainly wouldn't recommend running it on a large installation. i'm surprised you even tried. i run it on my home system at the moment. i wouldn't run it at work. i experiment with lots of things on my home system that i wouldn't even think of doing at work. some of them, very few, actually turn out to be worthwhile and safe enough to use at work. try dropping only SYN smtp packets if you still want to experiment with it, adding "--syn" to the end of the iptables args in the scripts. that should stop the hanging processes. > But when you've got a lot of mail (and a number of customer domains > that just tend to attract junk) it's easy to get a lot of processes > hanging around. unfortunately, my domain seems to attract a lot of junk. i've had my domain for over 10 years, and kept the same email address all along. and i've been joe-jobbed many times over the last decade by spammers who don't like me (or my anti-spam methods, or the fact that i share them openly), and i've had thousands of bogus, non-existant addresses in my domain added to spam lists also by spammers who don't like me. the current crop of spammers probably don't even notice or care, but in the early days of spam it was different. spammers got very offended and took it personally...which, of course, was excellent incentive to keep on blocking them :) i pissed off quite a few in the very early days, when spammers didn't hide their identities and hadn't yet learned not to use their own address. one of the things i wrote was a script which i could bounce spam to. it would then parse the sender addresses and add it to a database of spammersand sent copies of each spam to a random subset of the database. that infuriated them and amused me no end. my intention was to annoy them at least as much as their MMF or green card or whatever spam had annoyed me. unfortunately that stopped being a viable tactic fairly quickly, and it certainly wouldn't scale to anything like the spam load of today (back then 1 or 2 spams every few days was a lot. now i wouldn't even notice it). craig ps: anyone know if MMF spams still happen? i haven't seen one for years. could be my body checks rules block them all, or maybe they've just given up since 419 scams are more lucrative. -- craig sanders <[EMAIL PROTECTED]> (part time cyborg) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is gray-listing a one-shot anti-spam measure?
On Tuesday 07 December 2004 20.41, mimo wrote: > Russell Coker wrote: > >On Friday 03 December 2004 20:07, Adrian 'Dagurashibanipal' von Bidder > ><[EMAIL PROTECTED]> wrote: > >>(And - this to Stephen Frost, I believe - there is a patch to postgrey > >>which I will include in the next version, and I believe which will also > >> be included in the next upstream, to whitelist a client IP as soon as > >> one greylisted email came through. So the load on legitimate > >> mailservers will be even smaller.) > > > >As has already been suggested it would be good to be able to configure > > the number of messages that come through before the client IP is > > white-listed. > But I think the > problem of this would be that initial messages would be even more > delayed, depending on the sending server, than they are with normal > one-shot greylisting. I think you misunderstand Russel. He does, afaict, not want the initial message be rejected multiple times, but he wants to see several messages coming through, with normal greylisting in effect, before the IP is whitelisted for all email. greetings -- vbi -- No caemos de sÃbito en la muerte, sino que a ella vamos minuto a minuto. -- SÃneca. (2 a.C-65) FilÃsofo latino.
