At 18:55 2005-07-05 +0000, Matthias Haeker wrote:
in intervals comming email, since we have now catch all anymore:) ,
most to anyname(_at_)its-h(_dot_)de>... User unknown
In which case it isn't a matter for procmail, since your MTA should be
rejecting the messages. How is procmail expected to process a message if
the MTA is rejecting it?
they are originating mostly for one or too days from the same ip.
Er, why not just temporarily firewall that IP? That at least deals with
the repeat offenders (traffic from the same address) . Further, since
LEGITIMATE email to your domain from some consumer network someplace
(wherein the same IP may eventually be assigned to some other user, either
via dialup, or a DHCP lease on a broadband account) should generally not be
expected - since such people should be using an SMTP host at their own ISP,
blocking individual consumer IPs shouldn't pose much of a hinderance to
legitimate mail traffic.
If you configure to run your own locally managed DNSBL, you can populate it
with IP addresses of known abusers. How you populate the DNS zone is your
own issue - it could certainly be done from a script invoked from procmail,
provided that the messages are locally delivered.
the idea is to count this atacks some how up to a certain threshold and then
bounce the messages from that ip for lets say 24 h
But if they're USER UNKNOWN, how is it that procmail is expected to be in
receipt of any of the messages?
discover a repaetly spam sending ip
writing this in a kind of blacklist
From your description, it sounds more like you should consider configuring
your syslog to write to the usual maillog AND to a named pipe (a program
with an input through an apparent file). The named pipe could catalogue
the attempts - the origin IPs and the envelope addresses, and do whatever
necessary on the back end. All the necessary data should be available in
the maillog. If you have the MTA configured to a high enough logging level
(or verbosity, detail, etc), then your named pipe would have access to an
increased amount of other data about the connection - though a basic
maillog really should have all you need.
This would more generically protect you against dictionary attack attempts,
since you wouldn't necessarily be in receipt of the message, and would be
blocking based on an abundance of invalid recipients (or other
characteristics - such as failure to issue a QUIT to close the session - a
near sure sign of a spam or zombie host). There are sendmail configuration
options which allow you to throttle connections based on such things, but
nothing to auto-blacklist them (though there may be some milters out there
which do this).
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail