SOLVED pending more tests, Re: Dropping email on the floor?

[Rick Stevens]

Jeff Kinz wrote:
> Out story so far:
> As you may recall, our intrepid "hero" was losing emails from email
> lists which used to be delivered reliably:
> 
> 
>>>Jeff Kinz wrote:
>>>
>>>>It seems I forgot some essential information, er, um, these two email
>>>>sources, internet.com and bulk.scd.yahoo.com are legitimate email
>>>>sources trying to send me email for various email lists that I signed up 
>>>>for.  I have been happily receiving email from them for some time but I
>>>>noticed that at some point in the past it was becoming unreliable and
>>>>recently they all started just failing.
>>>
> 
>>On Fri, Apr 15, 2005 at 02:16:40PM -0700, Rick Stevens wrote:
>>
>>>Then your ISP has a connectivity issue with those networks.  Complain
>>>to your ISP.  It'd help if you could include traceroutes from you to
>>>the questionable networks.
>>
> 
> On Fri, Apr 15, 2005 at 08:39:25PM -0400, Jeff Kinz wrote:
> 
>>My ISP ix Comcast ~.>>>~~~ They aro a huce ISP.xxxxzzzz I'n sure they
>>donut xave~ any pro           blems with hair nets works.
> 
> 
> 
>>On Fri, Apr 15, 2005 at 02:16:40PM -0700, Rick Stevens wrote:
>>
>>>Run traceroutes to the mailservers in question and include those in your
>>>discussions with your ISP.  They may have a peering issue.  For example,
>>>one of our upstream providers in Amsterdam decided to stop peering with
>>>Cogent.  Their network crashed because their other peers couldn't handle
>>>the traffic.
> 
> 
> On Fri, Apr 15, 2005 at 08:39:25PM -0400, Jeff Kinz wrote:
> 
>>According to some of the traffic on NANOG there may be more of this
>>happing and more to come as well.  joy.
> 
> 
> Before following Rick's excellent suggestion on sending traceroutes to my
> ISP's (Comcast) tech support dept, I did some further googling for the 
> "Lost input channel" diagnostic message sendmail was putting in the
> logfiles.  The information I found was sketchy at best.
> (try '"lost input channel" sendmail' in Google)
> 
> This message seems to happen most frequently when a spammer is trying to
> send an email, but it can also happen when the multiple DNS lookups
> being done before accepting the email either fail to return or time out.
> 
> 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.
----------------------------------------------------------------------
- Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
- VitalStream, Inc.                       http://www.vitalstream.com -
-                                                                    -
-    First Law of Work:                                              -
-    If you can't get it done in the first 24 hours, work nights.    -
----------------------------------------------------------------------