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

[Sven Mueller]

Henrique de Moraes Holschuh wrote on 28/07/2006 04:03:
> On Thu, 27 Jul 2006, Ross Boylan wrote:
> 
>>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"?
> 
> Correct.  This can be *really* annoying if you need multiple services that
> need to be configured the same way.  And AFAIK, Cyrus really dislikes it if
> you define two services with the same name.

Well, the master process (cyrmaster) doesn't complain and seems to start
both services when I name both the TCP as well as the unix socket LMTP
services "lmtp". But I can't guarantee that nothing weird happens in the
background just from my quick test.

>>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.
> 
> Worse, it may actually change how the preauthorization is done. I'd need to
> check. Preauthorized just means that if you do nothing, it came from
> "postman".  In particular, if you send a different auth through LMTP, Cyrus
> is supposed to verify and use the new auth, and DENY the delivery if the
> auth is wrong, or does not have the proper ACLs to actually deliver, etc.

According to the lmtpengine source (if I understood it correctly from
quickly browsing it), pre-authentication on the unix socket always
authenticates as "postman" (imap/lmtpengine.c line 1112). So if you specify
lmtpunix_admins: whatever
Nobody can use the unix socket without authenticating. I'm not sure
wether AUTH is fully supported on the unix socket. But I think so since
there is a comment in the source saying "we'll allow commands, but we
still accept the AUTH command".

>>So if there is no lmtp_admins, the general value of admins is used?  And
>>similarly for other services?
> 
> I am not sure expceptions do not exist.

Yes, no exceptions. <servicename>_<option> overrides <option> only for
one service (apart from those defined in cyrus.conf, there are also a
few hardcoded service names, but I forgot which ones that were, deliver
was one IIRC).

<a few minutes later>

I just checked, here is a list of hard-wired service names (they are
identical to the executable name AFAICT except those specifically noted):

arbitron
chk_cyrus
ctl_cyrusdb
ctl_deliver
ctl_mboxlist
cvt_cyrusdb
cyr_expire
deliver (executable: cyrdeliver)
dump (executable: cyrdump)
fetchnews
idled
ipurge
mbexamine
mbpath
ptdump
ptexpire
quota
reconstruct (executable: cyrreconstruct)
squatter
syncnews
tls_prune

>>>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).
> 
> If it is not there yet, I agree it is needed.

As I already said, it isn't in their manpage for imapd.conf and I can't
file a bug report because I can't register with their bugzilla.

> I don't know about how Cyrus IMAP and SASL are behaving re. allowplaintext,
> though, so I won't comment on those (I don't have the time to research that
> in the source code right now, sorry).

allowplaintext is handled like any other configuration directive. You
can override it for each service.

>> 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? 

You mean like when you only list "login" in the sasl_mech_list, but set
allowplaintext to "no"? In that case noone will be able to authenticate
on non-encrypted (i.e. non-TLS/non-SSL) sessions. I know this from
experience rather than from reading the source. The exception is

>> 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?

It should. If it doesn't, it is probably a bug. At least the sasl setups
in lmtpengine and imapd look similar enough so that ths should work.
Note that local unix-socket connections will still automatically be
authenticated as postman if no authentication is tried.

Regards,
Sven

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 188 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-imapd-debian-devel/attachments/20060728/6fbcc120/signature.pgp