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

[Jeff Kinz]

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')

Then rebuilt the sendmail config and restarted sendmail.

The problems seemed to stop almost immediately.

As a final verification I will reverse this change and see if the same
symptom re-appears.




-- 
Jeff Kinz, Emergent Research, Hudson, MA.