Re: How to SMTP (Email) Server Fedora 6?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux