Re: 450 instead of 550 even though DNSBL rank exceeds postscreen_dnsbl_threshold?

[Sahil Tandon]

On Sat, 2012-05-05 at 19:49:18 -0400, Wietse Venema wrote:

> Sahil Tandon:
> >  May  5 15:24:07 mx1 postfix/postscreen[38500]: CONNECT from 
> > [88.23.204.109]:40294 to [69.147.83.52]:25
> >  May  5 15:24:07 mx1 postfix/dnsblog[45237]: addr 88.23.204.109 listed by 
> > domain bl.spameatingmonkey.net as 127.0.0.3
> >  May  5 15:24:07 mx1 postfix/dnsblog[45234]: addr 88.23.204.109 listed by 
> > domain zen.spamhaus.org as 127.0.0.11
> >  May  5 15:24:07 mx1 postfix/dnsblog[45234]: addr 88.23.204.109 listed by 
> > domain zen.spamhaus.org as 127.0.0.4
> >  May  5 15:24:09 mx1 postfix/postscreen[38500]: DNSBL rank 5 for 
> > [88.23.204.109]:40294
> >  May  5 15:24:09 mx1 postfix/postscreen[38500]: HANGUP after 0.24 from 
> > [88.23.204.109]:40294 in tests after SMTP handshake
> >  May  5 15:24:09 mx1 postfix/postscreen[38500]: DISCONNECT 
> > [88.23.204.109]:40294
> > 
> > In this second instance, is it correct to infer that Postfix was under
> > stress given the 2s (rather than 6s) that elapses between the last
> > dnsblog(8) entry and when the DNSBL rank is logged by postscreen(8)?
> 
> No. What your see is this: there are no more before-220 tests when
> the DNBLS lookups complete, therefore postscreen makes its decision
> immediately.

Hmm, OK.

> Either you have pregreet tests turned off, or this this client has
> already passed the pregreet test recently, and that result was
> cached in the temporary whitelist database.

Gotcha, and because PREGREET tests are enabled, it must be the cache as
you note.

> By the way, what is going on with your DNS? Why do both DNSBL replies
> arrive (almost) simultaneously after two seconds?

In the log excerpt quoted above, CONNECT and dnsblog entries share the
same timestamp of '15:24:07', so - just so I understand your question -
do you mean why the 'DNSBL rank' is logged two seconds after CONNECT?  I
assumed that was because Postfix waits for postscreen_greet_wait to
elapse before logging 'DNSBL rank' when the score matches or exceeds the
threshold.

> >  May  5 15:25:08 mx1 postfix/postscreen[38500]: CONNECT from 
> > [88.23.204.109]:41253 to [69.147.83.52]:25
> >  May  5 15:25:10 mx1 postfix/dnsblog[45304]: addr 88.23.204.109 listed by 
> > domain zen.spamhaus.org as 127.0.0.4
> >  May  5 15:25:10 mx1 postfix/dnsblog[45304]: addr 88.23.204.109 listed by 
> > domain zen.spamhaus.org as 127.0.0.11
> >  May  5 15:25:10 mx1 postfix/dnsblog[45300]: addr 88.23.204.109 listed by 
> > domain bl.spameatingmonkey.net as 127.0.0.3
> >  May  5 15:25:10 mx1 postfix/postscreen[38500]: NOQUEUE: reject: RCPT from 
> > [88.23.204.109]:41253: 450 4.3.2 Service currently unavailable;
> >   from=, to=,
> >   proto=ESMTP, helo=<109.Red-88-23-204.staticIP.rima-tde.net>
> >  May  5 15:25:11 mx1 postfix/postscreen[38500]: HANGUP after 1.1 from 
> > [88.23.204.109]:41253 in tests after SMTP handshake
> >  May  5 15:25:11 mx1 postfix/postscreen[38500]: PASS NEW 
> > [88.23.204.109]:41253
> >  May  5 15:25:11 mx1 postfix/postscreen[38500]: DISCONNECT 
> > [88.23.204.109]:41253
> 
> postscreen sends out DNSBL lookup requests because the client is
> not yet whitelisted for this test.
> 
> Notice that again, both DNSBL replies arrive two seconds later.

