[To all recipients: Please, if you're still interested in the topic, subscribe to pkg-exim4-devel, and continue reading there. Reply-To: is appropriately set.]
On Sun, May 28, 2006 at 04:55:42PM +0200, Wouter Verhelst wrote: > 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. Agreed. > 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. Maybe it is a good idea to have a flow-chart of the new debconf structure somewhere? > 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. Agreed, that's an unnicety. > 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'. .local has no RFC backing :-( > . > 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. Do we still have that 24-line limit for debconf questions asked during installation? This does not take care too well for the classic case of a host with a fixed IP and its own FQDN, handling local mail for the FQDN. This is probably a not too special case of "own mail domain". > 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. Maybe we can have both, with the global file overriding the local one. > 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. Probably, es. > I think it's fair to say that systems with no mail domain will need a > smarthost to handle remote mail. Yes, and since SMTP AUTH has become commonplace, we'd probably need to ask for authentication credentials. > 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. Sounds kind of sexy, but I don't know about its possible implications. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
