Discussion:
Please participate in popularity-contest
(too old to reply)
Petter Reinholdtsen
2004-08-08 16:40:07 UTC
Permalink
At the moment, 6112 machines are reporting weekly to
popularity-contest with information on their installed packages, and
their architecture. This is only a small fraction of the machines
running Debian today. The results are available from

<URL:http://popcon.debian.org/>.

The collected information is among other things used to make sure the
most popular packages are early on the official Debian CDs. To make
sure this order reflect our user base, it is important that as many as
possible participate in popularity-contest.

Please considier installing popularity-contest and answering yes to
participate. :)

The versions of popcon in sarge and sid reports the running
architecture. The version in Woody does not. It is interesting to
see the architecture distribution. Here is the current distribution:

1 0.02% kfreebsd-i386
1 0.02% m68k
1 0.02% s390
2 0.04% mipsel
5 0.10% arm
5 0.10% mips
10 0.20% ia64
12 0.24% hppa
20 0.40% alpha
48 0.97% sparc
69 1.40% powerpc
218 4.41% amd64
4550 92.07% i386
4942 100.00% total (ignored 1170 without arch info)

Some archs could use more users participating. :)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
William Lee Irwin III
2004-08-08 17:00:07 UTC
Permalink
Post by Petter Reinholdtsen
1 0.02% kfreebsd-i386
1 0.02% m68k
1 0.02% s390
2 0.04% mipsel
5 0.10% arm
5 0.10% mips
10 0.20% ia64
12 0.24% hppa
20 0.40% alpha
48 0.97% sparc
69 1.40% powerpc
218 4.41% amd64
4550 92.07% i386
4942 100.00% total (ignored 1170 without arch info)
Some archs could use more users participating. :)
I've got hosts of various architectures, but they don't have routable
email. IIRC this relies on the host being able to send email directly.
Any advice/tricks there?


-- wli
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Petter Reinholdtsen
2004-08-08 17:10:05 UTC
Permalink
[William Lee Irwin III]
Post by William Lee Irwin III
I've got hosts of various architectures, but they don't have
routable email. IIRC this relies on the host being able to send
email directly. Any advice/tricks there?
Not really. I would recommend fixing your mail config, or submitting
a patch for popcon to handle a different transport method. HTTP comes
to mind.

6100 machines are able to send emails to popcon. It can't be that
hard. :)

There is also a FAQ entry regarding this. Have look at
<URL:http://popcon.debian.org/FAQ>.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Bas Zoetekouw
2004-08-09 00:30:09 UTC
Permalink
Hi Petter!
Post by Petter Reinholdtsen
Not really. I would recommend fixing your mail config, or submitting
a patch for popcon to handle a different transport method. HTTP comes
to mind.
HTTP support would be nice, as my mails aren't accepted for some vague
reason.
--
Kind regards,
+--------------------------------------------------------------------+
| Bas Zoetekouw | GPG key: 0644fab7 |
|----------------------------| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| ***@o2w.nl, ***@debian.org | a2b1 2bae e41f 0644 fab7 |
+--------------------------------------------------------------------+
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
William Lee Irwin III
2004-08-09 05:40:09 UTC
Permalink
[William Lee Irwin III]
Post by Petter Reinholdtsen
Post by William Lee Irwin III
I've got hosts of various architectures, but they don't have
routable email. IIRC this relies on the host being able to send
email directly. Any advice/tricks there?
Not really. I would recommend fixing your mail config, or submitting
a patch for popcon to handle a different transport method. HTTP comes
to mind.
6100 machines are able to send emails to popcon. It can't be that
hard. :)
There is also a FAQ entry regarding this. Have look at
<URL:http://popcon.debian.org/FAQ>.
You presume it's "broken". They're not intended to send or receive email.
No MTA's are installed, nor are any meant to be.


-- wli
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Tore Anderson
2004-08-09 09:50:11 UTC
Permalink
* William Lee Irwin III
Post by William Lee Irwin III
I've got hosts of various architectures, but they don't have
routable email. IIRC this relies on the host being able to send
email directly. Any advice/tricks there?
* Petter Reinholdtsen
Post by William Lee Irwin III
Not really. I would recommend fixing your mail config, [...]
* William Lee Irwin III
Post by William Lee Irwin III
You presume it's "broken". They're not intended to send or receive email.
No MTA's are installed, nor are any meant to be.
Furthermore, last I checked the Sarge installer (beta 4, IIRC) the
MTA was for some reason not capable of sending email to remote
destinations. Enabling the poularity contest would just result in a
cascade of bounces with the message «Mailing to remote domains not
supported».