In this case I think I see what you mean: the dnsblog logging appears 2s
after the CONNECT.  But FWIW, in previous instances with respect to this
client, the CONNECT and dnsblog share the same timestamp such that there
is no 2s delay, e.g.:

May  5 15:20:51 mx1 postfix/postscreen[38500]: CONNECT from
[88.23.204.109]:38458 to [69.147.83.52]:25
May  5 15:20:51 mx1 postfix/dnsblog[45022]: addr 88.23.204.109 listed by
domain bl.spameatingmonkey.net as 127.0.0.3
May  5 15:20:51 mx1 postfix/dnsblog[45025]: addr 88.23.204.109 listed by
domain zen.spamhaus.org as 127.0.0.11
May  5 15:20:51 mx1 postfix/dnsblog[45025]: addr 88.23.204.109 listed by
domain zen.spamhaus.org as 127.0.0.4
May  5 15:20:57 mx1 postfix/postscreen[38500]: DNSBL rank 5 for
[88.23.204.109]:38458
May  5 15:20:57 mx1 postfix/postscreen[38500]: NOQUEUE: reject: RCPT
from [88.23.204.109]:38458: 550 5.7.1 Service unavailable; client
[88.23.204.109] blocked using bl.spameatingmonkey.net;
from=, to=, proto=ESMTP,
helo=<109.Red-88-23-204.staticIP.rima-tde.net>

... and ...

May  5 15:22:22 mx1 postfix/postscreen[38500]: CONNECT from
[88.23.204.109]:38943 to [69.147.83.52]:25
May  5 15:22:22 mx1 postfix/dnsblog[45121]: addr 88.23.204.109 listed by
domain bl.spameatingmonkey.net as 127.0.0.3
May  5 15:22:22 mx1 postfix/dnsblog[45116]: addr 88.23.204.109 listed by
domain zen.spamhaus.org as 127.0.0.4
May  5 15:22:22 mx1 postfix/dnsblog[45116]: addr 88.23.204.109 listed by
domain zen.spamhaus.org as 127.0.0.11
May  5 15:22:24 mx1 postfix/postscreen[38500]: DNSBL rank 5 for
[88.23.204.109]:38943
May  5 15:22:24 mx1 postfix/postscreen[38500]: NOQUEUE: reject: RCPT
from [88.23.204.109]:38943: 550 5.7.1 Service unavailable; client
[88.23.204.109] blocked using bl.spameatingmonkey.net;
from=, to=, p

..::mailbox listing issue::..

[Alfonso Reyes]

Hi everyone.

I'm trying yo set up postfix with dovecot imap, everything works fine.

We are using mailboxes without home directory (useradd -G username) and all
the mailboxes go to /var/spool/mail/.

We have all the users mailbox on that folder.

If you add you account all the users mailbox are listed on the mail client.
You cant see their emails but all the accounts are listed which is what we
dont want.

Do you know how can we fix this?

And id it's possible yo have a sent, draft, trash folders too?

Thanks un advance for you help, Im not posting the postfix and dovecot
configuration because It seems not to be necesary but id you need It please
let me know.

Regards.

Ing. Alfonso Alejandro Reyes Jimenez.

Re: 450 instead of 550 even though DNSBL rank exceeds postscreen_dnsbl_threshold?

[Wietse Venema]

Sahil Tandon:
>  May  5 15:24:07 mx1 postfix/postscreen[38500]: CONNECT from 
> [88.23.204.109]:40294 to [69.147.83.52]:25
>  May  5 15:24:07 mx1 postfix/dnsblog[45237]: addr 88.23.204.109 listed by 
> domain bl.spameatingmonkey.net as 127.0.0.3
>  May  5 15:24:07 mx1 postfix/dnsblog[45234]: addr 88.23.204.109 listed by 
> domain zen.spamhaus.org as 127.0.0.11
>  May  5 15:24:07 mx1 postfix/dnsblog[45234]: addr 88.23.204.109 listed by 
> domain zen.spamhaus.org as 127.0.0.4
>  May  5 15:24:09 mx1 postfix/postscreen[38500]: DNSBL rank 5 for 
> [88.23.204.109]:40294
>  May  5 15:24:09 mx1 postfix/postscreen[38500]: HANGUP after 0.24 from 
> [88.23.204.109]:40294 in tests after SMTP handshake
>  May  5 15:24:09 mx1 postfix/postscreen[38500]: DISCONNECT 
> [88.23.204.109]:40294
> 
> In this second instance, is it correct to infer that Postfix was under
> stress given the 2s (rather than 6s) that elapses between the last
> dnsblog(8) entry and when the DNSBL rank is logged by postscreen(8)?

