Re: Are you seeing these mailer bounces?

On 01/05, John Hinton wrote:
> one. So, if you have a system which is bouncing after receipt, you are 
> subject to landing on this or other blocklists. Is this right or wrong? 

If you're sending backscatter, you're propagating spam for the spammers.

> I do think more of this is happening due to various spam programs 
> running deeper and deeper into the mail delivery system, all the way to 
> the end user's PC, at which point bounce is the only option as reject 
> has long since passed.


> It is a conundrum, but basically in my opinion, spam should either be 
> delivered or deleted... never bounced.. or rejected at the smtp process 

Yup I agree emails should be bounced during the initial smtp session
or not at all.  That way the bounce message delivery is the job of the
sending mail server, so if it's a spammer the bounce doesn't get sent,
and there's no backsactter.

After that... definitely only if everything that fails SPF checks was
rejected during the initial smtp session, if at all.  

> using something like SpamHaus. I also am running milter-ahead on our 

It's really interesting how much you can block at that point with
greylisting, helo checks, spamhaus, and dsbl.  While still sending error
messages to legit senders and not causing backscatter.

It took me longest to bother with the helo checks.  I just didn't think it
would be that worthwhile, but blocking anything that claims to be your own
IP address or domain, and anything that is claiming a hostname that isn't
an fqdn, is... well, definitely worthwhile.  And cheap.

For example, with postfix, in main.cf:
smtpd_helo_restrictions =
  permit_mynetworks,
  check_helo_access hash:/etc/postfix/helo_access,
  reject_non_fqdn_hostname,
  reject_invalid_hostname,
  permit

smtpd_client_restrictions =
       permit_mynetworks,
       reject_unknown_client
       reject_rbl_client list.dsbl.org
       reject_rbl_client zen.spamhaus.org


And in /etc/postfix/helo_access I just list my IP and domain:
140.186.190.71 REJECT
chaosreigns.com REJECT

> backup mailserver which looks forward to the server that should be 
> receiving the email to check for a legit user or that in fact the server 
> is up.. if not it rejects the email. This took care of any backscatter 
> we were producing.

An important step.  I'm seeing a lot of people arguing that backup MXes
(which only exist to queue mail when the primary is down but don't provide
direct client access) are nolonger worth the effort of maintaining.

> recipient. As a sysadmin I really can't block or classify as spam 
> bounced mail, as this is indicative of problems so many times, but it 
> sure is irritating when it is just backscatter.

I train all backscatter as spam and all legitimate bounces as nonspam, and
it's pretty amazing how well spamprobe deals.

Really I don't train spamprobe on spam vs. nonspam, I train it on stuff I'd
really rather not have gotten vs. stuff I should get, and it performs
beautifully.

> And yes, sorry as this is a bit off topic from SpamProbe.. but is why we 
> should consider what we are actually doing before bouncing any email.

I think it's sufficiently relevant to anyone who's using spamprobe.

-- 
"Safe is anywhere a hungry person cant walk in three days." - John Titor
http://www.ChaosReigns.com

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV