diff options
Diffstat (limited to 'Notes')
| -rw-r--r-- | Notes | 95 |
1 files changed, 95 insertions, 0 deletions
@@ -0,0 +1,95 @@ +Memory Allocation & Leaks +========================= + +Investigate and fix leaks. +More thorough checking of malloc failures. Where possible fail functions +that check malloc but don't check a subsequent strdup. + +Threads +======= + +Add mutexes to allow multiple threads to access data structures where +reasonable. It would make sense for smtp_start_session() to be able to +run in a different thread from the rest of the program. Having said that, +libESMTP should be safe in a multithreaded program so long as only one +thread accesses one session_t and its children at a time. There are no +global variables so different threads could work on different sessions +simultaneously. + +Headers +======= + +When a header is set and is overriding a header in the message, make sure +a value set in the API is used only once. For example the api defines +"X-My-Header: Hello World" but the message has two instances of X-My-Header: +The resulting message should have only one X-My-Header. + +Implement Disposition-Notification-Options: not very urgent. + +Sender: is required if there are multiple values to From: + +Quoting +======= + +In concatenate.c: Add a version of concatentate() that takes an extra argument +which determines the quoting rules for the string being copied to the buffer. +At present, the application must be careful to supply only characters which are +legal when not quoted which is obviously v. unsatisfactory. + +When supplying a phrase or a mailbox, different quoting conventions apply +do different syntatic elements of the phrase and maibox. A better solution +might be to provide new APIs which quote and combines individual syntatic +elements into a single string which is then passed to the API. + +Auth +==== + +Need to support client side for + EXTERNAL RFC 2222 sect 7.4 (done - untested) + CRAM-MD5 RFC 2195 (done) + PLAIN RFC 2595 (done) + LOGIN undocumented (done) + ANONYMOUS RFC 2245 + OTP RFC 2444 + SecurID RFC 2808 + DIGEST-MD5 RFC 2831 + Kerberos RFC 2222 sect 7.1 + GSSAPI RFC 2222 sect 7.2 + +TLS/SSL +======= + +Since S/MIME or PGP/MIME is the only real way to protect the message, +what does STARTTLS achieve? No real point authenticating the client +to the server in general mail relay. + +Mail submission: is a client certificate useful? + Client certificate provides authentication in conjunction with AUTH + (EXTERNAL) or as an alternative. + +Server certificate: should the client verify the server certificate or +the CA? What is gained by doing so? + Certainty that mail is submitted via an organisation's MTA. Important + if disclaimers / signing etc. is done. + +S/MIME will protect the message content. TLS will protect the envelope. + +Provides protection against passive attack. + +Actually, for the case of mail submission, TLS might be quite useful. +Consider the case of someone from an organisation who is out on the road. +The only MTA they might have access to that will accept mail for relay +is their own organisation's submission server. This first hop may pass +a significant number of routers which could potentially eavesdrop on +the message. The submission server might be responsible for signing +and encrypting messages on the grounds that it is normally accepting +connections from behind a firewall. This is feasible using S/MIME or +PGP MIME. Without encrypting the first hop, this confidentiality measure +is lost. Client certificate is likely to be required in this scenario too. + +Auth + TLS +========== + +Really need a mechanism to manage authentication tokens, e.g. SASL user/pw +combos or X.509 certs/private keys. + |