I would assume this precludes most of our users from participating in
the popularity contest, unless of course this default has been changed
in the latest release candidate of d-i.
--
Tore Anderson
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Andreas Metzler
2004-08-09 10:40:07 UTC
Permalink
On 2004-08-09 Tore Anderson <***@debian.org> wrote:
[...]
Post by Tore Anderson
Furthermore, last I checked the Sarge installer (beta 4, IIRC) the
MTA was for some reason not capable of sending email to remote
destinations. Enabling the poularity contest would just result in a
cascade of bounces with the message «Mailing to remote domains not
supported».
I would assume this precludes most of our users from participating in
the popularity contest, unless of course this default has been changed
in the latest release candidate of d-i.
exim4's default is local-delivery only, because it is the only sane
default. During installation you'll be given the opprtunity to select
a different setup of course.
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Tore Anderson
2004-08-09 15:20:14 UTC
Permalink
* Tore Anderson
Post by Tore Anderson
Furthermore, last I checked the Sarge installer (beta 4, IIRC) the
MTA was for some reason not capable of sending email to remote
destinations. Enabling the poularity contest would just result in a
cascade of bounces with the message «Mailing to remote domains not
supported».
* Andreas Metzler
Post by Tore Anderson
exim4's default is local-delivery only, because it is the only sane
default.
So, er, the only sane default is «not working»? I must admit I disagree
with you there.. What is the rationale for that?

Anyway, to see if you or I am the odd man out here :-) , I tested the
packages that are providing mail-transport-agent to see if they worked
with only their default configuration. My Debconf priority is set
to "high" - and the packages was installed by just hitting enter whenever
I was asked something, and finally send an email to a remote address
and see if it arrived.

Results:

postfix, courier-mta: Worked without requiring any interaction.

exim (v3): Worked fine, but insisted on me entering the account
rootmail should be forwarded to.

sendmail: Worked fine, but I had explicitly say that I wanted to
configure it.

smail: Insisted on me specifying smarthost (I entered "none") and
an alias for rootmail just like exim. After that, it sent mail
just fine.

xmail: Didn't provide /usr/lib/sendmail (policy violation?), but
mail sent via 'nc localhost smtp' arrived to the remote
destination as expected.

emtp-run: Did not work, probably due to its nature - it requires
a mail relay to function as far as I understand.

nullmailer, ssmtp: Worked, though that was probably just luck -
they seem to require an smtp relay just like esmtp-run, but
guessed mail.`dnsdomainname` in the default configuration which
happens to work here.

masqmail: Didn't work, says "not online" in its log. Given the
package description I think that it is possibly due to its
nature, and that if I were able to signal to it that "I am
online now" somehow, it could possibly be working.

zmailer: Didn't work, don't know why - there wasn't any logs or
obvious error messages that I can see.

exim4-daemon-*: Doesn't work - intentionally so as you said.

So it seems to me that most the other MTA's try to provide a working
default configuration to the extent possible. What's so special
about Exim (v4, to be specific), that makes it undesireable/impossible
to ship a working configuration as the default?

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.
Post by Tore Anderson
During installation you'll be given the opprtunity to select a different
setup of course.
Of course, I can make Exim do all kinds of stuff if I set my mind to it.
It is the default settings I care about, the one the user get after
having done a pinky-finger installation - in my opinion they should,
whenever possible, provide a working setup. Currently they don't, and
sadly probably won't do so for Sarge either, unless the d-i crew
overrides the default setting.

Kind regards,
--
Tore Anderson
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Radu Spineanu
2004-08-09 16:50:16 UTC
Permalink
Post by Tore Anderson
xmail: Didn't provide /usr/lib/sendmail (policy violation?), but
mail sent via 'nc localhost smtp' arrived to the remote
destination as expected.
/usr/sbin/sendmail is policy but i will make a new release that creates
this symlink.