No. What your see is this: there are no more before-220 tests when
the DNBLS lookups complete, therefore postscreen makes its decision
immediately.

Either you have pregreet tests turned off, or this this client has
already passed the pregreet test recently, and that result was
cached in the temporary whitelist database.

By the way, what is going on with your DNS? Why do both DNSBL replies
arrive (almost) simultaneously after two seconds?

>  May  5 15:25:08 mx1 postfix/postscreen[38500]: CONNECT from 
> [88.23.204.109]:41253 to [69.147.83.52]:25
>  May  5 15:25:10 mx1 postfix/dnsblog[45304]: addr 88.23.204.109 listed by 
> domain zen.spamhaus.org as 127.0.0.4
>  May  5 15:25:10 mx1 postfix/dnsblog[45304]: addr 88.23.204.109 listed by 
> domain zen.spamhaus.org as 127.0.0.11
>  May  5 15:25:10 mx1 postfix/dnsblog[45300]: addr 88.23.204.109 listed by 
> domain bl.spameatingmonkey.net as 127.0.0.3
>  May  5 15:25:10 mx1 postfix/postscreen[38500]: NOQUEUE: reject: RCPT from 
> [88.23.204.109]:41253: 450 4.3.2 Service currently unavailable;
>   from=, to=,
>   proto=ESMTP, helo=<109.Red-88-23-204.staticIP.rima-tde.net>
>  May  5 15:25:11 mx1 postfix/postscreen[38500]: HANGUP after 1.1 from 
> [88.23.204.109]:41253 in tests after SMTP handshake
>  May  5 15:25:11 mx1 postfix/postscreen[38500]: PASS NEW [88.23.204.109]:41253
>  May  5 15:25:11 mx1 postfix/postscreen[38500]: DISCONNECT 
> [88.23.204.109]:41253

postscreen sends out DNSBL lookup requests because the client is
not yet whitelisted for this test.

Notice that again, both DNSBL replies arrive two seconds later.

Apparently this time the DNSBL score did not reach your '5' threshold,
so the client is not blocked. Perhaps some bit got flipped as the
dnsblog reported its results to the postscreen daemon; postscreen
'-v' logging will show how it maintains DNSBL scores.

Next, postscreen does what it is supposed to do when the DNSBL tests
succeeds: it saves the result to the temporary whitelist database
and logs PASS NEW, because all tests are now completed.

If this discrepancy is reproducible let me know. Otherwise I 
will not lose sleep over this.

Wietse

450 instead of 550 even though DNSBL rank exceeds postscreen_dnsbl_threshold?

[Sahil Tandon]

For context:

 % postconf mail_version postscreen_dnsbl_threshold postscreen_dnsbl_action
 mail_version = 2.9.1
 postscreen_dnsbl_threshold = 3
 postscreen_dnsbl_action = enforce

I have likely missed something simple, so feel free to bludgeon me with
your cluebats. Earlier today, I received some UCE from 88.23.204.109.
Grepping the logs for that address AND 'postscreen' or 'dnsblog', I saw
several instances of this client being rejected by postscreen(8).
However, the following sequence of events confused me:

 May  5 15:23:41 mx1 postfix/postscreen[38500]: CONNECT from 
[88.23.204.109]:39722 to [69.147.83.52]:25
 May  5 15:23:41 mx1 postfix/dnsblog[45216]: addr 88.23.204.109 listed by 
domain bl.spameatingmonkey.net as 127.0.0.3
 May  5 15:23:41 mx1 postfix/dnsblog[45209]: addr 88.23.204.109 listed by 
domain zen.spamhaus.org as 127.0.0.4
 May  5 15:23:41 mx1 postfix/dnsblog[45209]: addr 88.23.204.109 listed by 
domain zen.spamhaus.org as 127.0.0.11
 May  5 15:23:47 mx1 postfix/postscreen[38500]: DNSBL rank 5 for 
