On Thu, Aug 24, 2000 at 10:27:44PM -0400, Neil L. Roeth wrote:
> My impression is that you think that to get mail from several sources
> with fetchmail and have it put into separate folders requires that you
> dump it into a single file and then filter using regular expressions
> in procmail.
Nope. I feel that if one wants to have filters that separate mailing
lists out on a per account basis one must also have the filters contain logic
to know which account those lists are going to so they also know which
subdirectory to place them into. So, for example, if I have lists for foo and
bar and they are directories under ~/Mail how will a filter know that incoming
mail from a mailing list is to bar and place it in ~/Mail/bar/lists/barlist
without that logic in the filter itself?
> uses procmail, but does not even require a procmail configuration
> file, and therefore has no regular expressions, much less any to
> modify, to put mail from separate mail accounts into separate folders
> on your local machine. Mail from separate accounts *never* gets
> merged into a single source from which it needs to be filtered.
But it also doesn't get filtered at all so all incoming mail from all
mailing lists is merged together once again. While I use mutt in this
configuration and find it up to the task I don't enjoy it and would much
rather the mail be separated out with mutt providing me a constant, on-screen
overview of what accounts and folders within those accounts have new mail.
> Extensions to allow the folder to have a different name than the mail
> server, and to invoke fetchmail just once for all your mail servers,
> are obvious. The above assumes one account per mail server, but that
> is not hard to relax, either.
True.
> problem of the mail clients. As others have pointed out, you can
> configure existing mail clients to send it out via the correct server
> with hooks attached to the folders. That sounds darn close to what
> you want.
Close, but not ideal to what I need. This is something I cannot waver
upon. Thank you for your insight, though.
> We are all looking forward to trying out the mail client you build that does
> exactly what you want - I would like the Emacs version :-)
Nope, no Emacs. :P
I find it humourous that later on you ask why one should build SMTP into a
mail client yet, apparently, have no problems with an editor that has a built
in FTP client, web client, mail and news client... :)
> I don't understand why you object to your mail client invoking an
> instance of, say, sendmail in order to contact the appropriate
> outgoing server for the particular message you are sending. Some
> process has to contact that server using SMTP, why build SMTP into a
> mail client when there is already an existing program that does that?
The assumption is that there is a sendmail to envoke. In a private
message to someone else I finally was able to put to words why I say an SMTP
interface is a requirement for a mail client in my mind. Let me see if I can
rewrite what I wrote there (at work on a different client and I don't have my
ZIP disk with me to get at those archives).
It all comes down to defining an interface. When an MUA calls an MTA now
it is traditionally via the command line. However, this is not the only way
one can call an MTA. SMTP is just another interface to that MTA, IMHO.
However, there are two differences between the command-line and SMTP that I
can see.
1: Command-line you're limited to the local machine doing delivery. I do not
think a blind handoff is a "delivery" so having a local SMTP server doing
nothing but smart-host handoffs is a waste of resources.
2: SMTP is a defined standard (RFC821 IIRC) whereas command-line has no
defined standard of getting the message to the MTA. The current ad hoc
standard is "Sendmail replacement" which means it mimics sendmail's behavior
as of version x with no guarentees that it mimics any recent command-line
interface chances. And let's not even get into the grand-daddy issue of
sendmail. Tell me, what is the default location of sendmail again? /etc?
/lib? /usr/bin? /usr/sbin? /usr/lib? I forget what it is on OS/2 and BeOS.
I forget if BeOS has a variant of sendmail.
Correct me if I'm wrong but in fetchmail's past it didn't directly call
the MDA but, instead, fed the messages into the MTA through SMTP. I do
believe that is still an option. I would also like to think that fetchmail
also allows the option of feeding into a different machine's SMTP server.
In fact, a quick check of the man page on fetchmail's man page says that it
does.
Now, the MTA's job is to know how to deliver the message from one machine
to another. Great, the MTA is still there to do that. But by building SMTP
into the client you have the added option of not being forced to use the local
MTA, if indeed there is one. There is a difference between adding another
interface into a mail server and adding in the functionality of an MTA.
Finally, there is always the argument of space on disk, in memory and cost
of a person's time. He honest now. Which one is smaller on disk and in
memory? A full MTA that is /only/ going to be used in smart-host mode (IE,
blindly forwarding to a single SMTP server you specified) or a small routine
in the mail client using mostly functions that are already there (remember,
mutt does do basic POP and IMAP so adding network code isn't an issue, it is
there) to do the same thing? Which one is easier to setup, a full MTA,
running the risk of an open relay or this:
outgoing-smtp: smtp.isp.com
outgoing-smtp-port: 25
Surely you must admit that is even easier than trying to figure out what
interface to use on the command line and configuring it for a plethora of
different unix and pseduo-unix variants of sendmail and sendmail replacements.
That is the joy of being modular /and/ standards compliant.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
