On Fri, October 8, 2010 7:20 pm, Ron Guerin wrote: > Chris Knadle wrote: ...
>> However that said, far too often what you'll find is that an MTA is >> installed by default, but not configured to upload mail anywhere, and >> also with nobody reading the local mail. Depending on how you look at >> this, this is either only slightly better or possibly worse than having >> no MTA installed at all. > > I agree this is a flaw in the present setup. It's one that snuck in > along with the "GUI Era", I suspect. (not that one has anything > specifically to do with the other) Ah. Actually now that I consider this, yeah, I think it does. If you think about it, Windows Desktop boxes are almost never set up to be able to email to the outside on their own. The reason is that Desktop boxes are not considered to be /servers/. However *nix boxes are capable of doing both, so there's some expectation that certain services that would normally fall into the "server" realm would be running on them... such as mail. The other side of the coin is that it's more robust for communication methods not to have to rely on X-Windows. It would also be a bad idea to rely on X-Windows for communications that were not initiated by a GUI program -- such as a cron job -- because there's also a good chance that this is a server that doesn't have X installed at all. The reason Windows is different on this is because if the GUI doesn't work, then Windows doesn't work. > When everyone was using Pine and > Mutt, you didn't have this problem. Now, for obvious reasons, we live > in a world of POP3 and IMAP4 and not the presumption of a local mailbox > in one of the standard mailbox formats (practically speaking, that's > either mbox or Maildir). You're right on this one, too. Mutt will look at local mailboxes by default, but almost no GUI-based MUA [Mail-User-Agent] seems to do that by default, and I've even had trouble configuring some MUAs (like kmail) to look at a mailbox on the local machine. > Is there some master Bugzilla for the > Intertubes where we can file a bug along with the suggested fix that > distros ship MUAs that automatically connect to the local user's mailbox > unless told not to? Actually I wonder if that could be put into one of the standards, such as LSB. Or perhaps there's an MUA-specific RFC that could be amended to add this. >> How many people on this list bother to configure their desktops and >> laptops to allow forwarding mail to an external mail server? [I just >> recently had to do this, but before that I never bothered.] >> > > I tend to be religiously observant about MTAs being properly > operational. Yet, this year, I installed Linux on a notebook for > myself, selected the MTA I prefer these days, and then forgot to set it > up to route around any ISP's attempt at filtering. This eventually got > done when I went looking for a problem, which had gone unnoticed simply > because the mail was queued and unable to escape any of the networks I'd > been connected to. > > Obviously you've pointed out two important flaws in how things work (or > fail to) in the real world. Maybe mail isn't the right way to get these > messages, but it's what we have, and it's what we use. And if it's set > up properly, it works a good deal better than what you get in Windows, > which is the equivalent of the unwatched mailbox. (Event Viewer use is > not a passive act) > > My question would be, how many people configured their systems to get > the mail out, out of regret that this was not already happening? I'm > now one of those people. The big "smack to the head" about this that I ran into had to do with DebConf10; the Debian people use a utility called 'caff' (it's in the 'signing-party' package) to email out signatures. However 'caff' makes the assumption that it can send an email, and have it get onto the internet directly -- meaning a local MTA has to be configured to mail to the 'net. So of course I used it to make a signature, which went to the locally unconfigured MTA, where it silently got stuck. Only because I'm familiar with email server administration did I know to run 'mailq' to look to see if caff had sent the mail to the local MTA. Following this I spent a few hours trying to figure out how I wanted to handle this. Eventually I settled on having the machine using its own separate username/password for SMTP AUTH over TLS and using the mail submission port. [TLS -- because it's not a good idea to send username/passwords in the clear.] So unfortunately the reason I know about this problem is because I had it. -- Chris -- Chris Knadle [email protected] _______________________________________________ Mid-Hudson Valley Linux Users Group http://mhvlug.org http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug Upcoming Meetings (6pm - 8pm) MHVLS Auditorium Nov 3 - Open Source Hardware: Bugs, Beagles and Beyond Dec 1 - IBM's Open Client Deployment Jan 5 - Building a Comunity Site with Drupal
