Adrian Irving-Beer wrote a nice summary of mail handling including:
> When an MTA like sendmail, Postfix, etc. gets a mail,
> it may do one of two things. If it's configured to
> have a "smart host" / "relayhost", it will simply
> connect to that host, send all four pieces of info,
> and let that server handle everything. The server
> must be set up to allow relaying from the sending host's IP address.
Does Postfix have any place in the incoming mail path?
Or should it be basically:
- fetchmail to /Maildir for IMAP server
or
- fetchmail to ~/Inbox for direct local use by KMail
If one is not filtering spam or the like, is there
a need for (say) Procmail in the middle?
If KMail could accept mail from the ISP's POP3 server,
and do its own sorting afterward, does it need anything
different when fetchmail is used to get the mail from
the ISP first?
If fetchmail is now the entity (instead of the mail
reader such as KMail) that's going out to
the ISPs POP server, and a local IMAP server (say,
Courier or Dovecot but not necessarily them if there's
a better solution for just four people...), then the mail
should just be dumped into <somewhere>/Maildir and
the IMAP server worries about sorting it out and
showing _copies_ to requesters that connect to
(I forget the number of ) the IMAP service port, right?
If IMAP is initially set up to be just /Maildir/Inbox,
does one attack the IMAP server directly (or edit
its config file) to introduce useful subdirectories
like [OCLUG] and [SUSE] etc. for fetched mail,
or does that get done at KMail and somehow told
to IMAP server, or does it all happen in KMail's
imagination and the IMAP server never needs to
know that Mail that initially came into the Inbox
is should hereafter be seen as living in a folder
labelled [OCLUG] or a folder labelled [SUSE]?
My assumption was that the basic
/Maildir/
cur
new
history
directories would be augmented by instructions from
the connecting mail-reader, to create the useful
category directories and move received mail into
them. But other than Exchange at the office, I've
never had an IMAP setup to play with and see what
a working one looks like, needs, will tolerate...
> (Note that this is also what Windows mail clients do;
> they connect directly to their ISP's mail server,
> send all the info, and let the server handle it.)
> If not, it will go through the recipient list.
> Every recipient's domain is looked up, using a
> DNS query for "MX" (Mail eXchange) records. These
> denote mail servers set up to handle mail for that
> domain. It connects to each of these (port 25)
> and sends the envelope sender, the list of recipients
> that "reside" on that server, and the headers and body.
If one does not even have an in-house DNS server
(little four-computer household LAN served by a
LinkSys router and ADSL modem), is any of that
last paragraph applicable? This is the kind of
stuff that I constantly _almost_ get when reading
/d/o/z/e/n/s/ hundreds of pages of man/info/howto/
list-mail on-or-near the topic.
Also, assuming that one intends to let the local
ISP do everything outgoing, what (in say Postfix
configuration) tells it to handle outgoing mail
that way, rather than using the MX records to find
a selection of remote servers directly? To put
that question in more practical terms (or to highlight
that I've misunderstood the concept...), what setting
might a know-nuthin' have innocently answered/changed,
not knowing that this causes Postfix to ignore the
smarthost option. Or yet another way... if the
complete configuration necessary to use DNS,
MX records and selected remote servers is not
in place, does Postfix default to looking at
the ISP as a prospective smarthost? Is it likely
that the know-nuthin' has put Postfix in a condition
where it isn't taking either option?
Somebody in the other list mentioned that they
like to get a basic working prototype (proof
of concept?) going before reading RFCs and such
documents, as it helps them get their heads
around terminology and concepts. Hah! I'd love
to have a basic working flow of mail.
(I did, for years, when I just let KMail handle
everything from one Linux box, but now that I
want to have the mail brought locally and
served on my tiny network, it's all gone to hell.)
Part of the problem is that I've read so much
stuff before getting even the most basic
setup working. Man pages and Info and Howtos
going back to the mid-1990s; each one talking
about one or two pieces and assuming that I
knew about the other pieces and already had
them working so the parts I was reading about
should "just work".
My latest blunder when mail seemed to be disappearing
due to my haphazard attacks, resulted in turning
off recognition that incoming messages were dupes
of messages already on my local hard disk - because
I'd already told fetchmail to --keep (on the ISP)
until I have things working locally, this resulted
in a complete new download every ten minutes and
1.5 million files in my /Maildir, 98% of them
duplicates, and no good way to tell them apart because
they all have unique generated filenames.
Naturally, an attempt to move most of this to
another partition took four days of continuous
disk activity. Whoops! Maybe shoulda paid more
attention to that "Beagle" thing that was introduced
with SUSE 10.1 and seems to be trying to index
everything over and over and ...
Probably I should write off the entire last month's
mail as something I'll never be able to recover
(KMail will choke if I ask it to open a directory
containing 1.5 million mails...), re-format my
various partitions and re-install the distro to
ensure that I have fresh, unadulterated versions
of all programs and (more important) their config files.
Kevin (blunderer extraordinaire)
The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.