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.