Re: [spamdyke-users] Spamdyke and Plesk 8.3
I am running Plesk8.3.0 on SuSE10.0 with latest Spamdyke - and it works pretty fine, avg. >96% of Spam is blocked. Regards Arne Christian Aust schrieb am 25.04.2008 08:51: > Interesting, indeed. I'm running Plesk 8.3, too, and did not yet > encounter any problems. Can somebody else confirm issues or trouble-free > operations? Regards, > > Christian > > Arne Metzger ([EMAIL PROTECTED]) schrieb am Fri Apr 25 07:47:30 2008: > >> It would be interesting to know, why it runs better before relaylock. >> I have the same here: Plesk8.3.0, latest Spamdyke and my config >> (/etc/xinetd/stmp_psa) calls first relaylock, then spamdyke and then the >> rest. >> >> Regards >> Arne >> >> Sam Clippinger schrieb am 24.04.2008 19:48: >>> Also, I seem to recall that spamdyke and relaylock don't get along >>> perfectly well; spamdyke does better when it runs before relaylock (I >>> can't find my notes on this to explain why). > ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] feature request: Test mode
Suggestion:
For enable/disable type parameters config could change like this:
old form: reject-ip-in-cc-rdns
new form: reject-ip-in-cc-rdns=(on|off|log)
For current settings with values:
old form: ip-blacklist-file=/path/to/file
new form: ip-blacklist-file=(on|off|log):/path/to/file
('off' in the later may seem awkward but if the switch system is
implemented it can be a useful way to temporarily disable it. You do it
by commeting it out now).
Regards
Bgs
Sam Clippinger wrote:
> Very interesting idea. I'll definitely put that one on the list.
>
> -- Sam Clippinger
>
> Marcin Orlowski wrote:
>> Hi,
>>
>> I'd love to see sort of test mode. So I could i.e. enable
>> log-ip-in-cc-rdns which would work the same way known
>> reject-ip-in-cc-rdns works but without really denying
>> matching connection. It shall just log it (i.e. as
>> TEST_IP_IN_CC_RDNS) and that's it. That would be extremely
>> useful to run on production environment for some time
>> to find out how it would act "for real". I'd analyse
>> logs then to decide if I'd benefit or not, or how to
>> configure whitelists to have this option work as best
>> for my users as it possibly could.
>>
>> Test mode could be available for most options it'd
>> make sense for.
>>
>> Marcin
>> ___
>> spamdyke-users mailing list
>> spamdyke-users@spamdyke.org
>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>>
> ___
> spamdyke-users mailing list
> spamdyke-users@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] feature request: Test mode
N.Novozhilov wrote:
> Why do not comment string which you don't want at the moment?
"You do it by commeting it out now)."
That's what I wrote too. I just added that if we have a switch system
implemented anyway, it would be a more elegant way to handle it.
>
>
> On Fri, 25 Apr 2008 11:40:59 +0200
> Bgs <[EMAIL PROTECTED]> wrote:
>
>> Suggestion:
>>
>> For enable/disable type parameters config could change like this:
>>
>> old form: reject-ip-in-cc-rdns
>> new form: reject-ip-in-cc-rdns=(on|off|log)
>>
>> For current settings with values:
>>
>> old form: ip-blacklist-file=/path/to/file
>> new form: ip-blacklist-file=(on|off|log):/path/to/file
>>
>> ('off' in the later may seem awkward but if the switch system is
>> implemented it can be a useful way to temporarily disable it. You do it
>> by commeting it out now).
>>
>> Regards
>> Bgs
>>
>>
>> Sam Clippinger wrote:
>>> Very interesting idea. I'll definitely put that one on the list.
>>>
>>> -- Sam Clippinger
>>>
>>> Marcin Orlowski wrote:
Hi,
I'd love to see sort of test mode. So I could i.e. enable
log-ip-in-cc-rdns which would work the same way known
reject-ip-in-cc-rdns works but without really denying
matching connection. It shall just log it (i.e. as
TEST_IP_IN_CC_RDNS) and that's it. That would be extremely
useful to run on production environment for some time
to find out how it would act "for real". I'd analyse
logs then to decide if I'd benefit or not, or how to
configure whitelists to have this option work as best
for my users as it possibly could.
Test mode could be available for most options it'd
make sense for.
Marcin
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>>> ___
>>> spamdyke-users mailing list
>>> spamdyke-users@spamdyke.org
>>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>>>
>> ___
>> spamdyke-users mailing list
>> spamdyke-users@spamdyke.org
>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>
>
> ~~
> Regards
> Nicholas A. Novozhilov, NAN6-RIPE
>
> NTR Lab
> System administrator
> ___
> spamdyke-users mailing list
> spamdyke-users@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] feature request: Test mode
Why do not comment string which you don't want at the moment?
On Fri, 25 Apr 2008 11:40:59 +0200
Bgs <[EMAIL PROTECTED]> wrote:
> Suggestion:
>
> For enable/disable type parameters config could change like this:
>
> old form: reject-ip-in-cc-rdns
> new form: reject-ip-in-cc-rdns=(on|off|log)
>
> For current settings with values:
>
> old form: ip-blacklist-file=/path/to/file
> new form: ip-blacklist-file=(on|off|log):/path/to/file
>
> ('off' in the later may seem awkward but if the switch system is
> implemented it can be a useful way to temporarily disable it. You do it
> by commeting it out now).
>
> Regards
> Bgs
>
>
> Sam Clippinger wrote:
> > Very interesting idea. I'll definitely put that one on the list.
> >
> > -- Sam Clippinger
> >
> > Marcin Orlowski wrote:
> >> Hi,
> >>
> >> I'd love to see sort of test mode. So I could i.e. enable
> >> log-ip-in-cc-rdns which would work the same way known
> >> reject-ip-in-cc-rdns works but without really denying
> >> matching connection. It shall just log it (i.e. as
> >> TEST_IP_IN_CC_RDNS) and that's it. That would be extremely
> >> useful to run on production environment for some time
> >> to find out how it would act "for real". I'd analyse
> >> logs then to decide if I'd benefit or not, or how to
> >> configure whitelists to have this option work as best
> >> for my users as it possibly could.
> >>
> >> Test mode could be available for most options it'd
> >> make sense for.
> >>
> >> Marcin
> >> ___
> >> spamdyke-users mailing list
> >> spamdyke-users@spamdyke.org
> >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
> >>
> > ___
> > spamdyke-users mailing list
> > spamdyke-users@spamdyke.org
> > http://www.spamdyke.org/mailman/listinfo/spamdyke-users
> >
> ___
> spamdyke-users mailing list
> spamdyke-users@spamdyke.org
> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
~~
Regards
Nicholas A. Novozhilov, NAN6-RIPE
NTR Lab
System administrator
___
spamdyke-users mailing list
spamdyke-users@spamdyke.org
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] --help goes to stderr insead of stdout
Hi, is there any reason output of --help goes to stderr stream instead of stdout? Regards, -- "Daddy, what "Formatting drive C:" means?"... Marcinhttp://wfmh.org.pl/carlos/ ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] problems with DENIED_IP_IN_CC_RDNS
Sam Clippinger wrote: > The defaults are described in the text of each section in the README > file but not in the table that shows all of the configuration options... > I didn't realize that. The defaults are printed in the help screen when > you run "spamdyke -h". --max-recipients NUM Allow a maximum of NUM recipients per connection for non-local senders. Default: unlimited recipients per connection. NUM must be between (or equal to) 0 and 2147483647. Well, I still have to *guess* if 0 means "unlimited recipients" here ;) BTW: There's no anchor for "Extra Utilities" on http://spamdyke.org/documentation/README.html Regards, -- "Daddy, what "Formatting drive C:" means?"... Marcinhttp://wfmh.org.pl/carlos/ ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] problems with DENIED_IP_IN_CC_RDNS
Sorry about that. :) I've fixed the web page and the help text will be updated in version 4.0.0. Thanks! -- Sam Clippinger Marcin Orlowski wrote: > Sam Clippinger wrote: > >> The defaults are described in the text of each section in the README >> file but not in the table that shows all of the configuration options... >> I didn't realize that. The defaults are printed in the help screen when >> you run "spamdyke -h". >> > > --max-recipients NUM >Allow a maximum of NUM recipients per connection for non-local senders. >Default: unlimited recipients per connection. >NUM must be between (or equal to) 0 and 2147483647. > > > Well, I still have to *guess* if 0 means "unlimited recipients" here ;) > > BTW: There's no anchor for "Extra Utilities" on > http://spamdyke.org/documentation/README.html > > Regards, > ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] --help goes to stderr insead of stdout
Yes. spamdyke's error messages go to stderr, because configuration errors should be logged instead of being sent to the remote server (stdout goes to the network). Because the error text is sent to stderr, it made sense to send the version banner and the help text to stderr also, for consistency. -- Sam Clippinger Marcin Orlowski wrote: > Hi, > > is there any reason output of --help goes to > stderr stream instead of stdout? > > Regards, > ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] --help goes to stderr insead of stdout
Sam Clippinger wrote: > Yes. spamdyke's error messages go to stderr, because configuration > errors should be logged instead of being sent to the remote server > (stdout goes to the network). Because the error text is sent to stderr, > it made sense to send the version banner and the help text to stderr > also, for consistency. May I ask for --config-test-??? that could be invoked just in shell so I do not need to put spamdyke in the qmail "chain", so I could just craft new shiny .conf file and then do: # spamdyke --config-test-??? -f shiny.conf to see if my shiny.conf is fine and valid, all the external files, dirs etc. are accessible etc. Marcin ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] --help goes to stderr insead of stdout
I'm not sure I understand how your suggestion is different from the existing "config-test" feature. -- Sam Clippinger Marcin Orlowski wrote: > Sam Clippinger wrote: > > >> Yes. spamdyke's error messages go to stderr, because configuration >> errors should be logged instead of being sent to the remote server >> (stdout goes to the network). Because the error text is sent to stderr, >> it made sense to send the version banner and the help text to stderr >> also, for consistency. >> > > May I ask for --config-test-??? that could be invoked just in shell > so I do not need to put spamdyke in the qmail "chain", so I could > just craft new shiny .conf file and then do: > > # spamdyke --config-test-??? -f shiny.conf > > to see if my shiny.conf is fine and valid, all the external files, dirs > etc. are accessible etc. > > Marcin > ___ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Spamdyke and Plesk 8.3
Hi Sam,
many thanks for your help.
I changed my spamdyke.conf and the smtp-psa like you suggested and it works.
:-))
Mails from our own users are no longer greylisted.
I also checked the maillog, and I did not find any of the errors you listed.
So you dont have look for bugs.
Also using spamdyke for the blacklists has another advantage. I have a few
users in Africa and Indonesia and the rblsmptd kicked them out very often
because their providers often have "bad" IPs. Now the can bypass the
blacklist check.
I still have a few questions but I start a new thread for them.
Again Thanks
Greetings from the Black Forrest
Markus Thüer
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Sam Clippinger
Gesendet: Donnerstag, 24. April 2008 19:49
An: spamdyke users
Betreff: Re: [spamdyke-users] Spamdyke and Plesk 8.3
You are correct -- authenticated connections should bypass graylisting
and all other filters. If that isn't working, your users should be
reporting lots of problems, because their MUAs (e.g. Outlook,
Thunderbird) won't be able to deliver email to your server -- they'll
get the graylist rejection message.
First, I would recommend several changes to your configuration. You're
correct that you can remove rblsmtpd and allow spamdyke to check
blacklists. This is a better solution because spamdyke will not check
blacklists for authenticated users (once we fix your authentication
problem, that is). So you should add the following lines to your
spamdyke.conf file:
check-dnsrbl=list.dsbl.org
check-dnsrbl=dnsbl.njabl.org
check-dnsrbl=bl.spamcop.net
Changes to spamdyke.conf will take effect as soon as you save the file.
Also, I seem to recall that spamdyke and relaylock don't get along
perfectly well; spamdyke does better when it runs before relaylock (I
can't find my notes on this to explain why). Once you remove rblsmtpd
and move relaylock around, your smtp_psa file should look like this:
service smtp
{
socket_type = stream
protocol = tcp
wait = no
disable = no
user = root
instances = UNLIMITED
server = /var/qmail/bin/tcp-env
server_args = -Rt0 /usr/local/bin/spamdyke -f /etc/spamdyke.conf
/var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd
/var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw
/var/qmail/bin/true
}
To force xinetd to reload its configuration, use this command:
killall -HUP xinetd
If those changes don't fix the problem, there are several things you can
do to troubleshoot it. The fastest way is to look at the maillog file
(Plesk moves it to /usr/local/psa/var/log/maillog). Look for spamdyke
log entries that start with "DENIED_GRAYLISTED" and also show a username
after "auth:" at the end of the line. If you find any, that means
spamdyke saw the authorization but still performed graylisting. That
would be a bug, so I'll need your help to fix it.
Next, look for spamdyke log entries that start with "DENIED_GRAYLISTED"
and end with "auth: (unknown)". If the "to:" and "from:" indicate the
messages are from your users to remote addresses, they probably should
have authenticated and bypassed graylisting. If the graylist filter
blocked them anyway, there might be a bug in spamdyke that isn't
allowing it to snoop on the qmail authentication. If you could turn on
full logging (with "full-log-dir") and send me the log of a connection
that authenticated but was graylisted anyway, I would appreciate it.
-- Sam Clippinger
Markus Thüer wrote:
>
> Hi,
>
> I am new to this list, and first I want to say thank you for spamdyke.
>
> I installed it recently on a Plesk 8.3 System for greylisting and it
> works fine.
>
> But I have problems with the authentification. I read the archive but
> I am still a bit confused and I am new to server administration. So
> please forgive me if I ask silly questions.
>
> I noticed that even mail accounts of my own domain were greylisted.
> After they are authentificated they should bypass spamdyke. Shouldnt
> they?
>
> I read that from spamdyke 3.0.0 I dont have to use the
> authentifcation in spamdyke because the authtentification of qmail is
> honored.
>
> So how do I get this working ?
>
> I am also using the blackhole daemon provided by plesk. Would it be
> better to use spamdyke for this?
>
> I dont dare to simply try things out on the server, for it is a live
> system with more than 400 e-mail accounts and I will (probably) be
> killed if it should stop working.
>
> So I want to be quite confident before I start to try anything. So
> please boost my confidence by giving me some hints how it should work.
>
> This is my spamdyke.conf:
>
> log-level=2
>
> local-domains-file=/var/qmail/control/rcpthosts
>
> max-recipients=15
>
> idle-timeout-secs=60
>
> graylist-dir=/var/qmail/spamdyke/greylist
>
> graylist-min-secs=300
>
> graylist-max-secs=4814400
>
> #policy-url=http:/www.kapuziner.org/greylisting.html
>
> #sender-blacklist-file=/var/qmail/spam
[spamdyke-users] greylisting for not existend adresses
Hi, When I checked my greylisting directory: /var/qmail/spamdyke/greylist/domain.org/ I found that there are a lot of not existing user names. Like users which are deleted or misspelled addresses or obvious fantasy addresses. It looks to me like every mail that is send to our server is greylisted even if there isnt an account where it could be delivered to. Should it work in this way? Or should they be rejected before greylisting information is stored? I work with plesk 8.3 and spamdyke 3.1.6 ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Greylisting wishes
OK, I guess I've been working on version 4.0.0 for too long now because I didn't realize I'd already implemented this feature (until I tried to add it again). However, I didn't do it quite the way we described in this thread; instead of changing the "ALLOWED" messages, I added a new log level that will print out extra messages. (In fact, the entire log level system has been revisited and reorganized). When the logging level is "verbose" or higher, messages like these will be produced: FILTER_RDNS_MISSING ip: 11.22.33.44 FILTER_RDNS_BLACKLIST ip: 11.22.33.44 rdns: 11-22-33-44.example.com file: /var/qmail/spamdyke/rdns_blacklist.txt(31) FILTER_RBL_MATCH ip: 11.22.33.44 rbl: foorbl.example.com FILTER_GRAYLISTED sender: [EMAIL PROTECTED] recipient: [EMAIL PROTECTED] path: /var/qmail/spamdyke/graylist.d/example.com/user/spamdomain.com/spammer FILTER_WHITELIST_IP ip: 11.22.33.44 file: /var/qmail/spamdyke/whitelist_ip.txt(7) ...and so on. Any filter that triggers either an acceptance or a rejection will produce a "FILTER" log message. Filters that only examine the connection (but aren't triggered) won't produce any output (unless the log level is increased to "debug" or higher). I chose this approach because it provides more information than just the matching filter; it gives the file and line numbers, the directory paths, etc. Because it requires setting the log level higher, it can be enabled when someone wants to collect the data for analysis or turned off if it is not wanted. Does that sound sufficient or should I remove it and change the "ALLOWED" messages instead? -- Sam Clippinger Sam Clippinger wrote: > "ALLOWED_GRAYLISTED" could be useful if graylisting isn't active for all > domains. It would mean that the graylisting filter had checked for the > existence of a graylist file for that connection (and found one). I > agree it should be possible to match an "ALLOWED" with a previous > "DENIED_GRAYLISTED" but that could involve searching log files from > multiple days if the remote server doesn't attempt redelivery very quickly. > > -- Sam Clippinger > > Michael Colvin wrote: > >> Doesn't it already log "DENIED GREYLISTED" when it greylists an address, >> then when it is sent again, and passes the greylist test, it logs >> "ALLOWED"... Doesn't that already identify greylisted e-mails? Or, are we >> talking about logging the fact that e-mails are allowed AND have already >> been greylisted? Which, if you greylist all domains, would be every e-mail, >> right? >> >> The "ALLOWED_WHITELISTED_*" items might be useful, but I don't see where >> logging allowed greylisted e-mails makes sense... In fact, "Allowed >> Greylist" seems kind of contradictory to me... :-) Just my .02, which, >> with the state of the dollar, is worth even less today than last week. :-) >> >> >> Michael J. Colvin >> NorCal Internet Services >> www.norcalisp.com >> >> >> >> >> >> >> >> >> >>> -Original Message- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of BC >>> Sent: Wednesday, April 23, 2008 1:32 PM >>> To: spamdyke-users@spamdyke.org >>> Subject: Re: [spamdyke-users] Greylisting wishes >>> >>> >>> On 4/23/2008 [EMAIL PROTECTED] wrote: >>> >>> >>> I could do that if it would be useful. Now is the time >>> for changes >>> >>> like this, since version 4.0 won't be backwards compatible >>> anyway. >>> >>> What about changing the log message for other reasons too? For example, ALLOWED_WHITELISTED_IP, ALLOWED_WHITELISTED_SENDER, etc. >>> I'd like to see that sort of addition to the logging, too. >>> >>> Thanks, >>> >>> Bucky >>> >>> ___ >>> spamdyke-users mailing list >>> spamdyke-users@spamdyke.org >>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >>> >>> >>> >> ___ >> spamdyke-users mailing list >> spamdyke-users@spamdyke.org >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> >> > ___ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] greylisting for not existend adresses
Unfortunately spamdyke is not able to determine if a recipient address is valid before qmail accepts it. This feature has been frequently requested and I plan to add it very soon. Until then, all recipients will be graylisted, whether they are invalid or not. -- Sam Clippinger Markus Thüer wrote: > > Hi, > > When I checked my greylisting directory: > /var/qmail/spamdyke/greylist/domain.org/ I found that there are a lot > of not existing user names. > > Like users which are deleted or misspelled addresses or obvious > fantasy addresses. > > It looks to me like every mail that is send to our server is > greylisted even if there isn’t an account where it could be delivered to. > > Should it work in this way? Or should they be rejected before > greylisting information is stored? > > I work with plesk 8.3 and spamdyke 3.1.6 > > > > ___ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] Plesk Whitelist and Spamdyke
Hi, just a simple question for the experts. I dont know the mail processing order of plesk. So I am wondering will mails from Senders who are whitelisted in Plesk (global or personal) be checked by spamdyke? Markus Thüer ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Greylisting wishes
I think I sorta like both. Sam Clippinger wrote: > OK, I guess I've been working on version 4.0.0 for too long now because > I didn't realize I'd already implemented this feature (until I tried to > add it again). However, I didn't do it quite the way we described in > this thread; instead of changing the "ALLOWED" messages, I added a new > log level that will print out extra messages. (In fact, the entire log > level system has been revisited and reorganized). > > When the logging level is "verbose" or higher, messages like these will > be produced: > FILTER_RDNS_MISSING ip: 11.22.33.44 > FILTER_RDNS_BLACKLIST ip: 11.22.33.44 rdns: 11-22-33-44.example.com > file: /var/qmail/spamdyke/rdns_blacklist.txt(31) > FILTER_RBL_MATCH ip: 11.22.33.44 rbl: foorbl.example.com > FILTER_GRAYLISTED sender: [EMAIL PROTECTED] recipient: > [EMAIL PROTECTED] path: > /var/qmail/spamdyke/graylist.d/example.com/user/spamdomain.com/spammer > FILTER_WHITELIST_IP ip: 11.22.33.44 file: > /var/qmail/spamdyke/whitelist_ip.txt(7) > ...and so on. Any filter that triggers either an acceptance or a > rejection will produce a "FILTER" log message. Filters that only > examine the connection (but aren't triggered) won't produce any output > (unless the log level is increased to "debug" or higher). > > I chose this approach because it provides more information than just the > matching filter; it gives the file and line numbers, the directory > paths, etc. Because it requires setting the log level higher, it can be > enabled when someone wants to collect the data for analysis or turned > off if it is not wanted. > > Does that sound sufficient or should I remove it and change the > "ALLOWED" messages instead? > > -- Sam Clippinger > > Sam Clippinger wrote: >> "ALLOWED_GRAYLISTED" could be useful if graylisting isn't active for all >> domains. It would mean that the graylisting filter had checked for the >> existence of a graylist file for that connection (and found one). I >> agree it should be possible to match an "ALLOWED" with a previous >> "DENIED_GRAYLISTED" but that could involve searching log files from >> multiple days if the remote server doesn't attempt redelivery very quickly. >> >> -- Sam Clippinger >> >> Michael Colvin wrote: >> >>> Doesn't it already log "DENIED GREYLISTED" when it greylists an address, >>> then when it is sent again, and passes the greylist test, it logs >>> "ALLOWED"... Doesn't that already identify greylisted e-mails? Or, are we >>> talking about logging the fact that e-mails are allowed AND have already >>> been greylisted? Which, if you greylist all domains, would be every e-mail, >>> right? >>> >>> The "ALLOWED_WHITELISTED_*" items might be useful, but I don't see where >>> logging allowed greylisted e-mails makes sense... In fact, "Allowed >>> Greylist" seems kind of contradictory to me... :-) Just my .02, which, >>> with the state of the dollar, is worth even less today than last week. :-) >>> >>> >>> Michael J. Colvin >>> NorCal Internet Services >>> www.norcalisp.com >>> >>> >>> >>> >>> >>> >>> >>> >>> -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of BC Sent: Wednesday, April 23, 2008 1:32 PM To: spamdyke-users@spamdyke.org Subject: Re: [spamdyke-users] Greylisting wishes On 4/23/2008 [EMAIL PROTECTED] wrote: > I could do that if it would be useful. Now is the time > > for changes > like this, since version 4.0 won't be backwards compatible > > anyway. > What about changing the log message for other reasons too? For > example, ALLOWED_WHITELISTED_IP, ALLOWED_WHITELISTED_SENDER, etc. > > I'd like to see that sort of addition to the logging, too. Thanks, Bucky -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] Plesk Whitelist and Spamdyke
spamdyke doesn't check Plesk's whitelists, so it will not honor them. In fact, I don't know how Plesk's whitelists work. If they're stored in files (doubtful), spamdyke may be able to read those files and use them. -- Sam Clippinger Markus Thüer wrote: > > Hi, > > just a simple question for the experts. > > I don’t know the mail processing order of plesk. So I am wondering > will mails from Senders who are whitelisted in Plesk (global or > personal) be checked by spamdyke? > > Markus Thüer > > > > ___ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