However by default it doesn't work because it's called with
sendmail -oi "$MAILTO" , and xmail expects sendmail -i "$MAILTO" .

I will look into this.

Radu
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Andreas Barth
2004-08-09 17:10:07 UTC
Permalink
Post by Radu Spineanu
Post by Tore Anderson
xmail: Didn't provide /usr/lib/sendmail (policy violation?), but
mail sent via 'nc localhost smtp' arrived to the remote
destination as expected.
/usr/sbin/sendmail is policy but i will make a new release that creates
this symlink.
However by default it doesn't work because it's called with
sendmail -oi "$MAILTO" , and xmail expects sendmail -i "$MAILTO" .
I will look into this.
If it's a mail-transport-agent, then (and exactly only than) it must
provide the file /usr/sbin/sendmail, and the executed code must be
able to parse the standard sendmail options.

Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Radu Spineanu
2004-08-09 19:00:12 UTC
Permalink
Post by Andreas Barth
Post by Radu Spineanu
Post by Tore Anderson
xmail: Didn't provide /usr/lib/sendmail (policy violation?), but
mail sent via 'nc localhost smtp' arrived to the remote
destination as expected.
/usr/sbin/sendmail is policy but i will make a new release that creates
this symlink.
However by default it doesn't work because it's called with
sendmail -oi "$MAILTO" , and xmail expects sendmail -i "$MAILTO" .
I will look into this.
If it's a mail-transport-agent, then (and exactly only than) it must
provide the file /usr/sbin/sendmail, and the executed code must be
able to parse the standard sendmail options.
It seems the -o options are not supported by xmail, however
-i which is the exact same thing as -oi IS, and i find it other MTA's
know about it, exim for one.

I have already created a build which has a workaround for this and
converts -oi to -i, but instead of me creating a patch, wouldn't be
easier for popularity-contest to change -oi to -i in the script ?

By me it's ok either way, i just want some second opinions..

Radu
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Andreas Metzler
2004-08-09 21:30:18 UTC
Permalink
[...]
Post by Radu Spineanu
Post by Andreas Barth
Post by Radu Spineanu
However by default it doesn't work because it's called with
sendmail -oi "$MAILTO" , and xmail expects sendmail -i "$MAILTO" .
I will look into this.
If it's a mail-transport-agent, then (and exactly only than) it must
provide the file /usr/sbin/sendmail, and the executed code must be
able to parse the standard sendmail options.
It seems the -o options are not supported by xmail, however
-i which is the exact same thing as -oi IS, and i find it other MTA's
know about it, exim for one.
I have already created a build which has a workaround for this and
converts -oi to -i, but instead of me creating a patch, wouldn't be
easier for popularity-contest to change -oi to -i in the script ?
By me it's ok either way, i just want some second opinions..
-oi is used by some important programs per default, including mutt. I
do not know by heart what options you'll need to support, but I'd
guess at least -oem -oi -i -t -F -f. - You'll have to check MUAs and
stuff like cron or at to be sure.
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Steve Greenland
2004-08-10 13:50:12 UTC
Permalink
Post by Andreas Metzler
-oi is used by some important programs per default, including mutt. I
do not know by heart what options you'll need to support, but I'd
guess at least -oem -oi -i -t -F -f. - You'll have to check MUAs and
stuff like cron or at to be sure.
Cron uses "-i -FCronDaemon -oem".

Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Radu Spineanu
2004-08-10 14:50:11 UTC
Permalink
Post by Steve Greenland
Post by Andreas Metzler
-oi is used by some important programs per default, including mutt. I
do not know by heart what options you'll need to support, but I'd
guess at least -oem -oi -i -t -F -f. - You'll have to check MUAs and
stuff like cron or at to be sure.
Cron uses "-i -FCronDaemon -oem".
Xmail works great with cron on a default install.

My sponsor is away and i would apreciate it if someone would help me
with an upload for the latest build.
If someone is willing please send me an email so i can give you the link.


