This might sound ridiculously simple-minded, but what is the difference between the type of mail client or system installed by default in Slackware compared to the more popular type of mail clients such as KMail or Thunderbird? I'm looking for a general description to understand the conceptual differences.

Like many people, to me the world of email is based upon a perspective of using a mail client software package. In Windows I have been using Eudora for many years. I hope to soon migrate to KMail. When I first installed Slackware and was prompted with a message that I had mail, I simply replied, WTF? As I have matured in my understanding of Slackware, I am starting to perceive that possibly there are several levels or types of mail clients. After some surfing, however, I found no satisfying explanation of the differences between a mail client such as KMail and something more low-level that provided me that curious screen message the first time I installed Slackware. When is one type of client suitable over another? I am unsure.

Because of my initial perspective, when I grew more familiar with Slackware and many months ago I reinstalled Slack to my multi-boot box, I installed no mail client packages. After all, from my perspective, eventually I'd be installing and configuring KMail. Thus, why bother with some ancient and cumbersome command-line or console-based client package? Made no sense to me at all.

At this time, I receive no cryptic messages when I login at the console. Yet, now I am wondering if that was a good idea and that perhaps I ought to install at least one "low-level" package. My thinking is that as I continue to mature in my understanding of Slackware I might one day want to receive mail messages generated from various system processes. To build my overall understanding I soon intend to install Slack on a second box and on that box play much more liberally and install many more packages than what is minimally installed on my current multi-boot box. Perhaps this time I ought to install a basic console-based mail client. But my purpose would not be so much to receive cryptic messages if I login at the console because I overwhelmingly login through KDM. Thus, any mail messages generated through various processes need to get forwarded to KMail. I am unsure if I have this concept correct, however.

I am looking for a conceptual understanding of all of this. I suspect that all explanations offered in this thread will help more people than just me.

Thanks again!

