On Thu, 22 Sep 2005 10:39:51 -0400, Marc Sherman
<msherman@???> wrote:
>Marc Haber wrote:
>> You can always drop in your own routers/transport without having to
>> interfere with the debconf-driven mechanisms.
>
>In my case, I found that for the vast majority of the files in
>/etc/exim4/conf.d/, I was either not using the file at all (such as the
>procmail/maildrop/etc routers),
That doesn't hurt
>or I had to edit it.
I'd like to know which edits you found necessary. Maybe you are right,
and these modifications can be useful for all users of the Debian
packages.
>>>In many cases, they do. They just read them on exim.org, instead of
>>>/usr/share/doc/exim4-*/.
>>
>> References to /usr/shade/doc/exim4-base/README.Debian are all over the
>> place. We have even changed spec.txt to refer there.
>
>You haven't changed the one place that most exim users look first for
>documentation: http://exim.org/exim-html-4.50/doc/html/spec.html
That one is not in my authority. Additionally, people who don't look
for local docs when they find a package look different from the
project web site, shouldn't be running a mail server in the first
place.
You might notice that the majority of Debian exim4 support requests
originates from people who are trying to run a service for third
parties on their box, and should know their own trade, but don't.
Simple end-users do not ask questions here or anywhere else, be it for
what reason whatever.
>My proposed solution appeared below in the same email, and I've been
>suggesting it for a long time now: exim should not be Debian's default MTA.
That's not in my authority, but I still feel that a full-featured MTA
is in order for most installations. So, it I were Debian's ftpmaster,
I probably wouldn't decide differently.
>Look, I'm not trying to attack you, and I'm not saying you're doing a
>bad job. What I'm saying is that you're doing the _wrong_ job. In
>fact, I think the existing packaging (especially the debconfiscation) is
>fantastic for the user who doesn't know anything about SMTP or MTAs and
>just wants email to work when they install a new debian box. Most of
>the time for this user base, for most use cases, It Just Works.
Not only for this user base. I am running all my servers with
minimally modified exim4-config straight from Debian unstable. And
yes, these boxes are also providing third-party services.
> The
>debconf questions make configuring most of the things usually configured
>by newbies easy to set, without touching any config files (the one
>important thing that's missing from debconf, maildir, is understandable
>given how you got screwed by the long debconf translation freeze).
The templates need to be re-worked, yes, right. I hope that this
transition can be made when the next big changes come up in
exim4-config.
> And
>for the expert user who knows a lot about how both exim and dpkg work,
>your package makes it easy for me to tell the debconf and dpkg stuff to
>get out of the way and let me configure exim the way I want, which is
>really all I can ask.
>
>But between those two user groups is a large group of people who are
>making the transition between clueless newbie and expert. IMO, the
>current exim package makes things _harder_ for those people, by cutting
>them off from their most valuable resource, this list (and all the
>online doc/faq/wiki material that goes with it). You have to admit this
>is true -- you've gone to great lengths to discourage your users from
>contacting this list, or reading the publically available docs, but
>instead using your own mailing lists and reading the exim-specific docs
>you install with the package.
The Debian docs say that people should be sure that they have a
genuine exim issue before contacting this list, and that they should
in doubt query the Debian exim4-users list, which has a quite good
turnaround time for answers.
So I have to disagree that people are cut off from upstream exim docs
and mailing list. They need some abstraction and transfer skills, but
you need to be smart to run a mail server on the internet anyway.
>I don't believe it's possible to effectively target both groups (the
>people who don't know or want to know anything about MTAs, but still
>want to run one, and the people who know little but are trying to learn)
>simultaneously. Broad debconfiscation is _required_ for the first
>group, and an impediment for the second group. So you have to choose
>between them. Because exim is the default MTA, you're forced to choose
>the former. In my opinion, however, it's much more valuable to target
>the second group; they're the ones who are likely to evolve into expert
>users, and from there, into contributors to both the package and exim
>itself. By targetting the people who want to learn, the entire
>community benefits.
exim4-config doesn't keep people from learning. If you _really_ want
to learn and _can_ learn, you'll grasp the Debian exim4 configuration
scheme in one hour max and you'll save even more time in the future.
Additionally, every volunteer is free to build and maintain an
exim4-config-foo package in the Debian archive which can better target
other user groups. There are even two approaches to that in the Debian
exim4 SVN repository which I have been forced to abandon for lack of
time. Everybody is free to pick up on them and to improve them. The
fact that nobody bothered to do so is in my opinion proof that the one
configuration method supported by the Debian exim4 maintainers is just
fine.
>So, to summarize, my suggestion remains: something else should be the
>default MTA, targetting the people who just want mail to work, and don't
>need a fully featured MTA.
People need a fully featured MTA. I don't think that nullmailer can do
sender rewriting to allow people to locally send e-mail which has
answers redirected to their ISPs web mail server. Additionally,
nullmailer doesn't go as default MTA because its sendmail interface is
not LSB compatible.
> My previous suggestion was ssmtp, which you
>pointed out correctly isn't appropriate. I don't know what the right
>default MTA is, but I remain convinced that it's not exim.
I remain convinced that the right default MTA would be one of the big
ones, like sendmail, postfix, exim or smail (which has already been
default before exim was promoted).
>> Which parts of our configuration can be performance impacting? And how
>> many of them might impact performance so that it becomes relevant for
>> an end-user desktop system?
>
>Sheer size of the config was what concerned me here. In particular, you
>define a number of routers that are inactive in most installations, but
>still get parsed on every invocation and checked for every message, such
>as hubbed_hosts, dnslookup_relay_to_domains, procmail, and maildrop.
I doubt that the performance loss suffered by that is even
measureable.
>daunting complications in the config files for the
>newbie-who-wants-to-learn.
So the configuraiton files are not adequately documented? When I
learned exim back in 1998, I was happy to find so many example in the
default configuration. This might be caused by the fact that I learn
better from examples than from specifications, but one can hardly
complain about lack of specification in the exim project.
>The other file that really concerned me most was
>31_exim4-config_rewriting: it contains both a rewrite rule that's always
>active, even if it's a no-op in most cases because /etc/email-addresses
>is empty by default, and a black-box debconf macro that can't be edited
>or learned from by the newbie-who-wants-to-learn.
Any idea about how do to this better? It's admittedly ugly, but at
least documented in the update-exim4.conf man page. Additionally, this
rewriting stuff has been in Debian's exim 3 packages for ages.
>However, I want to point out that it was an asside
>to the main point I was trying to make to the OP that Debian stable does
>ship a specific frozen version for a very long period of time,
which is a feature.
>and as
>Andreas pointed out, the current release of Exim is almost always what
>you want running on your mail server.
I suggest that exim 4.50 will still be appropriate on a local box for
a long time, and people running _servers_ can judge for themselves
whether they want to run the official versions (which might be
mandated anyway in corporat environments), build a local exim, use
third-party backports or do their own backport packages. Or, at least,
they should.
>> Actually, in the last weeks before release, the release team was
>> pretty cooperative. The reason I pushed for 4.50 in sarge was
>> exiscan's integration in the upstream source because the Debian build
>> process could be greatly simplified by removing the need to patch the
>> upstream sources before daemon-heavy build.
>
>My point about the release team was that they started talking about
>imminent release long before they had an actual plan or achievable
>schedule for it, which caused you to freeze your debconf translations
>far too early and led to some unfortunate issues in the package.
Sarge release was a desaster, right. Agreed.
>> That's not a problem. Debian has committed itself to keep the exim in
>> a stable release useable, as we did with exim 3, and still do. The
>> same will go for exim 4. Additionally, Andreas is already offering
>> "official" sarge backports of later exim4 packages. These are
>> prominently linked from the Debian exim4 web page.
>
>And I mentioned to the OP that the problem was solvable, if he was
>willing to do one of a number of things, including updating exim from
>backports.org (which really should link to or host Andreas' packages).
backports.org is not yet ready for sarge, I have been told.
>BTW, it took me five tries to figure out what you meant by "the Debian
>exim4 web page". Places I tried first:
>http://www.debian.org/exim4 (doesn't exist)
Yes, right, the correct url would be
http://packages.debian.org/exim4
>http://packages.debian.org/stable/mail/exim4
Ouch! I completely missed this. The general exim4 package blurb has
been committed to the exim4 meta package description as well, a minute
ago.
>http://packages.qa.debian.org/e/exim4.html
This has a link to the alioth project page in "Static Info" now.
Thanks for pointing that out.
>http://pkg-exim4.alioth.debian.org/
This one redirects to the real page, which is currently on
wiki.debian.net
>before I finally got to:
>http://wiki.debian.net/?PkgExim4
Which is the correct information source.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
