fetchmail-friends
[Top] [All Lists]

[fetchmail] Fetchmail / cyrus-Imap communication problem

2003-04-14 18:10:20
Hopefully this question hasn't already been asked, but I cannot find a
prior posting, so here goes.

My situation is as follows: I use fetchmail to retrieve mail from a
number of pop accounts and funnel them, via lmtp, into a cyrus-imap
message store. The communication from fetchmail to cyrus-imap is through
a unix socket that cyrus's lmtp daemon creates for this purpose.
Fetchmail runs in daemon mode on the same server, therefore, as the imap
store, and a typical line in /etc/fetchmailrc might read:

poll <mailserver> protocol pop3 user "<username>" pass "<password>" is 
"<localusername>"
        smtphost "/var/imap/socket/lmtp"

For about a year, I was using this system on an old Mandrake 8.1 system
that I had set up as a mail server. About a month or so ago I acquired
new hardware, and installed Debian Woody (stable) and set this system up
to replace my mail server, and that's when my troubles began.

I noted fairly soon after installing the new server that my volume of
email had gone down significantly, and soon thereafter I realized that
emails I should have received (eg emails that I had sent to myself, so I
knew they had at least been sent) never arrived.

To make a long story short, what seems to be going on is that when
fetchmail receives the emails from the pop server and tries for forward
them to the lmtp daemon, the first email is sent to
"<user>@/var/imap/socket" (obviously using the host taken from the
smtphost list in the corresponding entry in fetchmailrc. For reasons
that I cannot discern from the current source code, after the first
message fails, subsequent messages in that retrieval run are forwarded
to "<user>@localhost". Cyrus's lmtpd balks at the host name
'/var/imap/socket" and loses that message, so the net effect is that I
lost the first email from each retrieval run from the pop server.

Here's the transcript obtained via runnign fetchmail -v on just one pop
acocunt (I've edited out some identifying data) which I think
illustrates the problem. You can see that under debian woody, I have
fetchmail 5.9.11.

fetchmail: 5.9.11 querying <server> (protocol POP3) at Tue Apr  8 23:16:23 
2003: poll started
fetchmail: POP3< +OK Hello there.
fetchmail: POP3> USER <user>
fetchmail: POP3< +OK Password required.
fetchmail: POP3> PASS 
fetchmail: POP3< +OK logged in.
fetchmail: POP3> STAT
fetchmail: POP3< +OK 2 1518
fetchmail: POP3> LAST
fetchmail: POP3< -ERR Invalid command.
fetchmail: POP3> UIDL
fetchmail: POP3< +OK
fetchmail: POP3< 1 1049846540.26876_88.mail-hub-2.omnis.com
fetchmail: POP3< 2 1049846721.87590_25.mail-hub-1.omnis.com
fetchmail: POP3< .
2 messages for <user> at <server> (1518 octets).
fetchmail: POP3> LIST
fetchmail: POP3< +OK POP3 clients that break here, they violate STD53.
fetchmail: POP3< 1 759
fetchmail: POP3< 2 759
fetchmail: POP3< .
fetchmail: POP3> TOP 1 99999999
fetchmail: POP3< +OK headers follow.
reading message <user>@<server>:1 of 2 (759 octets)
fetchmail: LMTP< 220 rivendell LMTP Cyrus v2.1.12 ready
fetchmail: LMTP> LHLO localhost
fetchmail: SMTP< 250-rivendell
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250-ENHANCEDSTATUSCODES
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-SIZE
fetchmail: SMTP< 250-AUTH EXTERNAL
fetchmail: SMTP< 250 IGNOREQUOTA
fetchmail: LMTP> MAIL FROM:<nl(_at_)lippman(_dot_)org> BODY=7BIT SIZE=759
fetchmail: LMTP< 250 2.1.0 ok
fetchmail: LMTP> RCPT TO:<user@/var/imap/socket>
fetchmail: LMTP< 501 5.5.4 Syntax error in parameters
fetchmail: LMTP> RSET
fetchmail: LMTP< 250 2.0.0 ok
 flushed
fetchmail: POP3> DELE 1
fetchmail: POP3< +OK Deleted.
fetchmail: POP3> TOP 2 99999999
fetchmail: POP3< +OK headers follow.
reading message <user>@<server>:2 of 2 (759 octets)
fetchmail: LMTP> MAIL FROM:<nl(_at_)lippman(_dot_)org> BODY=7BIT SIZE=759
fetchmail: LMTP< 250 2.1.0 ok
fetchmail: LMTP> RCPT TO:<user(_at_)localhost>
fetchmail: LMTP< 250 2.1.5 ok
fetchmail: LMTP> DATA
fetchmail: LMTP< 354 go ahead
#fetchmail: LMTP>. (EOM)
fetchmail: LMTP< 250 2.1.5 Ok
 flushed
fetchmail: POP3> DELE 2
fetchmail: POP3< +OK Deleted.
fetchmail: POP3> QUIT
fetchmail: POP3< +OK Bye-bye.
fetchmail: 5.9.11 querying <server> (protocol POP3) at Tue Apr  8 23:16:28 
2003: poll completed
fetchmail: LMTP> QUIT
fetchmail: LMTP< 221 2.0.0 bye
fetchmail: normal termination, status 0

I've been through the source code and although I have tracked down where the 
smtphost processing
seems to take place, I don't want to get too heavily into this if this problem 
was already addressed in a later version,
and it's just a matter of using the newer version (6.2.1) in debian testing 
instead. I presume this is a version-related problem as
I did not have this problem on the older Mandrake system. Unfortunately, that 
system is no longer available to me (drives have been
reformated and hardward recycled) so I cannot easily verify what version of 
fetchmail I was using at the time.

Thoughts or help greatly appreciated.

Thanks.
Neal 


<Prev in Thread] Current Thread [Next in Thread>
  • [fetchmail] Fetchmail / cyrus-Imap communication problem, Neal Lippman <=