Logging DNSBL rejections

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Logging DNSBL rejections

Narcis Garcia
Hello;

I'm working with Debian GNU/Linux 7 and Postfix 2.9.6
I've configured a Postfix service with this (real rbl instead of example):

$ postconf -e 'smtpd_recipient_restrictions =
permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,reject_rbl_client
rbl.example.net'

$ postconf -e 'postscreen_dnsbl_sites = rbl.example.net'

$ service postfix reload

Spam delivery has been reduced with this, but I cannot investigate false
positives because nothing of this (RBL) is logged to /var/log/mail.log
nor /var/log/syslog

What do I need to do to Postfix logs DNSBL/RBL events?

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Wietse Venema
Narcis Garcia:

> Hello;
>
> I'm working with Debian GNU/Linux 7 and Postfix 2.9.6
> I've configured a Postfix service with this (real rbl instead of example):
>
> $ postconf -e 'smtpd_recipient_restrictions =
> permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,reject_rbl_client
> rbl.example.net'
>
> $ postconf -e 'postscreen_dnsbl_sites = rbl.example.net'
>
> $ service postfix reload
>
> Spam delivery has been reduced with this, but I cannot investigate false
> positives because nothing of this (RBL) is logged to /var/log/mail.log
> nor /var/log/syslog
>
> What do I need to do to Postfix logs DNSBL/RBL events?

Postfix logs all rejects, and all successful/failed deliveries with
severity mail.info. It is possible that you have Postfix chroot
turned on without proper configuration.

In master.cf, change the fourth column into 'n' in the line "smtp
.... smtpd".  Then type "postfix reload" and see if your SMTP server
logging is fixed.

Then, fix the fourth column of all other Postfix services, too.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Narcis Garcia
In reply to this post by Narcis Garcia
Doing this (unpriv to n) and restarting service I get the following from
/var/log/mail.log :

error: incorrect SMTP server privileges: uid=0 euid=0
fatal: the Postfix SMTP server must run with $mail_owner privileges
warning: process /usr/lib/postfix/smtpd pid 14987 exit status 1
warning: /usr/lib/postfix/smtpd: bad command startup -- throttling

$ postconf | grep -e 'mail_owner'
mail_owner = postfix


El 01/07/14 16:30, Wietse Venema ha escrit:

> Narcis Garcia:
>> Hello;
>>
>> I'm working with Debian GNU/Linux 7 and Postfix 2.9.6
>> I've configured a Postfix service with this (real rbl instead of example):
>>
>> $ postconf -e 'smtpd_recipient_restrictions =
>> permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,reject_rbl_client
>> rbl.example.net'
>>
>> $ postconf -e 'postscreen_dnsbl_sites = rbl.example.net'
>>
>> $ service postfix reload
>>
>> Spam delivery has been reduced with this, but I cannot investigate false
>> positives because nothing of this (RBL) is logged to /var/log/mail.log
>> nor /var/log/syslog
>>
>> What do I need to do to Postfix logs DNSBL/RBL events?
>
> Postfix logs all rejects, and all successful/failed deliveries with
> severity mail.info. It is possible that you have Postfix chroot
> turned on without proper configuration.
>
> In master.cf, change the fourth column into 'n' in the line "smtp
> .... smtpd".  Then type "postfix reload" and see if your SMTP server
> logging is fixed.
>
> Then, fix the fourth column of all other Postfix services, too.
>
> Wietse
>
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Wietse Venema
Narcis Garcia:
> Doing this (unpriv to n) and restarting service I get the following from
> /var/log/mail.log :

Should be: the chroot column that's fifth. My mistake.