Radu
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Andreas Metzler
2004-08-09 20:00:20 UTC
Permalink
Post by Tore Anderson
* Tore Anderson
Post by Tore Anderson
Furthermore, last I checked the Sarge installer (beta 4, IIRC) the
MTA was for some reason not capable of sending email to remote
destinations. Enabling the poularity contest would just result in a
cascade of bounces with the message «Mailing to remote domains not
supported».
* Andreas Metzler
Post by Tore Anderson
exim4's default is local-delivery only, because it is the only sane
default.
So, er, the only sane default is «not working»? I must admit I disagree
with you there.. What is the rationale for that?
It is not "not working". It is doing local delivery, which is imho the
only reason we have a MTA in the base-system.

[...]
Post by Tore Anderson
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.
Dear. Just look at it. That is what is happening. You just have to select
the right option.

-----------------------------
General type of mail configuration:

internet site; mail is sent and received directly using SMTP
mail sent by smarthost; received via SMTP or fetchmail
mail sent by smarthost; no local mail
--> local delivery only; not on a network
manually convert from handcrafted Exim v3 configuration
no configuration at this time

cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Tore Anderson
2004-08-10 10:10:11 UTC
Permalink
* Tore Anderson
Post by Tore Anderson
So, er, the only sane default is «not working»? I must admit I disagree
with you there.. What is the rationale for that?
* Andreas Metzler
Post by Tore Anderson
It is not "not working". It is doing local delivery, which is imho the
only reason we have a MTA in the base-system.
IMO a general-purpose MTA that is unable to send email in accordance
with RFC 2821 is best classified as "not working".

Besides, base even includes an MUA. I certainly expect an MUA to be
able to send to remote destinations; the days where the most common use
of email was to send to and receive from users on the same system are
long gone.

Then there's popularity-contest, which absolutely require an MTA that is
able to send email to remote destinations. Although not part of base,
d-i asks permission to enable it - but it won't work anyway as long as
Exim is configured with its default settings.

I think reportbug also deserves mention here as a tool that we should
endeavour to have working with an absolute minimum of user configuration
required.

* Tore Anderson
Post by Tore Anderson
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.
* Andreas Metzler
Post by Tore Anderson
Dear. Just look at it. That is what is happening. You just have to select
the right option.
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 mean - how many users do you think are genuinely interested in
configuring an MTA? My guess is: very very few - because most of
them just want their email to work out of the box.
--
Tore Anderson
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Andreas Metzler
2004-08-10 11:10:08 UTC
Permalink
On 2004-08-10 Tore Anderson <***@debian.org> wrote:
[...]
Post by Tore Anderson
* Andreas Metzler
Post by Andreas Metzler
Dear. Just look at it. That is what is happening. You just have to select
the right option.
Again, I'm aware that it is possible to override the default values
and thus enable all of Exim's functionality.
"Selecting the correct choice" and "overriding the default values" are
different things, as far as my command of English goes.
Post by Tore Anderson
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 mean - how many users do you think are genuinely interested in
configuring an MTA? My guess is: very very few - because most of
them just want their email to work out of the box.
Well, "internet site" does not implement this for everybody without a
fixed IP address, which I'd guess applies to more than 90% of our
installations. Being listed on DUL guarantees that direct SMTP
delivery does not work _reliably_. Blocking outgoing connections to
port 25 except to smarthost is not uncommon either.
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Tore Anderson
2004-08-10 12:10:06 UTC
Permalink
* Andreas Metzler
Post by Andreas Metzler
Well, "internet site" does not implement this for everybody without a
fixed IP address, which I'd guess applies to more than 90% of our
installations. Being listed on DUL guarantees that direct SMTP
delivery does not work _reliably_. Blocking outgoing connections to
port 25 except to smarthost is not uncommon either.
Of course, I do not expect that the package should perfectly handle
all kinds of installations - it's true that the «internet site»
option wouldn't work in all scenarios such as when an ISP blocks
port 25 egress or if you as and dial-up user try correspond with an
overzealous spam vigilante who refuses incoming connections based on
DULs alone. Fortunately, use of such measures seems to be used only
by a (not insignificant, though) minority of ISPs and postmasters.

However, using «internet site» in these scenarios is no worse than
using the local-only option - the outgoing email will in both cases
simply bounce back to sender.

The local-only option, on the other hand, guarantees with 100%
percent certainity that remote deliveries will -never- work, even
in the many cases where they easily could. I still do not comprehend
how it is possible for you to look upon this as the best default.

Anyway, it seems we're getting nowhere. EOD?

Kind regards,
--
Tore Anderson
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Matthias Urlichs
2004-08-12 15:30:08 UTC
Permalink
Post by Tore Anderson
However, using «internet site» in these scenarios is no worse than
using the local-only option - the outgoing email will in both cases
simply bounce back to sender.
That is not always the case; too many sites still accept mail, only to
bounce it later. Where to, if you have a send-only setup?

A working Internet mail setup implies the ability to receive email as well
as sending it. A sane default, IMHO, requires that both work reliably, OR
that both *don't* work.

Given that the former option is not possible to achieve automatically, the
latter is the only sane option.
--
Matthias Urlichs
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Kris Deugau
2004-08-10 15:40:10 UTC
Permalink
Post by Andreas Metzler
Post by Tore Anderson
* Andreas Metzler
Post by Andreas Metzler
Dear. Just look at it. That is what is happening. You just have
to select the right option.
Again, I'm aware that it is possible to override the default values
and thus enable all of Exim's functionality.
"Selecting the correct choice" and "overriding the default values"
are different things, as far as my command of English goes.
But both imply "Don't blindly accept whatever happens to be default;
make a specific *choice*".

-kgd
--
Get your mouse off of there! You don't know where that email has been!
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Malte Cornils
2004-08-10 11:40:07 UTC
Permalink
Hello,
Post by Tore Anderson
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
Post by Tore Anderson
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.
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.

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.

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).
Post by Tore Anderson
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.

Proposal:

1. We're now going to setup your email system.

( ) Local mail system (if you have no Internet connection or pure Webmail)
( ) Send and fetch mail via SMTP/POP3/IMAP
( ) Advanced configuration (also for modem/ISDN users directly
connection to the Internet)

If you're unsure, choose the first.

(Advanced configuration would lead to the well-known exim4 question set,
local mail system would just enable local delivery. If not:)

2. fetching mail

( ) fetch mail from POP3 mail server
( ) fetch mail from IMAP mail server

[ ] secure connection (encrypted SSL/TLS)
[ ] keep mail on server

(then, asks for server name/username/password. If the last option is
checked, the various tricks to detect new mail in the POP3 case should
be employed)

3. sending mail

[ ] secure connection (encrypted SSL/TLS)
[ ] needs authentication (username and password)
[ ] need to fetch mails before being able to send (POP-before-SMTP)

(asks for server name, ask for username/password if checked)

