|
| 1 | + |
| 2 | +Security Password |
| 3 | +================= |
| 4 | + |
| 5 | +DBMail now supports a special, separate password. |
| 6 | + |
| 7 | +This separate password allows you to specify behavior when users log into one |
| 8 | +of the DBMail servers using this password. |
| 9 | + |
| 10 | +The use-case for this feature is when you want to provide your users with an |
| 11 | +unobtrusive way to delete all sensitive messages from their accounts, even when |
| 12 | +under duress or active observation. When a lot of messages are affected the |
| 13 | +login delay will be somewhat greater, but other than that, it is impossible to |
| 14 | +tell that anything out of the ordinary has happpened. |
| 15 | + |
| 16 | +Changes |
| 17 | +------- |
| 18 | + |
| 19 | +A small schema-migration is required and provided in |
| 20 | +sql/DRIVER/upgrades/31202.xxx. If you run a version prior to 3.2.0 you will |
| 21 | +have to apply it manually. |
| 22 | + |
| 23 | +The password can be specified with the --security-password argument of |
| 24 | +dbmail-users. The same encryption as for the regular password is used. |
| 25 | + |
| 26 | +The behavior after logging in using this password can be set per user using the |
| 27 | +--security-action argument of dbmail-users. Currently two actions are |
| 28 | +hard-coded, but you can expand them as needed. |
| 29 | + |
| 30 | +Security-action: |
| 31 | +---------------- |
| 32 | + |
| 33 | +0: do nothing. This is also the default behavior. |
| 34 | +1: delete everything. In this case all mailboxes owned by the authenticated |
| 35 | + user are deleted immediately and irretrievably. |
| 36 | +2 and higher: these can be configured through the security_action setting |
| 37 | + in dbmail.conf: |
| 38 | + |
| 39 | +The first two are hard-coded, as said. It is not possible to override them in |
| 40 | +dbmail.conf. Trying to do so will invalidate the entry in dbmail.conf. |
| 41 | + |
| 42 | +An example: |
| 43 | + |
| 44 | +security_action = 2:\Deleted;3:\Flagged \Deleted Important $Important |
| 45 | + |
| 46 | +In this case two additional behaviors are defined. When a user has |
| 47 | +security-action 2, and logs on using the security-password all messages that |
| 48 | +have the \Deleted system-flag set are queued for later deletion by dbmail-util, |
| 49 | +and are immediately inaccessible to the user. |
| 50 | + |
| 51 | +For users with security-action 3, all messages that have the \Flagged or |
| 52 | +\Deleted system flags, or have a user labels 'Important' or '$Important' are |
| 53 | +queued for deletion and are also immediately inaccessible to the user. |
| 54 | + |
| 55 | +Please Note: |
| 56 | +------------ |
| 57 | + |
| 58 | +This feature is not without risks if used casually. Instruct your users |
| 59 | +carefully! Also make sure the security password can never be the same as the |
| 60 | +regular password because in that case it just won't work. |
| 61 | + |
| 62 | +Messages that have been queued for deletion *can*, if required, be restored to |
| 63 | +visibility by a system adminitrator by setting the status field. If the |
| 64 | +security action was set to '1' however, only a restore from backup of the |
| 65 | +database will bring back the deleted mail. |
| 66 | + |
| 67 | + |
| 68 | +LDAP support is currently not available. Please contact [email protected] if you |
| 69 | +required this feature and need LDAP authentication. |
| 70 | + |
| 71 | +#EOF |
0 commit comments