[88.23.204.109]:39722
 May  5 15:23:47 mx1 postfix/postscreen[38500]: NOQUEUE: reject: RCPT from 
[88.23.204.109]:39722: 550 5.7.1 Service unavailable; client
  [88.23.204.109] blocked using bl.spameatingmonkey.net;
  from=, to=, proto=ESMTP,
  helo=<109.Red-88-23-204.staticIP.rima-tde.net>
 May  5 15:23:48 mx1 postfix/postscreen[38500]: HANGUP after 1.1 from 
[88.23.204.109]:39722 in tests after SMTP handshake
 May  5 15:23:48 mx1 postfix/postscreen[38500]: DISCONNECT [88.23.204.109]:39722

As expected, the client was rejected because DNSBL rank 5 exceeds the
threshold. Then, the same client connected a few seconds later, but
presumably hung up without trying to transmit anything:

 May  5 15:24:07 mx1 postfix/postscreen[38500]: CONNECT from 
[88.23.204.109]:40294 to [69.147.83.52]:25
 May  5 15:24:07 mx1 postfix/dnsblog[45237]: addr 88.23.204.109 listed by 
domain bl.spameatingmonkey.net as 127.0.0.3
 May  5 15:24:07 mx1 postfix/dnsblog[45234]: addr 88.23.204.109 listed by 
domain zen.spamhaus.org as 127.0.0.11
 May  5 15:24:07 mx1 postfix/dnsblog[45234]: addr 88.23.204.109 listed by 
domain zen.spamhaus.org as 127.0.0.4
 May  5 15:24:09 mx1 postfix/postscreen[38500]: DNSBL rank 5 for 
[88.23.204.109]:40294
 May  5 15:24:09 mx1 postfix/postscreen[38500]: HANGUP after 0.24 from 
[88.23.204.109]:40294 in tests after SMTP handshake
 May  5 15:24:09 mx1 postfix/postscreen[38500]: DISCONNECT [88.23.204.109]:40294

In this second instance, is it correct to infer that Postfix was under
stress given the 2s (rather than 6s) that elapses between the last
dnsblog(8) entry and when the DNSBL rank is logged by postscreen(8)?
Perhaps that is irrelevant, but just something I noticed.  Anyway, the
oddness occurs just under a minute later, when the client connects
again:

 May  5 15:25:08 mx1 postfix/postscreen[38500]: CONNECT from 
[88.23.204.109]:41253 to [69.147.83.52]:25
 May  5 15:25:10 mx1 postfix/dnsblog[45304]: addr 88.23.204.109 listed by 
domain zen.spamhaus.org as 127.0.0.4
 May  5 15:25:10 mx1 postfix/dnsblog[45304]: addr 88.23.204.109 listed by 
domain zen.spamhaus.org as 127.0.0.11
 May  5 15:25:10 mx1 postfix/dnsblog[45300]: addr 88.23.204.109 listed by 
domain bl.spameatingmonkey.net as 127.0.0.3
 May  5 15:25:10 mx1 postfix/postscreen[38500]: NOQUEUE: reject: RCPT from 
[88.23.204.109]:41253: 450 4.3.2 Service currently unavailable;
  from=, to=,
  proto=ESMTP, helo=<109.Red-88-23-204.staticIP.rima-tde.net>
 May  5 15:25:11 mx1 postfix/postscreen[38500]: HANGUP after 1.1 from 
[88.23.204.109]:41253 in tests after SMTP handshake
 May  5 15:25:11 mx1 postfix/postscreen[38500]: PASS NEW [88.23.204.109]:41253
 May  5 15:25:11 mx1 postfix/postscreen[38500]: DISCONNECT [88.23.204.109]:41253
 ...

No logging of a DNSBL rank, and the client just gets a 4xx after passing
the deep protocol tests. As per design, future connections are passed on
to smtpd(8) which then delivers the mail.

Please let me know if any other portions of the log or a full 'postconf
-n' (I'll just have to sanitize certain portions) would be useful.

-- 
Sahil Tandon

Re: Multiple IP

[Wietse Venema]

