diff options
author | Isis Lovecruft <isis@torproject.org> | 2013-01-17 21:16:12 +0000 |
---|---|---|
committer | Isis Lovecruft <isis@torproject.org> | 2013-01-17 21:16:12 +0000 |
commit | 6af8264dfbcaf88be2fb19928f5c5b8f0f78d7cc (patch) | |
tree | 5af59c479c03525c36f9ff679422635e236ea12b | |
parent | ef35681ac236bfce050fa9bbfb0c7710967911ad (diff) | |
parent | 6488cc08c274d98658450fdc4e7cc41a1037cedc (diff) |
Merge branch 'develop' into feature-check_recipient
Conflicts:
NOTES.md
-rw-r--r-- | NOTES.md | 48 |
1 files changed, 46 insertions, 2 deletions
@@ -2,5 +2,49 @@ # 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? +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. |