Les Mikesell wrote: > Mikkel L. Ellertson wrote: > >> So you are saying that the configuration should be changed to one >> that helps a few of the people that want to run a mail server, >> while making it harder the people that do not need it, and >> makes no difference to most people that are going to run a mail >> server. > > No, I'm saying it should be easy to make it do what you want in the same > way RH/fedora configurations make it easy to use other network services > like sshd without having to write your own configuration or edit one > that was built to make a network service not use the network. > That would be great - but to do it will probably require using a different SMTP server. Sendmail configuration is not simple. Take it up with the people that write it. This is a good argument for changing the default mail server, not for changing the default configuration. >> It makes more sense to have a configuration that works for >> most people. > > "Most" people were only using linux for servers back when this setup was > created. Regardless, that's not the point. Some people need a real > name server, some need a caching version, some don't need any. You can > accommodate all of those choices with RedHat-style packaging and commands. > The thing is, it works for most people running desktops as well. It is only the people that need the server to accept mail from the network that is fails for. This is not most people. If you do not have a an Internet connection that allows incomming port 25 connections, and your system is not acting as a mail server for a local network, you can use it as is. The machine that does this is the exception, not the rule. This does not make the default configuration broken. It may indicate the need for additional packages, or a change in the default mail server. It may be time to reconsider if Sendmail should be the default package. >> And it does work for most machines that are not mail >> servers. (Are you trying to say most machines are configured as mail >> servers, not counting delivering locally generated mail?) > > I'm saying that if someone, somewhere doesn't have a mail server for > you, you aren't going to find mail very useful. Why do you want to make > it difficult for that person even if it isn't you? > Just because one machine on my network needs to be a mail server is no reason for every machine to be listening for incoming mail. Having a default that works fine on 5 of 6 machines makes sense, especially because I need a costume configuration for the one that is a mail server anyway. If it were set up the way you want, I would have to change the configuration on every machine, instead of just one. If most people are going to be able to ether use the current default configuration, or are going to need a costume configuration, why change the current configuration so that it is less then optimal for most people and only works for a few people. >> Regardless of what kind of configuration is shipped, it is not going >> to work for most people running a mail server without changes. > > Why do you think that a mail server that works in one place could not > work with the same configuration in many places? Now that almost all > client programs speak authenticated smtps, a canned server that > authenticates with your system PAM setup would be as portable as sshd. > To start with, it does nothing to address how outgoing mail is handled, and that is the biggest change in configurations form one location to another. It also fails on networks with separate servers for incoming and outgoing mail servers. It is also a less then ideal setup for machines that are not mail servers. I am sure there are other examples, but these are off the top of my head... >> You talk about shipping "expertly built working configuations". >> Maybe if you defined what they should be, there could be packages >> containing those configurations for people that need them. > > If I were an expert, I wouldn't be complaining about having to write my > own configuration to get something that works at all. What I'm saying > is that someone else could have done it better - like they have done for > sshd, httpd, etc. and it would be easier to discuss and solve problems > if everyone started from the same working setup. > They have not done it for ssh, or most other daemons. They have done it for at least a couple of options for Bind. For http, they have several add-on packages depending on what you want the Apache server to do. But don't say that Sendmail is being discriminated agenst because it is harder to configure then ssh - each daemon has its own configuration requirements. The more options, the more complicated the configuration requirements. Sendmail has more options then most daemons, and one of the most difficult configuration files I have ever seen. Try making sense of the header re-writing rules some time. I am not an expert in Sendmail configuration ether. There are not too many of them out there. I can picture a half dozen base configurations that would have to then be tweaked for local settings. Filtering incoming mail server - it runs on the firewall machine. It rejects mail that matches filtering rules, and passes mail for the local system to the local mail server. Local POP/SMTP server. It accepts incoming mail, and puts it in local mail boxes. It process mail from the local network, and takes care of delivering mail to other domains directly. Local POP server. It accepts mail for the local network, putting it in mail boxes. It does not process any outgoing mail. Basically a relay host for the local network. Local SMTP server. It only handles outgoing mail. It passes mail from the local network that is for the local network to the POP server. It delivers mail to other domains directly. POP/SMTP server that uses a relay host for outgoing mail. This one may get complicated depending on how you have to authenticate with the relay host. Local SMTP server using a relay host. This one is kind of rare, because if you have enough traffic to justify a separate outgoing mail server, you usually do not use a relay host. Local POP/SMTP server on a dialup connection. This requires longer spooling of outgoing messages, and warning times. Incoming mail may require the server to accept incoming network connections, or a program like fetchmail may grab Internet mail. This does not cover using other transports, or things like secondary mail servers. It also doesn't cover things like scanning incoming or outgoing mail or mail attachments, limiting message size or any of the other tweaks that are common. Then their are things like virtual mail hosts that require different configurations. You can also handle some of the configuration differences by creative use of the local mail dns server. I am sure their are other common configurations that should be covered, but these are the ones I have used in the past. >> Something >> like the caching-nameserver package for Bind. > > Ahh, so you do understand what is missing... > Sure, I understand how things could be improved. But that does NOT make the default installation broken, as you keep saying. It would be nice to have alternate configuration packages for Sendmail. So why don't you put is a request for them instead of complaining on the list that the current configuration is broken because it does not support what you want to do out of the box? I have listed some of the configurations that should be covered... Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
