<div dir="ltr"><div>Hi Jeroen,<br><br></div>Sorry for my late reply but I missed your mail ...<br><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/6/19 Jeroen van Meeuwen (Kolab Systems) <span dir="ltr"><<a href="mailto:vanmeeuwen@kolabsys.com" target="_blank">vanmeeuwen@kolabsys.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi there,<br>
<br>
as part of an exercise to make use of event notifications for the purposes of auditing (non-syslog), I wanted to add an event notification for ACL changes.<br>
<br>
Please find attached a patch for your review, an aggregate of the work in dev/acl-change-notification[1]<u></u>.<br>
<br>
I have a couple of things I myself am pondering as well;<br>
<br>
- ACL change notifications are not a part of any RFC as such (but for [2]), and therefore the fields aclSubject / aclRights may need a 'vnd.cmu' prefix? Does the event name "AclChange" need a similar prefix?<br>
</blockquote><div>According to RFC 5423 [1], we should use 'vnd.' to prefix both private event names and private event parameters. However the RFC don't require it (no MUST statement) <br></div><div>I questionned myself too and choosen to prefix by vnd. because Cyrus is mostly compliant with RFC rules.<br>
</div><div>However :<br></div><div> - IMHO I would prefer not prefix with vnd.<br></div><div> - RFC 6648 [2] depreciates such construction for most cases<br></div><div><br>[1] <a href="http://tools.ietf.org/html/rfc5423#section-6">http://tools.ietf.org/html/rfc5423#section-6</a><br>
[2] <a href="http://www.rfc-editor.org/rfc/rfc6648.txt">http://www.rfc-editor.org/rfc/rfc6648.txt</a><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- In relation to the previous consideration, this change (in part) could relate to "Access Control List Changes in IMAP NOTIFY"[2].<br>
<br></blockquote>Unfortunately this section is not really helpful for us to choose event name and event parameters.<br>Notice that IMAP4 ACL Extension [3] is very similar to IMAP STORE : they both use "+" to add rights or flags, "-" to remove rights or flags and nothing to replace existing rights or flags.<br>
Thus, I would suggest to define ACL change like events related to changes in message flags : AclsSet (or maybe AclSet ?) and AclsClear (or maybe AclClear ?) instead of AclChange.<br>I'm OK with "aclSubject", it's shorten than "aclIdentifier".<div>
<br>[3] <a href="http://tools.ietf.org/html/rfc4314">http://tools.ietf.org/html/rfc4314</a><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- The event (type) could perhaps use a separate "event_groups" in imapd.conf(5), but for now I stuffed them under "access" - the fields themselves could also be subject to inclusion in event_extra_params instead, perhaps.<br>
<br></blockquote><div>Semantically it is good to reuse "access" group to enable ACL change notification. The downside is that you will be flooded with Login and Logout notifications which may not interest you. Maybe "mailbox" group would be better. <br>
</div><br></div>Regards,<br><br>Sébastien<br></div></div></div></div>