Here's an interesting fetchmail problem that blocked my fetchmail
processing for several days. Alas, once again fetchmail is stuck on a
dodgy incoming mail.
For what it's worth, I include the output of `fetchmail -v -v`, but I
think I know where it is failing.
After reading one (clearly spam) message from
undxf703rz(_at_)microbitnet(_dot_)com,
fetchmail tries to hand this on to my local sendmail. Attempting (and
failing) to resolve microbitnet.com takes one minute, by which time it
seems my ISP has become bored. At least, that's how I interpret these
lines:
...
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<undxf703rz(_at_)microbitnet(_dot_)com> SIZE=2850
<loooong pause here>
fetchmail: SMTP< 451 4.1.8 Domain of sender address
undxf703rz(_at_)microbitnet(_dot_)com does not resolve
fetchmail: SMTP> RSET
fetchmail: SMTP< 250 2.0.0 Reset state
.fetchmail: flushed
fetchmail: POP3> DELE 1
fetchmail: socket error while fetching from pop.ntlworld.com
fetchmail: 6.2.5 querying pop.ntlworld.com (protocol POP3) at Sat Dec 13
06:01:31 2003: poll completed
fetchmail: Query status=2 (SOCKET)
...
This problem persisted for days, until I did the obvious and retrieved and
discared the offending message manually: and things seem back to normal.
Now, is this a fetchmail bug? It's certainly not nice, but presumably the
blame can be shared around. It's very odd that microbitnet.com should be
harded to resolve than other domain names, for instance.
Anyhow, this prevents fetchmail from operating unattended, so I think I'll
claim it's a fetchmail bug.
.fetchmail.log
Description: Fetchmail log