The Wednesday 2004-01-28 at 20:29 -0500, Patrick Shanahan wrote:

...

Where is fetchmail home page?

http://catb.org/~esr/fetchmail/

Thanks. I'm going to see if there is a newer version - the one in 8.2 sometimes balks with "bad header" and leaves email on the server. Mmm, slow server... and it refuses to download the gpg key for verification (empty). We'll see.

I know knothing about your troubles at sourceforge. I see them not.

I thought so. I can browse using my secondary provider (tiscali). They must be blocking the teleline/terra ISP, the biggest here. Also, I can not send emails to them, I'm blocked: |nimrodel:~ # mailq |-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- |A8C4222B03 805 Thu Jan 29 01:33:25 ***********@teleline.es |(host mail.sourceforge.net[66.35.250.206] said: 451-Could not complete |sender verify callout 451-Could not complete sender verify callout for |<*****@teleline.es>. 451-The mail server(s) for the domain may be |temporarily unreachable, or 451-they may be permanently unreachable from |this server. In the latter case, 451-you need to change the address or |create an MX record for its domain 451-if it is supposed to be generally |accessible from the Internet. 451 Talk to your mail administrator for |details. (in reply to RCPT TO command)) | |husky-discuss-request at ....rceforge.net Very funny way of rejecting people... :-? I can't even guess why, or whom to protest/report to. -- Cheers, Carlos Robinson

On Wednesday 28 January 2004 09:38 pm, Carlos E. R. wrote:

Thanks. I'm going to see if there is a newer version - the one in 8.2 sometimes balks with "bad header" and leaves email on the server.

Would appreciate you letting me (the list) know if you solve the issue. My fetchmail clogs up about once a week. Must be a new trick from the spammers... -- +----------------------------------------------------------------------------+ + Bruce S. Marshall bmarsh@bmarsh.com Bellaire, MI 01/29/04 09:32 + +----------------------------------------------------------------------------+ "We have all passed a lot of water since then." - Samuel Goldwyn

The Thursday 2004-01-29 at 09:33 -0500, Bruce Marshall wrote:

Would appreciate you letting me (the list) know if you solve the issue. My fetchmail clogs up about once a week. Must be a new trick from the spammers...

I'm trying to compile it. There are two messages in the configure run that worries me: root-mode pid file will go in /var/run checking for procmail... /usr/bin/procmail checking for sendmail... /usr/sbin/sendmail checking for maildrop... no Will not use a fallback MDA <================ checking for short... yes checking size of short... 2 checking for int... yes checking size of int... 4 checking for long... yes checking size of long... 4 checking for inner_connect... no Disabling SSL support... <==================== Both openssl and openssl-devel are installed. It seems to be looking for a "crypt" library: configure:11739: gcc -o conftest -O conftest.c -lcrypt -lresolv >&5 but I don't know which one could it be, there is no such lib: libxcrypt-1.4-23 libmcrypt-2.5.5-27 cryptplug-0.3.15-26 libgcrypt-1.1.12-14 Looking at the original SuSE's fetchmail, the dependencies are: cer@nimrodel:~> rpm -q --requires fetchmail smtp_daemon ld-linux.so.2 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.3) libc.so.6(GLIBC_2.2) libc.so.6(GLIBC_2.3) libcrypt.so.1 ----> glibc-devel libcrypto.so.0.9.6 ----> openssl libdl.so.2 libresolv.so.2 libresolv.so.2(GLIBC_2.0) libresolv.so.2(GLIBC_2.2) libssl.so.0.9.6 rpmlib(PayloadIsBzip2) <= 3.0.5-1 At least, it compiles. -- Cheers, Carlos Robinson

The Friday 2004-01-30 at 20:58 +0100, Ivan Sergio Borgonovo wrote:

...

I'm trying to compile it. There are two messages in the configure run that worries me:

I made the rpm and srpm for SuSE 8.1 and it is working. I don't think it could be harder to make it for 9.0.

It has ssl and all other stuff. The only thing I changed compared to original SuSE rpm was disabling POP2.

In 8.2 there must be something different, it complains there is no ssl.

If you need it I can compile one for i586 or i686.

Thanks, but I like compiling for my self - and I use 8.2. I have it there, waiting till I see a mail stuck on the server; then I will test whether it solves the problem or not :-) -- Cheers, Carlos Robinson

The Saturday 2004-01-31 at 18:02 +0100, Ivan Sergio Borgonovo wrote:

...

In 8.2 there must be something different, it complains there is no ssl.

Did you try with the SuSE .spec file configure?

No; but you must remember that the rpm build command runs the configure program, and it is "configure" who says there is no SSL. Mmm, lets look again:

./configure --prefix=/usr \ --disable-POP2 \ --enable-nls \ --> use Native Language Support --with-included-gettext \ --> use the GNU gettext library included here --enable-NTLM \ --> compile in NTLM authentication support --enable-RPA \ --> compile in RPA protocol support --enable-SDPS \ --> compile in SDPS protocol support --mandir=%{_mandir} \ --infodir=%{_infodir} \ --sysconfdir=/etc \ --sharedstatedir=/var \ --with-ssl=/usr \ <========== --disable-nls --> how come? enable or dissable? # --with-gssapi # --with-kerberos5 # --enable-opie

