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

Re: Idea: making it easier to change DEBCONF_PRIORITY

On Sun, May 28, 2006 at 11:18:32AM +0200, Wouter Verhelst wrote:
> On Sun, May 28, 2006 at 08:59:31AM +0200, Marc Haber wrote:
> > I am open to suggestions. Back when the exim4 packages were developed,
> > we mainly copied what exim 3 did and debconfed the questions.
> I'll try to come up with something.

Okay, so I've been thinking about this for most of the day now. What
I've come up with is the following. It would need to be implemented
still, but I want to discuss the general idea before I come up with a
proof-of-concept implementation (or even a proposed final

The current approach centers around `how is your system connected to
other hosts on the Internet?'

While this was highly relevant in the day the original exim v3 config
script was written, I would submit that this is no longer the case --
or, at least, that it is no longer as important as it used to be. The
central question in these days of desktop users versus administrators of
large domains is "do you have your own mail domain". Though it is
possible to configure your system in case you do not have your own mail
domain currently, it feels a bit as if it was added as an afterthought,
and is making the system needlessly confusing IMO.

I would therefore suggest that the first question asked is about whether
or not the user has his own mail domain. Maybe not as a boolean; perhaps
as a select question with "no", "yes (handled locally)", and "yes
(handled remotely)" or so, where the option to handle mail locally
should also be used to handle the case of no network connection.

It should also include an option "stay away from my mail
configuration!", which should then exit the config script immediately,
_without_ asking any further questions. One of the most serious gripes I
have with the current configuration system is that if you say "do not
configure anything about my mail system; I know it'll be broken, I'll
fix it", it will _still_ ask you exim4/dc_postmaster and a few other
questions. Surely if you warned the user that everything will be
completely and utterly broken, they're sure they know what they're doing
and want to get rid of the debconf questions?

Something like the following template would work:

Template: exim4/domain-type
Type: select
_Choices: no, yes (handled locally), yes (handled remotely), no configuration
Default: no
_Description: Do you have your own mail domain?
 An email address consists of two parts: the part before the `@' sign,
 known as the `local part' which has to be unique for every mail domain;
 and the part after the `@' sign, known as the `mail domain', which is
 to be globally unique.
 The most common setup is for people to have an email address with their
 ISP or with a web-based mail provider. If this is the case for you,
 then you do not have your own mail domain; in that case, choose `no'.
 If you are not certain what to do, this is probably the right choice.
 If you do have your own mail domain, and you want this system to handle
 it as its primary mailserver, then you should choose `yes (handled
 locally)' here. Every account on the system will then be an email
 address, for which mail will be stored on the local hard disk; it will
 be possible to create more email addresses through /etc/aliases.
 This is also the option which you should choose if your computer is not
 connected to the Internet in any way; as for the mail domain for which
 you will be asked later on, you can make something up, so long as you
 make sure it ends in '.local'.
 If you have your own mail domain, but you want mail to be taken care of
 on another system, then you should choose `yes (handled remotely)'
 here. Choosing that option will result in all mail being sent off to
 another system. You must manually ensure that there is a valid email
 address configured on the remote system for all local accounts that may
 send mail, or that may (appear to) receive mail locally.
 If you prefer to manually configure your mail system, then choose `no
 configuration'. Use of this option is not recommended except for
 experienced system administrators; it will render your mail system
 completely broken until you manually configure it.

So, if the user then told you that they do not have their own domain,
you'll need a way for local user names to be mapped to globally valid
email addresses. This could perhaps be done through a dotfile in the
user's home directory, where they can enter their globally valid email
address; when the system then mails something to a remote system, it
should rewrite headers such that mail sent through /usr/bin/sendmail has
their return path set up properly so that recipients can just hit
'reply' and have it end up where expected. I'm suggesting a dotfile
since that will allow every user to manage it for themselves; however,
it might just as well be a system-wide file which then the sysadmin has
to manage. It doesn't really matter all that much.

Still in the case of no local domain, the user might also have the
choice of having all mail sent off to the 'net (in case they use webmail
or prefer to use POP3 or IMAP4 to read their mail) or to have their mail
stored locally (so that they can read it out of /var/mail; they will
need to set up fetchmail to get it there, though). Perhaps give this
question a lower priority and set the default to send it remotely; I
expect that people doing mail through webmail and/or POP3-capable
clients is far more common than people willing to set up fetchmail etc.

I think it's fair to say that systems with no mail domain will need a
smarthost to handle remote mail.

In case the user indicates he does have his own mail domain, you should
ask for that mail domain, something like exim4/dc_other_hostnames, and
then perhaps have some questions regarding smarthosts, if any, and the
relaying questions that already exist today (I don't think a mail system
which does rewriting as described above should do relaying as well).

I propose to completely drop the "hiding the local mailname"; I suspect
the above setup will handle most cases where hiding the local mailname
is interesting, while it will also not make things needlessly


Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4

Attachment: signature.asc
Description: Digital signature

Reply to: