Re: Blocking spam by IP number
Bruce Perens [EMAIL PROTECTED] writes: By the way, I return an error message rather than simply delaying the connection until it times out because under the Electronic Communications and Privacy Act it is unlawful to intercept electronic mail without an indication to the sender. From: Carey Evans [EMAIL PROTECTED] How would this apply to kernel firewalling (leaving aside that I live in NZ)? Would reject be OK and deny not? An immediate reject would be fine. The most important thing (to a U.S. user) is to inform _all_ users that you do not guarantee reliable delivery of e-mail and that you do not guarantee that nobody will read their e-mail. You might even want to put this in your /etc/motd. This will remove some of your liability under the ECPA. However, even once you have done that, you can go to jail for intercepting the e-mail of one of your users and preventing it from being delivered without informing the other party. Most writers of anti-spam software are blissfully ignorant of this. Thus, do not cause it to time out in the message queue. Return an SMTP error immediately, so that the other party is informed of non-delivery. Bruce -- Can you get your operating system fixed when you need it? Linux - the supportable operating system. http://www.debian.org/support.html Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Blocking spam by IP number
This kind of information would look good on our web site. On Sat, 16 Aug 1997, Bruce Perens wrote: Bruce Perens [EMAIL PROTECTED] writes: By the way, I return an error message rather than simply delaying the connection until it times out because under the Electronic Communications and Privacy Act it is unlawful to intercept electronic mail without an indication to the sender. From: Carey Evans [EMAIL PROTECTED] How would this apply to kernel firewalling (leaving aside that I live in NZ)? Would reject be OK and deny not? An immediate reject would be fine. The most important thing (to a U.S. user) is to inform _all_ users that you do not guarantee reliable delivery of e-mail and that you do not guarantee that nobody will read their e-mail. You might even want to put this in your /etc/motd. This will remove some of your liability under the ECPA. However, even once you have done that, you can go to jail for intercepting the e-mail of one of your users and preventing it from being delivered without informing the other party. Most writers of anti-spam software are blissfully ignorant of this. Thus, do not cause it to time out in the message queue. Return an SMTP error immediately, so that the other party is informed of non-delivery. Bruce -- Can you get your operating system fixed when you need it? Linux - the supportable operating system. http://www.debian.org/support.html Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- -- Until we extend the circle of our compassion to all living things, we will not ourselves find peace -Albert Schweitzer Richard G. Roberto -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Blocking spam by IP number
On Fri, 15 Aug 1997, Remco van de Meent wrote: On Fri, 15 Aug 1997, Craig Sanders wrote: : that's one of the reasons i prefer packet filtering to : tcp-wrappers. block it out in the kernel before it gets to the : application level. Hmm.. I don't agree with you on your last sentence. Why should the kernel take care of something which has absolutely nothing to do with the kernel itself? because some sites/networks send nothing but spamso it's simpler, faster, and less cpu/disk/memory load to just block their packets. packet filtering with firewall rules does the same thing as tcp wrappers, but it works regardless of which MTA is in use. For other sites, spam-filtering in the MTA and/or delivery agent (e.g. using procmail's system-wide /etc/procmailrc) is more appropriate. Blocking mail is something that, imho, the MTA should do. That is, the MTA handles 'mail', like the kernel handles 'packets'. And the spam is in the 'mail', not in the 'packets'. Do you understand what I mean? yes, i certainly understand what you mean. i also understand that there are scumbags out there who have paid for net connections with the sole purpose of sending junk mail. i don't want to ever receive any email from these vermin, and i want my system to waste as little time as possible processing their garbage. : can any of the MTAs reject mail based on arbitrary headers? or even just : the To: header (e.g. To: [EMAIL PROTECTED])? Nope. At least none I'm aware of. : I know i can do this easily enough with procmail (in fact, I do), but : IMO this is a job for the mail transfer agent, not the delivery agent. I don't have an opinion on this. I'd like to have it done in the MTA so that I am not tied to procmail (or any delivery agent, for that matter). I use something like the following in /etc/procmailrc to catch most junkmail which slips through my packet filtering and sendmail envelope filtering: VERBOSE=OFF LOGFILE=/root/Mail/from-all LOCKFILE=$HOME/.lockmail # marketing dickheads think that people are impressed by # personalisation like '[EMAIL PROTECTED]'. :0 * [EMAIL PROTECTED] /root/Mail/probable.junkmail :0 E * [EMAIL PROTECTED] /root/Mail/probable.junkmail # X-UID and X-UIDL seem to only occur on spam messages, so block # any message containing them. :0 E * ^X-UID: /root/Mail/probable.junkmail :0 E * ^X-UIDL: /root/Mail/probable.junkmail # some junkmailers are starting to use an X-Advertisement header. # i wish they'd all do it...makes filtering out spam a bit easier. :0 E * ^X-Advertisement: /root/Mail/probable.junkmail Anything which gets through this is caught in my personal ~/.procmailrc. DEFAULT=$HOME/mail/potential-junkmail in ~/.procmailrc delivers all mail which isn't caught by a rule to my potential-junkmail folder. I have rules to sort mail into different folders according to mailing list, to address, from address, subject, and other rules. I also have a final rule which delivers mail directly addressed to me to /var/spool/mail/cas - anything not sent to one of my known mailing lists and not sent to me personally is probably junkmail. I could just send it to /dev/null instead of ~/mail/potential-junkmail but occasionally i get BCC-ed legitimate mail which i don't want to lose. -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Blocking spam by IP number
Blocking mail is something that, imho, the MTA should do. That is, the MTA handles 'mail', like the kernel handles 'packets'. And the spam is in the 'mail', not in the 'packets'. Do you understand what I mean? Unfortunately, there is no known textual mechanism that can reliably reject spam. However, you can reliably deny connectivity from AGIS network (a known spam haven) to your socket 25. I choose to do that with a user-mode program, Craig does it with a kernel facility, but the effect is the same. By the way, I return an error message rather than simply delaying the connection until it times out because under the Electronic Communications and Privacy Act it is unlawful to intercept electronic mail without an indication to the sender. Bruce -- Can you get your operating system fixed when you need it? Linux - the supportable operating system. http://www.debian.org/support.html Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Blocking spam by IP number
Bruce Perens [EMAIL PROTECTED] writes: By the way, I return an error message rather than simply delaying the connection until it times out because under the Electronic Communications and Privacy Act it is unlawful to intercept electronic mail without an indication to the sender. How would this apply to kernel firewalling (leaving aside that I live in NZ)? Would reject be OK and deny not? -- Carey Evans * [EMAIL PROTECTED] On the telephone line I am anyone, I am anything I want to be. - Savage Garden, _Santa Monica_ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Blocking spam by IP number
On Mon, 11 Aug 1997, Bruce Perens wrote: I'm building a spam blocking package for Debian. While that is going on, i notice that the latest sendmail package includes Claus Aßmann's anti-spam stuff. I've been using them for several months now, and they're quite good. not perfect, but they do work. then you already have tcpd filtering your mail connections. If that's not the case, read the man page on tcpd. Once tcpd is set up, you can add the following text to the beginning of /etc/hosts.allow . This blocks connections from AGIS, a haven for spammers. I'd be interested in hearing about other IP addresses that should be blocked. I have ip firewalling enabled in the kernel and just packet filter them - it's easier to maintain a list of spam nets for distribution to several machines (around 6 major gateways and moderately large mail relays at the moment) than it is to distribute /etc/hosts.deny. here are the addresses that I block. i'm seriously considering blocking all AGIS-related networks. 208.9.64.0/24 # Cyber Promotions (Sprint) 207.14.212.0/24 # Financial Connections, Inc 208.1.117.0/24 # I can't remember (somewhere in Sprint) 205.199.212.0/24# Cyber Promotions (AGIS) 205.199.2.0/24 # Cyber Promotions (AGIS) 208.12.112.0/23 # MakeItSo, Inc 205.199.4.0/24 # nancynet - added 970529 the sprint cyberpromo network is probably long obsolete - they got booted from there ages ago. My final version will not simply deny the connections, but will output an SMTP error to them which will cause an immediate mail bounce at their end. firewalling them holds the mail in their queue for a few days and then bounces it - slowing down their mail delivery systems at the minor price of having their system attempt a connection every so often. firewalling is also much less work for my system to do than forking tcpd and checking the hosts_access rules. there's advantages and disadvantages to both ways of doing it. # The following net blocks are denied e-mail access because they belong to # sites that have not yet established an effective anti-spam policy. # AGIS provides net connectivity to most of the well-known spammers. tcp-env qmail-smtpd in.smtpd in-smtpd smtpd sendmail smail exim: \ I'd convert this to an /etc/mail/SpamNets file like so: # /etc/mail/SpamNets # can be network/netmask (eg 1.2.3.4/255.255.255.0) or # network/bits (eg 1.2.3.4/24) 205.254.160.0/255.255.224.0 # optional comment - who, why, when, etc 206.82.252.0/255.255.255.0 # 207.142.0.0/255.255.0.0 # 207.15.68.0/255.255.252.0 # 208.18.18.0/255.255.255.0 # 208.18.4.0/255.255.252.0# 209.14.0.0/255.255.0.0 # 204.68.252.0/255.255.255.0 # 204.137.128.0/255.255.128.0 # 205.164.0.0/255.255.0.0 # 206.62.0.0/255.255.0.0 # 205.198.0.0/255.254.0.0 # 206.42.0.0/255.254.0.0 # 206.148.0.0/255.254.0.0 # 206.185.0.0/255.255.0.0 # 206.248.0.0/255.252.0.0 # 206.84.0.0/255.254.0.0 # 204.157.0.0/255.255.0.0 # 208.9.64.0/24 # Cyber Promotions (Sprint) 207.14.212.0/24 # Financial Connections, Inc 208.1.117.0/24 # I can't remember (somewhere in Sprint) 205.199.212.0/24# Cyber Promotions (AGIS) 205.199.2.0/24 # Cyber Promotions (AGIS) 208.12.112.0/23 # MakeItSo, Inc 205.199.4.0/24 # nancynet - added 970529 (thanks for these network addresses, btw. i'll check out who they belong to and add them to my spamnets file) This could be processed at boot time with a script like the following: #! /bin/sh ANYWHERE=0.0.0.0/0 PORTS=25 # uncomment the following if you want blocked spam packets logged # (requires ip firewall logging enabled in the kernel) # #LOG=-o # read in /etc/mail/SpamNets for host/network addresses to firewall, # ignoring comments. JUNKMAIL=`sed -e '/^#/d' -e '/^$/d' -e 's/#.*$//' /etc/mail/SpamNets` # block out junkmailing scumbags for i in $JUNKMAIL ; do /sbin/ipfwadm -I -a reject $LOG -P tcp -S $i -D $ANYWHERE $PORTS done I use this on several mail machines/gateways. One of the systems using this is a freebsd system - the ipfw utility is similar to but significantly different from the linux ipfwadm utilityno problem, i just use a slightly different wrapper script. it should also be easy enough to produce firewalling commands for Ciscos and other routers. It would also be easy to put a web or gui front-end onto the script for easy (hah! nothing's easier than vi :-) maintainence of the list. craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone
Re: Blocking spam by IP number
On Thu, 14 Aug 1997, Remco van de Meent wrote: On Thu, 14 Aug 1997, David Sewell wrote: : I think a Debian spam-blocking package, using TCPD and generalized : to cover all MTAs, would be a good thing, with a couple of caveats. That's quite difficult to implement. One of the most important reasons: not all MTA are using tcpserver/inetd/xinetd as their 'parent'. For example ZMailer and Sendmail do create their own serversocket. (Yes I know, both of them have options to make them spawned by inetd). that's one of the reasons i prefer packet filtering to tcp-wrappers. block it out in the kernel before it gets to the application level. btw, sendmail can be compiled to use tcp wrappers. I think it's the -DTCP_WRAPPERS compile time option or something like that. Another reason that you don't want to use (imho) tcpd as a spamfilter: I like to 'filter' messages on more than just the other end's IP-address. I know ZMailer supports additional blocking: - source address (ip) - HELO line - MAIL line - RCPT line - existance of a valid DNS-entry in the several lines can any of the MTAs reject mail based on arbitrary headers? or even just the To: header (e.g. To: [EMAIL PROTECTED])? I know i can do this easily enough with procmail (in fact, I do), but IMO this is a job for the mail transfer agent, not the delivery agent. craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Blocking spam by IP number
On Fri, 15 Aug 1997, Craig Sanders wrote: : that's one of the reasons i prefer packet filtering to tcp-wrappers. : block it out in the kernel before it gets to the application level. Hmm.. I don't agree with you on your last sentence. Why should the kernel take care of something which has absolutely nothing to do with the kernel itself? Blocking mail is something that, imho, the MTA should do. That is, the MTA handles 'mail', like the kernel handles 'packets'. And the spam is in the 'mail', not in the 'packets'. Do you understand what I mean? : Another reason that you don't want to use (imho) tcpd as a spamfilter: I : like to 'filter' messages on more than just the other end's IP-address. : I know ZMailer supports additional blocking: :- source address (ip) :- HELO line :- MAIL line :- RCPT line :- existance of a valid DNS-entry in the several lines : : can any of the MTAs reject mail based on arbitrary headers? or even just : the To: header (e.g. To: [EMAIL PROTECTED])? Nope. At least none I'm aware of. : I know i can do this easily enough with procmail (in fact, I do), but : IMO this is a job for the mail transfer agent, not the delivery agent. I don't have an opinion on this. Remco. -- // Remco van de Meent // email: [EMAIL PROTECTED] // www: http://oloon.student.utwente.nl //Never make any mistaeks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Blocking spam by IP number
On Mon, Aug 11, 1997 at 11:49:00PM -0800, Bruce Perens wrote: My final version will not simply deny the connections, but will output an SMTP error to them which will cause an immediate mail bounce at their end. I've been using the tcpd banners option, with lines in /etc/hosts.deny that basically look like this: in.smtpd exim: \ [list of bad hosts/networks]: banners /usr/local/lib/tcpd Then in /usr/local/lib/tcpd I have a file named exim (add links as needed creating synonyms for in.smtpd and other sendmail-equivalent services) that contains these two lines: 550-5.7.1 SMTP connection refused from %h 550 5.7.1 Mail [EMAIL PROTECTED] from another host for reason The tcpd banners function means that the connection is not simply refused, but instead, the text contained in the file corresponding to the name of the service is transmitted to the client. (The given SMTP error codes are, I believe, the most up-to-date way of indicating administrative prohibition for security reasons; see RFCs 2034, 1893, and 821.) As for lists of known e-mail spam domains, I know of one site containing regularly-updated lists at ftp://ftp.cybernothing.org/pub/abuse/. (It is maintained by J.D. Falk, whois is with CAUCE, the Coalition Against Unsolicited Email.) I think a Debian spam-blocking package, using TCPD and generalized to cover all MTAs, would be a good thing, with a couple of caveats. For one thing, there's a legal issue: if the Debian package contains the actual net blocks and/or domain names to refuse mail from, that could open the Debian project to harrassing lawsuits from spammers. You'd probably want legal advice on this. Probably the package should put the burden of choosing blocked nets/sites on the individual user, maybe by getting addresses to block from a file that the package installer would be required to create (either by hand or maybe with a script that would pull in lists from given URLs--J.D. Falk's site has a couple of scripts like that). DS -- David Sewell * [EMAIL PROTECTED] | Where the earth is dry, the Dep't of Geosciences, Univ. of Arizona | soul is wisest and best. WWW: http://packrat.aml.arizona.edu/~dsew/ | --Heraclitus -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Blocking spam by IP number
On Thu, 14 Aug 1997, David Sewell wrote: : I think a Debian spam-blocking package, using TCPD and generalized to : cover all MTAs, would be a good thing, with a couple of caveats. That's quite difficult to implement. One of the most important reasons: not all MTA are using tcpserver/inetd/xinetd as their 'parent'. For example ZMailer and Sendmail do create their own serversocket. (Yes I know, both of them have options to make them spawned by inetd). Another reason that you don't want to use (imho) tcpd as a spamfilter: I like to 'filter' messages on more than just the other end's IP-address. I know ZMailer supports additional blocking: - source address (ip) - HELO line - MAIL line - RCPT line - existance of a valid DNS-entry in the several lines This makes the blocking highly configurable - that's what you want to have (imho again :/ ) Remco -- // Remco van de Meent // email: [EMAIL PROTECTED] // www: http://oloon.student.utwente.nl //Never make any mistaeks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
