RBL problems affect mail reception

[Oguz Yilmaz]

Hi,

On my postfix mail server I have RBL definitions at
smtpd_client_restrictions phase. At the moment 2 of 4 rbl's waiting until
tcp timeout without an answer when I try with nslookup. This affects my
clients. Also client programs are waiting for sending e-mail. Is there any
way to put some timeout or any other resoluton for the problem?

Regards,

Oguz Yilmaz

smtpd_client_restrictions =
 check_client_access hash:/etc/postfix/access,
 permit_sasl_authenticated,
 permit_mynetworks,
 reject_rbl_client dnsbl.sorbs.net,
 reject_rbl_client dnsbl.njabl.org,
 reject_rbl_client cbl.abuseat.org,
 reject_rbl_client bl.spamcop.net,
 permit

Re: not receiveing bounce backs when using postfix

[Barney Desmond]

2009/4/4  :
>
> Apr  3 23:32:11 mail postfix/smtp[6451]: 96B0EB8: to=,
> relay=b.mx.mail.yahoo.com[66.196.97.250]:25, delay=0.38,
> delays=0.28/0.01/0.05/0.04, dsn=5.0.0, status=bounced (host
> b.mx.mail.yahoo.com[66.196.97.250] said: 554 delivery error: dd This user
> doesn't have a yahoo.com account (df...@yahoo.com) [-5] -
> mta241.mail.re3.yahoo.com (in reply to end of DATA command))
> Apr  3 23:32:11 mail postfix/cleanup[7281]: 2ACDFBA:
> message-id=<20090404033211.2acd...@mail.firstfinancial.org>
> Apr  3 23:32:11 mail postfix/bounce[31334]: 96B0EB8: sender non-delivery
> notification: 2ACDFBA

Show more logs. 96B0EB8 is the failed delivery to yahoo, 2ACDFBA is
the non-delivery notification that postfix will attempt to pass back
to Exchange. You need to find where that non-delivery notification has
gone.

Re: header_checks doesn't work (postfix 2.5.5 on debian lenny)

[Magnus Bäck]

On Friday, April 03, 2009 at 18:50 CEST,
 sosogh  wrote:

[...]

> [r...@postfix]# more recipient_access.txt 
> /special.com/   FILTER smtp:[127.0.0.1]:10026 

This regular expression will match not only special.com but also
especial.com, a.special.company.net etc. Consider writing a proper
regular expression or just use a regular indexed map. You don't need
PCRE for this.

[...]

-- 
Magnus Bäck
mag...@dsek.lth.se

Re: not receiveing bounce backs when using postfix

[Wietse Venema]

nr...@firstfinancial.org:
> Thanks for the fast reply.
> 
> I fixed the logging issue.
> 
> >From the /var/log/maillog
> 
> Apr  3 23:32:11 mail postfix/smtp[6451]: 96B0EB8: to=,
> relay=b.mx.mail.yahoo.com[66.196.97.250]:25, delay=0.38,
> delays=0.28/0.01/0.05/0.04, dsn=5.0.0, status=bounced (host
> b.mx.mail.yahoo.com[66.196.97.250] said: 554 delivery error: dd This user
> doesn't have a yahoo.com account (df...@yahoo.com) [-5] -
> mta241.mail.re3.yahoo.com (in reply to end of DATA command))
> Apr  3 23:32:11 mail postfix/cleanup[7281]: 2ACDFBA:
> message-id=<20090404033211.2acd...@mail.firstfinancial.org>
> Apr  3 23:32:11 mail postfix/bounce[31334]: 96B0EB8: sender non-delivery
> notification: 2ACDFBA

Do:

$ grep 2ACDFBA /var/log/maillog

Wietse

Re: RBL problems affect mail reception

[Sahil Tandon]

On Sat, 04 Apr 2009, Oguz Yilmaz wrote:

