Bug#379881: cyrus-imapd-2.2: several oddities about imapd.conf parameters

Ross Boylan ross at biostat.ucsf.edu
Thu Jul 27 17:52:14 UTC 2006


On Wed, 2006-07-26 at 20:05 +0200, Sven Mueller wrote:
> Package: cyrus-imapd-2.2
> Tags 379881 + pending upstream
> Thanks
> 
> Ross Boylan wrote on 26/07/2006 05:34:
> > Package: cyrus-imapd-2.2
> > Version: 2.2.13-3
> > Severity: normal
> > 
> > I've left severity at normal since some of these might affect
> > someone's ability to get the system working.
> > 
> > 1.lmtp_admins
> > The distributed imapd.conf has this
> > # Space-separated list of users that have lmtp "admin" status (i.e. that
> > # can deliver email through TCP/IP lmtp) in addition to those in the
> > # admins: entry above
> > #lmtp_admins: postman
> > 
> > The imapd.conf man page doesn't mention the parameter.
> 
> Right, because there is no lmtp_admins parameter unless you defined an
> "lmtp" service in cyrus.conf. I updated lib/imapoptions to at least
> mention this type of parameters.
The "lmtp" service refers to the service with name "lmtp" or the one
that is substantively lmtp?  As far as I can tell from man cyrus.conf, I
could go
	silly		cmd="lmtpd" listen="localhost:lmtp" prefork=0 maxchild=2

Then I would need "silly_admins"?

More importantly, if I have lmtpunix, do I need lmtpunix_admins?  I
suspect the answer is that, in general I would, but in this particular
case connections through the unix domain socket are preauthorized, so
specifying lmtpunix_admins is pointless.

> 
> > And the upstream upgrade instructions (from 2.1 to 2.2) says "the
> > admins and lmtp_admins configuration options no longer union.  Per
> > service options completely override the default value when they are
> > specified."  This contradicts the comment in the config file, which
> > says they do union.  It is also a bit ambiguous whether the upgrade
> > instructions mean that if you do not specify lmtp_admins, you will get
> > them equal to the admins list.
> 
> Right, if you specify "lmtp_admins" (and have an "lmtp" service in
> cyrus.conf), that service will use the value from "ltmp_admins" instead
> of the one from "admins". This is now also corrected in both
> lib/imapoptions (which is used to generate the imapd.conf manpage) and
> in the imapd.conf file we ship with the package.
So if there is no lmtp_admins, the general value of admins is used?  And
similarly for other services?
> 
> > 2. lmtp_allowplaintext is no longer defined say the upgrade
> > instructions "and must be specified using the service name of your
> > lmtp process if you require a specific value".  The parameter is
> > absent from imapd.conf and its man page, which is good (or at least
> > consistent).  I can't tell what the alternate syntax is, however, or
> > how this relates to the sasl options.
> 
> Every configuration parameter mentioned in imapd.conf can also be
> specified as <service>_<parameter to override <parameter> just for
> <service>.
Wow, it would have been nice for them to mention that in the man page.
I don't think I saw that anywhere (on the man page or elsewhere).

The upstream upgrade instructions do mention something like this in
connection with tls only.

Also, the upstream overview includes this tidbit, which would be helpful
to have in the man page (maybe not verbatim, but the ideas):
"To disallow the use of plaintext passwords for authentication, you can
set allowplaintext: no in imapd.conf. This will still allow PLAIN under
TLS, but IMAP LOGIN commands will now fail."

My reference to the sasl options may have been unclear.  I meant, if you
set lmtp_allowplaintext and sasl_mech_list how do they interact,
perticularly if they contradict each other?  Also, *if* lmtp has an
analogue to IMAP LOGIN, does lmtp_allowplaintext work similarly to the
quoted description at the end of the preceding paragraph?  At any rate,
would SASL authentication still permit PLAIN under TLS, even if
lmtp_allowplaintext is no?

> 
> > 3. Both of the preceding suggest there may be some new syntax for
> > specifying options in imapd.conf (something like the sasl_foo for sasl
> > options), but I don't see it spelled out anywhere.
Already dealt with above.

Thanks for the info.






More information about the Pkg-Cyrus-imapd-Debian-devel mailing list