This is similar to bug #223933 & #235379 -- similar in that the same effect
occurs [fetchmail basically stops retrieving messages] but the cause this
time appears to be a mal-formed "from" address [and so far, 100% of these
have been spam]
fetchmail's log reports:
============================================================
fetchmail: 56 messages for <deleted> at mail2.1stnetusa.com (209077 octets).
fetchmail: reading message <deleted>@mail2.1stnetusa.com:1 of 56 (5946 octets)
fetchmail: SMTP error: 501 Bad address syntax
fetchmail: not flushed
fetchmail: client/server protocol error while fetching from
mail2.1stnetusa.com
fetchmail: Query status=4 (PROTOCOL)
fetchmail: sleeping at Sun Sep 12 12:00:30 2004
============================================================
logging in via telnet to "clear" this problem, I see:
============================================================
osnut:/var/log # telnet mail2.1stnetusa.com pop3
Trying 206.171.253.49...
Connected to mail2.1stnetusa.com.
Escape character is '^]'.
+OK POP3 mail2.1stnetusa.com v2003.83rh server ready
user <deleted>
+OK User name accepted, password please
pass <deleted>
+OK Mailbox open, 56 messages
retr 1
+OK 5946 octets
Return-Path: <P[5-](_at_)epomail(_dot_)com>
Received: from cpe-68-116-200-25.ma.charter.com
(cpe-68-116-200-25.ma.charter.com [68.116.200.25])
by mail2.1stnetusa.COM (8.12.11/8.12.10) with SMTP id i8C5AVnr031168;
Sat, 11 Sep 2004 22:10:36 -0700
X-Message-Info: SV/t+480+d/VBT+6/13411299508938
Received: from smtp-cress(_dot_)botulism(_dot_)P[5-](_at_)epomail(_dot_)com
([68.116.200.25]) by
q610-pf1(_dot_)P[5-](_at_)epomail(_dot_)com with Microsoft
SMTPSVC(5.0.3490.1290);
Sun, 12 Sep 2004 09:50:14 +0400
Received: from signal151(_dot_)aphasia(_dot_)P[5-](_at_)epomail(_dot_)com
(genevieve158(_dot_)P[5-](_at_)epomail(_dot_)com [68.116.200.25])
by smtp-uncle(_dot_)spouse(_dot_)P[5-](_at_)epomail(_dot_)com (Postfix)
with SMTP id
426DLQ98F19VK
for <denis(_at_)1stnetusa(_dot_)com>; Sun, 12 Sep 2004 10:45:14 +0500
Received: from smtp-carborundum(_dot_)coupon(_dot_)P[5-](_at_)epomail(_dot_)com
([68.116.200.25]) by
zf1-l24(_dot_)P[5-](_at_)epomail(_dot_)com with Microsoft
SMTPSVC(5.0.6688.9727);
Sun, 12 Sep 2004 00:50:14 -0500
X-Message-Info: OBSPP+%ND_LC_CHAR[1-3]97+zzb+N+934/953053631257
Received: (qmail 15008 invoked by uid 47); Sun, 12 Sep 2004 04:44:14 -0100
Date: Sun, 12 Sep 2004 10:43:14 +0500
Message-Id: <550025679(_dot_)95613(_at_)P[5-]@epomail.com>
From: Rachel Melendez <P[5-](_at_)epomail(_dot_)com>
To: Denis <denis(_at_)1stnetusa(_dot_)com>
Subject:
MIME-Version: 1.0 (produced by ranklegauguin 1.8)
Content-Type: multipart/alternative;
boundary="--0297487016671684712"
Status: RO
----0297487016671684712
Content-Type: text/html;
charset="iso-9805-0"
Content-Transfer-Encoding: quoted-printable
Content-Description: transfer airedale tolerant
<html>
[rest of message deleted]
============================================================
Note the FROM line:
From: Rachel Melendez <P[5-](_at_)epomail(_dot_)com>
given that this is probably illegal syntax, I gather it is simply a mechanism
the spammer is using to avoid nastygrams in return. The net effect, of
course, is that fetchmail simply "stops" retrieving messages [from an
end-user's viewpoint -- technically, fetchmail continues to wake up every 5
minutes, but refuses to budge on this message]
WHAT I WOULD LIKE: a configuration option to drop these messages (delete from
server) since there isn't really anything that can be done about them. In
the case of the original bugs noted, one was due to a hard failure of the
server to deliver the message, which may mean the message is already gone;
and the other has to do with a similarly-munged message-ID, which causes a
headache for fetchmail itself it seems [I would venture to guess the
duplicate-search is looping, but that's only a guess...]
I'm running fetchmail as a daemon in a basic straight-fetch-and-deliver mode;
version 6.2.3 from a stock SuSE 9.0 install (and the NEWS file in the latest
source does not give any indication that this problem has been addressed)
pgpJNkFqVOaMs.pgp
Description: signature