Note: nls is both enabled and disabled. Is that possible? Perhaps the trick is "--with-ssl=/usr" - let's see... yes, that was it. Now I have ssl. Interesting, must be something different in SuSE than what the author used for development. Still, there is another section wrong: |checking for procmail... /usr/bin/procmail |checking for sendmail... /usr/sbin/sendmail |checking for maildrop... no |Will not use a fallback MDA Looking at the neededforbuild and usedforbuild sections I checked what rpms I had not installed: |neededforbuild: | package opie is not installed |usedforbuild: | package rcs is not installed | package sendmail is not installed | package opie is not installed Sendmail obviously I don't need, as I use postfix. Rcs... I'm not a developer. opie... what for? It is a pam module. | Summary : An OPIE module for PAM | Description : | |OPIE stands for "One-time Passwords In Everything". This is a PAM module |implementing this feature. . Well, I'll do it with: ./configure --with-ssl=/usr --sysconfdir=/etc --sharedstatedir=/var --with-included-gettex No with "--with-included-gettex" make fails, I remove it. I finally have the binary ready to test when I get an email stuck on the server with "bad header". -- Cheers, Carlos Robinson

The Monday 2004-02-02 at 21:18 +0100, Carlos E. R. wrote:

Unfortunately, I forgot to run it "verbose". I don't know what that email was, but I think it as a virus.

I got one of them: |Feb 3 20:15:31 nimrodel fetchmail[4676]: reading message ****tiscali.es:1 of 1 (102707 octets) |Feb 3 20:15:31 nimrodel fetchmail[4676]: incorrect header line found while scanning headers |Feb 3 20:15:31 nimrodel fetchmail[4676]: line: This is a multi-part message in MIME format.^M |Feb 3 20:15:56 nimrodel fetchmail[4676]: flushed |Feb 3 20:15:56 nimrodel fetchmail[4676]: POP3> DELE 1 |Feb 3 20:15:56 nimrodel fetchmail[4676]: POP3< +OK message marked for deletion However, I can not find that email anywhere. In the "virus" folder there is nothing that size, nor in the procmail log. There is no handshake wit postfix to send it locally... I think it is simply and silently deleted :-? Bu it is downloaded, I see the modem busy for some time while it downloads those 100Kb. I don't know, I think I could make this fetchmail the default one to use, and see what happens when it handles these kind of email first hand: it could be thinking that this email has already been seen :-? -- Cheers, Carlos Robinson

On Mon, 2 Feb 2004 21:18:37 +0100 (CET) "Carlos E. R." <robin1.listas@tiscali.es> wrote:

Yes, it worked. I just saw an email stuck there:

|Feb 2 20:45:49 nimrodel fetchmail[5004]: incorrect header line found while scanning headers|Feb 2 20:46:30 nimrodel fetchmail[5004]: retained

So, I stopped the system fetchmail (6.2.1-25) and started the new one, and I saw:

|Feb 2 20:48:43 nimrodel fetchmail[5901]: reading message **tiscali.es:1 of 1 (102176 octets)|Feb 2 20:48:44 nimrodel fetchmail[5901]: incorrect header line found while scanning headers|Feb 2 20:49:24 nimrodel fetchmail[5901]: flushed

Unfortunately, I forgot to run it "verbose". I don't know what that email was, but I think it as a virus.

Test proved positive :-)

:( I still have problem with IMAP and the newest fetchmail... I conserved the obnoxious message and I'll try to "download" it through telnet to see what's going on.

On Mon, 16 Feb 2004 14:27:46 +0100 (CET) "Carlos E. R." <robin1.listas@tiscali.es> wrote:

The Monday 2004-02-16 at 11:14 +0100, Ivan Sergio Borgonovo wrote:

...

:( I still have problem with IMAP and the newest fetchmail... I conserved the obnoxious message and I'll try to "download" it through telnet to see what's going on.

I got nothing more on two weeks. You may be able to download it using mozilla (that's what I use), or your isp webmail, if it has it. In any case, you probably won't see what the problem is.

Yep, but it would be nice to fly a bug report to fetchmail author or to my ISP ;) With telnet I can see exactly what's passing by regardless of if it is RFC compliant or not. What I did was in fact use webmail to move it in another folder. Moving it back in the INBOX blocked mail flow again. So... good chance to diagnose what's the problem and fly a bug report/feature request to fetchmail author.

On Mon, 16 Feb 2004 21:31:15 +0100 (CET) "Carlos E. R." <robin1.listas@tiscali.es> wrote:

The Monday 2004-02-16 at 15:14 +0100, Ivan Sergio Borgonovo wrote:

...

So... good chance to diagnose what's the problem and fly a bug report/feature request to fetchmail author.

Right. I think they have a mail list. Read the FAQ first, starting with G3. And retry calling fetchmail with "-v -v", to get an extended log.

I did and I didn't discover anything interesting. fetchmail just stopped waiting... So I'm planning to do it "by hand" as soon as I'll finish to build last snapshot of kdesdk3. BTW the blocking email was not spam and it was coming from a well known source. So at least we don't have to worry about any sort of counter attack of spammers vs spam fighters.