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
signature.asc
Description: OpenPGP digital signature
