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?
byside to the unkwon receiver error
procmail sorts out received nown possible virus, to quarantine
in the moment i catch some of them with
:0
* Received: from (domain\.de|213.213.213.213)
* !Received:.*\[213.213.213.213\]
!quarantine
cause some virus claim sometimes to be from a user from the local domain
some adressed to valid user
and
* ^Content-(Type|Disposition):
* (filename|name)=".*(\.zip|\.rar)"
* !From:.*(anybody\.com\.cy|valid\.de)
!quarantine
for zip in general, except friends, what is not a realy good solution and
needs a lot care
same for exe files but to /DEV/NULL
anyway
other folow then from the same ip with diferent sender email adress and so on
many variations
i woud like to
use this information and write it in a data file somehow????
and
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)
the smtp host runs in a freebsd sandbox at a serverfarm some where
even it is root account with a lot of freedom to meas around for me
there are some limitations
when i asked last time the support for to build my firewall
they mentioned that this is not a good idea
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.
a own nameserver is not included in my account
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.
sounds good to me
the maillog is very informativ showing up all i need
only thing i dont know is howto:)
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).
do you know a activ sendmail mailing list to ask there
i tried moon but there is little hapend ???
sendmail has a news group i coudnt manage to acces
Matthias
____________________________________________________________
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