| Philip Miller 2004-08-12, 2:49 am |
| Malte Cornils wrote:
> On Tue, Aug 10, 2004 at 11:37:04AM +0200, Tore Anderson wrote:
>
>
>
That sounds quite reasonable to me.
[vbcol=seagreen]
> 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.
>
> 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:[vbcol=seagreen]
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
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|