fetchmail's not forwarding mail

Fetchmail can check my mail from the pop servers fine, if I run fetchmail -c, it'll tell me how many messages I have, but it won't forward it to /var/mail/kozumo. Is there something special I have to do to make it do that?

Thanx

P.S. here's my .muttrc, since GnuVince seems to believe that it's a mutt problem:

set folder=~/mail
set mbox=~/mail/inbox
set record=~/mail/sentbox

[pbharris]

here is my ~/.fetchmailrc

set postmaster "pbharris"
set bouncemail
set no spambounce
set properties ""
set daemon 1200
poll mail.intermaxx.com with proto POP3
    user 'pbharris' there with password 'n0w4ym4n' is 'pbharris' here

i don't use mutt, if it is like elm then it should not matter, elm moves all my stuff to ~/Mail

hide your password, mister!

[pbharris]

hide your password, mister!

fret not
'tis not my password, my username or my ISP

[Outlaw]

author=kozumo link=board=software&num=1019348989&start=0 #0 date=04/20/02 at 20:29:49]
Fetchmail can check my mail from the pop servers fine, if I run fetchmail -c, it'll tell me how many messages I have, but it won't forward it to /var/mail/kozumo. Is there something special I have to do to make it do that?

Fetchmail passes mail to the delivery agent which in turn puts a copy in var/mail/user and var/spool/mail/user. When the mail has been read, and you tell mutt it's ok to send read mail to mbox, it will be deleted from /var/mail/user and /var/spool/mail/user.

You should be running some sort of delivery agent such as postfix or exim.

Mutt will, by default, look in /var/mail/user for mail.

Have a look at this: http://www.linuxjunior.org/cgi-bin/p...play&id=16

Thanx radar, I have exim installed and I was wondering if there was anything in exim.conf I should put so that my mail from the pop server gets received by mutt, because I took a look at it and nothing seems wrong, the domain have the right authorizations and I don't know what else to add to it.

Thanx

[Outlaw]

I have to clarify what I said above, for my setup, procmail puts a copy in /var/mail/user based on my .procmailrc - and so when mutt starts up, it looks there. So if you don't want to use procmail, and you want exim to dump the mail where you have mutt looking, change the transport line in exim.conf. Where is mutt looking when you start it up? /home/kozumo/mail? You can tell when you fire it up by looking att the bottom.

Here's my first transports entry:

# TRANSPORTS CONFIGURATION #
################################################## ####################
# ORDER DOES NOT MATTER #
# Only one appropriate transport is called for each delivery. #
################################################## ####################

# This transport is used for local delivery to user mailboxes. On debian
# systems group mail is used so we can write to the /var/spool/mail
# directory. (The alternative, which most other unixes use, is to deliver
# as the user's own group, into a sticky-bitted directory)

local_delivery:
driver = appendfile
group = mail
mode = 0660
mode_fail_narrower = false
envelope_to_add = true
return_path_add = true
file = /var/spool/mail/${local_part}

If your outgoing mail is working, you can send yourself a test and verify that mail is going to where exim says it's dumping it. In this case do mutt -f /var/spool/mail/kozumo - it should be there. If not check also /var/mail/kozumo. If not there either, do mailq as root to see if the mail at least is in the system, but undeliverable. Sometimes the mail files are not giving the delivery program write access. Also, sometimes if your outgoing mail has for example localhost as the qualify_domain instead of provider.net, the outgoing mail provider will refuse the mail. But that would only affect outgoing mail - though it does'nt help when your trying to send test mails to yourself.

Let me know how your making out. I can perhaps send you some test mails.

Check your private messages.