I am not sure whether this is easy enough though and I hope I'm not
missing something obvious :-( This is obviously sarge+1 stuff.

-Malte
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Philip Miller
2004-08-12 04:30:07 UTC
Permalink
Post by Malte Cornils
Post by Tore Anderson
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
Post by Tore Anderson
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.
Post by Malte Cornils
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
Post by Malte Cornils
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.
Post by Malte Cornils
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.
Post by Malte Cornils
Post by Tore Anderson
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
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Steve Greenland
2004-08-10 14:00:13 UTC
Permalink
Post by Tore Anderson
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.
And that way people bitch about having port 25 open by default.

I suppose the ideal default would be "able to send mail remotely, but
not receive it." Of course, then you wouldn't get delivery failure
notices, but it's been so long since I got a valid one, I'm not sure
that's a big deal.

In any case, this isn't going to happen for sarge...

Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Andrew Pimlott
2004-08-25 23:10:07 UTC
Permalink
Post by Steve Greenland
Post by Tore Anderson
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.
And that way people bitch about having port 25 open by default.
exim4-config from testing/unstable only listens on localhost by default.

This points to the problem that the first two options ("internet site;
mail is sent and received directly using SMTP" and "mail sent by
smarthost; received via SMTP or fetchmail") are deceptive, and probably
contribute to people not having working outgoing mail. They should make
it clear that SMTP won't be open to the world by default.

With this clarification, I think that "internet site" is a sensible
default. Despite firewalls and blacklists, this does work most of the
time.

Andrew
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Justin Pryzby
2004-08-10 15:50:12 UTC
Permalink
pop-con and reportbug can always do:

escape($DATA);
mail `host -tmx $DEST |perl` <<-EOF
helo `hostname`
mail from: <nobody@`hostname -f`>
rcpt to: $TO
data
$DATA
.
EOF

Maybe we should provide this for those packages, for uniformity?

Justin
Post by Tore Anderson
* Tore Anderson
So, er, the only sane default is ?not working?? I must admit I disagree
with you there.. What is the rationale for that?
* Andreas Metzler
It is not "not working". It is doing local delivery, which is imho the
only reason we have a MTA in the base-system.
IMO a general-purpose MTA that is unable to send email in accordance
with RFC 2821 is best classified as "not working".
Besides, base even includes an MUA. I certainly expect an MUA to be
able to send to remote destinations; the days where the most common use
of email was to send to and receive from users on the same system are
long gone.
Then there's popularity-contest, which absolutely require an MTA that is
able to send email to remote destinations. Although not part of base,
d-i asks permission to enable it - but it won't work anyway as long as
Exim is configured with its default settings.
I think reportbug also deserves mention here as a tool that we should
endeavour to have working with an absolute minimum of user configuration
required.
Andreas Metzler
2004-08-10 16:20:10 UTC
Permalink
Post by Justin Pryzby
escape($DATA);
mail `host -tmx $DEST |perl` <<-EOF
helo `hostname`
rcpt to: $TO
data
$DATA
.
EOF
Maybe we should provide this for those packages, for uniformity?
[...]

reportbug includes code for direct smtp-delivery without MTA iirc even
in woody.
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Justin Pryzby
2004-08-10 15:50:12 UTC
Permalink
`dnsdomainname` is an interesting default; of course its not guaranteed
to work (for me its just my local host name). Probably you already have
something on your system saying "use this to send mail" (a "smarthost").
Otherwise, none of these would have worked.

Another option would be to do a dnslookup on 'smtp-server', which seems
to get used sometimes.

Justin
Post by Tore Anderson
Anyway, to see if you or I am the odd man out here :-) , I tested the
packages that are providing mail-transport-agent to see if they worked
with only their default configuration. My Debconf priority is set
to "high" - and the packages was installed by just hitting enter whenever
I was asked something, and finally send an email to a remote address
and see if it arrived.
postfix, courier-mta: Worked without requiring any interaction.
exim (v3): Worked fine, but insisted on me entering the account
rootmail should be forwarded to.
sendmail: Worked fine, but I had explicitly say that I wanted to
configure it.
smail: Insisted on me specifying smarthost (I entered "none") and
an alias for rootmail just like exim. After that, it sent mail
just fine.
xmail: Didn't provide /usr/lib/sendmail (policy violation?), but
mail sent via 'nc localhost smtp' arrived to the remote
destination as expected.
emtp-run: Did not work, probably due to its nature - it requires
a mail relay to function as far as I understand.
nullmailer, ssmtp: Worked, though that was probably just luck -
they seem to require an smtp relay just like esmtp-run, but
guessed mail.`dnsdomainname` in the default configuration which
happens to work here.
Andrew Pollock
2004-08-12 08:00:15 UTC
Permalink
Post by Justin Pryzby
`dnsdomainname` is an interesting default; of course its not guaranteed
to work (for me its just my local host name). Probably you already have
something on your system saying "use this to send mail" (a "smarthost").
Otherwise, none of these would have worked.
Another option would be to do a dnslookup on 'smtp-server', which seems
to get used sometimes.
If you're going to rely on non-standard naming conventions like that, you're
gonna have a bad time...
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Jérôme Warnier
2004-08-09 14:10:10 UTC
Permalink
Post by Petter Reinholdtsen
[William Lee Irwin III]
Post by William Lee Irwin III
I've got hosts of various architectures, but they don't have
routable email. IIRC this relies on the host being able to send
email directly. Any advice/tricks there?
Not really. I would recommend fixing your mail config, or submitting
a patch for popcon to handle a different transport method. HTTP comes
to mind.
This is not a question of MTA config. Why should we use a local MTA only
for popcon?
HTTP could be an interesting ID, but I thought more about being able to
use a remote MTA. Is that possible or would it need a huge work to get
popcon to do that?

[..]
--
Jérôme Warnier
Consultant
BeezNest
http://beeznest.net
Emanuele Rocca
2004-08-09 14:50:14 UTC
Permalink
Post by Jérôme Warnier
HTTP could be an interesting ID, but I thought more about being able to
use a remote MTA. Is that possible or would it need a huge work to get
popcon to do that?
What about using something like Mail::Sender(3pm) to actually send the
mail?

This would allow to specify a remote MTA.

ciao,
ema

--
Questo è il domani di cui ti preoccupavi ieri. E ora sai perché.
Martin Dickopp
2004-08-09 08:20:07 UTC
Permalink
Post by Petter Reinholdtsen
Please considier installing popularity-contest and answering yes to
participate. :)
On all my machines, the /usr partition is mounted read-only. It is my
understanding that popcon uses the atime to determine which programs
have been run. What will be the effect if popcon is run on a machine
with read-only /usr?

