RE: [Mimedefang] Blocking spam senders using IPTables?
Jim, Looking at my log files I do NOT see the issue which you describe where a client continues to send data regardless of the commands returned. Of course I am not sure how much, if any, of that would be logged. I suspect only the initial connect and the quit would generate a log antry You are correct - Sendmail doesn't log them by default. If you get a null connection, that gets logged. If the sender is refused by check_rcpt, that gets logged. But invalid commands, including those generated after a sender ignores a 5xx error and carries on through the DATA phase, aren't logged at all. In theory, you would set the log level to 12 to get these, but that doesn't appear to work as described in the documentation, unless of course only valid commands are logged. In any case, at this level every milter action is included, so its pointless. I could trawl through the source to find out what level if any will log invalid commands, but it is so deep that the other logged stuff will swamp the logs very quickly. Instead, pick a persistent spammer who already gets kicked off by check_rcpt and dump the raw packets whenever they connect on port 25. If you still don't believe this happens, see any of the following: http://www1.ietf.org/mail-archive/web/asrg/current/msg07705.html http://www.zmailer.org/mhalist/2000/msg00539.html http://mail.teamdelsol.com/popauth3/popauth-3.0.0/popauth.pl Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking spam senders using IPTables?
Yes, however, certain 5xx responses I do not see ANY reason for allowing a client to recover, for example, if the client was relaying through a blacklisted IP.. there is NOTHING the client can do to change that during the same conversation, thus it makes zero sense to allow it to recover or potentially blast data at your server... for those violations it makes sense to simply return the 5xx code and close the connection. Since the RFC uses the SHOULD phrase when describing how a server shoudl react to/after sending 5xx codes, performing this action would still be RFC compliant and disallow any attempts to blast data from blacklisted IP blocks (whether access list or DNSRBL). Frankly, it just makes sense to handle it this way and may already be this way.. (I have not had a chance to look at the source yet). I have seen a few hacks that do what you are describing and also as you mentioned.. you can do this on a broader bases with 8.13 out of the box and I think this would help when the 5xx was generated for some reason other than a bad IP block. Regardless, I agree.. this should be handled long before any costly milters if at all possible. Jim Ebright ESISNET, LLC www.esisnet.com On Thu, 04 Nov 2004 08:35:16 -0600, Aleksandar Milivojevic wrote Hm, wouldn't better idea be detecting this in Sendmail. For example, after sendmail sends 5xx response to DATA, if next command looks like mail header, or if next 5 or 6 commands are invalid, start inserting sleep(60) after every call to read(), and call read() with really small buffer (say only 1k, or even smaller). Only minimum bandwith will be wasted, spammer would be significantly slowed down, and you are still perfectly RFC compliant (there's nothing in RFC's saying that you are not allowed to slow things down). It shouldn't be hard to patch Sendmail in this way. Basically, this would be generalization of already existing Sendmail feature (slowing things down if number of bad RCPT's is detected). If tactic becomes widespread, spammers might start actually looking for 5xx codes and acting accordingly. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang -- EsisNet.com Webmail Client ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Blocking spam senders using IPTables?
James, Seems to me this would be much better served implemented as a DNSRBL than a iptables solution. By using your own DNSRBL, you would have a scalable, RFC compliant solution that still drops the connection well before the data phase and before any mimedefang/SA processing, if you implement the DNSRBL inside your mail server software itself. You've missed my point - RBL lists have their place, but when the sender is badly behaved, they add nothing to the solution. My scenario is a sender who keeps trying no matter how many times we send a 5xx response code, and who in some cases uses a mailer which stuffs the whole message down the connection before you even get a chance to say hello.Even using a RBL, the bandwidth has been used, and the system has incurred the load of handling the packets and doing lookups. The greeting delay feature introduced in the latest Sendmail incarnation also doesn't help, as the greeting is ignored and the Sendmail daemon still has to process the queued packets. At the IPTables level, Sendmail never sees the packets, and the very limited processing is done by the kernel using optimised packet matching and filtering routines. Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Blocking spam senders using IPTables?
--On Tuesday, November 2, 2004 3:51 PM + Paul Murphy [EMAIL PROTECTED] wrote: We're dealing with spammers who either ignore the 5xx response and keep trying, Outlook does that too. You can end up with tens of thousands of connections a day trying to send the same couple of messages, never mind the 5xx responses. Joseph Brennan Academic Technologies Group, Academic Information Systems (AcIS) Columbia University in the City of New York ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Blocking spam senders using IPTables?
Paul, No, I understand your point, it is just that by using IP tables to drop the connection _very_ few packets before sendmail (postfix, etc) would (if using your own DNSRBL, i.e. install the software and lock it down for your own use yourself...) you do not gain alot and loose RFC compliancy. I am not sure you understand how an SMTP conversaation takes place... it is my understanding that the client cannot ignore a 5xx response and continue blasting data... since the server will not talk to a client after sending a 5xx response and closes the connection. Thus after recieving a 5xx return code a client would have to start over, generating another 5xx... etc. Dropping a connection at the firewall level (IP tables) would indeed save you a few bytes of connection data per request... but at the cost of true scalability across clusters and RFC compliancy. If you are looking for a simpler approach than DNSRBL then perhaps you can use sendmails (postfix, etc) access list. If you are not delaying checks it would have the exact same benefit, and not involve one extra DNS lookup, just a hash table lookup, and still be fairly easy to maintain across multiple nodes. Ultimately.. I think the reason you are seeing the data come in before your server finaly sends a 5xx reject is the way your filters/milter are setup, if you used an access list or DNSRBL to send the reject earlier you would not incur the data phase hit at all. A simple test of this would be to hardcode a pattern match for one of them in filter_sender and enable that filter in mimedefang and see if your mail server now drops the connection earlier, before the data phase... but.. I still think dropping before you even get to a costly milter would be best (access list, DNSRBL, etc). James Ebright ESISNET, LLC www.esisnet.com On Wed, 3 Nov 2004 10:51:51 -, Paul Murphy wrote James, Seems to me this would be much better served implemented as a DNSRBL than a iptables solution. By using your own DNSRBL, you would have a scalable, RFC compliant solution that still drops the connection well before the data phase and before any mimedefang/SA processing, if you implement the DNSRBL inside your mail server software itself. You've missed my point - RBL lists have their place, but when the sender is badly behaved, they add nothing to the solution. My scenario is a sender who keeps trying no matter how many times we send a 5xx response code, and who in some cases uses a mailer which stuffs the whole message down the connection before you even get a chance to say hello.Even using a RBL, the bandwidth has been used, and the system has incurred the load of handling the packets and doing lookups. The greeting delay feature introduced in the latest Sendmail incarnation also doesn't help, as the greeting is ignored and the Sendmail daemon still has to process the queued packets. At the IPTables level, Sendmail never sees the packets, and the very limited processing is done by the kernel using optimised packet matching and filtering routines. Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ -- EsisNet.com Webmail Client ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Blocking spam senders using IPTables?
James, I am not sure you understand how an SMTP conversaation takes place... it is my understanding that the client cannot ignore a 5xx response and continue blasting data... since the server will not talk to a client after sending a 5xx response and closes the connection. Thus after recieving a 5xx return code a client would have to start over, generating another 5xx... etc. I understand it very well, thanks. It appears however that you don't. You are incorrect in saying that a client cannot ignore a 5xx response. Try it via Telnet and see what happens: gate:~# telnet mail.example.com 25 Trying AAA.BBB.CCC.DDD... Connected to mail.example.com. Escape character is '^]'. HELO mail.example2.org 220 Ready ESMTP 250 mail.example.com Hello mail.example2.org [FFF.GGG.HHH.III], pleased to meet you MAIL FROM: [EMAIL PROTECTED] 250 2.1.0 [EMAIL PROTECTED] Sender ok RCPT TO: [EMAIL PROTECTED] 550 5.0.0 [EMAIL PROTECTED] We don't accept mail from spammers DATA 503 5.0.0 Need RCPT (recipient) Example data portion 500 5.5.1 Command unrecognized: Example data portion . 500 5.5.1 Command unrecognized: . quit 221 2.0.0 mail.example.com closing connection Connection closed by foreign host. If you code the filter to issue a 5xx error at the MAIL FROM: stage, the effect is very similar. Spammers who stuff data down the pipe don't check the response codes, so you have to accept each line of the message, parse it to see whether it has a valid command, and then issue the 500/551 error. Their aim is to process several million messages quickly, and bandwidth is not generally a concern (otherwise they'd take more care to clean up their lists to remove addresses which are known to generate errors), so they don't implement much in the way of error checking and recovery. Yes, some will take the hint and go away, but some don't, and some do but come back later. To do what you suggest, the mail daemon would have to send the 5xx error, and then send a TCP RST packet to the sender's port to effectively drop the connection, but the RFC requires that it is possible to recover from a 5xx error and to continue, since the server may have one address fail out of a batch of 20, or have 10 messages to deliver in one connection. In any case, section 3.9 of RFC 2821 states: SMTP clients that experience a connection close, reset, or other communications failure due to circumstances not under their control (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 451 response had been received and act accordingly. Therefore, compliant systems will keep trying, and will keep being dropped, and will keep using up your resources. Refusing the connection before the SMTP server sees the packet is the only way to resolve this issue. Basically, in a world where some people refuse to play nicely, it is naïve to run your systems as though everyone does - you already filter for viruses and spam, so this is just a refinement. Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking spam senders using IPTables?
James Ebright wrote: I am not sure you understand how an SMTP conversaation takes place... it is my understanding that the client cannot ignore a 5xx response and continue blasting data... since the server will not talk to a client after sending a 5xx response and closes the connection. Thus after recieving a 5xx return code a client would have to start over, generating another 5xx... etc. Client can ignore 5xx response from Sendmail. For example, if you have 1.2.3.4 REJECT in access file, and client ignores 5xx, conversation would look something like: 220 foobar.com ESMTP Unauthorized access prohibited ehlo barfoo.com 250-foobar.com Hello barfoo.com [1.2.3.4], pleased to meet you 250 ENHANCEDSTATUSCODES MAIL FROM:[EMAIL PROTECTED] 550 5.7.1 Access denied RCPT TO:[EMAIL PROTECTED] 550 5.7.1 Access denied DATA 550 5.7.1 Access denied From: [EMAIL PROTECTED] 550 5.7.1 Access denied To: [EMAIL PROTECTED] 550 5.7.1 Access denied Subject: buy something 550 5.7.1 Access denied and so on, until spammer disconnects... Try it out. Sendmail will close network socket only when other side disconnects, sends QUIT, or in case of timeout. This is because we have only error built-in mailer in Sendmail. If we had disconnect built-in mailer, things would probably be a bit different. -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Forcing Sendmail to close connection (was Re: [Mimedefang] Blocking spam senders using IPTables?)
On Wed, 3 Nov 2004, Aleksandar Milivojevic wrote: This is because we have only error built-in mailer in Sendmail. If we had disconnect built-in mailer, things would probably be a bit different. From reading the Sendmail source code, it looks like Sendmail 8.13.1 treats a 421 reply code from a milter magically, and shuts down the connection. See line 3376 of sendmail/milter.c and line 848 of sendmail/srvsmtp.c. I do not believe this feature exists in Sendmail 8.12.x. It looks like some rule sets can also force the connection to be terminated by returning 421. Regards, David. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: Forcing Sendmail to close connection (was Re: [Mimedefang] Blocking spam senders using IPTables?)
David F. Skoll wrote: On Wed, 3 Nov 2004, Aleksandar Milivojevic wrote: This is because we have only error built-in mailer in Sendmail. If we had disconnect built-in mailer, things would probably be a bit different. From reading the Sendmail source code, it looks like Sendmail 8.13.1 treats a 421 reply code from a milter magically, and shuts down the connection. See line 3376 of sendmail/milter.c and line 848 of sendmail/srvsmtp.c. I do not believe this feature exists in Sendmail 8.12.x. It looks like some rule sets can also force the connection to be terminated by returning 421. Not treating it magically. It treats it logically. ;-) 421 is used when server side of connection must close its end. For example, if you send SIGTERM to Sendmail (or any other MTA), it *must* attempt to asynchroniously send 421 to all connected clients before it exits, in the hope that client will pick it up when it tries to issue next command. Basically, it is a way to say client Something is killing me, I wan't be able to finish this transaction, try again later. Basically, after sending 421, there's no point in keeping the connection open anymore. I've attempted to put this into access file on 8.12.x, and also to send it from MIMEDefang, and Sendmail doesn't close the connection. So I guess it is something new in 8.13.x. Also 4xx codes are temp failures, instructing client to try again later... So there are some drawbacks in case of false positives. For starters. Legitimate senders will not be notified right away that teir mail hasn't made it (usually delay of around 5 days). If filter becomes trigger happy, bunch of sites will constantly retry to deliver bunch of emails to you (which is good and bad, you can quicly fix the filter before anything is permanently rejected)... I guess this works nicely with logic behind Can-It? -- Aleksandar Milivojevic [EMAIL PROTECTED]Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7 ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Blocking spam senders using IPTables?
On Wed, 3 Nov 2004, Joseph Brennan wrote: Outlook does that too. You can end up with tens of thousands of connections a day trying to send the same couple of messages, never mind the 5xx responses. There are also some broken MTAs which respond to a 4xx as if it were a 5xx and drop the message and send a bounce back. Lotus Notes is one of such ofenders. Fer ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Blocking spam senders using IPTables?
Aleksander, Probably not a good idea, since you don't know how big is remote network block. It might be something like /24, but it also might be something like /29. If you blindly assume it is /24, you'll get the spammer blocked (maybe, it just might be that one of your users had .forward file at remote site, and you can't know that either), but you will also penalize everybody else. My approach is to arbitrarily look across the last octet, work out the distribution of the addresses which are sending spam, and then take action to block any address within one standard deviation of the average octet value. Whether the network is /24 or /29 doesn't matter, until two /29 blocks which are in the same /24 both start sending me spam which triggers this check, in which case, yes it is possible that someone in the middle gets burned. As examples, here is one block which has been sending me spam: 66.55.189.16 66.55.189.17 66.55.189.19 66.55.189.20 66.55.189.21 66.55.189.25 66.55.189.29 66.55.189.30 66.55.189.32 66.55.189.33 66.55.189.35 66.55.189.36 66.55.189.37 66.55.189.39 66.55.189.41 66.55.189.42 66.55.189.43 66.55.189.47 66.55.189.48 66.55.189.49 66.55.189.50 66.55.189.51 66.55.189.52 66.55.189.53 66.55.189.54 66.55.189.57 66.55.189.58 66.55.189.59 66.55.189.61 66.55.189.63 All I can assume is that since all of these addresses are sending me the same type of spam (recipient address in the subject, mainly consumer electronics or casino related), they must be owned by the same people. A check with WHOIS says the whole range is owned by Vendare (VENDARE-EMAIL), but I can't assume they haven't subnetted and sold on addresses in blocks. However, I do know the extent (16 - 63), and I can assume that they own all of the addresses in that range. However, if they owned 1-64, and someone else has 65-128, and I got a spam from 66, I might assume that their range was 1-66, and accidentally block someone else. To counter this, I use the average +/- one SD, which in this particular case gives a range from 27 to 56, so I block all known spammer addresses, and also every address between 27 and 56. If I add an entry for 66, the average changes from 41.25 to 42.03, the SD from 14.18 to 14.60, and the range changes to be 27 to 57. If I add a single spammer at 66.55.189.254, the results are dramatically different - the range becomes 8 to 88, which is not good. The reason is because the average is based on an assumption that we have only one entry per IP address, but of course it will be weighted based on the number received from each address, so if the spammer range is showing up to 10 spam messages per address, and the outlier is showing 1, this sort of skewing should not happen. Also, by keeping a spam/ham count for every IP address we see, it would be possible to also check whether any predicted spammer addresses were in fact known to us for sending legitimate mail. This also allows for .forward files from MSN, Yahoo, etc plus mailing lists which occasionally carry Spam - if we receive 1000 legitimate e-mails and 5 spams, the total for this domain is -995 which would not trigger the IpTables block at +10. Storing this data in a database table with spam and ham counts per IP address per day/week and then summing over the last week/month to get a current ham/spam ratio per IP would be relatively simple. Expiring old totals would be necessary, but also simple. Perhaps once per hour, the ratio would be calculated for each IP, the IPTables list updated to reflect any changes, and a notification sent to the administrator with a list of the changes made, and the domain names of any systems now blocked. Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Blocking spam senders using IPTables?
The key word in that statement from RFC 2821 is SHOULD which has a very specific meaning in an RFC as defined in RFC 2119: 3. SHOULD This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I certainly believe this situation qualifies and dropping a connection due to a blast would still keep you compliant. Looking at my log files I do NOT see the issue which you describe where a client continues to send data regardless of the commands returned. Of course I am not sure how much, if any, of that would be logged. I suspect only the initial connect and the quit would generate a log antry (along with any user unknowns generating entries as well) during the course of normal logging. Besides, what would it accomplish if the spammer ignored all return codes... they would NEVER be able to reliably send any mail. No, I am not claiming they (spammers) are playing nice but it to believe they are not capable programmers is to underestimate them. We examine between 160-180k messages daily and run a small delay without seeing numerous children hanging around either, so I believe I can logically conclude either it is not happening often here or sendmail is actually closing the connection after a DNSRBL or Access list violation (I would have to look at sendmails source to be sure though), or the client is actually issuing a quit and trying again. This all happens well before milter/Mimedefang/SA are involved. Also, it looks like I might try sending a 421 back from violations within my milters now instead of the 5xx as I see zero reason to allow client recovery based on a rule violation within my milter (depending on the particular rule). Jim On Wed, 3 Nov 2004 14:40:49 -, Paul Murphy wrote James, I am not sure you understand how an SMTP conversaation takes place... it is my understanding that the client cannot ignore a 5xx response and continue blasting data... since the server will not talk to a client after sending a 5xx response and closes the connection. Thus after recieving a 5xx return code a client would have to start over, generating another 5xx... etc. I understand it very well, thanks. It appears however that you don't. You are incorrect in saying that a client cannot ignore a 5xx response. Try it via Telnet and see what happens: . -- EsisNet.com Webmail Client ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Blocking spam senders using IPTables?
Just a check - is everyone so stunned by my suggestion that they can't speak, or too busy laughing at something in it? Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking spam senders using IPTables?
On 11/2/2004 07:12, Paul Murphy wrote: Just a check - is everyone so stunned by my suggestion that they can't speak, or too busy laughing at something in it? I thought it looked like a pretty interesting idea and was waiting to hear more. Do please relate your experience with it if you give it a whirl. :) ~Jason -- ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking spam senders using IPTables?
- Original Message - From: Paul Murphy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 01, 2004 10:26 AM Subject: [Mimedefang] Blocking spam senders using IPTables? Given that real mail from these sites is unlikely, I'm tempted to implement a system of blocking all traffic from these IP addresses using the following scheme: A. Add a date/time stamped record to a database with that IP address as the key, and a spam count of 1 B. If the number of records matching that IP is now 3 or more, modify the IPTables system to drop all traffic from that IP with an ICMP Host-Prohibited message C. Run a daily expiry process which removes all records which are more than X days old (with X starting at 10 days) and which removes the IPTables entry if the new count is less than 3. Watch out for mail services that forward e-mail to your users. Think this: A user has an MSN account that gets a lot of spam, and that user sets his MSN account to forward to his local mailbox. Blam! You no longer receive _any_ email from MSN. ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
Re: [Mimedefang] Blocking spam senders using IPTables?
Greetings, You run the risk of starting a DoS attach against your own box. The RFC's state that senders should keep trying for ~5 days Quote : Chances are that you would get more DoS by new connections constantly : coming in, than by 5xx responses causing at least protocol-compliant : senders to give up. Search for tcp wrappers in comp.mail.sendmail for details Alberto ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Blocking spam senders using IPTables?
Chris, Watch out for mail services that forward e-mail to your users. Think this: A user has an MSN account that gets a lot of spam, and that user sets his MSN account to forward to his local mailbox. Blam! You no longer receive _any_ email from MSN. Accepted - that's why I'd only want to use this approach to target persistent and readily identifiable spammers. By blocking using this technique, you'd be accepting that any matching system would effectively cease to exist as far as you are concerned. The problem I'm trying to address is where your system is flooded by messages from addresses which belong to spammers, and despite greylisting and MD/SA scoring it as 20+ and sending a 500/571 permanent error, they keep trying at the same rate. At the moment, it is an annoying background trickle, but I can see a tidal wave in the distance because for every site which does sensible blocking, there are 100 more who will accept the message, and so it is never worthwhile for them to edit their lists to remove the addresses which fail. Some would argue that returning a permanent error for spam is incorrect, but that's my policy, it works for me, and it has the support of the directors here. If I can cut my bandwidth usage by 5% and reduce the load on my MD/SA system by eradicating the garbage from this one company, the effort will be worth it. Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Blocking spam senders using IPTables?
Alberto, You run the risk of starting a DoS attach against your own box. The RFC's state that senders should keep trying for ~5 days Quote : Chances are that you would get more DoS by new connections constantly : coming in, than by 5xx responses causing at least protocol-compliant : senders to give up. Search for tcp wrappers in comp.mail.sendmail for details The problem is that we're not dealing here with protocol-compliant senders. We're dealing with spammers who either ignore the 5xx response and keep trying, or who have a seemingly endless supply of garbage to send, all of which gets the 5xx response after I've incurred considerable processing time working out that it was spam. TCPWrappers would normally help, but it is too late in the process (they've already connected to the SMTP server), and too lacking in future possibilities such as delayed responses and tarpitting. In many cases, the spammer will happily still send their data down the pipe, even though every request gets a 5xx response immediately. You can't expect them to play nicely. Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
RE: [Mimedefang] Blocking spam senders using IPTables?
Seems to me this would be much better served implemented as a DNSRBL than a iptables solution. By using your own DNSRBL, you would have a scalable, RFC compliant solution that still drops the connection well before the data phase and before any mimedefang/SA processing, if you implement the DNSRBL inside your mail server software itself. As for how you decide who ends up on your DNSRBL (or IPTables) list, well, as you say, that is your own policy, However, I would encourage you to implement some way to track how items get added and a way for a remote third party that may have been added to see if they are on your list, why they were added, and a way to request removal/whitelisting. Personally, nothing is added to our private lists here without a human eyeball confirming it and our systems have less than .01% false positive rate and block/reject/bounce/quaranteen several million spam/virus messages a month. Jim Ebright ESISNET, LLC www.esisnet.com On Tue, 2 Nov 2004 14:49:22 -, Paul Murphy wrote Chris, Watch out for mail services that forward e-mail to your users. Think this: A user has an MSN account that gets a lot of spam, and that user sets his MSN account to forward to his local mailbox. Blam! You no longer receive _any_ email from MSN. Accepted - that's why I'd only want to use this approach to target persistent and readily identifiable spammers. By blocking using this technique, you'd be accepting that any matching system would effectively cease to exist as far as you are concerned. The problem I'm trying to address is where your system is flooded by messages from addresses which belong to spammers, and despite greylisting and MD/SA scoring it as 20+ and sending a 500/571 permanent error, they keep trying at the same rate. At the moment, it is an annoying background trickle, but I can see a tidal wave in the distance because for every site which does sensible blocking, there are 100 more who will accept the message, and so it is never worthwhile for them to edit their lists to remove the addresses which fail. Some would argue that returning a permanent error for spam is incorrect, but that's my policy, it works for me, and it has the support of the directors here. If I can cut my bandwidth usage by 5% and reduce the load on my MD/SA system by eradicating the garbage from this one company, the effort will be worth it. Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ -- EsisNet.com Webmail Client ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
[Mimedefang] Blocking spam senders using IPTables?
Hi, We've recently seen a large increase in SPAM volume, and although SA is taking care of the classification, a simple analysis of the messages shows that most have a pattern, in that everything which has a particular user's e-mail address in the subject is SPAM. Looking at the relay IP addresses, almost all are immediately suspected to be SPAM sender domains, rather than botnets or abused relays/proxies: 52.189.55.66.in-addr.arpa name = mx20.ejackpotclubdeals.com. 53.189.55.66.in-addr.arpa name = mx20.ejackpotclubbenefit.com. 54.189.55.66.in-addr.arpa name = mx20.ebigprizesclubdeals.com. 57.189.55.66.in-addr.arpa name = mx21.myvendaresecurities.com. 58.189.55.66.in-addr.arpa name = mx21.myphillipsdirect.net. 59.189.55.66.in-addr.arpa name = mx21.mymembersexclusive.com. 61.189.55.66.in-addr.arpa name = mx21.myjackpotclubgiveaway.com. 63.189.55.66.in-addr.arpa name = mx21.myusawellnet.com. 16.142.108.67.in-addr.arpa name = mx101.bargaincities.info. 17.142.108.67.in-addr.arpa name = mx101.bargain-city.info. 18.142.108.67.in-addr.arpa name = mx101.bargainsite.info. 19.142.108.67.in-addr.arpa name = mx101.bargainsites.info. 20.142.108.67.in-addr.arpa name = mx101.cuttingedgeinfoage.info. 21.142.108.67.in-addr.arpa name = mx101.cuttingedgeinfotech.info. 22.142.108.67.in-addr.arpa name = mx101.cuttingedge-infotech.info. 23.142.108.67.in-addr.arpa name = mx101.cuttingedgeintech.info. 32.142.108.67.in-addr.arpa name = mx102.cuttingedge-tech.info. 34.142.108.67.in-addr.arpa name = mx102.cuttingedgetechs.info. 35.142.108.67.in-addr.arpa name = mx102.cuttingedgetimes.info. 37.142.108.67.in-addr.arpa name = mx102.evirtualgoldmine.info. 38.142.108.67.in-addr.arpa name = mx102.evirtualgoldminez.com. 39.142.108.67.in-addr.arpa name = mx102.evirtualgoldpalace.info. Given that real mail from these sites is unlikely, I'm tempted to implement a system of blocking all traffic from these IP addresses using the following scheme: A. Add a date/time stamped record to a database with that IP address as the key, and a spam count of 1 B. If the number of records matching that IP is now 3 or more, modify the IPTables system to drop all traffic from that IP with an ICMP Host-Prohibited message C. Run a daily expiry process which removes all records which are more than X days old (with X starting at 10 days) and which removes the IPTables entry if the new count is less than 3. They appear to be using a bank of outgoing mail servers which are all on different IP addresses, and although I see multiple messages from some addresses, my current volume is low enough that it is normal to see addresses only two or three times in a couple of days - 493 messages from 223 unique IP addresses. I'd also be interested in implementing a block based on address range check, so perhaps if more than 10 SPAM messages which scored over 10 were received from an address block, then the known or estimated range of SPAM senders in that block would be blacklisted using IPTables, with a daily review. To illustrate this, supposed I received 3 SPAM messages from 1.2.3.4, 2 messages from 1.2.3.8, 2 messages from 1.2.3.9, and four from 1.2.3.12, then working firstly with a nominal class C assumption I would calculate that the average value for the fourth octet is 8.25, the standard deviation is 3.3, and so the normal range would be 5 to 11 - as a result, I would block all of the known IP values, plus the values in the range between 5 and 11, nicely filling in the gaps in the known range. This would go into the database with a timestamped value of 3. Given that I am happy that the false positive rate is zero based on the last week of logs, can anyone see any issues with this approach? Any suggestions on how to improve it? Best Wishes, Paul. __ Paul Murphy Head of Informatics Ionix Pharmaceuticals Ltd 418 Science Park, Cambridge, CB4 0PA Tel. 01223 433741 Fax. 01223 433788 ___ DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please contact the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741 ___ ___ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list [EMAIL PROTECTED] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
