Hi Reg!
Is there any chance you can post to the list in plaintext, rather than
HTML..? That's more readable for most people. Personally, I do kinda approve
of HTML, because it saves wasting those characters of my monitor > the 80th
one, but you chose a font which appears *terribly* small on my system.
On 10/8/03 8:47 pm, "rh" <[EMAIL PROTECTED]> wrote:
>
> Fetchmail / Procmail is working. But where exactly does fetchmail put your
> email before it passes it to procmail?
Standard out, I think - I'm pretty sure that that's how fetchmail passes
messages to maildrop, which I use.
The fetchmail man pages are massive and comprhensive - they're worth
printing out if you have access to a duplex printer. I think they're
available in .pdf.
I haven't used procmail, so I hope you find the following manpage extracts
pertinent:
man fetchmail:
fetchmail is a mail-retrieval and forwarding utility; it fetches mail
from remote mailservers and forwards it to your local (client)
machine's delivery system...
As each message is retrieved fetchmail normally delivers it via SMTP to
port 25 on the machine it is running on (localhost), just as though it
were being passed in over a normal TCP/IP link...
If no port 25 listener is available, but your fetchmail configuration
was told about a reliable local MDA, it will use that MDA for local
delivery instead. At build time, fetchmail normally looks for
executable procmail(1) and sendmail(1) binaries.
man fetchmailconf
-m <command> | --mda <command> (Keyword: mda)
You can force mail to be passed to an MDA directly
(rather than forwarded to port 25) with the --mda or -m option. To avoid
losing mail, use this option only with MDAs like procmail or sendmail
that return a nonzero status on disk- full and other resource-exhaustion
errors; the nonzero status tells fetchmail that delivery failed and
prevents the message from being deleted off the server.
When invoked, it first sets some environment variables to default
values, reads the mail message from stdin until an EOF, separates the body
from the header, and then, if no command line arguments are present, it
starts to look for a file named $HOME/.procmailrc. According to the
processing recipes in this file, the mail message that just arrived
gets distributed into the right folder (and more). If no rcfile is
found, or processing of the rcfile falls off the end, procmail will
store the mail in the default system mailbox.
man procmail
... When invoked, it first sets some environment variables to default
values, reads the mail message from stdin until an EOF, separates the body
from the header, and then, if no command line arguments are present,
it starts to look for a file named $HOME/.procmailrc. According to
the processing recipes in this file, the mail message that just
arrived gets distributed into the right folder (and more). If no rcfile
is found, or processing of the rcfile falls off the end, procmail
will store the mail in the default system mailbox.
On my system:
$ head .fetchmailrc
defaults
timeout 60
protocol pop3
# Test porpoises only
# keep
# fetchall
mda "/usr/bin/maildrop -d $USER"
> And if I am losing emails due to a bad procmailrc, how would I know it?
>From the above comments about "non-zero exit status", I don't think you can
lose mail in this way. Note the "keep" and "fetchall" commands in
.fetchmailrc - I found these VERY useful during installation & testing (they
allowed me to download the same messages a couple of dozen times during the
tweaking of my filters).
With maildrop, as I have discovered by making typos, if the filtering rules
send the message to a non-existent Maildir directory, they are instead
written or appended to the end of a file called "dead.letter" in ~user. If
.mailfilter does not have a rule to catch the message then the message goes,
I'm pretty sure, to the user's root Maildir (ie: the user's inbox).
Mailfilter is an alternative to procmail, so this is not of direct interest
to you - I only mention it as an observation.
> My emails are sitting in my ~/.maildir (after being fetchmail'ed and
> procmail'ed), and I can read them using any text editor. Is this normal?
Yes. From `man maildir`:
MESSAGES
E-mail messages are stored in separate, individual files, one E-mail
message per file. The tmp subdirectory temporarily stores E-mail
messages that are in the process of being delivered to this maildir. tmp
may also store other kinds of temporary files, as long as they are created
in the same way that message files are created in tmp. The new
subdirectory stores messages that have been delivered to this maildir, but
have not yet been seen by any mail application. The cur subdirectory
stores messages that have already been seen by mail applications.
> Does Courier-IMAP now just read the emails from this directory?
Yup. From http://www.inter7.com/courierimap.html
"The primary advantage of maildirs is that multiple applications can access
the same Maildir simultaneously without requiring any kind of locking
whatsoever."
> And I am assuming
> that when I try to access my email from my work computer, the emails stay on
> my home computer and are not downloaded to my work computer, correct?
Yes. You should try it using various clients over the LAN. IIRC your wife
has a Windows box, so you should be able to connect from that - I recently
connected to the courier-imap server on my LAN using my mother's PC, Outlook
Distress & her 56k dial-up connection. It was a little slow synchronising,
but quite adequate, especially considering how big some of my mailboxes are.
Note that Outlook Distress doesn't handle the "Trash" folder correctly - it
wants "Deleted Items" (this is mentioned in /etc/courier-imap/imapd), but
the system still seems to be usable. For hints on configuring some mail
clients check out: http://www.inter7.com/courierimap.html
HTH,
Stroller.
--
Enjoyed this post? Thanks for reading - please consider employing me!
Technical support / system administration - CV available on request
Linux / Unix / Windows / Mac OS X - UK or anywhere considered
--
[EMAIL PROTECTED] mailing list
