Okay, maybe not exactly 98%, but it can be guaranteed that the vast
majority of people using Exim fall into the category of people with an
ISP account who must use their ISP's mail server if they expect to be
able to send mail anywhere.

Given that this is the case, it seems like a serious problem with Exim4
that it fails to take into account the type of usage for the vast
majority of users and insists on setting up a default configuration that
is for all intents and purposes utterly worthless to them.

Here is what end user's want their mail client to do:

 - set itself up to authenticate against their ISP's mailer

 - if the mail supports TLS encryption, by all means use it

 - if the mailer supports CRAM-MD5 or other secure auth mechanism, use
   it

 - provide a simple, easy-to-find way to reconfigure Exim, ideally with
   a command that begins with "exim4" and can be found or easily
   intuited via tab-completion

A couple of other considerations:

 - the first debconf question is this question about split
   configuration.  Right off the bat the end-user gets inundated with
   something that is probably over their head and almost certainly totally
   irrelevant to them, unless they doing a serious SMTP setup in which case
   it might be irrelevant anyways.  This question only intimidates and
   probably annoys most end-users and does not help him/her achieve what
   they want to achieve, i.e. a fucntioning mail system

 - The second option for type of mail configuration is "mail sent by
   smarthost; received via SMTP or fetchmail"   There are couple of
   problems with this: first, the terminology is not what the average
   enduser is familiar with.  Again, they are being inundated right at
   the outset when all they want is the bloody mail to work with their
   ISP's mailer.   Second, when this option is selected, the end result
   99% of the time IS NOT A CONFIGURATION THAT ACTUALLY WORKS WITH THE
   MAILER.  Again, 98% of the mailers are going to require SMTP client
   AUTH but this DOES NOT GET CONFIGURED CORRECTLY!

 - The next question after this is "System mail name".  Again, for the
   average person used to setting up Lookout or whatever to work with
   their ISP's mailer, their reaction is going to be "What?  What does
   that have to do with anything?"

 - "IP-addreses for incoming connections" - the default is 127.0.0.1, but
   the text could be more clear and say something like "Do not change
   this unless you know what you are doing.  Altering this value could
   pose a security risk to your system.  For most users, the default value
   is sufficient."

-  "Other destinations for which mail is accepted" - it could be clearer
   and say that the default is sufficient for the vast majority of
   users.

 - "IP address or host name of the outgoing smarthost."  Here the name or
   address of the smarthost is entered.  Most users would think that
   after this point that it would be configured to work with the ISP's
   mailer, but they would be wrong.

 - "Hide local mail name in outgoing mail"  Here is a problem with this:
   if a user says "No" then tries to send mail, the ISP's mailer will
   likely reject it because it will see From: <local user>@<host name>
   with a message like "Sender address does not belong to logged in
   user"   That's because the ISP's mailer expects it to be
   <user>@<isp-mailer's domain> and has no idea about the host name of the
   user's computer.  This is a huge problem.  If the user answers "Yes"
   here then what is supposed to happen?  If in the next question you
enter the ISP's domain name for "Visible domain name for local users"
its confusing what the outcome is supposed to be.  Will this mean that
mail from local user "fred" to local user "joe" will appear to be from
fred@<isp's domain>?  Does Exim4 differentiate between mail sent between
accounts on the local machine and mail sent to outside?  This question
does not help the problem and only leads to more confusion.  I can
guarantee that at this point 98% of end user's are going to be
completely lost and just assume that getting mail to work is a lost
cause.  What is sad about this is that it does not need to be the case
because Exim4 has the capacity to do exactly what he and 98% of users
need.  Cannot Exim4 be designed to install so that it will work for most
people without a huge fuss?

On a side note, I am willing to bet that were it the case that Exim4 set
up properly, there would be a huge change in popularity-contest ratings,
because it is almost guaranteed that a large majority of the reports
fail to send.

retitle #410756 improvement suggestsions for default config
severity #410756 wishlist
reassign #410756 exim4-config
user exim4@packages.debian.org
usertags #410756 post-etch
thanks

Thanks for your suggestions. I have marked and tagged them
appropriately.

Just throw your credentials into /etc/exim4/passwd.client. We have
intentionally not debconfed this at the current time because of #244724.

This is already the case.