> error: incorrect SMTP server privileges: uid=0 euid=0
> fatal: the Postfix SMTP server must run with $mail_owner privileges
> warning: process /usr/lib/postfix/smtpd pid 14987 exit status 1
> warning: /usr/lib/postfix/smtpd: bad command startup -- throttling
>
> $ postconf | grep -e 'mail_owner'
> mail_owner = postfix
>
>
> El 01/07/14 16:30, Wietse Venema ha escrit:
> > Narcis Garcia:
> >> Hello;
> >>
> >> I'm working with Debian GNU/Linux 7 and Postfix 2.9.6
> >> I've configured a Postfix service with this (real rbl instead of example):
> >>
> >> $ postconf -e 'smtpd_recipient_restrictions =
> >> permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,reject_rbl_client
> >> rbl.example.net'
> >>
> >> $ postconf -e 'postscreen_dnsbl_sites = rbl.example.net'
> >>
> >> $ service postfix reload
> >>
> >> Spam delivery has been reduced with this, but I cannot investigate false
> >> positives because nothing of this (RBL) is logged to /var/log/mail.log
> >> nor /var/log/syslog
> >>
> >> What do I need to do to Postfix logs DNSBL/RBL events?
> >
> > Postfix logs all rejects, and all successful/failed deliveries with
> > severity mail.info. It is possible that you have Postfix chroot
> > turned on without proper configuration.
> >
> > In master.cf, change the fourth column into 'n' in the line "smtp
> > .... smtpd".  Then type "postfix reload" and see if your SMTP server
> > logging is fixed.
> >
> > Then, fix the fourth column of all other Postfix services, too.
> >
> > Wietse
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Narcis Garcia
In reply to this post by Narcis Garcia
Note that with default configuration Potstfix is already logging all
other events, except RBL ones, because in Debian chroot logging by
syslog is well configured in /etc/rsyslog.d/postfix.conf

I've deactivated temporarily chroot, and I'm still waiting if there is
some news about reject_rbl_client events being logged.


El 01/07/14 16:47, Narcis Garcia ha escrit:

> Doing this (unpriv to n) and restarting service I get the following from
> /var/log/mail.log :
>
> error: incorrect SMTP server privileges: uid=0 euid=0
> fatal: the Postfix SMTP server must run with $mail_owner privileges
> warning: process /usr/lib/postfix/smtpd pid 14987 exit status 1
> warning: /usr/lib/postfix/smtpd: bad command startup -- throttling
>
> $ postconf | grep -e 'mail_owner'
> mail_owner = postfix
>
>
> El 01/07/14 16:30, Wietse Venema ha escrit:
>> Narcis Garcia:
>>> Hello;
>>>
>>> I'm working with Debian GNU/Linux 7 and Postfix 2.9.6
>>> I've configured a Postfix service with this (real rbl instead of example):
>>>
>>> $ postconf -e 'smtpd_recipient_restrictions =
>>> permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,reject_rbl_client
>>> rbl.example.net'
>>>
>>> $ postconf -e 'postscreen_dnsbl_sites = rbl.example.net'
>>>
>>> $ service postfix reload
>>>
>>> Spam delivery has been reduced with this, but I cannot investigate false
>>> positives because nothing of this (RBL) is logged to /var/log/mail.log
>>> nor /var/log/syslog
>>>
>>> What do I need to do to Postfix logs DNSBL/RBL events?
>>
>> Postfix logs all rejects, and all successful/failed deliveries with
>> severity mail.info. It is possible that you have Postfix chroot
>> turned on without proper configuration.
>>
>> In master.cf, change the fourth column into 'n' in the line "smtp
>> .... smtpd".  Then type "postfix reload" and see if your SMTP server
>> logging is fixed.
>>
>> Then, fix the fourth column of all other Postfix services, too.
>>
>> Wietse
>>
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Wietse Venema
Narcis Garcia:
> Note that with default configuration Potstfix is already logging all
> other events, except RBL ones, because in Debian chroot logging by
> syslog is well configured in /etc/rsyslog.d/postfix.conf
>
> I've deactivated temporarily chroot, and I'm still waiting if there is
> some news about reject_rbl_client events being logged.

Postfix logs all rejects and all successful/failed deliveries with
severity mail.info. It has done this since 1997 before it was even
named Postfix.

To find out where mail.info is logged:

    $ logger -p mail.info this is a test...

and watch your logfiles for changes.

If your syslog daemon logs mail.info in a different file than
warnings or errors, then that just makes logfile analysis more
difficult than it needs to be.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Narcis Garcia
In reply to this post by Narcis Garcia
No log to mail.info file about rbl/dnsbl until now.
I've restored chroot option to default for smtp service.

$ logger -p mail.info this is a test
$ cat /var/log/mail.info | grep -e 'a test'

2014-07-01T17:43:17.257348+02:00 hostname username: this is a test



El 01/07/14 17:30, Wietse Venema ha escrit:

> Narcis Garcia:
>> Note that with default configuration Potstfix is already logging all
>> other events, except RBL ones, because in Debian chroot logging by
>> syslog is well configured in /etc/rsyslog.d/postfix.conf
>>
>> I've deactivated temporarily chroot, and I'm still waiting if there is
>> some news about reject_rbl_client events being logged.
>
> Postfix logs all rejects and all successful/failed deliveries with
> severity mail.info. It has done this since 1997 before it was even
> named Postfix.
>
> To find out where mail.info is logged:
>
>     $ logger -p mail.info this is a test...
>
> and watch your logfiles for changes.
>
> If your syslog daemon logs mail.info in a different file than
> warnings or errors, then that just makes logfile analysis more
> difficult than it needs to be.
>
> Wietse
>
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Narcis Garcia
In reply to this post by Narcis Garcia
How can I check in some manner that some of these parameters is working?