well ultimately there's no official differences in what you're asking about, but basically the underlying point is that most linux distros come with some form of SMTP server built into it. This means you have a mail delivery subsystem ready and waiting to be hooked into by ANYTHIGN that needs to send mail. (Windows does a very similar thing through MAPI i think... but badly) These notifications that you have mail are from a scripted check like biff looking at the contents of /var/spool/mail/username. this is an mbox mail file, and is a totally standard way to store mail. you can make KMail read them just like a console client like mutt can. From having this underlying subsystem, you just need a slight tinkering of the config to be able to send out email to the internet just by giving it to your own machine from any mechanism you want, be it a command line (like the emails from cron i expect you're getting) or a fully featured email client like Thunderbird or KMail.

There are a bunch of different ways to store mail, mbox'es like above, then Maildir's and MH mail files and then less conventional or accessible mechanisms like the larger clients might use. personally i recommend using a generic server interface to access your mail. by only communicating with a local IMAP server you leave the mail in it's original location rather than those apps sucking up your mail into a format that just annoys you later in life when you want to access it from different angles... but that's just me.

Thanks for the reply!

How is this (or could be) useful to me? That is, somebody using a computer strictly as a single-person workstation and not as a server? From my perspective, I need POP3 access to retrieve my mail from a mail server, and I need access an external SMTP server only to send my mail. Why would I need an SMTP server on my own box? Or are you implying that I could use this built-in SMTP server to bypass my ISP when sending my emails?

Why would I want to store my mail there, instead of inside a directory configured by my mail client in my home directory?

In a related question, is placing the biff check in /etc/profile as PV packages Slackware a good place or should this check be performed somewhere else when each individual logs in? Or does biff check only mails for the root account? I'm terribly fuzzy on this.

How do I configure these system processes to send mail to a different location other than /var/spool/mail/username, such as to a directory on my home directory? I expect eventually to migrate to KMail. I also do not want these system mails going to root, but to my normal user account. This seems easier for me, I think. Or am I missing the big picture still?

Please understand that my perspective is from a limited view and understanding of mail (from Windows), where the only tool I have known is a user-based mail client that fetches and send my email and stores that mail in a user directory, not some "strange" place like /var/spool/mail/username.

- basically you just give the email to yourself, it does the MX lookups and off goes the mail, no external SMTP hosts involved. in reality though, shitty ISP's like AOL block dynamic IP ranges, so you often end up relaying them upstream to a static SMTP, but it's all there in theory and does make it really nice and simple.

- cos that's where it's been stored in UNIX for decades! Personally i never use biff... it was used on the solaris network at my old university, which is the only reason i know about it.

- that's down to the SMTP server again. i've not really looked into it too much, but sendmail prefers mbox files, whereas psotfix likes maildirs (which generally DO live in /home/user/Maildir/) for example, on my mail server mails to root get sent to a folder within my personal user account. myprocmail setup that postfix passes the mail on to automatically puts it in a "root" folder. simple.

As i'd mentioned above, windows does actually do stuff like this already, but not in the same way. if you have outlook installed and stuff, you'll have a MAPI profile which means you can write a 5 line wscript file to send emails to whoever you want, through scheduled tasks etc... pretty similar really

Thanks for the info. I plan to soon (within days) install Slack 10.2 on a second box. Unlike my first time, because this box will be dedicated to Slack and no additional operating systems, I will possess more than sufficient drive space to perform a full install and all of this kind of thing will be there for me to explore fully.

Your description leads me to understand that rerouting all of these process mails to my normal user account is no big deal and having a built-in SMTP server will allow me to bypass the ISP in this respect (my ISP does not block that).

No, I don't use Outlook. I long ago stripped that program from my box, as well as all the ActiveX stuff and IE.

Your responses have helped me some, although I will learn more in the upcoming days when I play with my second box. I think part of my confusion is how I use the word server. By design the basic 'nix box is a server because of the inherent multi-user design, even when that box is serving only one user locally at that box. This is a conceptual problem, I think.

The email message upon a slack install is from Mr. V. After you log in as root the first time to set up a user account, just type pine at the console to read the message.

Not sure, if that helps, but just for your fundamental understanding and further research it may be worthy to know some common definitions and abbreviations. Note, that I only can give a *very* rough overview here, as Email is sitll the most complex service on the Internet.

The basic concept of email message transport comprises a number of components.

MUA (Mail User Agent). This is the actual mail client. It is the program that you use to read, prepare and edit email messages. Pine and Mutt are typical examples.

MTA (Mail Transfer Agent). This is the program for transmitting email messages. Slackware comes with Sendmail as standard, Postfix, Exim and QMail are also popular. The MTA usually manages the spooling and queuing of inbound and outbound Email.

MDA (Mail Delivery Agent). This type of program is responisble for delivering incoming mail from the spool directory to the actual recipient on the local system. Fetchmail and Procmail fall into this category, although fetchmail is quite a bit more than just an MDA. In fact, Fetchmail fetches mail messages from a POP3 or IMAP folder at your ISP, while Procmail can apply lots of filtering.
With fetchmail and procmail combined you can, eg, set up a dial-up machine with many users on it that share only one email account and only one Internet email address and still can receive email just for them. Procmail scans the incoming mail messages fetched by fetchmail for characteristica that you can freely define and then deliver each message to the user account it is meant for on your machine. Very powerful!

Now, what about KMail, Mozilla Thunderbird and such?
In fact these programs can do everything on their own, and as long as you are the only user of your machine, it is much simpler to set them up than to configure the whole trinity of MUA, MTA and MDA. Once you have more than one user, you may find scenarios, when you need more flexibility, but those programs will carry you quite a few miles.

Regarding your question about a "basic" or "command line" mail tool, you should never delete the program called mail or mailx. Unix based system need this program for certain internal tasks (sorry, never understood myself, what they actually do with it, just found that it may cause BIG trouble to delete that program).

BTW, you don't need Mutt and Co. You can do it all with mail. But when you try it out you will at once now why programs like Mutt and KMail have been developed --- it has something to do with "end-user experience" ;-).

In case you want to learn more, the best information on this subject I ever found were some articles in SuSE's support database. Go to http://sdb.suse. com and search for 'mail'.

gargamel

Now THAT was helpful!

Actually I don't see why KMail, etc. can't be used on any typical workstation, even with multiple login accounts, because users would fetch their own mail when they use the box.

Any idea of what kinds of problems? In my stripped-down installation of Slack 10.1. I never installed the mail utility, and I disabled that biff stuff in /etc/profile too. My box works well (as far as I can see ). Thus, what might I be missing? I haven't notice /var/spool getting any larger.

I intend to stick with KMail. That tool seems the most similar to Eudora and is native KDE, the desktop environment I prefer. The only thing I have yet to figure out is how to operate KMail from three separate config files. I have been doing this for several years with Eudora (I monitor mail for two other people in addition to my own personal addresses and I insist upon keeping the files stored in separate directories). I don't need to run three concurrent sessions of KMail, which I can do with Eudora, I just need to keep the files in separate directories and use different respective config files. I'd be grateful if anybody has some insight into this.

Yes, I know T-bird provides a profiles option that probably would do what I need in that one respect, but I dislike GTK apps in general and on my KDE. I'd rather just use native KDE apps.

With a single machine or only a handful of them there is no big problem with that. But as the number of users and machines increases a centralized mail hub becomes more and more practical. Eg, you can then filter incoming email for spam and viruses before delivering them. Other reasons to implement such an architecture are performance and hiding identities. You can do almost everything with KMail, too, but at some point you will find yourself repeating the same administration tasks over again for each user and each mail account (which may not be the same). Good admins will try to protect their users against certain types of attacks, spam and viruses, without too much impact on the overall system performance. So it's actually a question of efficiency. In your scenario it just makes no sense to set up an MTA. But with thousands of mail accounts on several dozens of machines it is different.

There may be no mail or mailx package that you can remove, as it is a basic Unix command included in some other package in series A (though I havent't checked it). Vice versa, you don't have to install it, because it is not optional. As far as I remember mail (or mailx, one of them) must be there, because some other programs depend on them and won't properly work without it. You probably can delete the binary files for the command, and still be able to boot and work with your system, but you may find that some commands behave strange, and you may not even get a hint that it is because there is no mail or mailx.

KMail is excellent, and it is probably the best mail tool for your environment. The only reasons I prefer Mozilla Thunderbird is that it exists on Linux and Windows, and because it can do S/MIME encryption.

Just one closing hint. If you are totally sure that you will never have to exchange mails with other programs, then stop reading here. Otherwise I'd like to suggest that you think about the storage format for your mail. This is a non-obvious, but very important point.

Let me explain it in short:

mbox is very simple. It doesn't know anything about folder hierarchies. However, Mozilla Thunderbird, KMail and others can store Email in mbox folders with sub-folders that have sub-folders on their own, and so on. How can that be?
The trick is that these programs use index files. But what is good for the usability becomes a big problem when you want to import Email into another program in the future. Eg, Mozilla Mail can import Email from a number of programs, including mbox folders, but it can't handle indexed mbox files as created by KMail.

So, if you choose mbox, try to avoid multi-level folder hierarchies.

In fact, this problem (and some other shortcomings of mbox) were the motivation for some developers to create new formats like mh and maildir. Programs that can handle mh or maildir can much more easily exchange mails. Folder hierarchies are no problem here. However, not all mail programs support these formats. Mozilla Mail, eg, doesn't even provide an import or conversion filter. Mutt can do MH, KMail cannot.

So the disadvantage of all non-mbox formats is that they aren't nearly as widely supported as mbox is. Although all of them are technically superior.

If you ever have the need to convert mail folders from one format to another, Sylpheed can prove very helpful. Although it is GTK based. ;-)

Have fun!

gargamel

Currently I use Eudora 5.1 in Windows as my mail client. I just haven't had the time or energy to start thinking about migrating that aspect of my online activity. Eudora uses the mbox format, although I understand that KMail has (or at least once did have) issues with importing Eudora mbox files because of something Eudora does quirky. There are third party tools available for converting, although I might have to install an extra mail client to import all of my Eudora folders. I've been leaning loosely toward converting to maildir, but I have not yet crossed that bridge.

On my second box, soon to be dedicated solely to running Slackware, I did a full install so I will be able to more fully investigate the links and processes of some of this. I'm already receiving the "silly" you have mail message when I login at the command line, but I have had more important installation and setup concerns for the moment.

KMail is an obvious choice merely because I like KDE. I toyed with KMail several minor versions ago so I suppose a lot will remain familiar.

Thanks for all of your time and help!