New initial mail setup proposal (was Re: initial mail setup proposal (was: Re: Please participate in popularity-contest))
Malte Cornils wrote:
On Tue, Aug 10, 2004 at 11:37:04AM +0200, Tore Anderson wrote:
Besides, base even includes an MUA. I certainly expect an MUA to be
able to send to remote destinations
[...]
Then there's popularity-contest [...] I think reportbug also deserves mention here [...]
endeavour to have working with an absolute minimum of user configuration
required.
* Andreas Metzler
> In my opinion a sane default setting for a fully-flegded MTA like
> Exim would be to ask if the user had any specific SMTP submission service
> at his ISP or wherever he'd like to use, and if not - mail is sent
> directly using DNS/SMTP. YMMV.
That sounds quite reasonable to me.
In my experience installing Debian for quite a varied number of people,
most need something similar to the mail account setup in most graphical
MUAs - most common setups here in Germany would use a SMTP submission
service with SMTP-after-POP or SMTP-auth via TLS. Unfortunately, this
would "bloat" the d-i setup with questions for account, password and the
same for POP3. Best for those users would probably be configuring fetchmail
in conjunction with exim.
There are 2 basic purposes of mail configuration in the Debian installer:
1. Delivery of messages to root from cron and debconf notes
2. Off-site delivery of reportbug and popcon messages
This group is closely followed by those which use pure webmail (those
would probably be best served by local delivery only). Since they are
mostly inexperienced users, making it easy for them should be the
default.
Local delivery is exactly the wrong choice for people who use pure webmail. It means that
they will never see messages sent to root.
Users which use DNS/SMTP are almost always able and knowledgable enough
to do a eximconfig to configure everything to their liking post-install
(or even manually).
I disagree with that, both on the assumption of implied knowledge (general mail-system
knowledge => Debian mail configuration knowledge) and that we should require that
configuration after the installation, when it really should be integrated and made easier.
Again, I'm aware that it is possible to override the default values
and thus enable all of Exim's functionality. What I'm arguing is that
«internet site» should be the default preselected choice, just like it is
in the Exim 3 package. That way remote email will work in most cases
without demanding that the user must configure the MTA differently than
the default.
I'd argue that most users expect mail regarding their new Debian system
to land in their main inbox. They do not even know that their new
desktop system has its own mail system. And at least for students, most
live behind a NAT router, so port 25 is not reachable from the outside
anyway.
> [snip Malte's proposal]
There are two essential questions that we're trying to answer with the mail configuration:
1. How should mail addressed to root be handled?
2. How should mail addressed externally be handled?
Absent from this is any consideration for receiving and/or retrieving mail, which should
NOT be a part of Debian installation, because that's not essential to the operation of a
Debian system, while mail to root is, and mail from popcon and reportbug are useful.
I'll describe the answers and their implications, then I'll move on to a proposal for how
this should all be presented to the user.
Mail to root can be delivered either to a local account (either root or some other
previously created account (user account creation comes before mail, right?)) or to an
external address. An external address means we need to get that address and external mail
delivery MUST be configured.
External mail can be unconfigured (should disable reportbug and popcon), Direct-to-MX
SMTP, or can use an ISP SMTP server (smarthost). For RFC 2821 compliance, for Direct-to-MX
SMTP, we need to ensure that we have a fully qualified domain name for HELO (determined by
earlier hostname configuration, need to check that it's an FQDN).
So, without further ado, here's my proposed series of dialogs:
>>>>>>>>>>
1. Root email delivery
Certain messages generated by the system need to be delivered to the system administrator
(root) account. To what address should they be delivered?
________________________
Note: for delivery to a local account, just enter the account name [0]
2. External email delivery
How would you like externally addressed messages to be delivered? Debian's bug reporting
and package popularity survey tools depend on this configuration.
( ) Direct SMTP delivery
( ) SMTP through an ISP server
( ) No external delivery [1]
3. ISP Mail Server configuration [2]
What is the name of your ISP's outgoing mail server?
________________________
What authentication is necessary?
( ) None
( ) SMTP AUTH
( ) POP before SMTP
4. What account credentials should be used? [3]
POP Server: _____________ [4]
User name: _____________
Password: _____________
<<<<<<<<<<
[0] Obviously, local user creation must come before mail configuration, for this to work
[1] If the root address is external, this option should be disabled, and the following
note should follow this option:
"Since you configured root mail to be delivered to a non-local address, external delivery
configuration is mandatory."
Alternately, this option could simply not appear in that case.
[2] This dialog is only shown if the user selected "SMTP through an ISP server" in step 2
[3] This dialog is only shown if the user selected "SMTP AUTH" or "POP before SMTP" in step 3
[4] This line is only shown if "POP before SMTP" was selected in step 3
The relative merits of this proposal are as follows:
* It does not use arbitrary 'classes' of email systems with implicit assumptions that the
user is not made aware of and should not need to know or worry about
* It obtains exactly the information that is needed with minimal excess questioning. In
the lightest case, only 2 questions are asked.
Corollary to this simplification proposal is that all of the information obtained by these
questions should be stored independent of the default MTA configuration.
Debconf should store the answers to all of these questions, and each package that Provides
mail-transport-agent should read its basic configuration from that database. If those
packages don't support SMTP AUTH, that may be a problem. I'd imagine most MTAs would need
a small utility to support POP-before-SMTP, and the supporting code to make use of it.
Root's alias should probably be written into /etc/aliases, as a special exception to not
changing configuration files. Obviously, this would only be done on system installation.
As I look, /etc/aliases is not in any particular package, and is not officially a
configuration file. This is probably a bad thing.
Reportbug should probably stop trying to do direct delivery on its own, because if
external mail delivery through the local MTA fails, then it's a result of explicit
administrator configuration, which should be respected.
Whew, I hope I'm not missing anything. Comments are certainly welcome, though I wonder
which list is really appropriate for this discussion. At any rate, please don't CC me,
because I will follow this on debian-devel.
Regards,
Philip Miller
Happy Debian user, sys-admin, and evangelist. I must have saved the souls of 40 or 50
machines by now ;-D
Reply to: