There seems to be a lot of dissatisfaction with sendmail in the call to replace it with Exim or Postfix, but I didn't see any specifics about why people object to it. Anyone care to give details?
I'm using sendmail together with MIMEDefang to run SpamAssassin and ClamAV against messages during the SMTP transaction so that I can reject obvious spam and viruses before they're committed to a queue. MIMEDefang uses a user-edited Perl script to establish the exact rules for acceptance, making the system very flexible. How hard is that to set up in Postfix or Exim?
On Thu, Feb 24, 2005 at 11:45:15AM -0800, Kenneth Porter wrote:
There seems to be a lot of dissatisfaction with sendmail in the call to replace it with Exim or Postfix, but I didn't see any specifics about why people object to it. Anyone care to give details?
Most of the discusion has been about what should be the default. For "newbies" sendmail can be a pain to configure. It's documentation leaves something to be desired, and the default sendmail.cf file isn't all that helpful.
That's not to say that sendmail isn't useful or does't work properly. It does. But if a package is going to be the default for a distribution, it should also be fairly simple for new users to configure and adapt to.
I'm using sendmail together with MIMEDefang to run SpamAssassin and ClamAV against messages during the SMTP transaction so that I can reject obvious spam and viruses before they're committed to a queue. MIMEDefang uses a user-edited Perl script to establish the exact rules for acceptance, making the system very flexible. How hard is that to set up in Postfix or Exim?
I haven't looked at postfix yet (will tonight maybe), but for exim all one has to do is uncomment one line in the default config file once spamassassin and a virus checker are installed. Very easy.
josh
On Thursday 24 February 2005 14:53, Josh Boyer wrote:
On Thu, Feb 24, 2005 at 11:45:15AM -0800, Kenneth Porter wrote:
There seems to be a lot of dissatisfaction with sendmail in the call to replace it with Exim or Postfix, but I didn't see any specifics about why people object to it. Anyone care to give details?
Most of the discusion has been about what should be the default. For "newbies" sendmail can be a pain to configure. It's documentation leaves something to be desired, and the default sendmail.cf file isn't all that helpful.
That's not to say that sendmail isn't useful or does't work properly. It does. But if a package is going to be the default for a distribution, it should also be fairly simple for new users to configure and adapt to.
I take issue to that. sendmail has always been *TONS* easier for me to configure then postfix/exim. the sendmail.mc file is simple to understand and edit.
I'm using sendmail together with MIMEDefang to run SpamAssassin and ClamAV against messages during the SMTP transaction so that I can reject obvious spam and viruses before they're committed to a queue. MIMEDefang uses a user-edited Perl script to establish the exact rules for acceptance, making the system very flexible. How hard is that to set up in Postfix or Exim?
I haven't looked at postfix yet (will tonight maybe), but for exim all one has to do is uncomment one line in the default config file once spamassassin and a virus checker are installed. Very easy.
On Thu, Feb 24, 2005 at 03:04:40PM -0500, Richard June wrote:
On Thursday 24 February 2005 14:53, Josh Boyer wrote:
On Thu, Feb 24, 2005 at 11:45:15AM -0800, Kenneth Porter wrote:
There seems to be a lot of dissatisfaction with sendmail in the call to replace it with Exim or Postfix, but I didn't see any specifics about why people object to it. Anyone care to give details?
Most of the discusion has been about what should be the default. For "newbies" sendmail can be a pain to configure. It's documentation leaves something to be desired, and the default sendmail.cf file isn't all that helpful.
That's not to say that sendmail isn't useful or does't work properly. It does. But if a package is going to be the default for a distribution, it should also be fairly simple for new users to configure and adapt to.
I take issue to that. sendmail has always been *TONS* easier for me to configure then postfix/exim. the sendmail.mc file is simple to understand and edit.
I guess we'll have to agree to disagree. Anything that requires using m4 after editing a config file isn't intuitive IMHO.
josh
On Feb 24, 2005, Josh Boyer jwboyer@jdub.homelinux.org wrote:
I guess we'll have to agree to disagree. Anything that requires using m4 after editing a config file isn't intuitive IMHO.
FWIW, it doesn't require you to actually run m4. There's a Makefile to do that for you.
I take it that you dislike autoconf scripts for similar reasons?
Alexandre Oliva wrote:
On Feb 24, 2005, Josh Boyer jwboyer@jdub.homelinux.org wrote:
I guess we'll have to agree to disagree. Anything that requires using m4 after editing a config file isn't intuitive IMHO.
FWIW, it doesn't require you to actually run m4. There's a Makefile to do that for you.
I take it that you dislike autoconf scripts for similar reasons?
autoconf scripts only need to be run when a program is compiled, m4 either directly or indirectly needs to be run whenever you change the config file for sendmail, there is a difference :)
-sb
On Thursday 24 February 2005 15:42, Josh Boyer wrote:
On Thu, Feb 24, 2005 at 03:04:40PM -0500, Richard June wrote:
On Thursday 24 February 2005 14:53, Josh Boyer wrote:
On Thu, Feb 24, 2005 at 11:45:15AM -0800, Kenneth Porter wrote:
There seems to be a lot of dissatisfaction with sendmail in the call to replace it with Exim or Postfix, but I didn't see any specifics about why people object to it. Anyone care to give details?
Most of the discusion has been about what should be the default. For "newbies" sendmail can be a pain to configure. It's documentation leaves something to be desired, and the default sendmail.cf file isn't all that helpful.
That's not to say that sendmail isn't useful or does't work properly. It does. But if a package is going to be the default for a distribution, it should also be fairly simple for new users to configure and adapt to.
I take issue to that. sendmail has always been *TONS* easier for me to configure then postfix/exim. the sendmail.mc file is simple to understand and edit.
I guess we'll have to agree to disagree. Anything that requires using m4 after editing a config file isn't intuitive IMHO.
edit the config file, run service sendmail restart. all done. you don't have to run m4 manually, the sendmail initscript does that for you.
On Thu, 2005-02-24 at 15:04 -0500, Richard June wrote:
I take issue to that. sendmail has always been *TONS* easier for me to configure then postfix/exim. the sendmail.mc file is simple to understand and edit.
You lot really are wimps. You should configure sendmail the proper way - edit the raw config (ideally with TECO since the command sets are so similar).
[And yes, I have done this, although with sendmail 5.x - in the days when you had to reverse domain names within the UK. Now I generally use exim, although have run postfix in living memory]
Nigel.
Am Do, den 24.02.2005 schrieb Josh Boyer um 20:53:
Most of the discusion has been about what should be the default. For "newbies" sendmail can be a pain to configure. It's documentation leaves something to be desired, and the default sendmail.cf file isn't all that helpful.
Nobody is advised to edit sendmail.cf and submit.cf directly. Everybody should always use the .mc files and use m4 to generate the .cf files from that. Even a "newbie" can do simple setups this way. The makefile under /etc/mail makes it simple to rebuild the .cf file or even a service restart rebuilds the .cf if .mc files were changed. More complex setup always require a deeper understanding of the whole mail server (MTA side as well IMAP/POP3 side) topic. The basic Sendmail setup shipped with Fedora Core runs out-of-the-box locally. The change to open it for outside connections is a 1 line change. Well understandable documented. A good understanding with running an MTA is needed because a misconfigured MTA not only can influence communication faults with other MTAs but even lead to lost mail.
I haven't looked at postfix yet (will tonight maybe), but for exim all one has to do is uncomment one line in the default config file once spamassassin and a virus checker are installed. Very easy.
So with Sendmail by calling these kind of applications as a milter entry in the sendmail.mc.
josh
Alexander
On Thu, Feb 24, 2005 at 09:06:48PM +0100, Alexander Dalloz wrote:
Am Do, den 24.02.2005 schrieb Josh Boyer um 20:53:
Most of the discusion has been about what should be the default. For "newbies" sendmail can be a pain to configure. It's documentation leaves something to be desired, and the default sendmail.cf file isn't all that helpful.
Nobody is advised to edit sendmail.cf and submit.cf directly. Everybody should always use the .mc files and use m4 to generate the .cf files from that.
Yes, sorry. I meant sendmail.mc.
Even a "newbie" can do simple setups this way. The makefile under /etc/mail makes it simple to rebuild the .cf file or even a service restart rebuilds the .cf if .mc files were changed.
Yes, but with exim you don't need to run make. You just edit the config file and you're done.
More complex setup always require a deeper understanding of the whole mail server (MTA side as well IMAP/POP3 side) topic. The basic Sendmail setup shipped with Fedora Core runs out-of-the-box locally. The change to open it for outside connections is a 1 line change. Well understandable documented.
Really? I disagree. I hardly know anything about mail servers, yet I exim allows me to run spam and virus checking by simply uncommenting one line. And unlike sendmail, I didn't have to explicitly enable outside connections.
A good understanding with running an MTA is needed because a misconfigured MTA not only can influence communication faults with other MTAs but even lead to lost mail.
I'll agree that it's always a good idea to learn about things. But that doesn't mean that an MTA can't be configured to do more advanced feature out of the box.
So with Sendmail by calling these kind of applications as a milter entry in the sendmail.mc.
Sure, but a user needs to know what a milter entry is right? And how to set it up to do what you need it to do, etc. I don't have a clue what a milter entry is.
I'm not saying sendmail can't do equivalent (or even more) things. I don't claim to know a lot about MTAs, what makes them good, what doesn't, and why one is better than the other. I'm just saying that from a newbie perspective (mine), exim was easier for me to use.
josh
Am Do, den 24.02.2005 schrieb Josh Boyer um 21:56:
Even a "newbie" can do simple setups this way. The makefile under /etc/mail makes it simple to rebuild the .cf file or even a service restart rebuilds the .cf if .mc files were changed.
Yes, but with exim you don't need to run make. You just edit the config file and you're done.
As said too, same with Sendmail: just restart the service so that it rereads his configuration.
More complex setup always require a deeper understanding of the whole mail server (MTA side as well IMAP/POP3 side) topic. The basic Sendmail setup shipped with Fedora Core runs out-of-the-box locally. The change to open it for outside connections is a 1 line change. Well understandable documented.
Really? I disagree. I hardly know anything about mail servers, yet I exim allows me to run spam and virus checking by simply uncommenting one line. And unlike sendmail, I didn't have to explicitly enable outside connections.
That is an argument to "improve" the default setup Sendmail is shipping with Fedora Core. I wonder a bit that Exim is shipped wide open to the net, because both Sendmail and Postfix are limited to localhost with good reasons.
So with Sendmail by calling these kind of applications as a milter entry in the sendmail.mc.
Sure, but a user needs to know what a milter entry is right? And how to set it up to do what you need it to do, etc. I don't have a clue what a milter entry is.
You don't know because you didn't read the documentation. It is ok as you don't run Sendmail. My argument was different: anyone running an MTA reachable from the public internet should know well about his service. This is very obvious for all who's daily business is mail administration.
I'm not saying sendmail can't do equivalent (or even more) things. I don't claim to know a lot about MTAs, what makes them good, what doesn't, and why one is better than the other. I'm just saying that from a newbie perspective (mine), exim was easier for me to use.
If you feel so, ok. From reading the Exim documentation I don't have the impression that the Exim configuration is that intuitive.
josh
Alexander
On Thu, 2005-02-24 at 22:17 +0100, Alexander Dalloz wrote:
Am Do, den 24.02.2005 schrieb Josh Boyer um 21:56:
As said too, same with Sendmail: just restart the service so that it rereads his configuration.
Restarting the service runs m4 on sendmail.mc? If so, I didn't know that.
Really? I disagree. I hardly know anything about mail servers, yet I exim allows me to run spam and virus checking by simply uncommenting one line. And unlike sendmail, I didn't have to explicitly enable outside connections.
That is an argument to "improve" the default setup Sendmail is shipping with Fedora Core.
Yes, sure.
Sure, but a user needs to know what a milter entry is right? And how to set it up to do what you need it to do, etc. I don't have a clue what a milter entry is.
You don't know because you didn't read the documentation. It is ok as you don't run Sendmail.
I did run Sendmail. For almost a year. In fact, I first tried exim 2 days ago.
Yes, I didn't read any documentation other than what's in sendmail.mc (at first). Yes, that makes me lazy. But I only read the exim.conf file too, and now I have spamassassin running at SMTP time. And yes, that also could be an argument for improving Sendmail's default configuration.
My argument was different: anyone running an MTA reachable from the public internet should know well about his service. This is very obvious for all who's daily business is mail administration.
Eventually. I was in a situation where I switched ISPs and didn't have an email address anymore. I hate hotmail, and didn't have access to gmail yet. So, I got a mail server running as fast as I could. _Then_ I learned more about it.
Had Sendmail come with some spam filtering stuff built in, I'd have used it from day one. As it stood, it didn't and I never found the time to figure out how to enable that.
It took me about a day to get me and my one other mail user up and running on the simple setup that I have. Probably half of that was messing with the Sendmail configs. With exim, it took me 20 minutes and that included getting spam filtering running. And again, all I did was read the config files for each.
I'm not saying sendmail can't do equivalent (or even more) things. I don't claim to know a lot about MTAs, what makes them good, what doesn't, and why one is better than the other. I'm just saying that from a newbie perspective (mine), exim was easier for me to use.
If you feel so, ok. From reading the Exim documentation I don't have the impression that the Exim configuration is that intuitive.
This is quickly turning into a flame. I'm partly to blame for it, but that's not what I intended.
I don't think Sendmail is "bad". I just think other MTAs are easier to use out of the box. That's just my opinion. Me, and the mail server that shouldn't be running by all accounts I've read in this thread, are bowing out now.
josh
--On Thursday, February 24, 2005 5:41 PM -0600 Josh Boyer jwboyer@jdub.homelinux.org wrote:
Eventually. I was in a situation where I switched ISPs and didn't have an email address anymore. I hate hotmail, and didn't have access to gmail yet. So, I got a mail server running as fast as I could. _Then_ I learned more about it.
Note that that's another argument for relegating *all* the MTA's to Extras and shipping a dirt-simple SMTP pass-through that does little more than proxy local mail requests to the ISP or company server.
On Sat, 2005-02-26 at 09:00 -0800, Kenneth Porter wrote:
--On Thursday, February 24, 2005 5:41 PM -0600 Josh Boyer jwboyer@jdub.homelinux.org wrote:
Eventually. I was in a situation where I switched ISPs and didn't have an email address anymore. I hate hotmail, and didn't have access to gmail yet. So, I got a mail server running as fast as I could. _Then_ I learned more about it.
Note that that's another argument for relegating *all* the MTA's to Extras and shipping a dirt-simple SMTP pass-through that does little more than proxy local mail requests to the ISP or company server.
Not really. My ISP gives me a line and an IP address. That's it. I don't have access to any of their mail servers. So I needed an MTA that could both send and receive on it's own, and not proxy through anything.
josh
On Sat, Feb 26, 2005 at 09:00:43AM -0800, Kenneth Porter wrote:
Note that that's another argument for relegating *all* the MTA's to Extras and shipping a dirt-simple SMTP pass-through that does little more than proxy local mail requests to the ISP or company server.
By this argument, should *all* servers be moved to Extras?
Le samedi 26 février 2005 à 09:00 -0800, Kenneth Porter a écrit :
--On Thursday, February 24, 2005 5:41 PM -0600 Josh Boyer jwboyer@jdub.homelinux.org wrote:
Eventually. I was in a situation where I switched ISPs and didn't have an email address anymore. I hate hotmail, and didn't have access to gmail yet. So, I got a mail server running as fast as I could. _Then_ I learned more about it.
Note that that's another argument for relegating *all* the MTA's to Extras and shipping a dirt-simple SMTP pass-through that does little more than proxy local mail requests to the ISP or company server.
You can do this with one well-documented declaration in postfix (relayhost), I suppose exim is as esay to setup.
The nice thing about a full-featured MTA with real local queues is your mail will still pass through when your ISP decides to do a big advertising campaign without upgrading its network first.
Regards,
--On Saturday, February 26, 2005 7:15 PM +0100 Nicolas Mailhot Nicolas.Mailhot@laPoste.net wrote:
The nice thing about a full-featured MTA with real local queues is your mail will still pass through when your ISP decides to do a big advertising campaign without upgrading its network first.
I don't question the value of a full-featured MTA for an advanced user. I just don't see it as being a required feature for a new user.
Presumably the people installing Fedora who can't configure sendmail are either home users (who have a full-featured ISP to operate a real MTA) or business users operating behind a company MTA. AFAIK, Fedora isn't being pushed as an "MTA training platform", so there's no need to keep one in the Core product when it's tight for space. And if it's not tight for space, one could still use a very simple outbound-only queuing MTA for the default and make Postfix/Exim/Sendmail choices for advanced users.
On Mon, Feb 28, 2005 at 08:55:37AM -0800, Kenneth Porter wrote:
--On Saturday, February 26, 2005 7:15 PM +0100 Nicolas Mailhot Nicolas.Mailhot@laPoste.net wrote:
Presumably the people installing Fedora who can't configure sendmail are either home users (who have a full-featured ISP to operate a real MTA) or business users operating behind a company MTA. AFAIK, Fedora isn't being pushed as an "MTA training platform", so there's no need to keep one in the Core product when it's tight for space. And if it's not tight for space, one could still use a very simple outbound-only queuing MTA for the default and make Postfix/Exim/Sendmail choices for advanced users.
That makes some sense. But then you have the broken upgrade path issue if you drop _all_ fully featured MTAs from Core. Potentially that is.
I think it's more plausible once the installer supports installing from other repos. Which is FC5 I hear.
So for FC4 I think one of the current MTAs should be present. I'm not going to dare suggest which one, but one of them should remain :). Then for FC5 we can do what you suggested.
josh
man, 28.02.2005 kl. 17.55 skrev Kenneth Porter:
--On Saturday, February 26, 2005 7:15 PM +0100 Nicolas Mailhot Nicolas.Mailhot@laPoste.net wrote:
The nice thing about a full-featured MTA with real local queues is your mail will still pass through when your ISP decides to do a big advertising campaign without upgrading its network first.
I don't question the value of a full-featured MTA for an advanced user. I just don't see it as being a required feature for a new user.
Presumably the people installing Fedora who can't configure sendmail are either home users (who have a full-featured ISP to operate a real MTA) or business users operating behind a company MTA. AFAIK, Fedora isn't being pushed as an "MTA training platform", so there's no need to keep one in the Core product when it's tight for space. And if it's not tight for space, one could still use a very simple outbound-only queuing MTA for the default and make Postfix/Exim/Sendmail choices for advanced users.
Not having to start a mta at boot would make it boot quicker as well...
Once upon a time, Kenneth Porter shiva@sewingwitch.com said:
Note that that's another argument for relegating *all* the MTA's to Extras and shipping a dirt-simple SMTP pass-through that does little more than proxy local mail requests to the ISP or company server.
That's fine if you are building a workstation-only system, but are you also going to drop Apache, OpenLDAP, vsftpd, ...?
--On Saturday, February 26, 2005 2:25 PM -0600 Chris Adams cmadams@hiwaay.net wrote:
That's fine if you are building a workstation-only system, but are you also going to drop Apache, OpenLDAP, vsftpd, ...?
I guess that depends on what Fedora is being targeted for, and how aggressive one wants to be about slimming down the distro to fit on less media.
But note that I didn't say "drop", just move to Extras. Presumably Fedora *Core* could switch to a bare-bones workstation install with capability equivalent to XP Home (which lacks an MTA), and everything else moved to Extras for advanced users who want server capability. And unlike XP Pro and Windows 2003, you still get to add all that functionality for *free*. Basic users can get a working installation from a magazine CD, and the rest can download additional content for the fancy stuff.
Hi.
Kenneth Porter shiva@sewingwitch.com wrote:
Fedora *Core* could switch to a bare-bones workstation install with capability equivalent to XP Home (which lacks an MTA),
Except that you cannot reasonably run a *NIX system without an MTA.
On Thu, Feb 24, 2005 at 02:56:11PM -0600, Josh Boyer wrote:
Really? I disagree. I hardly know anything about mail servers, yet I exim allows me to run spam and virus checking by simply uncommenting one line. And unlike sendmail, I didn't have to explicitly enable outside connections.
Bug not feature. The default sendmail configuration explicitly disables outside connections for a reason. They shouldn't be enabled unless you're running a real server that needs outside connections, and you shouldn't be running one if you "hardly know anything about mail servers."
Besides, enabling outside connetions is simply commenting one line which is heavily documented in the four lines above it in the default sendmail.mc. As you yourself already stated, commenting and uncommenting one line is a simple matter, easy to do, especially with such explicit instructions. :)
John
--On Thursday, February 24, 2005 2:56 PM -0600 Josh Boyer jwboyer@jdub.homelinux.org wrote:
Yes, but with exim you don't need to run make. You just edit the config file and you're done.
So typing "make" is hard for someone who's able to use a text editor?
Currently sendmail is launched via a symlink used to enable MTA switching. I suppose one could add more indirection and invoke it by a script that runs Make first.
Really? I disagree. I hardly know anything about mail servers, yet I exim allows me to run spam and virus checking by simply uncommenting one line. And unlike sendmail, I didn't have to explicitly enable outside connections.
So should RH ship sendmail's config set to accept incoming connections, or close Exim for workstation users who have no business receiving SMTP connections? That's a packaging bug, not a usability issue; one of the packages is shipped with the wrong setting.
If uncommenting a line to enable inbound connections is "hard" for a newbie sendmail user, wouldn't the same action to enable scanning in Exim be just as hard?
Sure, but a user needs to know what a milter entry is right? And how to set it up to do what you need it to do, etc. I don't have a clue what a milter entry is.
milter = mail filter. A sendmail plug-in. It gets called for each step of the SMTP conversation. Milters exist for several AV's and spam scanners, and MIMEDefang lets you run arbitrary Perl to perform complex matching and decisions.
--On Thursday, February 24, 2005 1:53 PM -0600 Josh Boyer jwboyer@jdub.homelinux.org wrote:
But if a package is going to be the default for a distribution, it should also be fairly simple for new users to configure and adapt to.
What MTA configuration would a new user be expected to do? It sounds like the big one is enabling inbound scanning.
How "RPM-friendly" are Exim and Postfix to adding plug-ins? Can I just run the install RPM for the plug-in and these MTA's pick them up? Or is manual configuration necessary? (For comparison, most sendmail plug-ins currently require manual configuration, usually by copying some lines from the plug-in's readme to the sendmail.mc file. But a smarter plug-in could just provide an M4 file to include in sendmail's cf "feature" files and the user could just re-make the mc file to incorporate it.)
On Thu, 2005-02-24 at 11:45 -0800, Kenneth Porter wrote:
There seems to be a lot of dissatisfaction with sendmail in the call to replace it with Exim or Postfix, but I didn't see any specifics about why people object to it. Anyone care to give details?
When i switched from Sendmail to Qmail then to Postfix, the biggest reason was Qmail's and Postfix's modular architecture, which allows not only much better security, but more flexibility and better performance. The same argument worked for Postfix and Qmail, but against Sendmail and Exim.
I would have stayed with Qmail, were it not for it's weird licence and lack of active development.
On Thu, Feb 24, 2005 at 11:45:15AM -0800, Kenneth Porter wrote:
There seems to be a lot of dissatisfaction with sendmail in the call to replace it with Exim or Postfix, but I didn't see any specifics about why people object to it. Anyone care to give details?
In my environment, on 99% of all systems, I've never needed anything but a simple queue-to-smarthost mail sending daemon, with no receive functionality at all. Therefore, I don't care which mail daemon is included, as long as it can do that and supports some type of /etc/aliases file. I'd actually prefer to see a simple ssmtp-like program, but ssmtp doesn't meet those needs (it doesn't queue, doesn't expand local aliases).
On the 1 or 2 systems that do need a full mail server, our mail admins roll their own builds/installs of sendmail anyway.
Le jeudi 24 février 2005 à 16:35 -0500, Chuck R. Anderson a écrit :
On Thu, Feb 24, 2005 at 11:45:15AM -0800, Kenneth Porter wrote:
There seems to be a lot of dissatisfaction with sendmail in the call to replace it with Exim or Postfix, but I didn't see any specifics about why people object to it. Anyone care to give details?
In my environment, on 99% of all systems, I've never needed anything but a simple queue-to-smarthost mail sending daemon, with no receive functionality at all. Therefore, I don't care which mail daemon is included, as long as it can do that and supports some type of /etc/aliases file. I'd actually prefer to see a simple ssmtp-like program, but ssmtp doesn't meet those needs (it doesn't queue, doesn't expand local aliases).
On the 1 or 2 systems that do need a full mail server, our mail admins roll their own builds/installs of sendmail anyway.
Funny I just wrote the same thing (and I do think they are wrong btw, but then they did chose sendmail in the first place)
--On Thursday, February 24, 2005 4:35 PM -0500 "Chuck R. Anderson" cra@WPI.EDU wrote:
In my environment, on 99% of all systems, I've never needed anything but a simple queue-to-smarthost mail sending daemon, with no receive functionality at all. Therefore, I don't care which mail daemon is included, as long as it can do that and supports some type of /etc/aliases file. I'd actually prefer to see a simple ssmtp-like program, but ssmtp doesn't meet those needs (it doesn't queue, doesn't expand local aliases).
I can understand queuing, in case the real server is down. That can be the simple-minded queuing implemented by most MUA's. But why aliases? Shouldn't those also be handled by the real server?
I'd guess that we could take the SMTP back end off an MUA and call it "sendmail" for application compatibility and ship that.
On Sat, Feb 26, 2005 at 09:05:11AM -0800, Kenneth Porter wrote:
I can understand queuing, in case the real server is down. That can be the simple-minded queuing implemented by most MUA's. But why aliases? Shouldn't those also be handled by the real server?
System daemons and server applications often send mail to system accounts. These and root mail need to be aliased to a real person who is going to be reading the mail from them. The mappings are often server-specific, or at least department-specific, and cannot be stored on the central mail server. I'm not talking about huge mailing lists or hosting virtual mail accounts, just providing the basic functionality that the default /etc/aliases from sendmail demonstrates.
Le samedi 26 février 2005 à 09:05 -0800, Kenneth Porter a écrit :
--On Thursday, February 24, 2005 4:35 PM -0500 "Chuck R. Anderson" cra@WPI.EDU wrote:
In my environment, on 99% of all systems, I've never needed anything but a simple queue-to-smarthost mail sending daemon, with no receive functionality at all. Therefore, I don't care which mail daemon is included, as long as it can do that and supports some type of /etc/aliases file. I'd actually prefer to see a simple ssmtp-like program, but ssmtp doesn't meet those needs (it doesn't queue, doesn't expand local aliases).
I can understand queuing, in case the real server is down. That can be the simple-minded queuing implemented by most MUA's. But why aliases? Shouldn't those also be handled by the real server?
You can always get by with your provider if you pay more. Often you have to play tricks when you only have a basic residential access. In my case that means real queues + aliases + address rewriting + sasl auth + use of port 24 not 25. I'd be surprised if I where alone in this case.
To fight spamming and worms ISP put in place all sorts of creative annoyances that mean you really need a smart MTA if you don't want to be reduced to webmail.
Regards,
On 02/24/2005 11:45:15 AM, Kenneth Porter wrote:
There seems to be a lot of dissatisfaction with sendmail in the call to replace it with Exim or Postfix, but I didn't see any specifics about why people object to it. Anyone care to give details?
It's not that sendmail is bad, it's just that postfix (and reportedly exim) are a lot easier to configure without an O'Reilly book at your side.
Also - postfix can be run in a chroot jail without too much effort, last I heard - that was just not possible with sendmail.