reject_rbl_client
reject_rhsbl_reverse_client
reject_rhsbl_helo
reject_rhsbl_sender


El 01/07/14 17:46, Narcis Garcia ha escrit:

> No log to mail.info file about rbl/dnsbl until now.
> I've restored chroot option to default for smtp service.
>
> $ logger -p mail.info this is a test
> $ cat /var/log/mail.info | grep -e 'a test'
>
> 2014-07-01T17:43:17.257348+02:00 hostname username: this is a test
>
>
>
> El 01/07/14 17:30, Wietse Venema ha escrit:
>> Narcis Garcia:
>>> Note that with default configuration Potstfix is already logging all
>>> other events, except RBL ones, because in Debian chroot logging by
>>> syslog is well configured in /etc/rsyslog.d/postfix.conf
>>>
>>> I've deactivated temporarily chroot, and I'm still waiting if there is
>>> some news about reject_rbl_client events being logged.
>>
>> Postfix logs all rejects and all successful/failed deliveries with
>> severity mail.info. It has done this since 1997 before it was even
>> named Postfix.
>>
>> To find out where mail.info is logged:
>>
>>     $ logger -p mail.info this is a test...
>>
>> and watch your logfiles for changes.
>>
>> If your syslog daemon logs mail.info in a different file than
>> warnings or errors, then that just makes logfile analysis more
>> difficult than it needs to be.
>>
>> Wietse
>>
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Wietse Venema
Narcis Garcia:
> How can I check in some manner that some of these parameters is working?
>
> reject_rbl_client
> reject_rhsbl_reverse_client
> reject_rhsbl_helo
> reject_rhsbl_sender

How can WE check that you have configured them properly?

It is possible to configure these so that they will never fire.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Stan Hoeppner
On 7/1/2014 11:18 AM, Wietse Venema wrote:

> Narcis Garcia:
>> How can I check in some manner that some of these parameters is working?
>>
>> reject_rbl_client
>> reject_rhsbl_reverse_client
>> reject_rhsbl_helo
>> reject_rhsbl_sender
>
> How can WE check that you have configured them properly?
>
> It is possible to configure these so that they will never fire.

Very true.  For example, if you are using your ISP's resolvers to query
a Spamhaus DNSBL the query may be rejected due to terms of usage
violation.  Temporary DNS problems will also cause query failures.

You need to test your queries to your DNSBLs.  Each one should have
instructions on their website telling you how.  Here are the Spamhaus
instructions:

http://www.spamhaus.org/faq/section/DNSBL%20Usage#366

Cheers,

Stan
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Narcis Garcia
In reply to this post by Wietse Venema
Is there any website or service in internet to send a mail test from a
blacklisted IP?


El 01/07/14 19:12, Stan Hoeppner ha escrit:

> On 7/1/2014 11:18 AM, Wietse Venema wrote:
>> Narcis Garcia:
>>> How can I check in some manner that some of these parameters is working?
>>>
>>> reject_rbl_client
>>> reject_rhsbl_reverse_client
>>> reject_rhsbl_helo
>>> reject_rhsbl_sender
>>
>> How can WE check that you have configured them properly?
>>
>> It is possible to configure these so that they will never fire.
>
> Very true.  For example, if you are using your ISP's resolvers to query
> a Spamhaus DNSBL the query may be rejected due to terms of usage
> violation.  Temporary DNS problems will also cause query failures.
>
> You need to test your queries to your DNSBLs.  Each one should have
> instructions on their website telling you how.  Here are the Spamhaus
> instructions:
>
> http://www.spamhaus.org/faq/section/DNSBL%20Usage#366
>
> Cheers,
>
> Stan
>
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Wietse Venema
Narcis Garcia:
> Is there any website or service in internet to send a mail test from a
> blacklisted IP?

Yes. telnet to 127.0.0.2 port 25.

        Wietse

