[IMGate] Re: mta_clients_bw.map not working the way I expect

2005-11-17 Thread Len Conrad
if you can't figure this out, no shame. then in main.cf debug_peer_level = 1 debug_peer_list = ... read this from man postconf : debug_peer_list (default: empty) Optional list of remote client or server hostname or network address patterns that cause the verbose logging level to increase

[IMGate] Re: mta_clients_bw.map not working the way I expect

2005-11-14 Thread List_Mail
I have the same issues. Ips that i have put still get there. Right now I have issues with 58.33 and 222.65 I have them in the mta_clients_bw.map and doing a postmap -q comes back and says 554 acl mta_bw but they still get thru. If I lookin the log it shows the email coming in and says

[IMGate] Re: mta_clients_bw.map not working the way I expect

2005-11-11 Thread Paul Fuhrmeister
. This is one of them. Paul Fuhrmeister [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Len Conrad Sent: Friday, November 11, 2005 10:56 AM To: IMGate@mgw2.MEIway.com Subject: [IMGate] Re: mta_clients_bw.map not working the way I

[IMGate] Re: mta_clients_bw.map not working the way I expect

2005-11-11 Thread John Beaver
Mail17# postmap -q 64.200.217. hash:mta_clients_bw.map 554 ACL client_bw where do you get that IP from? Spam has almost doubled for us in the last 5 days. We started looking at the IP Numbers of the sending servers. We've found some class c's sending nothing but spam that don't seem to be

[IMGate] Re: mta_clients_bw.map not working the way I expect

2005-11-11 Thread Paul Fuhrmeister
Mail17# postmap -q 64.200.217. hash:mta_clients_bw.map 554 ACL client_bw where do you get that IP from? I know their upstream provider (64.200.217.0/21) I'll mention to the abuse team to check them out. If you have any others in the 64.200.x.x space, post them. 64.200.217. is the only

[IMGate] Re: mta_clients_bw.map not working the way I expect

2005-11-11 Thread Paul Fuhrmeister
, 2005 3:24 PM To: IMGate@mgw2.MEIway.com Subject: [IMGate] Re: mta_clients_bw.map not working the way I expect %egrep -i 96F6E30F4B maillog Nov 11 01:55:35 mail17 postfix/smtpd[96457]: 96F6E30F4B: client=a.lahealthfast.com[64.200.217.195] Nov 11 01:55:35 mail17 postfix/smtpd[96457]: 96F6E30F4B

[IMGate] Re: mta_clients_bw.map not working the way I expect

2005-11-11 Thread Len Conrad
So we can't block an entire class c? man 5 transport blocking by Class A, B, C works fine, always has a.b.c 554 Len

[IMGate] Re: mta_clients_bw.map not working the way I expect

2005-11-11 Thread Rod Dorman
On Friday, November 11, 2005, 18:03:15, Paul Fuhrmeister wrote: So we can't block an entire class c? Note: 64.200.217.195 is *NOT* a Class 'C' address, its a Class 'A' address. If you're going to invoke classful nomenclature you're going to inherit all the other networking baggage that

[IMGate] Re: mta_clients_bw.map not working the way I expect

2005-11-11 Thread john
Len Conrad wrote: So we can't block an entire class c? man 5 transport blocking by Class A, B, C works fine, always has a.b.c 554 maybe it's the trailing . in his entries. try it without the trailing dot. OR you could use a CIDR table for these entries. But this would involve

[IMGate] Re: mta_clients_bw.map not working the way I expect

2005-11-11 Thread john
Rod Dorman wrote: On Friday, November 11, 2005, 18:03:15, Paul Fuhrmeister wrote: So we can't block an entire class c? Note: 64.200.217.195 is *NOT* a Class 'C' address, its a Class 'A' address. If you're going to invoke classful nomenclature you're going to inherit all the other