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 implemenation). 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 complicated. Thoughts? -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Attachment:
signature.asc
Description: Digital signature