Fossil SCM
Make the mail task more general, and more obviously a design+research task rather than implementing exactly what is in this file
Commit
316b55a6a6edeee7fe8191366e9ed528788cde5ad57bdaebfd6727ad50c41e4d
Parent
092a7fb796a3b37…
1 file changed
+44
-16
+44
-16
| --- www/gsoc-ideas.md | ||
| +++ www/gsoc-ideas.md | ||
| @@ -8,11 +8,11 @@ | ||
| 8 | 8 | This page applies to the two implementations of Fossil: [the classic Fossil](https://fossil-scm.org) |
| 9 | 9 | and [libfossil](https://fossil.wanderinghorse.net/r/libfossil). The two implementations |
| 10 | 10 | have an identical implementation of the Fossil data model, are 100% compatible in terms of |
| 11 | 11 | data access since they use the same SQL, and are 100% binary compatible in terms of on-disk storage. |
| 12 | 12 | |
| 13 | -## General Features | |
| 13 | +# General Features | |
| 14 | 14 | |
| 15 | 15 | * Improve the documentation history-browsing page to enable selection of 2 arbitrary versions to diff, similar to the [Mediawiki history feature enabled on Wikipedia](https://en.wikipedia.org/w/index.php?title=Fossil_(software)&action=history) |
| 16 | 16 | * Allow diffing of Forum posts |
| 17 | 17 | * Develop a test suite for the draft JSON API in libfossil. This JSON API is a way of integrating many kinds of systems with Fossil |
| 18 | 18 | * Re-implement the draft JSON API in libfossil to use the JSON capability in SQLite, now that SQLite has JSON. This is a large project and would start with feasibility analysis |
| @@ -19,25 +19,53 @@ | ||
| 19 | 19 | * Fossil hooks for pipelines with CI/CD such as static analysis, Buildbot, Gerrit, Travis and Jenkins are not well-documented and may need some further development. Make this work better, with configuration examples |
| 20 | 20 | * Create a [Pandoc](https://pandoc.org) filter that handles Fossil-style Markdown |
| 21 | 21 | * Create a [Pandoc filter that handles Pikchr](https://groups.google.com/g/pandoc-discuss/c/zZSspnHHsg0?pli=1) (Pikchr can be used with many kinds of layout, not just Markdown) |
| 22 | 22 | * Editor integration: [improve the Fossil VSCode plugin](https://marketplace.visualstudio.com/items?itemName=koog1000.fossil) or [create a Fossil plugin for Eclipse](https://marketplace.eclipse.org/taxonomy/term/26%2C31) |
| 23 | 23 | |
| 24 | -## Add code to handle email bounces | |
| 25 | - | |
| 26 | -Fossil can [send email alerts](./alerts.md), but cannot receive email at all. That is a good thing, because a | |
| 27 | -complete [SMTP MTA](https://en.wikipedia.org/wiki/MTA) is complicated and requires constant maintenance. There | |
| 28 | -is one specific case where receiving mail in some fashion would help, and that is for handling bounce messages | |
| 29 | -from invalid email addresses. | |
| 30 | - | |
| 31 | -A proposal for that is to implement a Fossil command such as: | |
| 32 | - | |
| 33 | -``` | |
| 34 | -fossil email -R repo receive_bounce | |
| 35 | -``` | |
| 36 | - | |
| 37 | -This is a non-network-aware Mail Delivery Agent, and would be called by an MTA such as Postfix, Courier or Exim. | |
| 38 | -This command would reject anything that doesn't look like a bounce it is expecting. | |
| 24 | +# Adding Inbound (Receiving) Email to Fossil | |
| 25 | + | |
| 26 | +This task involves designing a new feature and working with Fossil developers to | |
| 27 | +see how it can be feasible in practice. | |
| 28 | + | |
| 29 | +Fossil can [send email alerts](./alerts.md), but cannot receive email at all. | |
| 30 | +That is a good thing, because a complete [SMTP | |
| 31 | +MTA](https://en.wikipedia.org/wiki/MTA) is complicated and requires constant | |
| 32 | +maintenance, so Fossil should not try to be an MTA or ever listen to mail ports | |
| 33 | +on the Internet. | |
| 34 | + | |
| 35 | +There is one specific type of email reception that make sense for Fossil to | |
| 36 | +handle. When there is inbound mail related to a message that Fossil has | |
| 37 | +previously generated with a unique hash, Fossil already knows the context of | |
| 38 | +that message. An unknown sender cannot guess a valid hash although a malicious | |
| 39 | +sender could of course find a way to receive a valid hash and then use that to | |
| 40 | +gain access. The risk of automatic and non-specific spam is very low. | |
| 41 | + | |
| 42 | +A proposal to handle that would be to implement a Fossil command like this: | |
| 43 | + | |
| 44 | +``` | |
| 45 | +fossil email -R repo receive -t TYPE-OF-EMAIL -h HASH | |
| 46 | +``` | |
| 47 | + | |
| 48 | +Where the type of email would be one of a list something like this: | |
| 49 | + | |
| 50 | +* mail_bounce | |
| 51 | +* ticket_reply | |
| 52 | +* forum_reply | |
| 53 | + | |
| 54 | +This command is a non-network-aware [Mail Delivery | |
| 55 | +Agent](https://en.wikipedia.org/wiki/Mail_delivery_agent), and would be called | |
| 56 | +by an SMTP MTA such as Postfix, Courier or Exim. The MTA would need to be | |
| 57 | +configured to recognise that this is an email intended for Fossil, and what | |
| 58 | +type of email, and to extract its hash. People who configure MTAs are used to | |
| 59 | +doing this sort of thing, but no doubt Fossil would include a sample | |
| 60 | +[Postfix mail filter](http://www.postfix.org/FILTER_README.html#simple_filter) and | |
| 61 | +an equivalent driver for Exim. | |
| 62 | + | |
| 63 | +The Fossil command would reject anything that doesn't look like a bounce it is expecting. | |
| 64 | + | |
| 65 | +It is not certain that this design is the best one to address the inbound mail | |
| 66 | +problem. That is why the first part of this task is to find a workable design. | |
| 39 | 67 | |
| 40 | 68 | ## Work relating to the ticketing system in Fossil |
| 41 | 69 | |
| 42 | 70 | The Fossil SCM project uses tickets in a [somewhat unusual manner](https://fossil-scm.org/home/reportlist) |
| 43 | 71 | because the social programming |
| 44 | 72 |
| --- www/gsoc-ideas.md | |
| +++ www/gsoc-ideas.md | |
| @@ -8,11 +8,11 @@ | |
| 8 | This page applies to the two implementations of Fossil: [the classic Fossil](https://fossil-scm.org) |
| 9 | and [libfossil](https://fossil.wanderinghorse.net/r/libfossil). The two implementations |
| 10 | have an identical implementation of the Fossil data model, are 100% compatible in terms of |
| 11 | data access since they use the same SQL, and are 100% binary compatible in terms of on-disk storage. |
| 12 | |
| 13 | ## General Features |
| 14 | |
| 15 | * Improve the documentation history-browsing page to enable selection of 2 arbitrary versions to diff, similar to the [Mediawiki history feature enabled on Wikipedia](https://en.wikipedia.org/w/index.php?title=Fossil_(software)&action=history) |
| 16 | * Allow diffing of Forum posts |
| 17 | * Develop a test suite for the draft JSON API in libfossil. This JSON API is a way of integrating many kinds of systems with Fossil |
| 18 | * Re-implement the draft JSON API in libfossil to use the JSON capability in SQLite, now that SQLite has JSON. This is a large project and would start with feasibility analysis |
| @@ -19,25 +19,53 @@ | |
| 19 | * Fossil hooks for pipelines with CI/CD such as static analysis, Buildbot, Gerrit, Travis and Jenkins are not well-documented and may need some further development. Make this work better, with configuration examples |
| 20 | * Create a [Pandoc](https://pandoc.org) filter that handles Fossil-style Markdown |
| 21 | * Create a [Pandoc filter that handles Pikchr](https://groups.google.com/g/pandoc-discuss/c/zZSspnHHsg0?pli=1) (Pikchr can be used with many kinds of layout, not just Markdown) |
| 22 | * Editor integration: [improve the Fossil VSCode plugin](https://marketplace.visualstudio.com/items?itemName=koog1000.fossil) or [create a Fossil plugin for Eclipse](https://marketplace.eclipse.org/taxonomy/term/26%2C31) |
| 23 | |
| 24 | ## Add code to handle email bounces |
| 25 | |
| 26 | Fossil can [send email alerts](./alerts.md), but cannot receive email at all. That is a good thing, because a |
| 27 | complete [SMTP MTA](https://en.wikipedia.org/wiki/MTA) is complicated and requires constant maintenance. There |
| 28 | is one specific case where receiving mail in some fashion would help, and that is for handling bounce messages |
| 29 | from invalid email addresses. |
| 30 | |
| 31 | A proposal for that is to implement a Fossil command such as: |
| 32 | |
| 33 | ``` |
| 34 | fossil email -R repo receive_bounce |
| 35 | ``` |
| 36 | |
| 37 | This is a non-network-aware Mail Delivery Agent, and would be called by an MTA such as Postfix, Courier or Exim. |
| 38 | This command would reject anything that doesn't look like a bounce it is expecting. |
| 39 | |
| 40 | ## Work relating to the ticketing system in Fossil |
| 41 | |
| 42 | The Fossil SCM project uses tickets in a [somewhat unusual manner](https://fossil-scm.org/home/reportlist) |
| 43 | because the social programming |
| 44 |
| --- www/gsoc-ideas.md | |
| +++ www/gsoc-ideas.md | |
| @@ -8,11 +8,11 @@ | |
| 8 | This page applies to the two implementations of Fossil: [the classic Fossil](https://fossil-scm.org) |
| 9 | and [libfossil](https://fossil.wanderinghorse.net/r/libfossil). The two implementations |
| 10 | have an identical implementation of the Fossil data model, are 100% compatible in terms of |
| 11 | data access since they use the same SQL, and are 100% binary compatible in terms of on-disk storage. |
| 12 | |
| 13 | # General Features |
| 14 | |
| 15 | * Improve the documentation history-browsing page to enable selection of 2 arbitrary versions to diff, similar to the [Mediawiki history feature enabled on Wikipedia](https://en.wikipedia.org/w/index.php?title=Fossil_(software)&action=history) |
| 16 | * Allow diffing of Forum posts |
| 17 | * Develop a test suite for the draft JSON API in libfossil. This JSON API is a way of integrating many kinds of systems with Fossil |
| 18 | * Re-implement the draft JSON API in libfossil to use the JSON capability in SQLite, now that SQLite has JSON. This is a large project and would start with feasibility analysis |
| @@ -19,25 +19,53 @@ | |
| 19 | * Fossil hooks for pipelines with CI/CD such as static analysis, Buildbot, Gerrit, Travis and Jenkins are not well-documented and may need some further development. Make this work better, with configuration examples |
| 20 | * Create a [Pandoc](https://pandoc.org) filter that handles Fossil-style Markdown |
| 21 | * Create a [Pandoc filter that handles Pikchr](https://groups.google.com/g/pandoc-discuss/c/zZSspnHHsg0?pli=1) (Pikchr can be used with many kinds of layout, not just Markdown) |
| 22 | * Editor integration: [improve the Fossil VSCode plugin](https://marketplace.visualstudio.com/items?itemName=koog1000.fossil) or [create a Fossil plugin for Eclipse](https://marketplace.eclipse.org/taxonomy/term/26%2C31) |
| 23 | |
| 24 | # Adding Inbound (Receiving) Email to Fossil |
| 25 | |
| 26 | This task involves designing a new feature and working with Fossil developers to |
| 27 | see how it can be feasible in practice. |
| 28 | |
| 29 | Fossil can [send email alerts](./alerts.md), but cannot receive email at all. |
| 30 | That is a good thing, because a complete [SMTP |
| 31 | MTA](https://en.wikipedia.org/wiki/MTA) is complicated and requires constant |
| 32 | maintenance, so Fossil should not try to be an MTA or ever listen to mail ports |
| 33 | on the Internet. |
| 34 | |
| 35 | There is one specific type of email reception that make sense for Fossil to |
| 36 | handle. When there is inbound mail related to a message that Fossil has |
| 37 | previously generated with a unique hash, Fossil already knows the context of |
| 38 | that message. An unknown sender cannot guess a valid hash although a malicious |
| 39 | sender could of course find a way to receive a valid hash and then use that to |
| 40 | gain access. The risk of automatic and non-specific spam is very low. |
| 41 | |
| 42 | A proposal to handle that would be to implement a Fossil command like this: |
| 43 | |
| 44 | ``` |
| 45 | fossil email -R repo receive -t TYPE-OF-EMAIL -h HASH |
| 46 | ``` |
| 47 | |
| 48 | Where the type of email would be one of a list something like this: |
| 49 | |
| 50 | * mail_bounce |
| 51 | * ticket_reply |
| 52 | * forum_reply |
| 53 | |
| 54 | This command is a non-network-aware [Mail Delivery |
| 55 | Agent](https://en.wikipedia.org/wiki/Mail_delivery_agent), and would be called |
| 56 | by an SMTP MTA such as Postfix, Courier or Exim. The MTA would need to be |
| 57 | configured to recognise that this is an email intended for Fossil, and what |
| 58 | type of email, and to extract its hash. People who configure MTAs are used to |
| 59 | doing this sort of thing, but no doubt Fossil would include a sample |
| 60 | [Postfix mail filter](http://www.postfix.org/FILTER_README.html#simple_filter) and |
| 61 | an equivalent driver for Exim. |
| 62 | |
| 63 | The Fossil command would reject anything that doesn't look like a bounce it is expecting. |
| 64 | |
| 65 | It is not certain that this design is the best one to address the inbound mail |
| 66 | problem. That is why the first part of this task is to find a workable design. |
| 67 | |
| 68 | ## Work relating to the ticketing system in Fossil |
| 69 | |
| 70 | The Fossil SCM project uses tickets in a [somewhat unusual manner](https://fossil-scm.org/home/reportlist) |
| 71 | because the social programming |
| 72 |