Hi Sam,
On 07.10.2008 21:22 Uhr, Sam Clippinger wrote:
> I've considered that option in the past and just never gotten around to
> it. My reason for hesitating is that spamdyke should not disconnect too
> soon -- it should continue running long enough to gather information for
> its log messag
On 07.10.2008 20:41 Uhr, Arthur Girardi wrote:
> Hi Felix,
>
> Making use of the opportunity, I'd like to suggest you changing line
> 25 of your script where it reads:
>
> if( m/spamdyke/ ){
>
> to
>
> if( m/spamdyke\[/ ){
>
> so it only use spamdike processes' lines, becau
In my own experience with hacked accounts, when a spammer breaks into
a legitimate account, he usually try sending messages at once, in big
volumes, which is then easily spotted. I have myself a little dirty
crontab script which send me a message when the queue grows larger
than what I cons
I've considered that option in the past and just never gotten around to
it. My reason for hesitating is that spamdyke should not disconnect too
soon -- it should continue running long enough to gather information for
its log messages. In this particular case, disconnecting immediately
would f
I hadn't considered malicious authenticated users. In that case, a
filter like this would prevent them from forging addresses of other
users on your server. I don't believe that it would stop spam from
remote attackers who guess/steal legitimate passwords however, because
they would still kno
Thanks Felix, I figured it out: mcedit messed the pasted text. The wrong line
was this comment:
#printf "%2.2f%%\t(unknown/illegal)\n",
(($originsum{$key}-$tldsum)/$originsum{$key}*100) if $tldsum &&
($originsum{$key}-$tldsum);
Thanks again for the script.
Sergio
> -Original Message-
> F
Hi Felix,
Making use of the opportunity, I'd like to suggest you changing line
25 of your script where it reads:
if( m/spamdyke/ ){
to
if( m/spamdyke\[/ ){
so it only use spamdike processes' lines, because if not it will also
catch qmail log lines, for example, messages f
This behavior is correct. Incoming SMTP connections are accepted by
tcpserver, which reads the /etc/tcp.smtp(.cdb) file and sets the
environment variable "RELAYCLIENT" for all connections. Because that
variable is set, spamdyke allows the remote server to relay messages.
-- Sam Clippinger
Da
Thanks Felix. Yes, that was definitely the problem. Local DNS returns
NXDOMAIN for the IPs in question using host.
I'll remove it.
Faris.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Felix Buenemann
Sent: 07 October 2008 14:59
To: spamdyke-users@spamd
Hi,
On 06.10.2008 16:26 Uhr, Sam Clippinger wrote:
> The problem is that remote servers (spambots) are not disconnecting
> after getting a rejection message. When spamdyke sends a rejection code
> and there's no chance the connection could be allowed (e.g. no
> whitelists remain to be matched)
Or simply compile on a similar FreeBSD system e.g. a Desktop with gcc-4
and copy over the binaries to the server.
On 05.10.2008 19:02 Uhr, K. Shantanu wrote:
> Hello,
> I guess, I will use spamdyke 3.x, which compiles nicely on that server.
>
> Thanks,
> Shantanu
___
Try disabling lookups to your local server (127.0.0.1) in resolv.conf -
it might carry a reverse ip zone file (in-addr.arpa) for the network of
your servers ip but does not list the reverse dns entries of the other
servers. But as bind thinks it's authoritative for that zone it'll fail
the dns requ
Hi Sam,
sorry for my late reply, I've been away for a few days.
On 01.10.2008 0:35 Uhr, Sam Clippinger wrote:
> I've seen systems like this before; Yahoo! uses something similar to
> restrict authenticated email. In their system, authenticated users can
> only send messages "from" the authenti
I am using spamdyke and I have a problem with access file.
I use:
dflybsd# more /etc/tcp.smtp
:allow,RELAYCLIENT=""
dflybsd#
And:
dflybsd# more /usr/local/vpopmail/tcp.smtp
127.0.0.1:allow,RELAYCLIENT=""
:allow
This is my spamdyke.conf:
dflybsd# more /usr/local/etc/spamdyke.conf
log-level=exce
14 matches
Mail list logo
