rbl_client - One slipped through

This is a discussion on rbl_client - One slipped through within the alt.comp.mail.postfix forums, part of the Mail Servers and Related category; Hi. OK it's only one mail... Nevertheless, I find it strange to find a mail rejected by an rbl_client ...


Go Back   Usenet Forums > Mail Servers and Related > alt.comp.mail.postfix

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 12-28-2005
Mr Rob Shepherd
 
Posts: n/a
Default rbl_client - One slipped through

Hi.

OK it's only one mail...

Nevertheless, I find it strange to find a mail rejected by an rbl_client
made it's way to delivery.

Out of a single connection shown in the relevant portion of my maillog

http://users.seismic-media.co.uk/~ro...nsbl-query.txt

Most mails we're rejected and not queued. Why was the one addressed to
postmaster rejected but queued?

from main.cf
smtpd_client_restrictions = reject_rbl_client sbl-xbl.spamhaus.org

Thanks for any insight.

Rob
Reply With Quote
  #2 (permalink)  
Old 12-28-2005
Mr Rob Shepherd
 
Posts: n/a
Default Re: rbl_client - One slipped through

On Wed, 28 Dec 2005 12:53:25 +0000, Mr Rob Shepherd wrote:

> Hi.
>
> OK it's only one mail...
>
> Nevertheless, I find it strange to find a mail rejected by an rbl_client
> made it's way to delivery.
>
> Out of a single connection shown in the relevant portion of my maillog
>
> http://users.seismic-media.co.uk/~ro...nsbl-query.txt
>
> Most mails we're rejected and not queued. Why was the one addressed to
> postmaster rejected but queued?
>
> from main.cf
> smtpd_client_restrictions = reject_rbl_client sbl-xbl.spamhaus.org
>
> Thanks for any insight.
>
> Rob


Actually, strangely enough, This completely missed out

check_policy_service inet:127.0.0.1:10031

Is this time for me to upgrade versions? How do I find out the version
i'm running?

cheers

Rob

Reply With Quote
  #3 (permalink)  
Old 12-28-2005
Winfried Neessen
 
Posts: n/a
Default Re: rbl_client - One slipped through

* Mr Rob Shepherd <robshep@invalid.invalid> wrote:

> Actually, strangely enough, This completely missed out
> check_policy_service inet:127.0.0.1:10031
>

What kind of policy service is behind :10031?

The mail to postmaster@ went through most likely b/c of RFC 2142 which
says that mails to postmaster@ or abuse@ must always pass any check.

I'm not sure if reject_rbl_client takes care of this, but if not - you
have for sure an access list defined which allows mails to
postmaster@/abuse@ always to pass through.

> Is this time for me to upgrade versions? How do I find out the
> version i'm running?
>

Which version of what? Postfix or the policy deamon?

Winfried
--
Winfried Neessen (wn@neessen.net)
Send no mail to: nnfiwvwbx@this.is-dumb.de
Reply With Quote
  #4 (permalink)  
Old 12-28-2005
Mr Rob Shepherd
 
Posts: n/a
Default Re: rbl_client - One slipped through

On Wed, 28 Dec 2005 15:11:23 +0100, Winfried Neessen wrote:

> * Mr Rob Shepherd <robshep@invalid.invalid> wrote:
>
>> Actually, strangely enough, This completely missed out
>> check_policy_service inet:127.0.0.1:10031
>>

> What kind of policy service is behind :10031?
>


policyd (.sf.net) is a greylisting policy service.



> The mail to postmaster@ went through most likely b/c of RFC 2142 which
> says that mails to postmaster@ or abuse@ must always pass any check.
>


Aaah OK, thanks for this info, Winfried, I'll check this RFC next.

> I'm not sure if reject_rbl_client takes care of this, but if not - you
> have for sure an access list defined which allows mails to
> postmaster@/abuse@ always to pass through.


I'll look into this. I have no explicit access, but upon repeating the
trial from a different system, I notice postmaster is let through for
$myorigin but not for any other aliased domains or virtual domains.

>
>> Is this time for me to upgrade versions? How do I find out the
>> version i'm running?
>>

> Which version of what? Postfix or the policy deamon?



Postfix. I ran strings on some binaries and 2.1.5 is consistent. I'll
assume this is the version I have.

Thanks

Rob
Reply With Quote
  #5 (permalink)  
Old 12-29-2005
Winfried Neessen
 
Posts: n/a
Default Re: rbl_client - One slipped through

Hi Rob,

* Mr Rob Shepherd <robshep@invalid.invalid> wrote:

>> What kind of policy service is behind :10031?
>>

> policyd (.sf.net) is a greylisting policy service.
>

Ahh got it. I haven't used the greylisting policyd yet, as I use
policyd-weight[1]. But as the policy doesn't get initiazed, I think
the check_policy_service restiction is set below the reject_rbl_client
restictions in your main.cf - but to be sure, you need to post the
output of "postconf -n"

> I'll look into this. I have no explicit access, but upon repeating
> the trial from a different system, I notice postmaster is let
> through for $myorigin but not for any other aliased domains or
> virtual domains.
>