> On my postfix mail server I have RBL definitions at
> smtpd_client_restrictions phase. At the moment 2 of 4 rbl's waiting until
> tcp timeout without an answer when I try with nslookup. This affects my
> clients. Also client programs are waiting for sending e-mail. Is there any
> way to put some timeout or any other resoluton for the problem?

If clients and their programs are "trusted" senders, then exclude them from
RBL checks.

-- 
Sahil Tandon 

new clamav-milter quarantaine in hold queue script

[Robert Schetterer]

Hi, the redesign
of the  clamav-milter 0.95
does quarantaine in the hold queue
before infected mails were written to some configurable dir

havening them in hold is a nice option
but i am thinking of a script
getting them out of hold and store
in the filesystem and clean up hold

i have some clean mailerdaemon script
which works likely  for deferred started by cron

whats your opinion does it sound like a good
idea , i dont like the idea that infected mails may i.e hold forever

or is there a way, yet ,of configure postfix to unhold
them and delete by a configured time period

after all i ve asked clamav developers to bring back
store in filesystem option, which makes it more easy to investigate
infected mails cause sometimes false positives happens
with anitpishing code etc

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: not receiveing bounce backs when using postfix

[Wietse Venema]

nr...@firstfinancial.org:
> Here is the output.
> 
> # grep 2ACDFBA /var/log/maillog
> Apr  3 23:32:11 triton postfix/cleanup[7281]: 2ACDFBA:
> message-id=<20090404033211.2acd...@mail.firstfinancial.org>
> Apr  3 23:32:11 triton postfix/bounce[31334]: 96B0EB8: sender non-delivery
> notification: 2ACDFBA
> Apr  3 23:32:11 triton postfix/smtp[8455]: 2ACDFBA:
> to=, relay=none, delay=0.19,
> delays=0.14/0.05/0/0, dsn=5.4.4, status=bounced (Host or domain name not
> found. Name service error for name=firstfinancial.org type=: Host found
> but no data record of requested type)

2ACDFBA Is the Postfix bounce message, directed to the sender
address of message 96B0EB8 that could not be delivered.

If you want to find out why this bounce message is undeliverable,
see the mailing list welcome message below.

Wietse

TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail

TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Thank you for using Postfix.

Re: new clamav-milter quarantaine in hold queue script

[Victor Duchovni]

On Sat, Apr 04, 2009 at 06:16:33PM +0200, Robert Schetterer wrote:

> havening them in hold is a nice option
> but i am thinking of a script
> getting them out of hold and store
> in the filesystem and clean up hold

Here's my suggestion:

- Create a second Postfix instance in the same file-system.
- Run a cron job to move (rename(2)) messages from the HOLD queue
  of the main instance into the deferred queue of the second instance,
  carefully respecting the hash_depth of each directory.
- In the second instance, deliver all mail via a suitable daemonized
  SMTP server or via pipe(8) script. The daemon or script will be
  the entry point into a quarantine system that eventualy expires
  unclaimed mail, generates reports and allows other administrative
  or user actions as you see fit.

This means that "FILTER transport:nexthop" is perhaps a better choice than
"HOLD", but milters may not be able to express this action...

I am not aware of an open-source quarantine add-on for Postfix.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: new clamav-milter quarantaine in hold queue script

[Robert Schetterer]

Victor Duchovni schrieb:
> On Sat, Apr 04, 2009 at 06:16:33PM +0200, Robert Schetterer wrote:
> 
>> havening them in hold is a nice option
>> but i am thinking of a script
>> getting them out of hold and store
>> in the filesystem and clean up hold
> 
> Here's my suggestion:
> 
> - Create a second Postfix instance in the same file-system.
> - Run a cron job to move (rename(2)) messages from the HOLD queue
>   of the main instance into the deferred queue of the second instance,
>   carefully respecting the hash_depth of each directory.
> - In the second instance, deliver all mail via a suitable daemonized
>   SMTP server or via pipe(8) script. The daemon or script will be
>   the entry point into a quarantine system that eventualy expires
>   unclaimed mail, generates reports and allows other administrative
>   or user actions as you see fit.
> 
> This means that "FILTER transport:nexthop" is perhaps a better choice than
> "HOLD", but milters may not be able to express this action...
> 
> I am not aware of an open-source quarantine add-on for Postfix.
> 

