fetch. mail.

[cdevers at pobox.com (Chris Devers)]

Inspired by recent mails here discussing Fetchmail, I'm giving it a try,
and for the most part, it seems pretty straightforward.

Aside from the mysterious evaporating messages, that is.

I currently have my Pobox account set up to forward my old college
address, which is accessible either via POP or locally via telnet (they
don't seem to want to install ssh, *shrug*).

Among the mail going to this account is BLU mail, and Craigslist
subscriptions. Other stuff too, but let's just use those as examples.

The BLU mail is properly being downloaded & handed off to my local SMTP
daemon for local delivery, but the Craigslist mail is disappearing
somewhere along the line.

I can telnet into the account & open up Pine to verify that the CL mails
are making it to this account.

Scanning the fetchmail log, I see lines like this (abbreviated, and
certain data is obscured like ${so}):

    fetchmail: POP3> LIST 1
    fetchmail: POP3< +OK 1 1399
    fetchmail: POP3> RETR 1
    fetchmail: POP3< +OK 1399 octets
    fetchmail: reading message cdevers@${pop-server}:1 of 7 (1399 octets)
    fetchmail: incorrect header line found while scanning headers
    fetchmail: line: plain^M
    fetchmail:  flushed
    fetchmail: POP3> DELE 1
    fetchmail: POP3< +OK Message deleted
    fetchmail: POP3> LIST 2
    fetchmail: POP3< +OK 2 1962
    l: POP3> RETR 2
    fetchmail: POP3< +OK 1962 octets
    fetchmail: reading message cdevers@${pop-server}:2 of 7 (1962 octets)
    fetchmail: incorrect header line found while scanning headers
    fetchmail: line: plain^M
    fetchmail:  flushed
    fetchmail: POP3> DELE 2
    fetchmail: POP3< +OK Message deleted
    fetchmail: POP3> LIST 3
    fetchmail: POP3< +OK 3 3829
    fetchmail: POP3> RETR 3
    fetchmail: POP3< +OK 3829 octets
    fetchmail: reading message cdevers@${pop-server}:3 of 7 (3829 octets)
    fetchmail: SMTP< 220 postfix.${localhost} ESMTP Postfix
    fetchmail: SMTP> EHLO localhost
    fetchmail: SMTP< 250-postfix.${localhost}
    fetchmail: SMTP< 250-PIPELINING
    fetchmail: SMTP< 250-SIZE
    fetchmail: SMTP< 250-VRFY
    fetchmail: SMTP< 250-ETRN
    fetchmail: SMTP< 250-STARTTLS
    fetchmail: SMTP< 250-AUTH LOGIN PLAIN
    fetchmail: SMTP< 250-AUTH=LOGIN PLAIN
    fetchmail: SMTP< 250-XVERP
    fetchmail: SMTP< 250 8BITMIME
    fetchmail: SMTP> MAIL FROM:<${someone}> SIZE=3829
    fetchmail: SMTP< 250 Ok
    fetchmail: SMTP> RCPT TO:<cdevers at localhost>
    fetchmail: SMTP< 250 Ok
    fetchmail: SMTP> DATA
    fetchmail: SMTP< 354 End data with <CR><LF>.<CR><LF>
    .fetchmail: SMTP>. (EOM)
    fetchmail: SMTP< 250 Ok: queued as E895E16E327
    fetchmail:  flushed
    fetchmail: POP3> DELE 3
    fetchmail: POP3< +OK Message deleted


So, there's not a lot of detail to work with, but it seems like maybe the
CL mail system is sending out messages with malformed headers, and
Fetchmail is choking on retrieval of these messages.

How, short of getting the CL staff to reconfigure their servers (it's not
even clear that all of the malformed mail is coming from them to begin
with) can this be handled?

The relevant line in my ~/.fetchmailrc is:

    poll ${popserver} protocol pop3 username cdevers password ${password}

Is there something I can plug into ~/.fetchmailrc that would attempt to
download even malformed messages, &/or not automatically delete ones that
it had a hard time with?

It seems like one approach would be to have procmail & formail clean up
the message headers on the POP server, seeing as I have shell access. But
if that machine isn't even running SSH, I'm assuming installing formail is
out of the question -- and in any case, it seems cleaner to come up with a
solution that will work even if shell access to the remote mail server
isn't available.

Any ideas? Thanks :)



-- 
Chris Devers