CRAM-MD5 has the serious disadvantage of needing the password stored
in clear text on the client system. It is my opinion that the client
system is more likely to be compromised than the network being in use.
This might have changed in these days where unencrypted wireless LAN
installations play a role.

Do you have hard statistical data about how many ISP smarthosts do not
support STARTTLS but do support CRAM-MD5.

I still tend to belive that the decision to use CRAM-MD5 should be one
of the end user, but most end users are not qualified to take that
decision.

So you'd want to have a command exim4-reconfigure which does nothing
more than call dpkg-reconfigure exim4-config? Sorry, this is only
going to happen if this gets widely supported in Debian. The pointer
to dpkg-reconfigure exim4-config is in README.Debian.gz chapter 2.

This question can be moved to somewhere later in the configuration
process. I'm going to consider this for post-etch.

What terminology should be used here?

If you want to be heard, do not alienate the people who you want to
follow your advice.

If you use a GUI mailer, you'd be better off with having it deliver
directly to your ISP.

Don't we give a reasonable default for this question?

Good idea. Since debconf templates have a rather severe size limit, I
cannot guarantee that this can be implemented in debconf. I have
committed the text to README.Debian in svn.

Defaults are usually sufficient for the vast majority of users. I
don't think it is a good idea to bloat the docs with matters of course.

What do you suggest changing?

This is going to happen only if the ISP's mailer insists on their mail
addresses being used, which is thankfully the exception.

If it were _that_ easy, we'd have implemented this a long time ago.

We need your help. Please advise what to do. Give examples and
suggestions, wording for new templates and descriptions what's going
to happen.

popularity-contest (1.34) unstable; urgency=low
  * Remove question about submission method (http/smtp).  The HTTP
    method is and should be the primary submit method for new
   installations,
 -- Petter Reinholdtsen <pere@debian.org>  Mon,  4 Sep 2006 19:09:06 +0200

Please additionally note that I do not particularly enjoy communiating
with anonymous entities.

Additionally, when you claim percentages, I'd love to know how you
have determined these numbers. We are desperately trying to find out
who uses exim to gear them better. If you have just guessed them, I
guess against you that you have guessed way too high. That way, you're
only going to alienate the people you want to work for you.

You are also invited to join the pkg-exim4-devel mailing list to take
part in the development progress. You will probably love to read a
thread from the last summer (June - August, IIRC), where IIRC Wouter
suggested a completely new configuration scheme and also said that he
would implement it. Unfortunately, he hasn't yet gotten around to
actually produce code.

Greetings
Marc

One way I could envision it being would be like this:

First debconf question: "Please choose a level of configuration.  For
most users setting up mail to work with their ISP's mail server the
"Simple" method should be sufficient.  Choose "Advanced" if you are
setting up your own mailer or intend to do things like mail relaying.

Choosing "Simple" would then ask:

"Please enter the name of your provider's mail server"

   user enters mail.isp.com

   (At this point would it be a good idea to do a HELO or EHLO of the
    server to probe its capabilities?  If so, subsequent questions could
    be like "This server appears to support TLS encryption, should it be
    used?"  But based on your comment below it should use TLS if
    available.  However, based on this doc:
http://www.debian-administration.org/articles/280 it seemed that one
    has to create /etc/exim4/exim4.conf.localmacros and add
    "MAIN_TLS_ENABLE = true" to it to get TLS.

    I do not know enough about CRAM-MD5 and the merits of using or not
    using it or other auth mechanisms, only that it would of course be
    preferable to have it used when TLS is not available.  I don't have
    any hard data about how many smarthosts don't support TLS but do support
    CRAM-MD5 but I think the number is high based on my experience.
    Again, this is all relative to whether TLS or an encrypted auth
    mechanism would simply be used if they are detected.

(after questions settling the use of TLS and auth method (if need to be
asked)
"Please enter the mail username for your provider"
"Please enter the password for this account"

At this point it would finish with a note to the effect "Exim should now
be configured to send mail.  If there are problems or you need to
configure it you can run "dpkg-reconfigure exim4-config" as root."


Re: having a more simply named command to access the configuration,
didn't Exim v.3 have it (eximconfig or something like that)?  Not sure
why it did not continue with v.4.



Re: the "Hide local mail name in outgoing mail"  If this is answered "No" it is definitely a problem with gmx.net which will reject the mail.  This is the exact message:

======================================================================
SMTP error from remote mail server after MAIL FROM:<djo@maxi.alay.net>
SIZE=1562 AUTH=djo@maxi.alay.net:
    host mail.gmx.net [213.165.64.20]: 550 5.7.0 Sender address does not
belong to logged in user {mp030}

------ This is a copy of the message, including all the headers. ------

Return-path: <djo@maxi.alay.net>
Received: from djo by maxi.alay.net with local (Exim 4.63)
        (envelope-from <djo@maxi.alay.net>)
        id 1HGtWZ-0001Td-U4
        for prosolutions@gmx.net; Tue, 13 Feb 2007 01:00:31 -0800
Date: Tue, 13 Feb 2007 01:00:31 -0800
From: Daniel <djo@alay.mine.nu>
To: prosolutions@gmx.net
Subject: test2
Message-ID: <20070213090031.GB5555@maxi.alay.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
======================================================================

If I use the simple mail program nbsmtp to send mail (this is all it
does, just send mail through a smarthost) it sends correctly.  The
headers of a received message look like this (in comparison with above):

=======================================================================
From djon777@gmx.net  Tue Feb 13 00:57:49 2007
Return-Path: djon777@gmx.net
Delivered-To: GMX delivery to prosolutions@gmx.net
Received: from pop.gmx.net
        by maxi.alay.net with POP3 (fetchmail-6.3.6)
        for <djo@localhost> (single-drop); Tue, 13 Feb 2007 00:57:49
-0800 (PST)
Received: (qmail invoked by alias); 13 Feb 2007 08:55:27 -0000
        46gw==
Received: by maxi (nbSMTP-1.01-cvs) for uid 1000
        (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256/256
bits))
        djon777@gmx.net; Tue, 13 Feb 2007 00:55:52 -0800 (PST)
Date: Tue, 13 Feb 2007 00:55:30 -0800
From: Daniel <djon777@gmx.net>
To: prosolutions@gmx.net
Subject: test
Message-ID: <20070213085049.GA5555@maxi.alay.net>
Reply-To: Daniel <djon777@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
===========================================================================

In the first instance of the failed message through Exim, the problem
stems from From: being djo@maxi.alay.net.  I'm not sure which of the 2
From:'s this is.  But with the successful send via nbsmtp there are:

From djon777@gmx.net

I'm guessing the first one is the envelope from which is the important
one for the mail server, the second one is just my local username, which
apparently the GMX mail server doesn't care at all about.

Why isn't it possible for Exim to know that, if its sending an outgoing
message through a smarthost (as opposed to local mail) that it should
set the envelope From: accordingly?  In the instance that the mail is
local, then it should not have to do this.  In fact it would be
confusing if local mail had an envelope From: using the ISP's mailer
domain.

nbsmtp, as simple as it is, works every time with every ISP mailer, once
you know the server name, your credentials, and the type of auth
mechanism to use.  Why should Exim be more complicated than this for the
end user?

Getting back to the original debconf question "Hide local mail name in
outgoing mail" I think that it should not be necessary to ask this, as
nbsmtp, a much simpler program, does not have to ask it.



Regards,

sorry the end of the last message got accidentally cut off:


If I use the simple mail program nbsmtp to send mail (this is all it
does, just send mail through a smarthost) it sends correctly.  The
headers of a received message look like this (in comparison with above):

=======================================================================
From djon777@gmx.net  Tue Feb 13 00:57:49 2007
Return-Path: djon777@gmx.net
Delivered-To: GMX delivery to prosolutions@gmx.net
Received: from pop.gmx.net
        by maxi.alay.net with POP3 (fetchmail-6.3.6)
        for <djo@localhost> (single-drop); Tue, 13 Feb 2007 00:57:49
-0800 (PST)
Received: (qmail invoked by alias); 13 Feb 2007 08:55:27 -0000
Received: by maxi (nbSMTP-1.01-cvs) for uid 1000
        (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256/256
bits))
        djon777@gmx.net; Tue, 13 Feb 2007 00:55:52 -0800 (PST)
