[Mimedefang] Blocking spam senders using IPTables?

[James Ebright]

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 <amilivojevic at pbl.ca>    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
> MIMEDefang at lists.roaringpenguin.com
> http://lists.roaringpenguin.com/mailman/listinfo/mimedefang


--
EsisNet.com Webmail Client