Martin
(not a DD)
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Petter Reinholdtsen
2004-08-09 08:50:08 UTC
Permalink
[Martin Dickopp]
Post by Martin Dickopp
On all my machines, the /usr partition is mounted read-only. It is
my understanding that popcon uses the atime to determine which
programs have been run. What will be the effect if popcon is run on
a machine with read-only /usr?
All your installed packages will be reported as installed. The only
thing missing is the "used" vote, as the installed packages will
appear unused. Still, your submission will affect the package order
on the CD, because the CD package order is looking at the installation
count, not the used count.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Martin Dickopp
2004-08-09 15:10:08 UTC
Permalink
Post by Petter Reinholdtsen
[Martin Dickopp]
Post by Martin Dickopp
On all my machines, the /usr partition is mounted read-only. It is
my understanding that popcon uses the atime to determine which
programs have been run. What will be the effect if popcon is run on
a machine with read-only /usr?
All your installed packages will be reported as installed. The only
thing missing is the "used" vote, as the installed packages will
appear unused. Still, your submission will affect the package order
on the CD, because the CD package order is looking at the installation
count, not the used count.
Good to know. You've just found a new user. :)

However, in order not to distort the statistics, it would be nice if the
package could be configured to not even look at the atime.

I also don't agree with popcon always invoking the MTA as user "root",
because I think it is a reasonable configuration to /deliberately/
restrict "root" from sending mail to the outside world. I've send a
patch to fix this to the BTS (Bug#264593).

Martin
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Ryan Vilim
2004-08-09 21:00:18 UTC
Permalink
Post by Petter Reinholdtsen
Please considier installing popularity-contest and answering yes to
participate. :)
Well you now have 3 more machines (1 stable[typhon] and two
unstable[jabberwock and cerberus]) reporting. Although http support
would be nice, it isn't a problem with my computers.

Although just out of curiosity, exactly what information does it send?
(besides the usual, root passwords, mailboxes etc :p)
--
Ryan Vilim
http://jabberwock.ca
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Christoph Berg
2004-08-09 21:20:12 UTC
Permalink
Post by Ryan Vilim
Although just out of curiosity, exactly what information does it send?
(besides the usual, root passwords, mailboxes etc :p)
See /var/log/popularity-contest.

Christoph
--
***@df7cb.de | http://www.df7cb.de/
Martin Dickopp
2004-08-09 21:20:14 UTC
Permalink
Post by Ryan Vilim
Post by Petter Reinholdtsen
Please considier installing popularity-contest and answering yes to
participate. :)
Well you now have 3 more machines (1 stable[typhon] and two
unstable[jabberwock and cerberus]) reporting. Although http support
would be nice, it isn't a problem with my computers.
Although just out of curiosity, exactly what information does it send?
Look in /var/log/popularity-contest; it contains a copy of the mail that
is send.

