fetchmail-friends
[Top] [All Lists]

[fetchmail] Re: Bug in fetchmail 6.2.1 - please take a look!

2003-04-27 20:03:36
The difference between your system's behavior and mine is that you have
used the smtpname clause to specify an entry for the REPLY TO command
send to the [SL]MTP process. That's how I have fixed my own
implementation, btw - by adding an smtpname to each line in fetchmailrc.

I'm still not convinced that the behavoir I am seeing is correct,
however, since when building the RCPT TO line for [SL]MTP, the target
should be checked for proper syntax when a unix socket is going to be
accepted into the list of potential targets.

Maybe it is the case that smtpname MUST always be given to ensure a
valid receipient in the RCPT TO line - which moves the 'bug' to the man
page which does not indicate this.

nl

On Sun, 2003-04-27 at 20:51, Christian Schulte wrote:
Neal Lippman wrote:

OK, now I'm pretty convinced there is a bug in fetchmail. Hopefull some
maintainers do read this mailing list, and so can take a look at this
and/or discuss with me. I'm cc'ing the debian list because that's what I
use, and cyrus because it affects my forwarding of emails into
cyrus-imap as well.

I'm seeing the same behavoir in both the version with fetchmail in
debian stable (5.9.11) and debian testing (6.2.1), and I am fairly
convinced that this is a bug. At the least, the behavoir doesn't seem
ideal.

The long and short of it is the following. Here is a line from my
.fetchmailrc, altered a bit (passwords removed, for instance):

poll mail.lippman.org protocol pop3 user "testuser" pass "testpass" is 
    "test" smtphost "/var/imap/socket/lmtp"

This line should retrieve mail from my pop3 server and forward it via
lmtp to a socket which cyrus-imap's lmtp daemon is listing on.

If I send multiple messages to this email account, then then invoke
fetchmail to retrieve them, the first message is lost. This is true no
matter how messages are waiting for retrieval when fetchmail runs; the
first is always lost (if there is only one message waiting, it is of
course lost). The reason is that fetchmail tries to forward the first
message to "test@/var/imap/socket" which fails, because the lmtp daemon
(correctly) notes that this is incorrect syntax for an email address.
Fetchamil seems to pick up on this error (although the log does not
indicate that it is doing so), because all subsequent messages are then
fowarded to "test(_at_)localhost" which the lmtpd accepts. This behavoir, as
mentioned, occurs with 5.9.11 AND 6.2.1 versions. 

I cannot confirm that behaviour!

smtp:/etc/default# dpkg -l fetchmail
ii  fetchmail                              
5.9.11-6.2                             POP3, APOP, IMAP mail 
gatherer/forwarder (crypto-crippled binary)

smtp:/etc/default# cat /etc/fetchmailrc
set syslog
poll somehost.tld proto IMAP user "someuser" is cs(_at_)schulte(_dot_)it 
password 
"xxxx" fetchall flush smtpname cs(_at_)schulte(_dot_)it smtphost 
/var/imap/socket/lmtp

It works for me! cs(_at_)schulte(_dot_)it is a cyrus-2.2 mailbox. User cs in 
cyrus-virtual-domain schulte.it. fetchmail does not loose any messages 
for me but my fetchmailrc differs in yours that my local users already 
contain a @domain part. I tested to see if that maybe a problem and 
changed cs(_at_)schulte(_dot_)it to root. In syslog I could see lmtpd trying 
to 
append the message to the root account. Because that account does not 
exist delivery cannot work.

Apr 28 02:45:02 smtp lmtpunix[1602]: append_check() of 'user.root' failed

I think this also shows that delivery to the account whould have worked 
if the account would have existed and because of this mail being the 
only one fetched fetchmail works!

--Christian--




<Prev in Thread] Current Thread [Next in Thread>