You should take care of this. Every (virtual)-domain needs to be
reachable via abuse@/postmaster@ if mail is sent or received through
this.

>> Which version of what? Postfix or the policy deamon?
>>

> Postfix. I ran strings on some binaries and 2.1.5 is consistent.
> I'll assume this is the version I have.
>

Much easier:
,----[ postconf | grep mail_version ]
| mail_version = 2.1.5
`----

Winfried


Footnotes:
----------
[1] http://www.policyd-weight.org
--
Winfried Neessen (wn{at}neessen.net)
Send no mail to: sphkjpgij@this.is-dumb.de
Reply With Quote
  #6 (permalink)  
Old 12-29-2005
Mr Rob Shepherd
 
Posts: n/a
Default Re: rbl_client - One slipped through

On Thu, 29 Dec 2005 01:02:09 +0100, Winfried Neessen wrote:

> But as the policy doesn't get initiazed, I think
> the check_policy_service restiction is set below the reject_rbl_client
> restictions in your main.cf - but to be sure, you need to post the
> output of "postconf -n"


OK then, Thanks Winfried.

These two are from different parameters. Is the order in which they are
updated in main.cf important?

alias_database = hash:/etc/mail/aliases
alias_maps = hash:/etc/mail/aliases, hash:/usr/local/mailman/data/aliases
command_directory = /usr/local/postfix/sbin
config_directory = /usr/local/postfix/etc
daemon_directory = /usr/local/postfix/libexec
debug_peer_level = 2
default_database_type = hash
header_checks = regexp:/usr/local/postfix/etc/hc_regex/sober.regex, regexp:/usr/local/postfix/etc/mime_header_checks.regexp
home_mailbox = .maildir/
html_directory = no
inet_interfaces = all
local_recipient_maps = unix:passwd.byname $alias_maps
mail_owner = postfix
mailq_path = /usr/localpostfix/bin/mailq
manpage_directory = /usr/local/postfix/man
mydestination = hash:/usr/local/postfix/etc/this_destination
newaliases_path = /usr/local/postfix/bin/newaliases
owner_request_special = no
queue_directory = /var/spool/postfix
readme_directory = no
relay_domains = hash:/usr/local/postfix/etc/relay_domains
relay_recipient_maps = hash:/usr/local/postfix/etc/relay_recipient_maps
relayhost = smtpauth.dsl.pipex.com
sample_directory = /usr/local/postfix/etc
sender_canonical_maps = hash:/usr/local/postfix/etc/sender_canonical
sendmail_path = /usr/local/postfix/lib/sendmail
setgid_group = postdrop
smtpd_client_restrictions = reject_rbl_client sbl-xbl.spamhaus.org
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, check_policy_service inet:127.0.0.1:10031
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/usr/local/postfix/etc/virtual_aliases, hash:/usr/local/mailman/data/virtual-mailman
virtual_gid_maps = static:12
virtual_mailbox_base = /home/vmailman
virtual_mailbox_domains = hash:/usr/local/postfix/etc/virtual_domains
virtual_mailbox_maps = hash:/usr/local/postfix/etc/virtual_users
virtual_minimum_uid = 100
virtual_uid_maps = static:9015



> You should take care of this. Every (virtual)-domain needs to be
> reachable via abuse@/postmaster@ if mail is sent or received through
> this.
>


Of course abuse and postmaster can receive mail from all domains this
system carries mail for, the aliases are in place, however
postmaster@myorigin is queued even if rbl fails, and never greylisted, but
postmaster@others follow the same restrictions as any other legitimate
mail..

>>> Which version of what? Postfix or the policy deamon?
>>>

>> Postfix. I ran strings on some binaries and 2.1.5 is consistent.
>> I'll assume this is the version I have.
>>

> Much easier:
> ,----[ postconf | grep mail_version ]
> | mail_version = 2.1.5
> `----


Cheers for that.

Many thanks, and cheers for any insight.

Rob

Reply With Quote
  #7 (permalink)  
Old 12-29-2005
Winfried Neessen
 
Posts: n/a
Default Re: rbl_client - One slipped through

* Mr Rob Shepherd <robshep@invalid.invalid> wrote:

> These two are from different parameters. Is the order in which they
> are updated in main.cf important?
>
> [...]
> smtpd_client_restrictions =
> reject_rbl_client sbl-xbl.spamhaus.org
> smtpd_recipient_restrictions =
> permit_mynetworks,
> reject_unauth_destination,
> reject_unlisted_recipient,
> check_policy_service inet:127.0.0.1:10031
>

As the smtpd_client_restrictions will be checked first, the mail
doesn't reach the policy daemon, as it already got blocked by the RBL.
So it is as I expected. Besides of this, you should have a look at the
UCE control page for postfix[1] and make your restrictions a little
bit more strict.

Winfried


Footnotes:
----------
[1] http://www.postfix.org/uce.html
--
Winfried Neessen (wn{at}neessen.net)
Send no mail to: gcsstfops@this.is-dumb.de
Reply With Quote
  #8 (permalink)  
Old 12-29-2005
Mr Rob Shepherd
 