>
> El 01/07/14 19:12, Stan Hoeppner ha escrit:
> > On 7/1/2014 11:18 AM, Wietse Venema wrote:
> >> Narcis Garcia:
> >>> How can I check in some manner that some of these parameters is working?
> >>>
> >>> reject_rbl_client
> >>> reject_rhsbl_reverse_client
> >>> reject_rhsbl_helo
> >>> reject_rhsbl_sender
> >>
> >> How can WE check that you have configured them properly?
> >>
> >> It is possible to configure these so that they will never fire.
> >
> > Very true.  For example, if you are using your ISP's resolvers to query
> > a Spamhaus DNSBL the query may be rejected due to terms of usage
> > violation.  Temporary DNS problems will also cause query failures.
> >
> > You need to test your queries to your DNSBLs.  Each one should have
> > instructions on their website telling you how.  Here are the Spamhaus
> > instructions:
> >
> > http://www.spamhaus.org/faq/section/DNSBL%20Usage#366
> >
> > Cheers,
> >
> > Stan
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Narcis Garcia
In reply to this post by Narcis Garcia
if I run mail command or swaks, they both make Postfix to send with SMTP
from 127.0.0.1 or public IP. Never 127.0.0.2

Can I tell Postfix to make 1 mail sending from 127.0.0.2 ?
If so, I suppose the SMTP service listening at TCP/25 will receive the
local communication from 127.0.0.2 (?)

Thanks for all the answers.


El 01/07/14 19:58, Wietse Venema ha escrit:
> Narcis Garcia:
>> Is there any website or service in internet to send a mail test from a
>> blacklisted IP?
>
> Yes. telnet to 127.0.0.2 port 25.
>
> Wietse

Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Stan Hoeppner
On 7/1/2014 2:21 PM, Narcis Garcia wrote:
> if I run mail command or swaks, they both make Postfix to send with SMTP
> from 127.0.0.1 or public IP. Never 127.0.0.2
>
> Can I tell Postfix to make 1 mail sending from 127.0.0.2 ?
> If so, I suppose the SMTP service listening at TCP/25 will receive the
> local communication from 127.0.0.2 (?)

You've completely lost your way, you're confused.  DNSBL tests are on
inbound connections.  Here you're talking about sending mail outbound.
I think Wietse's answer confused you.

Why are you averse to using the standard tools that everyone uses to
test DNSBL queries, mainly 'host' and 'dig'?  This is all that's needed
to confirm your IP DNSBL queries are working, assuming you execute them
with the same user permissions as Postfix.

Cheers,

Stan




> El 01/07/14 19:58, Wietse Venema ha escrit:
>> Narcis Garcia:
>>> Is there any website or service in internet to send a mail test from a
>>> blacklisted IP?
>>
>> Yes. telnet to 127.0.0.2 port 25.
>>
>> Wietse
>
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Wietse Venema
In reply to this post by Narcis Garcia
Narcis Garcia:
> if I run mail command or swaks, they both make Postfix to send with SMTP
> from 127.0.0.1 or public IP. Never 127.0.0.2

$ telnet 127.0.0.2 25

Then type the SMTP commands.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Narcis Garcia
In reply to this post by Narcis Garcia
At this moment I don't want to check manually if an IP is blacklisted or
not (I already had made that exercise).

I want my Postfix installation presents a REJECTION to me. I'm looking
for a way to send a mail because I want to reach my Postfix and it
REJECTS it due to DNSBL rule.

If it cannot be done, then I'll need to setup my own DNSBL to manually
blacklist another IP (p.e. in the LAN);

www DOT zytrax DOT com/books/dns/ch9/dnsbl.html


El 01/07/14 21:38, Stan Hoeppner ha escrit:

> On 7/1/2014 2:21 PM, Narcis Garcia wrote:
>> if I run mail command or swaks, they both make Postfix to send with SMTP
>> from 127.0.0.1 or public IP. Never 127.0.0.2
>>
>> Can I tell Postfix to make 1 mail sending from 127.0.0.2 ?
>> If so, I suppose the SMTP service listening at TCP/25 will receive the
>> local communication from 127.0.0.2 (?)
>
> You've completely lost your way, you're confused.  DNSBL tests are on
> inbound connections.  Here you're talking about sending mail outbound.
> I think Wietse's answer confused you.
>
> Why are you averse to using the standard tools that everyone uses to
> test DNSBL queries, mainly 'host' and 'dig'?  This is all that's needed
> to confirm your IP DNSBL queries are working, assuming you execute them
> with the same user permissions as Postfix.
>
> Cheers,
>
> Stan
>
>
>
>
>> El 01/07/14 19:58, Wietse Venema ha escrit:
>>> Narcis Garcia:
>>>> Is there any website or service in internet to send a mail test from a
>>>> blacklisted IP?
>>>
>>> Yes. telnet to 127.0.0.2 port 25.
>>>
>>> Wietse
>>
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Wietse Venema
Narcis Garcia:
> At this moment I don't want to check manually if an IP is blacklisted or
> not (I already had made that exercise).
>
> I want my Postfix installation presents a REJECTION to me. I'm looking
> for a way to send a mail because I want to reach my Postfix and it
> REJECTS it due to DNSBL rule.

