Re: Idea: making it easier to change DEBCONF_PRIORITY
On Sun, May 28, 2006 at 08:59:31AM +0200, Marc Haber wrote:
> On Sat, May 27, 2006 at 07:38:23PM +0200, Wouter Verhelst wrote:
> > On Thu, May 25, 2006 at 12:21:17PM +0200, Marc Haber wrote:
> > > The problem is that there is no way to automatically determine the
> > > "best choice".
> > I disagree.
> > > There are common setups contradicting each other,
> > Can you name them?
> There are still ISPs not offering a Smarthost.
Does this include residential ISPs?
> And if they offer a smarthost, the range of having authentication, no
> authentication, SMTP AUTH, SMTP after POP, TLS, no TLS, is rather
That sucks. I didn't know that.
However, it doesn't have to be so bad. Apart from the POP-before-SMTP,
exim is able to handle all of them natively; and it handles TLS without
requiring special setup on the client side (provided STARTTLS is
> > > and the only way to reliably determine which setup does apply to the
> > > local situation is to ask the user.
> > I agree; however, I'm not convinced that the way exim4 currently does
> > this is the most appropriate one.
> 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.
The main problem I have with the current setup is that out of the
choices which are currently available, I never know which to pick since
none of them seems to ever work correctly for my purposes. This may be
because I misunderstand them; however, personally I wouldn't call myself
an inexperienced exim user (I've been setting up some fairly complex
exim-based setups), so I wonder how someone who is inexperienced would
> > > Frankly, I don't think that there is any chance of simplifying the
> > > setup of exim4. mail is rocket science,
> > Certainly not. Everone uses it; it's ubiquitous.
> Almost nobody gets it right, and the mechanisms behind it are by far
> the most complex every-day internet service. Even DNS is simpler.
What does that have to do with getting your default setups to do it
> > > and it should be avoided in a newbie setup - they tend to only use web
> > > mail anyway.
> > So, then cater for a default configuration that keeps that in mind.
> That default configuration would be "no local MTA at all".
Which would also result in 'no local cron daemon at all'. And, thus, a
breaking of the expectation established in policy 2.5, section
`important'. I don't think it's a good idea.
I'd think you're better off with a default that has no local domain name
but which uses rewriting.
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4