summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorIsis Lovecruft <isis@torproject.org>2013-01-17 21:16:12 +0000
committerIsis Lovecruft <isis@torproject.org>2013-01-17 21:16:12 +0000
commit6af8264dfbcaf88be2fb19928f5c5b8f0f78d7cc (patch)
tree5af59c479c03525c36f9ff679422635e236ea12b
parentef35681ac236bfce050fa9bbfb0c7710967911ad (diff)
parent6488cc08c274d98658450fdc4e7cc41a1037cedc (diff)
Merge branch 'develop' into feature-check_recipient
Conflicts: NOTES.md
-rw-r--r--NOTES.md48
1 files changed, 46 insertions, 2 deletions
diff --git a/NOTES.md b/NOTES.md
index 996995c..fd462b1 100644
--- a/NOTES.md
+++ b/NOTES.md
@@ -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.