Hi Victor, this sounds very complicated
i was thinking more about a cron cript like this ( surly modified to the
hold issue )




#!/bin/sh

# we need to clean up MAILER-DAEMON messages

#try to deliver by force
#postqueue -f

#now its time to kill the rest

TMPFILE=/tmp/clean.queue.$$
DEFERDIR=/var/spool/postfix/deferred

# collect the filenames
mailq |grep MAILER-DAEMON | cut -f1 -d ' ' > $TMPFILE

for DEFERFILE in `cat $TMPFILE`
do
   FILEPATH=`find $DEFERDIR -name $DEFERFILE`


#echo "$FILEPATH" #for debug
#echo "$DEFERFILE" #for debug

#
# checks in use with spamass.
#
#  egrep -i 'spamassassin|hits\=[0-9]{1,2}\.[0-9]' $FILEPATH >
/dev/null
#  if [ $? -eq 0 ]
#  then
#   deferred message is most likely spam
##
   postsuper -d $DEFERFILE deferred
#  fi
done

rm -f $TMPFILE > /dev/null


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: new clamav-milter quarantaine in hold queue script

[Victor Duchovni]

On Sat, Apr 04, 2009 at 07:01:08PM +0200, Robert Schetterer wrote:

> > Here's my suggestion:
> > 
> > - Create a second Postfix instance in the same file-system.
> > - Run a cron job to move (rename(2)) messages from the HOLD queue
> >   of the main instance into the deferred queue of the second instance,
> >   carefully respecting the hash_depth of each directory.
> > - In the second instance, deliver all mail via a suitable daemonized
> >   SMTP server or via pipe(8) script. The daemon or script will be
> >   the entry point into a quarantine system that eventualy expires
> >   unclaimed mail, generates reports and allows other administrative
> >   or user actions as you see fit.
> > 
> > This means that "FILTER transport:nexthop" is perhaps a better choice than
> > "HOLD", but milters may not be able to express this action...
> > 
> > I am not aware of an open-source quarantine add-on for Postfix.
> 
> Hi Victor, this sounds very complicated

Yes, I am proposing a robust, comprehensive system that could serve a
variety of needs.

> i was thinking more about a cron cript like this ( surly modified to the
> hold issue )

What do mail-daemon messages have to do with junk placed in the HOLD
queue by a milter

> TMPFILE=/tmp/clean.queue.$$
> DEFERDIR=/var/spool/postfix/deferred
> 
> # collect the filenames
> mailq |grep MAILER-DAEMON | cut -f1 -d ' ' > $TMPFILE
> 
> for DEFERFILE in `cat $TMPFILE`
> do
>FILEPATH=`find $DEFERDIR -name $DEFERFILE`

This is subject to race-conditions, because queue-ids can be re-used.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Backscatter

[LuKreme]

I've seen an increase in backscatter emails recently. Perfectly valid  
headers (AFAICT)


Return-Path: <>
X-Original-To: kr...@kreme.com
Delivered-To: kr...@covisp.net
Received: from mail9.webair.com (mail9.webair.net [74.206.236.69])
by mail.covisp.net (Postfix) with ESMTPS id 4FC10118B5B0
for ; Sat,  4 Apr 2009 00:18:38 -0600 (MDT)
Received: (qmail 45760 invoked for bounce); 4 Apr 2009 06:18:36 -
Date: 4 Apr 2009 06:18:36 -
From: mailer-dae...@mail9.webair.com
To: kr...@kreme.com
Subject: failure notice
Message-Id: <20090404061838.4fc10118b...@mail.covisp.net>