Telnet to 127.0.0.2 port 25 then send mail.

THIS MAIL SHOULD BE REJECTED by Postfix because almost every DNSBL
uses 127.0.0.2 as a test pattern.

This is my final attempt to help you.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Benny Pedersen-2
On 1. jul. 2014 22.00.22 CEST, [hidden email] wrote:

>Narcis Garcia:
>> At this moment I don't want to check manually if an IP is blacklisted
>or
>> not (I already had made that exercise).
>>
>> I want my Postfix installation presents a REJECTION to me. I'm
>looking
>> for a way to send a mail because I want to reach my Postfix and it
>> REJECTS it due to DNSBL rule.
>
>Telnet to 127.0.0.2 port 25 then send mail.
>
>THIS MAIL SHOULD BE REJECTED by Postfix because almost every DNSBL
>uses 127.0.0.2 as a test pattern.
>
>This is my final attempt to help you.

For the record here, his postfix might not listen on 127.0.0.2, and 127.0.0.2 is not a ip, its a result code

Confusing result code and telnet ip
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Wietse Venema
Benny Pedersen:
[ Charset UTF-8 unsupported, converting... ]

> On 1. jul. 2014 22.00.22 CEST, [hidden email] wrote:
> >Narcis Garcia:
> >> At this moment I don't want to check manually if an IP is blacklisted
> >or
> >> not (I already had made that exercise).
> >>
> >> I want my Postfix installation presents a REJECTION to me. I'm
> >looking
> >> for a way to send a mail because I want to reach my Postfix and it
> >> REJECTS it due to DNSBL rule.
> >
> >Telnet to 127.0.0.2 port 25 then send mail.
> >
> >THIS MAIL SHOULD BE REJECTED by Postfix because almost every DNSBL
> >uses 127.0.0.2 as a test pattern.
> >
> >This is my final attempt to help you.
>
> For the record here, his postfix might not listen on 127.0.0.2, and 127.0.0.2 is not a ip, its a result code
>
> Confusing result code and telnet ip

Benny you have no idea what you are talking about.

When a client connects from 127.0.0.2, the Postfix DNSBL client
will make a query, for example, for 2.0.0.127.zen.spamhaus.org.

    2.0.0.127.zen.spamhaus.org has address 127.0.0.4
    2.0.0.127.zen.spamhaus.org has address 127.0.0.10
    2.0.0.127.zen.spamhaus.org has address 127.0.0.2

That can be used to trigger a reject when the client sends mail.

The only glitch is that by default,

    telnet 127.0.0.1 smtp

results in

    Jul  1 17:09:57 wzv postfix/smtpd[13454]: connect from localhost[127.0.0.1]

But that is easily fixed with "ifconfig lo 127.0.0.2 netmask 255.0.0.0".

    Jul  1 17:11:24 wzv postfix/smtpd[13454]: connect from unknown[127.0.0.2]

(and don't forget to reset the lo address to 127.0.0.1).

QED. Now, if the OP were only willing to cooperate he could have
had his answer hours ago.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Logging DNSBL rejections

Wietse Venema
My reply had one typo. This is the fixed version.

When a client connects from 127.0.0.2, the Postfix DNSBL client
will make a query, for example, for 2.0.0.127.zen.spamhaus.org.

    2.0.0.127.zen.spamhaus.org has address 127.0.0.4
    2.0.0.127.zen.spamhaus.org has address 127.0.0.10
    2.0.0.127.zen.spamhaus.org has address 127.0.0.2

That can be used to trigger a reject when the client sends mail.

The only glitch is that by default,

    telnet 127.0.0.2 smtp

results in

    Jul  1 17:09:57 wzv postfix/smtpd[13454]: connect from localhost[127.0.0.1]

But that is easily fixed with "ifconfig lo 127.0.0.2 netmask 255.0.0.0".

    Jul  1 17:11:24 wzv postfix/smtpd[13454]: connect from unknown[127.0.0.2]

QED. Now, if the OP were only willing to cooperate he could have
had his answer hours ago.

        Wietse

12