Posts: n/a
Default Re: rbl_client - One slipped through

On Thu, 29 Dec 2005 17:26:55 +0100, Winfried Neessen wrote:
> As the smtpd_client_restrictions will be checked first, the mail
> doesn't reach the policy daemon, as it already got blocked by the RBL.
> So it is as I expected.


Negative. It did _not_ get blocked by the RBL. the RBL issued a *reject*,
as it did with all other requests in the connection, but postfix queued it
anyway and omitted a later check to the policy daemon.

This was the point of my original post - Does postmaster have special
rules? If postmaster@myorigin does, then why not postmaster@legit-domain

Besides of this, you should have a look at the
> UCE control page for postfix[1] and make your restrictions a little
> bit more strict.


I admit I haven't spent a huge amount of time on this, and with
greylisting I receive approx 0 UCEs per day, But I did trawl through this
guide before. Taking another look, there isn't anything that suggests
would make a huge improvement. However, is there anything you suggest?

Thanks

Rob

Reply With Quote
  #9 (permalink)  
Old 12-29-2005
Greg Hackney
 
Posts: n/a
Default Re: rbl_client - One slipped through


It's hard to tell since there's only an incomplete partial snippet from your log files,
but it sorta looks to me like the message that made it through is a completely
different mail message from the ones that were marked blocked by RBL.

The message that made it through had a message ID of:
<0374957522757.NE567@iprimus.com.au>

and passed through some filter you have installed:

relay=filter

--
Greg



Mr Rob Shepherd wrote:
> Hi.
>
> OK it's only one mail...
>
> Nevertheless, I find it strange to find a mail rejected by an rbl_client
> made it's way to delivery.
>
> Out of a single connection shown in the relevant portion of my maillog
>


> http://users.seismic-media.co.uk/~ro...nsbl-query.txt
>
> Most mails we're rejected and not queued. Why was the one addressed to
> postmaster rejected but queued?
>
> from main.cf
> smtpd_client_restrictions = reject_rbl_client sbl-xbl.spamhaus.org
>
> Thanks for any insight.
>
> Rob

Reply With Quote
  #10 (permalink)  
Old 12-30-2005
Mr Rob Shepherd
 
Posts: n/a
Default Re: rbl_client - One slipped through

On Thu, 29 Dec 2005 22:24:04 +0000, Greg Hackney wrote:

>
> It's hard to tell since there's only an incomplete partial snippet from your log files,
> but it sorta looks to me like the message that made it through is a completely
> different mail message from the ones that were marked blocked by RBL.
>
> The message that made it through had a message ID of:
> <0374957522757.NE567@iprimus.com.au>
>
> and passed through some filter you have installed:
>
> relay=filter
>


It is the same message. The headers of the message show this. Header
pasted below.

The message did pass through the filter. As you can see, the queue
changes as it is fed through the filter. (uid=9022)

However, the strangeness of this scenario is regardless of this.

One can see that it is taken initially as queue id 14415A6ABA....
The log shows this queue id gets rejected by the rbl but is queued anyway
and doesn't pass through the policyd service as mentioned in another part
of the thread.

The strangest points about this transfer is.

1. The message according to the output of the rbl_check is addressed to
root but all other transfer info see postmaster. At the time of rbl_check
(RCPT TO) only the envelope has been seen.

2. The message is queued even when rejected by rbl_check

3. The message is not send through the policy service

4. I can recreate (3) using telnet but only ever for
postmaster@'$myorigin' not for root, other users or any other legitimate
domain.

Strangeness.

I shall upgrade to 2.2 in the new year.

Thanks

Rob


Return-Path: <spence@mypersonalemail.com>
X-Original-To: postmaster@example.com
Delivered-To: robshep@example.com
Received: by mailserver1.example.com (Postfix, from userid 9022)
id 0C855A6ABC; Wed, 28 Dec 2005 09:39:15 +0000 (GMT)
Received: from pcp03885075pcs.radnor01.pa.comcast.net
(pcp03885075pcs.radnor01.pa.comcast.net [68.32.19.98])
by mailserver1.example.com (Postfix) with SMTP id 14415A6ABA
for <postmaster@example.com>; Wed, 28 Dec 2005 09:38:54 +0000 (GMT)
X-Message-Info: 286zsyLJrcpW69TCh42yhbBOCfaO02Y15bskTQZpcdGTF5
Received: from dns9iprimus.com.au (6.216.61.60) by ann10-iuu47.cyber.net.pk
with Microsoft SMTPSVC(5.0.2195.6824);
Wed, 28 Dec 2005 04:28:43 -0500
Received: from crstudio.it (127.0.0.1) by dnszoznam.sk
(SMTPD32-7.12 ) id EPY2XR502; Wed, 28 Dec 2005 02:27:43 -0700
Subject: Re: your web site details..
From: Olive@example.com, Hayden@example.com
To: accounting@example.com
Message-Id: <0374957522757.NE567@iprimus.com.au >
Content-Type: multipart/alternative;
boundary="--611943660938597"
Date: Wed, 28 Dec 2005 09:38:54 +0000 (GMT)

----611943660938597
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable


Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 11:44 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0