Fetchmail piping to sendmail, DNS probs causing POP server timeout

[Derrick Norris]

Like many of us, I get a *lot* of spam coming into my ISP-assigned 
email address.  Since I originally installed this system (at release 
4.2) I have used fetchmail piping through to sendmail to fetch from 3 
POP accounts.  I don't run DNS on my box and use my ISP's DNS servers 
for resolution.

I'm now on 4.9 and seems like a couple of release upgrades back, I 
started having problems with this setup.  I don't know if it was some 
upgrade of fetchmail and/or sendmail that started the problem, or if 
it was just coincidence.

Many of the spam emails use invalid "from" domains, or semi-valid ones 
(having MX records but no A records for instance).

I have noticed a couple of particularly troublesome domains that cause 
the following to happen:
-- fetchmail logs into the POP server and starts retrieving mail
-- each mail is piped through to sendmail, which goes through
   its normal domain verification checks and accepts the mail
   if the checks succeed
-- several mails are processed like this, then it gets to the email
   with the FUBAR domain
-- sendmail does what I suppose is the equivalent of a "host"
   command on the bad domain name to attempt verification
-- my ISP's DNS servers (2 of them) give timeouts on the A and
   AAAA records (I have verified this with the host command) and
   finally cough up an MX record.  However sendmail is doing this,
   given its retrans and retry settings, ends up taking almost 3
   minutes to finally return from the check
-- by this time, my ISP's POP server has shut down my connection
   due to inactivity and fetchmail terminates with a socket error

So the end result is I get multiple copies of all the mail that is 
before the bad one in the mailbox, and other mail stacks up 
unretrieved behind the bad one until I log into the ISP's webmail 
system, find and manually delete the bad email.  Subsequent fetchmail 
runs will then usually fetch all my mail, until that spammer hits me 
up again to buy some Xanax.

I tried playing with various combinations of the TO_RESOLVER_RETRANS 
and TO_RESOLVER_RETRY settings to no final avail.  I could tell it 
was having an effect because the length of time to return from the 
check of the bad domain changed.  But I found that I would have to 
put them to something like 1-2 seconds and 1-2 retries to get it work 
(it takes 40 seconds for a host command on that domain to return), 
and I don't like the idea of that for reliability of verification of 
good domains.

I ended up just putting the worst offender in my access file with a 
REJECT, rebuilding the DB and restarting sendmail, thinking this 
would solve it for that particular domain.  But for some reason 
sendmail still tries to verify the domain even though I have plainly 
told it to just reject the mail.  Seems to me like the first thing 
sendmail should do is check the access db and just blindly pass 
through domains with an OK and block those with a REJECT, eliminating 
the need to do a DNS check for those domains.  I can tell it's 
processing the REJECT because my maillog says so, but it's still 
doing the DNS check.

I know that the root cause of the problem is incomplete DNS records 
for the spammer's domain, probably combined with at least partially 
braindead DNS servers at my ISP (for instance, they recently stopped 
resolving earthlink.net for a little while).  I don't think I will 
have much luck getting either of those situations to change.

Does anyone know why sendmail insists on performing a domain lookup 
even on domains that I have specified in the access db?  Is there a 
configuration parameter I can set to make it stop doing that?

Thanks in advance for any help, and sorry for the long post.  This 
might be better sent to some kind of sendmail list, but I know the 
folks who answer questions here have knowledge both deep and wide.

-- Derrick Norris