Bug#403605: exim4-config: dc_other_hostnames expanded by the shell, corrupting it

Paul Slootman paul at debian.org
Mon Dec 18 16:37:46 UTC 2006


On Mon 18 Dec 2006, Marc Haber wrote:
> 
> On Mon, Dec 18, 2006 at 12:41:27PM +0100, Paul Slootman wrote:
> > Package: exim4-config
> > Version: 4.63-11
> > Severity: grave
> > Justification: email was bounced, thus lost to me
> 
> Bounced e-mail is not lost. Downgrading.

Yes, it is. If you bounce mail e.g. for a sales email address, most
potential customers will move on to another vendor. *I* do not have the
data, hence it is lost.


> > I have a wildcard MX *.wurtel.net, and that's filled in
> > /etc/exim4/update-exim4.conf.conf accordingly:
> > 
> > dc_other_hostnames='wurtel.net : *.wurtel.net : ...'
> 
> not supported, dc_other_hostnames is a list of semicolon-separated
> domain names. No wildcards here.

Why is the field called dc_other_HOSTnames then, if it's DOMAINnames?
I see it as a mapping between MX records and the exim config.
It works just fine as it is, if the script didn't forget to quote the
arguments to echo. Having to implement wildcard MXen in another way just
obfuscates the exim config even more.

> > I recommend that a fix is included in the version that's to go into
> > etch.
> 
> Agreed. Be warned, however, that we might fix this by forbidding * and
> ? in ue4.conf.conf by means of replacing them with "_" after giving a
> warning. Better move your wildcard to the macros made available inside
> exim configuration.

Please give examples, because it's a pain to find out what the macro of
the day is in the exim4-config setup :-(  Is there any definitive list,
with explanations? (A pointer to what exim variable or setting is
involved is fine, or just a chapter number in the exim docs, although
those may be volatile.)


Paul Slootman




More information about the Pkg-exim4-maintainers mailing list