Martin
--
,--. ,= ,-_-. =.
/ ,- ) Martin Dickopp, Dresden, Germany ((_/)o o(\_))
\ `-' http://www.zero-based.org/ `-'(. .)`-'
`-. \_/
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Georg Neis
2004-08-09 21:30:11 UTC
Permalink
* Ryan Vilim <***@jabberwock.ca> wrote:
[popularity-contest]
Post by Ryan Vilim
Although just out of curiosity, exactly what information does it send?
(besides the usual, root passwords, mailboxes etc :p)
See /usr/share/doc/popularity-contest/FAQ and README.gz.

Georg
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Rudi Effe
2004-08-10 00:20:09 UTC
Permalink
Post by Petter Reinholdtsen
At the moment, 6112 machines are reporting weekly to
popularity-contest with information on their installed packages, and
their architecture.  This is only a small fraction of the machines
running Debian today.  
Hi Petter, thank you for informing us about the project - any connections to
debian-edu?

One thing is what packages are installed (>1000 with me) another question is
what packages are used! Shouldn't one include att's accounting that measures
the amount of time processes are running?

Shouldn't one rate the acitivity on developers' CVS much more? Can a project
any good if it is not vivid?

Regards
rUdi
Russ Allbery
2004-08-10 03:20:06 UTC
Permalink
Post by Rudi Effe
One thing is what packages are installed (>1000 with me) another
question is what packages are used! Shouldn't one include att's
accounting that measures the amount of time processes are running?
There is a measure of what programs are used built into
popularity-contest, although it relies on atimes of binaries and doesn't
always do quite the right thing.
Post by Rudi Effe
Shouldn't one rate the acitivity on developers' CVS much more? Can a
project any good if it is not vivid?
I have a program that I use daily that I've not modified in the slightest
in over a year, and that I've modified only to add features requested by
other people in over two years. Some programs just do what they do well
and don't need to change.
--
Russ Allbery (***@stanford.edu) <http://www.eyrie.org/~eagle/>
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Petter Reinholdtsen
2004-08-10 07:10:08 UTC
Permalink
[Rudi Effe]
Post by Rudi Effe
Hi Petter, thank you for informing us about the project - any
connections to debian-edu?
Not directly. Debian-edu needs a good installer, so I work on
debian-installer. debian-installer needs to be put on a CD, so I work
on debian-cd. debian-cd need a way to order the 15000 packages in
Debian when generating CDs, so I work on popularity-contest. Besides,
I believe a few of the 15000 packages in Debian are unused and should
be removed, and the only way to detect which packages are unused is to
make sure popcon are as widely used as possible. I believe the time
between releases are related to the amount of packages in Debian, and
want the package count to go down to speed up the release time.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Enrico Zini
2004-08-10 07:20:08 UTC
Permalink
Post by Petter Reinholdtsen
make sure popcon are as widely used as possible. I believe the time
between releases are related to the amount of packages in Debian, and
want the package count to go down to speed up the release time.
Nothing wrong with removing unused packages, but I believe that the time
between releases is more dependent on a release process that isn't
scaling to the increase of the archive. I'd consider giving some
thought at the release process more interesting than just limiting the
growth of the Debian Universe.

But I should stop here: release process is better discussed after sarge
releases.


Ciao,

Enrico
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Andrew Pollock
2004-08-10 01:40:06 UTC
Permalink
Post by Petter Reinholdtsen
Please considier installing popularity-contest and answering yes to
participate. :)
Have you also sent this to debian-user? Maybe even one of the announce
lists?

We make the distribution for our users, which isn't just us developers. The
wider the user base using popcon, the more relevant the results will be.

What I'm trying to say is Debian Developer Dave is likely to have a
different package set installed to Joe User.

regards

Andrew
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Paul Scott
2004-08-10 06:30:11 UTC
Permalink
Post by Andrew Pollock
Post by Petter Reinholdtsen
Please considier installing popularity-contest and answering yes to
participate. :)
Have you also sent this to debian-user? Maybe even one of the announce
lists?
We make the distribution for our users, which isn't just us developers. The
wider the user base using popcon, the more relevant the results will be.
What I'm trying to say is Debian Developer Dave is likely to have a
different package set installed to Joe User.
I interjected Petter's request into a thread on the subject on Debian
User just yesterday.

Paul Scott
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Petter Reinholdtsen
2004-08-10 07:00:19 UTC
Permalink
[Andrew Pollock]
Post by Andrew Pollock
Have you also sent this to debian-user? Maybe even one of the
announce lists?
I've send emails to debian-devel-announce, but not debian-user. I'm
not too comfortable sending emails to lists where I don't participate
myself (I'm not subscribed to debian-user).

But I would be glad if someone else would announce it in other forums.
:)
Post by Andrew Pollock
What I'm trying to say is Debian Developer Dave is likely to have a
different package set installed to Joe User.
Yes, I agree. And we should have popcon reports for all sorts of
users to get as good statistics as possible.
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Loading...