Sendmail misconfiguration; it's possible to tell sendmail not to try to
resolve those domains. Don't ask me how though; getting sendmail to do
the right thing is sufficiently painful that I stick with postfix and exim
these days.
Yes, I tried that game.
Unfortunately, it lead me down another dark alleyway where I got mugged by
sendmail. Basically sendmail then ends up with queues of messages that
need to be processed later, and I never fully figured out how to get it to
actually deal with them in a timely way. As I recall it, incoming mail
could be delayed for minutes or hours at a time, and I never got my
outgoing mail queue working properly.
So, hacking my sendmail configuration seems a nasty idea.
I have two thoughts about this:
1. It seems that integrating fetchmail with sendmail and a mildly
unhelpful POP server (on a major ISP) is an unsolved problem! I've
been playing this particular game on and off for about a year now. I
would have though that integration into common environments was part
of the development of fetchmail.
2. A simple integration tool to fix the "impedance mismatch" problem
occurs to me, and should be easy enough to implement.
A separate application which acted as a buffer between fetchmail and
sendmail would be incredibly useful and, presumably, very easy to write.
Before I dust off my rusty Unix, let me ask: does such a tool already
exist?
It would take as input a sequence of mail messages, store them somewhere
(as a list of persistent files, presumably) and hand them off to sendmail
as quickly as it can. Any messages that sendmail balks on can be
redispatched anywhere and anyhow (the bin will suit me just fine, or
they can be repackaged and forwarded to the postmaster).
Sounds awfully like what fetchmail does, but with buffering added in.
Or, of course, I could move away from sendmail. Hmm. Or I could just
stop running fetchmail. Hmph.