More Spam?

Rick Stevens rstevens at vitalstream.com
Wed Apr 20 01:27:46 UTC 2005


Jeff Kinz wrote:
> On Tue, Apr 19, 2005 at 03:16:52PM -0700, Rick Stevens wrote:
> 
>>Jeff Kinz wrote:
>>
>>>Following that direction, as an experiment I added these two lines to
>>>the sendmail.mc file:
>>>FEATURE(`nocanonify')
>>>FEATURE(`accept_unresolvable_domains')
>>
>>UGH!  Those are bad moves.  HUGE amounts of spam and viruii come from
>>unresolvable domains--that's one reason you don't want to accept such
>>stuff.  Stop it before it gets into your spools and your spam bot or
>>antivirus has to deal with it.
>>
>>
>>>Then rebuilt the sendmail config and restarted sendmail.
>>>
>>>The problems seemed to stop almost immediately.
>>
>>Well, sure.  You're accepting some bad stuff now.  We have simple rules
>>here:  If you send us stuff that's not from a FQDN, if your domain
>>doesn't resolve, if the IP you claim you're on doesn't reverse resolve
>>or doesn't match what you claim your domain is, we reject it, log the
>>IPs and such and file complaints.  We've gotten two /24 networks banned
>>from the internet like that (the *ssholes were in China).
>>
>>I can absolutely guarantee you'll see spam and viruses galore coming
>>from China, Columbia, Korea and Brazil.
>>
>>
>>>As a final verification I will reverse this change and see if the same
>>>symptom re-appears.
>>
>>It will.
> 
> On Wed, Apr 20, 2005 at 01:38:16AM +0300, Kostas Sfakiotakis wrote:
> 
>>>FEATURE(`nocanonify')
>>>FEATURE(`accept_unresolvable_domains')
>>
>>Jeff , isn't enabling the accept unresolvable domains
>>Feature a door for spamming the server in question ?
>>What would the sideeffects of that be ?
> 
> 
> Rick and Kostas are both correct (except for .. see below).  Turning on
> those two features in Sendmail does potentially allow more spam to reach
> your systems.  It is not recommended except in dire cases.
> 
> The point in this case was to reduce the number and kind of DNS
> queries Sendmail was making about the incoming emails. Turning on the
> above features does that.  My ISP, Comcast, is experiencing, ahem, DNS
> "difficulties" which, because the DNS lookups on email from certain sources
> were failing, (others were/are having no problems) was preventing my
> systems from getting large quantities of legitimate emails.  Now those
> good emails are getting through.
> 
> re - the SPAM, well so far the increase has not been detectable and 
> thanks to bogofilter its not showing up anywhere except the spam bin
> (knocks on wood) so far, so good.
> 
> So - I have a question.  It appears that Comcast will never get its act
> together enough to use its DNS services the way I need to.  Does anyone
> have any suggestions on what other techniques I can use to implement a
> better (more responsive/timely) DNS ?

Use other DNS servers.  Edit ye ol' /etc/resolv.conf and stuff in
some other servers.  Here's a few:

VitalStream, Inc., Los Angeles, CA  USA (I run these two, among others)
64.7.192.162 (dns-01-001.root-dns.com)
64.7.192.163 (dns-01-002.root-dns.com)

open-rsc.org:
199.166.28.10 (PS0.NS2.VRX.NET) - Atlanta, Ga
199.166.29.3 (nl.public.rootfix.net) - Nederlands
199.166.31.3 (NS1.QUASAR.NET) - Orlando, FL, USA
199.5.157.128 (ASLAN.OPEN-RSC.ORG) - Detroit, MI, USA

Of course, you could set up a caching DNS server on your network and use
it.  Or sign up for one of the free DynamicDNS services and use their
servers (and set a record for your home stuff, too).

Comcast really should pull their heads out of their arses and fix their
problems.  DNS ain't rocket science.  Any semi-competent network person
should be able to sort out their issues.
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-  What's small, yellow and very, VERY dangerous?  The root canary!  -
----------------------------------------------------------------------




More information about the Redhat-install-list mailing list