Kirill Bychkov:
> Thank you for advice.
> 
> But the more I read the docs, the more I do not understand this feature.
> Sorry.
> 
> In my case, postfix-in and postfix-out is one instance.
> I already have 2 postfix with identical configuration on separate servers.
> I need to create +5 or more postfix servers with same identical
> configuration. To economy I want to do it on one server.
> My steps:
> 1. I create null-client
> 2. I create 5 instances
> 3. Configure the instance.
> 
> What is the main difference between the configuration of my existing servers,
> except inet_interface?

Each MTA needs a unique main.cf/master.cf location.

Each MTA needs a unique inet_interfaces setting. No MTA can have
the default inet_interfaces value, otherwise it will listen on all
IP addresses, and will get other MTA's traffic when that MTA is
down.

Each MTA needs a unique myhostname setting.
Each MTA needs a unique queue_directory setting.
Each MTA needs a unique data_directory setting.
Each MTA needs a unique myhostname setting.

If this is not described in MULTI_INSTANCE_README, please submit
corrections.

Wietse

Re: Multiple IP

[Kirill Bychkov]

Thank you for advice.

But the more I read the docs, the more I do not understand this feature.
Sorry.

In my case, postfix-in and postfix-out is one instance.
I already have 2 postfix with identical configuration on separate servers.
I need to create +5 or more postfix servers with same identical
configuration. To economy I want to do it on one server.
My steps:
1. I create null-client
2. I create 5 instances
3. Configure the instance.

What is the main difference between the configuration of my existing servers,
except inet_interface?
In my case, inet_interface of each instance will be unique ip address for
receive and send mails.



On 3 May 2012 10:43, Patrick Ben Koetter  wrote:

> * Kirill Bychkov :
> > Hi all,
> >
> > I need create server with 5 IP addresses (interfaces) and postfix(es).
> The
> > role of this server is relay.
> > If message delivered into my mail server on one ip address, for example,
> > 172.16.35.35, so this message should be sent from same ip: 172.16.35.35.
> > In other words, on which interface the message came, with this should be
> > sent.
> > What method should I do?
> > 1. Postfix multi instace (postmulti)
> > 2. Postfix manual multi instance (
> > http://advosys.ca/papers/email/58-postfix-instance.html)
> > 3. Configure master.cf and main.cf of one postfix instance.
>
> Use 1.
>
> p@rick
>
> --
> All technical questions asked privately will be automatically answered on
> the
> list and archived for public access unless privacy is explicitely required
> and
> justified.
>
> saslfinger (debugging SMTP AUTH):
> 
>

Re: header_checks rule that doesn't work

[Vincent Lefevre]

On 2012-05-05 12:41:35 +0200, mouss wrote:
> with pcre, you can use \s+
> 
> /Received:\s*from\s+\S+\s+\(\S+\s+\[\S+\]\)\s+by\+\S+/
  ^^ \s+
> 
> that looks a bit cryptic, doesn't it? :)

I wish pcre had a flag so that a space means \s+. That would
particularly be useful here, where headers may be split at any
whitespace.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: header_checks rule that doesn't work

[Vincent Lefevre]

On 2012-05-04 22:47:15 -0500, /dev/rob0 wrote:
> The OP showed that on two lines, but if it is, there would be leading 
> whitespace. You want to match a whole logical header, not only a 
> continued line.

Ah, OK, thanks, I hadn't seen this part of the doc. I think I was
confused by http://www.postfix.org/BUILTIN_FILTER_README.html which
says at the beginning:

  Postfix supports a built-in filter mechanism that examines message
  header and message body content, one line at a time, before it is
  stored in the Postfix queue.

The following would be less confusing:

  Postfix supports a built-in filter mechanism that examines message
  header and message body content, one header or one body line at a
  time, before it is stored in the Postfix queue.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: A major f*up on part of spamhaus:

[/dev/rob0]

On Sat, May 05, 2012 at 09:38:47AM +0200, DTNX Postmaster wrote:
> On May 4, 2012, at 13:12, Ralf Hildebrandt wrote:
> 
> > http://www.spamhaus.org/sbl/query/SBL138067
> > 
> > The evidence section lists "inetnum: 95.218.0.0 -
> > 95.219.255.255", yet spamhaus listed 93.218.0.0/15
> > (93 instead of 95)!
> > 
> > 93.218.0.0/15 includes large parts of german Deutsche
> > Telekom dialups :|
> 
> http://www.spamhaus.org/pbl/query/PBL681428
> 
> Wouldn't you reject them anyway because they are on the PBL,
> or bypass the RBL check for authenticated clients that relay
> through your server?

That was my first thought as well. Listings on SBL are supposed to 
work in deep header parsing. So listing PBL space in SBL could be 
disastrous.

Thanks, Ralf, for reporting this. Thanks, Spamhaus, for fixing it.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: header_checks rule that doesn't work

[mouss]

Le 05/05/2012 05:47, /dev/rob0 a écrit :
> On Fri, May 04, 2012 at 10:03:35PM -0400, Wietse Venema wrote:
>> Vincent Lefevre:
>>> I've received a mail having:
>>>
>>> From: 
>>> =?GB2312?B?tfXBoyy2/rrP0ru19cGjLMj9us/Su7X1waMsy8S6z9K7tfXBoyy3/srOtfXB?=
>>>
>>> I wanted to reject such mail with
>>>
>>> /^.=\?GB2312\?B\?/   REJECT GB2312 in headers
> 
> The OP showed that on two lines, but if it is, there would be leading 
> whitespace. You want to match a whole logical header, not only a 
> continued line. The expression should be:
> 
> /^From:.=\?GB2312\?B\?/   REJECT GB2312 in headers
> 
> Or, remove the anchor:
> 
> /=\?GB2312\?B\?/   REJECT GB2312 in headers
> 
>>> in header_checks.pcre, but this didn't work. I don't understand 
>>> because
>>>
>>>   postmap -q - pcre:/etc/postfix/header_checks.pcre < the_message
>>>
>>> says that the rule applies on this line.
>>
>> Try:
>>
>> postmap -h -q 
>>
>> This way you enforce that it looks at headers only.
> 
> One thing the header_checks(5) manual is not clear about is how to 
> match the line end and leading whitespace. Is it matched by a single 
> space in the expression,

No: with the following header:
Received: from localhost (localhost [127.0.0.1])
  by russian-caravan.cloud9.net (Postfix) with ESMTP

$ cat  test.pcre
/^Received:.*\) by/ WARN match single space
/^Received:.*\)  by/ WARN match two spaces
/^Received:.*\)\s+by/ WARN match \s+
$ postmap -h -q - pcre:test.pcre < test.hdr
 WARN match \s+



> or would we have to replace spaces with 
> something like this: "[[:blank:]]+" ?

with pcre, you can use \s+

/Received:\s*from\s+\S+\s+\(\S+\s+\[\S+\]\)\s+by\+\S+/

that looks a bit cryptic, doesn't it? :)

Re: Postscreen DNSBL weights

[Andrea gabellini - SC]

Hello,

this is my configuration:

postscreen_dnsbl_sites = list.dnswl.org=127.0.[0..255].[2..3]*-2,
iadb.isipp.com=127.[0;3].[1;100].[255;10;100]*-2,
wl.mailspike.net=127.0.0.[18..20]*-2, dnsbl.ahbl.org,
combined.njabl.org=127.0.0.[2;4;9]*2,
dnsbl.sorbs.net=127.0.0.[2;3;7;10], zen.spamhaus.org=127.0.0.[10;11]*2,
bl.spamcop.net, bl.mailspike.net=127.0.0.[2;10;11;12]*2,
b.barracudacentral.org, ix.dnsbl.manitu.net
postscreen_dnsbl_threshold = 2

Andrea

Il 04/05/2012 17:29, Rod K ha scritto:
> Hi all,
>
> Was wondering if anyone would be willing to share what DNSBL and
> weights they are using with Postscreen.
>
> Thanks,
>
> Rod

Re: A major fuckup on part of spamhaus:

[DTNX Postmaster]

On May 4, 2012, at 13:12, Ralf Hildebrandt wrote:

> http://www.spamhaus.org/sbl/query/SBL138067
> 
> The evidence section lists "inetnum: 95.218.0.0 - 95.219.255.255", yet
> spamhaus listed 93.218.0.0/15 (93 instead of 95)!
> 
> 93.218.0.0/15 includes large parts of german Deutsche Telekom dialups :|

http://www.spamhaus.org/pbl/query/PBL681428

Wouldn't you reject them anyway because they are on the PBL, or bypass 
the RBL check for authenticated clients that relay through your server?

Cya,
Jona