Date: Tue, 13 Feb 2007 00:55:30 -0800
From: Daniel <djon777@gmx.net>
To: prosolutions@gmx.net
Subject: test
Message-ID: <20070213085049.GA5555@maxi.alay.net>
Reply-To: Daniel <djon777@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
=========================================================================

It looks like the issue is the first From: (the envelope From:?).  In
the failed message through Exim:

MAIL FROM:<djo@maxi.alaya.net>  (I believe this is the envelope from)
From: Daniel <djo@alay.mine.nu>  message From: which gets ignored

The message through nbsmtp:
From djon777@gmx.net
nbsmtp, a much simpler app than Exim, always sends mail correctly
through every mailer when it is provided with the name of the mailer, the
credentials, and the type of auth mechanism to use.  Why is Exim more
complex than this?



Regards,

That'd mean doubling the work to maintain the configuration. Since I
already spend way tooo much time with exim4, this is unlikely to
happen until the Debian exim4 team gets an external offer to maintain
the additional configuration stuff.

That would mean leaving the user in the cold rain should the ISPs mail
server ever change its capabilities. I have seen cases where the ISPs
mail server name was an alias to different machines that were not even
running the same software.

TLS as a client is always used when available. You can trust the docs.
http://pkg-exim4.alioth.debian.org/README/README.Debian.html#TLS

The document cited talks about enabling exim4 to support TLS as a
server, which is a tad more complex since a TLS server needs a
certificate.
http://pkg-exim4.alioth.debian.org/README/README.Debian.html#TLS

I disagree here. Unless an unencrypted wireless LAN is used, I find it
much more dangerous to have the SMTP passwort stored on the client as
clear text.

TLS is always used if available, CRAM-MD5 is used when a clear text
password is available. I am not sure which client authenticator takes
precedence should both clear text and crypted password be available.

Exim v.3 is not policy compliant in this regard. Debconf configuration
is mandatory these days.

GMX imposes many additional hardships on their users. I am not going
to special-case them.

Because there are many cases where this is undesireable. For example,
rewriting the envelope makes it harder to trace back the message to
the originating system. In other cases, it is important that the
envelope generated by the original client stays unmangled.

Please, go ahead, and use nbsmtp.

Because it has always been that way. I do not intend to break working
setups to support GMX' broken setup.

Give better arguments.

Greetings
Marc

No. A lot of mailers allow relaying from associate IP address ranges.
The number of mailers doing so is decreasing, but I say that they're
still the majority.

People who are not able to dump a password into a documented text file
should not be running an MTA in the first place. Please don't play
like things that are not available via debconf are completely
inaccessible.

I disagree.

Enough. Take this to debian-devel or to the tech ctte. I am not going
to address these issues on a short term.

Greetings
Marc

But the fact is that almost all mailers require authentication.  This is a
serious problem with Exim and makes it non-functional for the vast majority
of users.
Not really.  I've used quite a number of mailers over the years including
sbcglobal, earthlink, lycos, several other ISP's, and even my own mailers.
Always the same basic info is required: mailer name and login credentials.
(Whether the auth mechanism needs to be supplied or not depends on the
client mail software).  If you are trying to do complex stuff between
MUA's then it might be tricky, but basically all mail client software
works identical with any mailer once the basic parameters are
configured.


But the user using Thunderbird or kmail or whatever doesn't have this
problem, and they are using the ISP's mailer in the same way.  Why does
it become more complex just because Exim happens to be sending the mail?
I agree that in more complex or customized setups this might not be
desirable but I am speaking about the vast majority of end users who
just want mail to *work*.

retitle #410756 improvement suggestions for default config
severity #410756 wishlist
reassign #410756 exim4-config
user exim4@packages.debian.org
usertags #410756 post-etch
thanks

This is now committed to svn.

Greetings
Marc

This is now committed to svn.

Greetings
Marc

user exim4@packages.debian.org
usertags #410756 - post-etch
tags #410756 wontfix
thanks

A few months later, I still do not see any more changes that would be
appropriate for the exim4 packages at this state of development.

Greetings
Marc

user exim4@packages.debian.org
usertags #410756 - post-etch
tags #410756 wontfix
thanks

A few months later, I still do not see any more changes that would be
appropriate for the exim4 packages at this state of development.

Greetings
Marc

---