On Tue, Sep 11, 2001 at 08:58:12AM -0300, Derek Broughton wrote:
> Matthew Byng-Maddick:
> > I'm only labelling people who think that having a simplified interface to
> > try and let them administer a complex system they don't understand or want
> > to understand.
> Wrong. You're labelling people who think that administering complex systems
> is best aided by complex tools.
No, I think a text file is actually quite simple, and it has the advantage
that you can comment it, and document your changes, and stick it in CVS etc.
I think that having a simplified interface to a complex tool, which makes
you think that it's not actually that complex after all can be extremely
dangerous.
> > > >I hate to make this point, but mail is *extremely* technical. Getting
> > > Mail is just another application. Exim is just another mail server. It
> > The second sentence is correct ... The first is not. In my reasonably
> > limited experience with UNIX, there is no such thing as "just another
> > application". If that is really what you think, can I recommend MS Exchange?
> Why? Why would any idiot choose to use a broken tool, thus making it more
> difficult, if not impossible, to administer correctly.
Because it has a nice GUI that makes mail delivery appear simple.
In the same way as any fool can admin Windows NT, because it's just like
Windows (I hope you appreciate the fallacy of this).
> > Mail delivery is inherently extremely complex. All of the queueing, spooling
> Of course it is, but it STILL follows fairly simple and programmatically
> explainable rules. It is, indeed, just another application. If too many
Yes.
> UNIX tools aren't "just applications", then there are too many programmers
The reason I think that Mail, DNS, Web etc are not "Just another application"
relates to the fact that they are all sitting on a hostile network. If
people get them wrong they can impact much more than just the person whose
machine is badly configured, think DDoS, spam, network sniffing etc.
Yes, an MTA is an application but it's more than that too. You're going the
wrong way with what I feel about this.
> out there who can't program. That's not a problem with Exim. There is
> absolutely no reason why a good programmer couldn't create a good tool that
Tool != application. (since you're doing semantics)
> would prevent idiots from doing things incorrectly (face it - it doesn't
> matter how hard you think mail administration should be, there will be
Don't I know it. The number of spam systems out there that seem to think
that a 550 response means "try again in 10 minutes"...
> incompetents doing it), and help competent people do it more easily.
The problem comes when you realise that an incompetent setting up his
mail server as an open relay is going to affect half the internet, and
it won't just be him sitting there on the blacklist for 24h (to quote
patrick) that matters. I would much rather that everyone who did mail
had to take a kind of test to show their understanding and be whitelisted,
but that's clearly not going to happen. Even the questions that are asked
here, with an RTFM response shows far too many people with the *wrong*
attitude.
The problem is that once you have a competent person your mail system will
become quite complicated. I run a relatively small mail hub, which has, in
no particular order:
* facilities for virtual domains, and alias files for these domains managed
by the people in charge of them.
* delegated secondary MX routing, where each person has a file to be able
to control the subsequent routing, but with the admin deciding what files
to look up.
* TLS-based relay control
* Mailman mailing lists in the virtual domains.
* Delivery to Cyrus IMAPd
* Forwarding files for real users, with separate files controlling whether
they accept mail in various other domains.
This started off as something quite simple, and I'm not going to post any
reference to my exim .forward file which used to be 200 lines or so long,
included methods to store state etc. That too used to be very much simpler.
Where the power is allowed, complexity will grow as the requirements
change. I challenge someone to come up with a GUI that would have allowed
everything above...
> > and the SMTP in-step transaction are the way they are for a reason, if you
> > don't even try to understand it, should you be a mail admin?
> It's irrelevant - who pays mail admins what they're worth? So you're going
That's irrelevant.
> to end up with a lot of people being made mail admin whether they want it or
> not and whether they are capable or not.
This is why we have open relays, spam etc. Fun. huh ?
> > think not. If you try to be a kind of "fair-weather" mailadmin, then you are
> > going to have problems when some of the obscure failure modes happen (and
> > there are a few of these). Do you know about all of the different relay
> > modes for a mailserver? Do you know how to configure them. Mark Baker has
> This is not the issue. Bad mail admins will never know this - and no tool
> or lack of it will change that. You and others of your ilk seem to believe
quite. so they shouldn't have been able to do this.
> that if we can just make things difficult enough only smart people will use
> exim (or whatever other application), but this is simply wrong. Instead,
> without good tools bad admins will just use those applications in _worse_
> ways.
Possibly. It would be nice to make people read the specs first...
> > What happens when the webmin has let them set up an open relay and they get
> The same as when they configure by hand and open relay. Instead, the webmin
> module should make it difficult to set up _unknowingly_.
*should*, but will it ?
[snip following where you confirm all of my fears]
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
