On Fri, 2006-07-28 at 14:14 +0200, Sven Mueller wrote: > 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 That's interesting; I thought the reference to postman was some leftover, since I didn't see references to that name elsewhere in the docs.
> 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): > What is the significance of a hardcoded name? That even if you name the service by something else in cyrus.conf the hardcoded name will still work? That if you don't use the hardcoded name in cyrus.conf things will fail? > 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 > I was also thinking of the case in which one said allowplaintext: yes but PLAIN was not listed in sasl_mech. > >> 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 Too bad upstream hasn't been able to dedicate a bit more effort to the docs. > -- Ross Boylan wk: (415) 514-8146 185 Berry St #5700 [EMAIL PROTECTED] Dept of Epidemiology and Biostatistics fax: (415) 514-8150 University of California, San Francisco San Francisco, CA 94107-1739 hm: (415) 550-1062 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
