diff options
author | Isis Lovecruft <isis@torproject.org> | 2013-01-17 18:10:06 +0000 |
---|---|---|
committer | Isis Lovecruft <isis@torproject.org> | 2013-01-17 18:46:26 +0000 |
commit | 6488cc08c274d98658450fdc4e7cc41a1037cedc (patch) | |
tree | 5af59c479c03525c36f9ff679422635e236ea12b | |
parent | 880dc10044a5f8939e15e4b22b1870b53bae4bd7 (diff) |
Adding NOTES.md file for keeping track of design questions and resolution
ideas during development process, as well as ongoing progress for tickets and
feature implementations.
-rw-r--r-- | NOTES.md | 50 |
1 files changed, 50 insertions, 0 deletions
diff --git a/NOTES.md b/NOTES.md new file mode 100644 index 0000000..fd462b1 --- /dev/null +++ b/NOTES.md @@ -0,0 +1,50 @@ + +# Questions # +------------- + +1. What is the lowest available RAM for a target server running a leap_mx? + 1.a. Do we want to store all id_keys and/or aliases in memory? + +2. Asked in discussion section of '''postfix pipeline''' on the [leap_mx wiki +page](https://we.riseup.net/leap/mx) : + + "What is the best way to have postfix write a message to a spool directory? + There is a built-in facility for saving to a maildir, so we could just + specify a common maildir for everyone. alternately, we could pipe to a + simple command that was responsible for safely saving the file to disk. a + third possibility would be to have a local long running daemon that spoke + lmtp that postfix forward the message on to for delivery." + + I think that maildir is fine, but perhaps this will slow things down more + than monitoring a spool file. I would also imagine that if the server is + supposed to stand up to high loads, a spool file I/O blocks with every + email added to the queue. + +3. How do get it to go faster? Should we create some mockups and benchmark +them? Could we attempt to learn which aliases are most often resolved and +prioritize keeping those in in-memory mappings? + +4. What lib should we use for Python + Twisted + GPG/PGP ? + + +## Tickets ## +------------- + +'''To be created:''' + +ticket for feature-alias_resolver_couchdb_support: + + o The alias resolver needs to speak to a couchdb/bigcouch + instance(s). Currently, it merely creates an in-memory dictionary + mapping. It seems like paisley is the best library for this. + +ticket for feature-check_recipient: + + o Need various errors for anything that could go wrong, e.g. the recipient + address is malformed, sender doesn't have permissions to send to such + address, etc. + o These errcodes need to follow the SMTP server transport code spec. + +ticket for feature-virtual_alias_map: + + o Get the recipient's userid from couchdb. |