Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | More random and slightly incoherient notes on the www/emaildesign.md document. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
6f0e0598ce5db256b191be601573cb67 |
User & Date: | drh 2018-06-25 19:26:53.403 |
Context
2018-06-25
| ||
20:26 | Add the file_directory_size() utility function for measuring the number of objects in a directory. ... (check-in: 94e846d2 user: drh tags: trunk) | |
19:26 | More random and slightly incoherient notes on the www/emaildesign.md document. ... (check-in: 6f0e0598 user: drh tags: trunk) | |
18:43 | Fix an extra call to db_end_transaction() in "fossil config pull ticket". ... (check-in: f5eb03f5 user: drh tags: trunk) | |
Changes
Changes to www/emaildesign.md.
1 2 3 4 5 6 7 8 9 10 11 12 13 | Design of Email Notification ============================ This document contains high-level design notes for the email notification system in Fossil. Use this document to get a better understanding of how Fossil handles email notification, to help with doing custom configurations, or to help contribute features. This document assumes expert-level systems knowledge. A separate tutorial for setting up email notification by non-experts will be generated once the email notification system stabilizes. Email notification is under active development as of this writing | | | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | Design of Email Notification ============================ This document contains high-level design notes for the email notification system in Fossil. Use this document to get a better understanding of how Fossil handles email notification, to help with doing custom configurations, or to help contribute features. This document assumes expert-level systems knowledge. A separate tutorial for setting up email notification by non-experts will be generated once the email notification system stabilizes. Email notification is under active development as of this writing (2018-06-25). Check back frequently for updates. Data Design ----------- There are three new tables in the repository database. These tables are not created in new repositories by default. The tables only come into existance if email notification is configured and used. |
︙ | ︙ | |||
131 132 133 134 135 136 137 | * The [/setup_email](/help?cmd=/setup_email) page * The [/subscribers](/help?cmd=/subscribers) page Test command: * The [test-alert](/help?cmd=test-alert) command * The [test-add-alerts](/help?cmd=test-add-alerts) command | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 | * The [/setup_email](/help?cmd=/setup_email) page * The [/subscribers](/help?cmd=/subscribers) page Test command: * The [test-alert](/help?cmd=test-alert) command * The [test-add-alerts](/help?cmd=test-add-alerts) command Email Address Verification -------------------------- When anonymous passers-by on the internet sign up for email notifications, their email address must first be verified. An email message is sent to the address supplied inviting the user to click on a link. The link includes the random 32-byte subscriberCode in hex. If anyone visits the link, the email address is verified. There is no password. Knowledge of the subscriberCode is sufficient to control the subscription. This is not a secure as a separate password, but on the other hand it is easier for the average subscriber to deal with in that they don't have to come up with yet another password. Also, even if the subscriberCode is stolen, the worst that can happens is that the thief can change your subscription settings. No PII (other than the subscriber's email address) is available to an attacker with the subscriberCode. Nor can knowledge of the subscriberCode lead to a email flood or other annoyance attack, as far as I can see. If subscriberCodes are ever compromised, new ones can be generated as follows: > UPDATE subscriber SET subscriberCode=randomblob(32); Perhaps the system be enhanced to randomize the subscriberCodes periodically - say just before each daily digest is sent out? User Control Of Their Subscription ---------------------------------- If a user has a separate account with a login and password for the repository, then their subscription is linked to their account. On the /login page is a link to a page to control their subscription. For users without logins, they can request a link to a page for controling their subscription on the /alerts or /unsubscribe page. The link is sent via email, and includes the subscriberCode. Internal Processing Flow ------------------------ Almost all of the email notification code is found in the "src/email.c" source file. When email notifications are enabled, a trigger is created in the schema (the "email_trigger1" trigger) that adds a new entry to the PENDING_ALERT table every time a row is added to the EVENT table. During a "rebuild", the EVENT table is rebuilt from scratch, and we do not want users to get notifications for every historical check-in, so the trigger is disabled during "rebuild". Email notifications are sent out by the email_send_alerts() function. This function is can be called by having a cron job invoke the "fossil email exec" command. Or, if the email-autoexec setting is enabled, then email_send_alerts() is invoked automatically after each successful webpage is generated. The latter approach is used on the Fossil self-hosting repository. The email_send_alerts() function is a no-op (obviously) if there are no pending events to be sent. Digests are handled by recording the time of the last digest in the "email-last-digest" setting, and only sending a new digest if the current time is one day or later after the last digest. Individual emails are sent to each subscriber. I ran tests and found that I could send about 1200 emails/second, which is fast enough so that I do not need to resort to trying to notify multiple subscribers with a single email. Because each subscriber gets a separate email, the system can include information in the email that is unique to the subscriber, such as a link to the page to edit their subscription. That link includes the subscriberCode. Other Notes ----------- The "fossil configuration pull subscriber" command pulls down the content of the SUBSCRIBER table. This is intended to as a backup-only. It is not desirable to have two or more systems sending emails to the same people for the same repository, as that would mean users would receive duplicate emails. Hence the settings that control email notifications are not transmitted with the pull. The "push", "export", and "import" commands all work similarly |