But the message they are bouncing is not mine:

--- Below this line is a copy of the message.

Return-Path: 
Received: (qmail 45698 invoked by uid 89); 4 Apr 2009 06:18:34 -
Received: from unknown (HELO m4mlux-m4f14) (85.9.127.134)
 by mail9.webair.com with SMTP; 4 Apr 2009 06:18:34 -
Received-SPF: neutral (mail9.webair.com: 85.9.127.134 is neither  
permitted nor denied by SPF record at kreme.com)

Message-ID: <20090404134844.3352.qm...@m4mlux-m4f14>
To: dav...@kremefresh.com
Reply-To: dav...@kremefresh.com
Subject: RE:U.S.A. Pharmacy Discount ID948168547


(I did just update this spf record to "v=spf1 a mx  
ip4:75.148.117.94/29 ~all" which I expect will help some)


Is there some sort of strategy I can implement that will reject a good  
portion of these kinds of messages? What are other people doing to  
deal with backscatter? I read up on SRS, but it doesn't sound like a  
great idea.


--
Satan oscillate my metallic sonatas

Cannot use restrictions to block emails between local users.

[Xn Nooby]

I am working on a Webmail solution, that uses Squirrelmail, Postfix,
and Dovecot. I am trying to block email between users, and I don't
seem to be able to do this.

I was having trouble blocking emails selectively, so now I just trying
to block all emails - to make sure it is working.

In my main.cf, I have:

smtpd_sender_restrictions =
  check_sender_access regexp:/etc/postifx/check_sender_access.regexp


The check_sender_access.regexp file consists of:

/./ REJECT
/.*/ REJECT


Shouldn't this reject all email that goes through the system?

My local users can still email eachother. It is as if Postfix is being bypassed.

Non-local users are being blocked, so I am beginning to wonder if
Postfix is not being used when mail is between local user, perhaps it
is a Dovecot issue?

Is there any way to trace how an email moves through Postfix? It would
be great to see what is happening when it encounters the
smtpd_sender_restrictions and smtpd_recipient_restrictions.

Re: Backscatter

[Paweł Leśniak]

W dniu 2009-04-04 20:09, LuKreme pisze:
I've seen an increase in backscatter emails recently. Perfectly valid 
headers (AFAICT)


Return-Path: <>
X-Original-To: kr...@kreme.com
Delivered-To: kr...@covisp.net
Received: from mail9.webair.com (mail9.webair.net [74.206.236.69])
by mail.covisp.net (Postfix) with ESMTPS id 4FC10118B5B0
for ; Sat,  4 Apr 2009 00:18:38 -0600 (MDT)
Received: (qmail 45760 invoked for bounce); 4 Apr 2009 06:18:36 -
Date: 4 Apr 2009 06:18:36 -
From: mailer-dae...@mail9.webair.com
To: kr...@kreme.com
Subject: failure notice
Message-Id: <20090404061838.4fc10118b...@mail.covisp.net>


(I did just update this spf record to "v=spf1 a mx 
ip4:75.148.117.94/29 ~all" which I expect will help some)


Is there some sort of strategy I can implement that will reject a good 
portion of these kinds of messages? What are other people doing to 
deal with backscatter? I read up on SRS, but it doesn't sound like a 
great idea.



I'd recommend using rbl checks specified for this:
backscatter.map:
<> reject_rbl_client ips.backscatterer.org, reject_rbl_client 
bl.spamcannibal.org
postmaster reject_rbl_client ips.backscatterer.org, reject_rbl_client 
bl.spamcannibal.org
MAILER-DAEMON reject_rbl_client ips.backscatterer.org, reject_rbl_client 
bl.spamcannibal.org


Add
check_sender_access hash:/etc/postfix/backscatter.map
at the very last of RBLs in smtpd_recipient_restrictions (or other 
restrisctions if you prefer). For sure you should also read info on 
those blacklists.


IP you've provided as source of backscatter is listed in backscatterer.org.

Moreover, SPF won't help you much, because other mailserver admins would 
have to check it, and it's rarely supported.


Pawel Lesniak

Re: new clamav-milter quarantaine in hold queue script

[Robert Schetterer]

Victor Duchovni schrieb:
> On Sat, Apr 04, 2009 at 07:01:08PM +0200, Robert Schetterer wrote:
> 
>>> Here's my suggestion:
>>>
>>> - Create a second Postfix instance in the same file-system.
>>> - Run a cron job to move (rename(2)) messages from the HOLD queue
>>>   of the main instance into the deferred queue of the second instance,
>>>   carefully respecting the hash_depth of each directory.
>>> - In the second instance, deliver all mail via a suitable daemonized
>>>   SMTP server or via pipe(8) script. The daemon or script will be
>>>   the entry point into a quarantine system that eventualy expires
>>>   unclaimed mail, generates reports and allows other administrative
>>>   or user actions as you see fit.
>>>
>>> This means that "FILTER transport:nexthop" is perhaps a better choice than
>>> "HOLD", but milters may not be able to express this action...
>>>
>>> I am not aware of an open-source quarantine add-on for Postfix.
>> Hi Victor, this sounds very complicated
> 
> Yes, I am proposing a robust, comprehensive system that could serve a
> variety of needs.
> 
>> i was thinking more about a cron cript like this ( surly modified to the
>> hold issue )
> 
> What do mail-daemon messages have to do with junk placed in the HOLD
> queue by a milter

you missunderstood it was only meant as a principle example script
which i used times ago to delete mailerdaemon mails, it may be modified
to fit new needs

for sure mailer daemon has nothing to do with junk and milter
my intention is to store junk mails in hold in a dir in filesystem
and clean up hold by script, nothing more

> 
>> TMPFILE=/tmp/clean.queue.$$
>> DEFERDIR=/var/spool/postfix/deferred
>>
>> # collect the filenames
>> mailq |grep MAILER-DAEMON | cut -f1 -d ' ' > $TMPFILE
>>
>> for DEFERFILE in `cat $TMPFILE`
>> do
>>FILEPATH=`find $DEFERDIR -name $DEFERFILE`
> 
> This is subject to race-conditions, because queue-ids can be re-used.
> 


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: Backscatter

[Noel Jones]

Paweł Leśniak wrote:

W dniu 2009-04-04 20:09, LuKreme pisze:
I've seen an increase in backscatter emails recently. Perfectly valid 
headers (AFAICT)


Return-Path: <>

...

Not surprising, since the message is sent by a real MTA.



Is there some sort of strategy I can implement that will reject a good 
portion of these kinds of messages? What are other people doing to 
deal with backscatter? I read up on SRS, but it doesn't sound like a 
great idea.



I'd recommend using rbl checks specified for this:
backscatter.map:
<> reject_rbl_client ips.backscatterer.org, reject_rbl_client 
bl.spamcannibal.org


Good suggestion.  This will reject bounces from known 
backscatter sources.


postmaster reject_rbl_client ips.backscatterer.org, reject_rbl_client 
bl.spamcannibal.org
MAILER-DAEMON reject_rbl_client ips.backscatterer.org, reject_rbl_client 
bl.spamcannibal.org


These two will never match anything.  With a little adjustment 
they *might* be useful in a PCRE map.




Add
check_sender_access hash:/etc/postfix/backscatter.map
at the very last of RBLs in smtpd_recipient_restrictions (or other 
restrisctions if you prefer). For sure you should also read info on 
those blacklists.


Best in smtpd_data_restrictions so you don't reject 
sourceforge and others sender verification probes.




IP you've provided as source of backscatter is listed in backscatterer.org.

Moreover, SPF won't help you much, because other mailserver admins would 
have to check it, and it's rarely supported.


True.  It "seems" that sites with SPF are less frequently 
chosen as joe-job victims, but there's no guarantee.  At any 
rate, adding SPF shouldn't hurt anything.


Other suggestions...

Add the header_checks suggested in 
http://www.postfix.org/BACKSCATTER_README.html

Note the examples will need to be "customized" for your site.

If you're using SpamAssassin, the VBOUNCE rules are helpful.

If you're using amavisd-new, it has some bounce-killer 
features that might help.  Check amavisd-new release notes for 
details.  IIRC this is part of the "penpals" feature of 
amavisd-new.


If you're using clamav, the Sanesecurity addon signatures kill 
some common backscatter.


If all else fails and your system is drowning, it might not be 
unreasonable to TEMPORARILY reject all mail from the null 
sender.  This is a last resort measure and will reject legit mail.


  -- Noel Jones

Re: Cannot use restrictions to block emails between local users.

[Barney Desmond]

2009/4/5 Xn Nooby :
> I am working on a Webmail solution, that uses Squirrelmail, Postfix,
> and Dovecot. I am trying to block email between users, and I don't
> seem to be able to do this.

People seem to ask about this specific scenario a bit (want to stop
users sending mail to each other), I wonder why. Seems kinda silly to
me. Anyway...

> I was having trouble blocking emails selectively, so now I just trying
> to block all emails - to make sure it is working.
>
> In my main.cf, I have:
>
> smtpd_sender_restrictions =
>  check_sender_access regexp:/etc/postifx/check_sender_access.regexp

It's preferred that you show the output of `postconf -n` so everyone
can agree on what your server is doing. And you misspelt "postfix"
there :)

> The check_sender_access.regexp file consists of:
>
> /./ REJECT
> /.*/ REJECT
>
>
> Shouldn't this reject all email that goes through the system?
>
> My local users can still email eachother. It is as if Postfix is being 
> bypassed.

How does the webmail system inject mail? If it uses the "sendmail"
command then you CANNOT reject. sendmail is used by system processes
etc., cases when failure is not an option and mail must be accepted.
smtpd_mumble_restrictions applies only to mail received by SMTP.

Chances are you'll need to modify the webmail software so that it
sends mail via SMTP, then maybe you'll be able to reject it as you
want to (this will depend on the webmail software setting the right
sender address).

> Non-local users are being blocked, so I am beginning to wonder if
> Postfix is not being used when mail is between local user, perhaps it
> is a Dovecot issue?

NO. Dovecot does POP and IMAP, these are protocols only for mail
retrieval. Use what you already know to formulate hypotheses.

> Is there any way to trace how an email moves through Postfix? It would
> be great to see what is happening when it encounters the
> smtpd_sender_restrictions and smtpd_recipient_restrictions.

You could check the logs, it's all there. They'll also tell you how
the mail got into the system, which is particularly relevant here.

Re: new clamav-milter quarantaine in hold queue script

[Noel Jones]

Robert Schetterer wrote:

i was thinking more about a cron cript like this ( surly modified to the
hold issue )

What do mail-daemon messages have to do with junk placed in the HOLD
queue by a milter


Here's a dorky script I use to release mail on hold after a 
few days.  I have some questionable header_checks that HOLD 
mail and don't want to keep mail on hold forever if I'm on 
vacation or whatever...


It can easily be modified to move mail elsewhere or just 
delete "old" mail.  Caution: if you move the file without 
renaming it, keep it in the same filesystem to insure unique 
filenames.


Just run from cron a couple times a day.

8X
#!/bin/sh
# pf-releasehold - automatically release messages from
# the hold queue if they are greater than DAYSOLD days old.

PBIN=/usr/sbin
DAYSOLD=2

QUEUEDIR=`$PBIN/postconf -h queue_directory`
HOLDQUEUE=${QUEUEDIR}/hold
TMPFILE=/tmp/pfhold-$$

find ${HOLDQUEUE} -type f -mtime +${DAYSOLD} -print > ${TMPFILE}

if test -z ${TMPFILE}
  then echo 'nothing to release from hold'
   rm -f ${TMPFILE}
   exit
fi


# if we get this far, there must be something that needs to be 
released


for QUEUEPATH in `cat ${TMPFILE}`
do
QUEUEID=`basename ${QUEUEPATH}`

# change this line to adjust action
$PBIN/postsuper -H ${QUEUEID} 2>&1 |
   mail -s 'pf-releasehold' postmaster

done

rm -f ${TMPFILE}

8X


Of course, the better answer is:
If clamav-milter isn't doing what you need, use another 
milter.  There are several milters that can interface to clamd.


  -- Noel Jones

Re: Backscatter

[LuKreme]

On 4-Apr-2009, at 16:02, Noel Jones wrote:
Best in smtpd_data_restrictions so you don't reject sourceforge and  
others sender verification probes.


Is there anything I need to be concerned about having/not having in  
smtpd_data_restrictions?  it is currently commented out.  if I simply  
put:


smtpd_data_restrictions =
reject_unauth_pipelining,
reject_rbl_client ips.backscatterer.org,
reject_rbl_client bl.spamcannibal.org
permit

is that good enough?  (the pipelining was there before in the  
commented out declaration along with the permit). I am sad to say I am  
still a little unclear about how the various smtpd_mumble_restrictions  
work together.


IP you've provided as source of backscatter is listed in  
backscatterer.org.
Moreover, SPF won't help you much, because other mailserver admins  
would have to check it, and it's rarely supported.


True.  It "seems" that sites with SPF are less frequently chosen as  
joe-job victims, but there's no guarantee.  At any rate, adding SPF  
shouldn't hurt anything.


Well, I am hoping spf helps a bit. I'd left off the ~all on some  
domain's configuration and I've noticed a lot os this backscatter has


Received-SPF: neutral (mail9.webair.com: 85.9.127.134 is neither  
permitted nor denied by SPF record at kreme.com)



Other suggestions...

Add the header_checks suggested in 
http://www.postfix.org/BACKSCATTER_README.html
Note the examples will need to be "customized" for your site.


Oh, those look like a good idea in general, backscatter or not. At  
least in the header_checks.  I am leery of running body_checks as it  
seems those would be expensive.



If you're using SpamAssassin, the VBOUNCE rules are helpful.



Yeah, but SA is run after reception.  I'd rather reject backscatter  
than discard it, if possible.


Thanks, this is great info.

--
I'll trade you 223 Wesley Crushers for your Captain Picard

Re: Backscatter

[Sahil Tandon]

On Sat, 04 Apr 2009, LuKreme wrote:

> On 4-Apr-2009, at 16:02, Noel Jones wrote:
>> Best in smtpd_data_restrictions so you don't reject sourceforge and  
>> others sender verification probes.
>
> Is there anything I need to be concerned about having/not having in  
> smtpd_data_restrictions?  it is currently commented out.  if I simply  
> put:
>
> smtpd_data_restrictions =
> reject_unauth_pipelining,
> reject_rbl_client ips.backscatterer.org,
> reject_rbl_client bl.spamcannibal.org
> permit

The trailing permit is unnecessary.  And some people worry about blocking
legitimate mail from sites listed on those RBLs.  If you share that fear, you
could use an access(5) table to limit the RBL lookups (and rejections) only
to null envelope senders.

> is that good enough?  (the pipelining was there before in the commented 
> out declaration along with the permit). I am sad to say I am still a 
> little unclear about how the various smtpd_mumble_restrictions work 
> together.

For more clarity and general illumination, see:
http://www.postfix.org/SMTPD_ACCESS_README.html

-- 
Sahil Tandon 

Re: Backscatter

[LuKreme]

On 4-Apr-2009, at 16:02, Noel Jones wrote:
Best in smtpd_data_restrictions so you don't reject sourceforge and  
others sender verification probes.



That didn't go well:

Apr  4 20:15:28 mail postfix/smtpd[16843]: 60D15118AC14: reject: DATA  
from english-breakfast.cloud9.net[168.100.1.7]: 554 5.7.1 Service  
unavailable; Client host [168.100.1.7] blocked using  
ips.backscatterer.org; Sorry 168.100.1.7 is blacklisted at http://www.backscatterer.org/?ip=168.100.1.7 
; from= to=  
proto=ESMTP helo=



--
Say, give it up, give it up, television's taking its toll
That's enough, that's enough, gimme the remote control
I been nice, I been good, please don't do this to me
Turn it off, turn it off, I don't want to have to see

Re: Cannot use restrictions to block emails between local users.

[Xn Nooby]

> Chances are you'll need to modify the webmail software so that it
> sends mail via SMTP, then maybe you'll be able to reject it as you
> want to (this will depend on the webmail software setting the right
> sender address).

Hurray, that worked!  I was able block an email after changing
SquirrelMail from "sendmail" to "SMTP".

FYI, this email server is for internal use, in an environment where
people are supposed to only use it to contact their supervisors, and
not eachother.

thanks!!

Re: Backscatter

[Paweł Leśniak]

W dniu 2009-04-05 04:27, Sahil Tandon pisze:

On Sat, 04 Apr 2009, LuKreme wrote:

   

On 4-Apr-2009, at 16:02, Noel Jones wrote:
 

Best in smtpd_data_restrictions so you don't reject sourceforge and
others sender verification probes.
   

Is there anything I need to be concerned about having/not having in
smtpd_data_restrictions?  it is currently commented out.  if I simply
put:

smtpd_data_restrictions =
 reject_unauth_pipelining,
 reject_rbl_client ips.backscatterer.org,
 reject_rbl_client bl.spamcannibal.org
 permit
 


The trailing permit is unnecessary.  And some people worry about blocking
legitimate mail from sites listed on those RBLs.  If you share that fear, you
could use an access(5) table to limit the RBL lookups (and rejections) only
to null envelope senders.
   
You should NEVER use ips.backscatterer.org as global RBL. You'll block 
legitimate mails for sure. The question is only how many.
Also using bl.spamcannibal.org for all senders is not very safe. Before 
using ANY RBL read what it actually does.


From backscatterer.org site:
"Listing Policy is quite simple. Every IP which backscatters or does 
sender callouts will be listed the next 4 weeks here."
So every host which does email verification would be entirely blocked, 
and that's almost surely not what one would want.

And on more citation:
"Unfortunable many and also big providers do still backscatter. They are 
flooding you with bounces but will almost always send real mail too.
As long as you are not a BOFH nor having the intention to boycott such 
servers we strongly recommend to use ips.backscatterer.org in SAFE MODE 
to prevent false positives.
SAFE MODE means you will do DNSBL-Querys if MAIL FROM: is <> or 
postmaster only.
Used in safe mode ips.backscatterer.org will protect you against 
misdirected bounces and sender callouts while you can not loose any real 
mail."


A bit different situation is with spamcannibal. It's "normal" RBL, but 
in my place it was giving 10 to 50 false positives daily. A month ago 
spamcannibal was stopping some backscatter. Now I get rarely any hits, 
but it's used as the very last RBL to check emails from <> ans 
postmaster. Soem citation from their site:


"The ONLY way you can get into SpamCannibal's database is by sending 
spam or virus ladened email to our mail servers!
SpamCannibal does not block email access except for IP addresses and 
ranges that have sent or relayed what we believe to be spam or other 
unsolicited email directly to our email servers. SpamCannibal uses its 
database to block access by IP addresses ONLY for its own mail servers, 
however, the database we use for that purpose is freely available for 
anyone to look at and use as they see fit. "


So if one would do a typo in email and got into their honeypot, the host 
(or subnet) is getting blacklisted. For me it's much to simple to get 
blacklisted at spamcannibal.org.



Pawel Lesniak