HOME

sh-3ll 1.0
Current File : //usr/share/doc/libesmtp/Notes
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.