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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"