annotation_definitions and other options in imapd.conf
This is from the imapd.conf man page: annotation_definitions: none File containing external (third-party) annotation definitions. - Does anyone have any idea what this means or what this is used for? Also, there are any number of options in imapd.conf that don't make any sense to me. For example, auth_mech: - Isn't this handled by SASL? autocreatequota: If nonzero, normal users may create their own IMAP accounts by creating the mailbox INBOX. The user's quota is set to the value if it is positive, otherwise the user has unlimited quota. - How can you create an INBOX if you don't already have an IMAP account? defaultacl: anyone lrs The Access Control List (ACL) placed on a newly-created (non-user) mailbox that does not have a parent mailbox. - That sounds interesting; how does one go about creating a non-user mailbox? implicit_owner_rights: lkxa: The implicit Access Control List (ACL) for the owner of a mailbox. - Why wouldn't the default include t? It seems weird that owners can deleted mailboxes but not messages by default. ldap_* options - Again, I thought all authentication is handled by SASL? In the debian version of /etc/cyrus.con, this comment appears: # this is only necessary if idlemethod is set to idled in imapd.conf #idled cmd=idled - idlemethod is not a listed option in `man imapd.conf` Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: annotation_definitions and other options in imapd.conf
Quoting Patrick Goetz pgo...@mail.utexas.edu: This is from the imapd.conf man page: annotation_definitions: none File containing external (third-party) annotation definitions. - Does anyone have any idea what this means or what this is used for? Defining custom annotation strings? The server does not let you stuff anything the client wants into the annotation database, it has to be a an approved string. Also, there are any number of options in imapd.conf that don't make any sense to me. For example, auth_mech: - Isn't this handled by SASL? Partially, yes. Don't forget that identity management is AAA - three As, not one. Authorization, Authentication, Accounting. autocreatequota: If nonzero, normal users may create their own IMAP accounts by creating the mailbox INBOX. The user's quota is set to the value if it is positive, otherwise the user has unlimited quota. - How can you create an INBOX if you don't already have an IMAP account? There is no such thing as an IMAP account (again AAA not A). You authenticate to the IMAP server, and then you create a mailbox. Or the administrator has provisioned one of the auto-create patches. defaultacl: anyone lrs The Access Control List (ACL) placed on a newly-created (non-user) mailbox that does not have a parent mailbox. - That sounds interesting; how does one go about creating a non-user mailbox? ??? A shared mailbox. See sharedprefix. I suggest you need to spend a bit more time with Cyrus and general IMAP documentation. implicit_owner_rights: lkxa: The implicit Access Control List (ACL) for the owner of a mailbox. - Why wouldn't the default include t? It seems weird that owners can deleted mailboxes but not messages by default. I've never had occasion to set such a directive. But some people have bizarre configurations or need to support broken e-mail clients. ldap_* options - Again, I thought all authentication is handled by SASL? Again, it is AAA not A. In the debian version of /etc/cyrus.con, this comment appears: # this is only necessary if idlemethod is set to idled in imapd.conf #idled cmd=idled - idlemethod is not a listed option in `man imapd.conf` Is this a current version of Cyrus? I suspect this is a bit of Debian fossilization. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: annotation_definitions and other options in imapd.conf
On 2014-12-03 13:38, Patrick Goetz wrote: This is from the imapd.conf man page: annotation_definitions: none File containing external (third-party) annotation definitions. - Does anyone have any idea what this means or what this is used for? IMAP annotations are described here: http://tools.ietf.org/html/rfc5257 Given it needs client support to be useful at all, probably a case of don't touch it if you don't already know what it means, or were explicitly instructed to. Also, there are any number of options in imapd.conf that don't make any sense to me. For example, auth_mech: - Isn't this handled by SASL? Apparently this can be used to bypass sasl and directly use LDAP/Kerberos for authentication. autocreatequota: If nonzero, normal users may create their own IMAP accounts by creating the mailbox INBOX. The user's quota is set to the value if it is positive, otherwise the user has unlimited quota. - How can you create an INBOX if you don't already have an IMAP account? If you use SASL to plug in external user sources, you can have an IMAP account without already having an inbox. This allows users to create one themselves, otherwise an admin needs to create them for the users (which should be the normal case, to ensure mails are properly received before the user's first login…). defaultacl: anyone lrs The Access Control List (ACL) placed on a newly-created (non-user) mailbox that does not have a parent mailbox. - That sounds interesting; how does one go about creating a non-user mailbox? Via Cyrus' perl module or cyradm, e.g. implicit_owner_rights: lkxa: The implicit Access Control List (ACL) for the owner of a mailbox. - Why wouldn't the default include t? It seems weird that owners can deleted mailboxes but not messages by default. The owner can't even see mails by default! Those are all _administrative_ rights, content access has to be enabled manually (so an administrative account can create user mailboxes without accidentally getting access to their mails, I suppose). ldap_* options - Again, I thought all authentication is handled by SASL? Should be. The (mostly undocumented) PTLoader thingie allows plugging in alternative methods (see above). In the debian version of /etc/cyrus.con, this comment appears: # this is only necessary if idlemethod is set to idled in imapd.conf #idled cmd=idled - idlemethod is not a listed option in `man imapd.conf` It's Debian specific, cf. /usr/share/doc/cyrus-common/README.Debian.gz -- Mit freundlichen Grüßen, / Best Regards, Sven Schwedas Systemadministrator TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz Mail/XMPP: sven.schwe...@tao.at | +43 (0)680 301 7167 http://software.tao.at signature.asc Description: OpenPGP digital signature Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: annotation_definitions and other options in imapd.conf
On 12/03/2014 06:53 AM, Adam Tauno Williams wrote: auth_mech: - Isn't this handled by SASL? Partially, yes. Don't forget that identity management is AAA - three As, not one. Authorization, Authentication, Accounting. So, for example: Authorization would be cm user.username in cyradm Authentication would be saslauthd - PAM -- PAM modules Accounting would be setting permissions and quotas sam user.username write sq user.username N I'm still not seeing where auth_mech or ldap options fit into this, although Sven seems to have offered an explanation: there is some undocumented way of bypassing saslauthd. Which, if true, I suggest is a terrible idea and should be stripped out of the code. Allowing for direct PAM authentication might work somehow, assuming there is a way to handle TLS authentication. Authentication architecture needs to be less, not more complicated in general in the unix/linux world. Anyway, thanks Adam and Sven for the replies -- that was extremely helpful. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: annotation_definitions and other options in imapd.conf
On 12/03/14 12:45 -0600, Patrick Goetz wrote: On 12/03/2014 06:53 AM, Adam Tauno Williams wrote: auth_mech: - Isn't this handled by SASL? Partially, yes. Don't forget that identity management is AAA - three As, not one. Authorization, Authentication, Accounting. So, for example: Authorization would be cm user.username in cyradm Authentication would be saslauthd - PAM -- PAM modules Accounting would be setting permissions and quotas sam user.username write sq user.username N cyrus sasl performs authentication. This would be consistent across all servers which use libsasl, such as imapd or slapd. It's primary purpose is to resolve *who* the authentication identity is and to relieve the server daemon (imapd) of the burden of figuring out how to authenticate users. Authorization is handled primarily outside of libsasl, and is left up to the server which use libsasl (imapd). Authorization involves who can access what, and is configured by way of ACL commands - e.g. john can access jane's mailbox. slapd performs this step via olcAccess configuration. Accounting is the ability to track who accessed what, and when - i.e. syslog output. I'm still not seeing where auth_mech or ldap options fit into this, although Sven seems to have offered an explanation: there is some undocumented way of bypassing saslauthd. Which, if true, I suggest is a terrible idea and should be stripped out of the code. Allowing for direct PAM authentication might work somehow, assuming there is a way to handle TLS authentication. Authentication architecture needs to be less, not more complicated in general in the unix/linux world. auth_mech, as I've used it, figures out who exists in which groups. So if jane has given read permissions to group 'wheel', and john in a member of wheel in /etc/groups, *and* auth_mech is configured to be unix, then john would be granted access to jane's mailbox on request. A big problem with 'auth_mech: unix' is that it's *slow* on systems with lots of groups, due to the way unix searches for group membership (by iterating over all groups in the system). If that happens every time a user attempts to open a mailbox, your system will fall over. The other auth_mechs, such as ldap, can make that process efficient. -- Dan White Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
