[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TLS in smtpserver

Eugene Crosser wrote:
> On 12-May-99 at 23:22, Matti Aarnio (mea@nic.funet.fi) wrote:
> >      Yes and no, that is actually a fairly sizable can of worms.
> >      Perhaps with a runtime option (PARAM), which local admin
> >      can decide if that information if ok at the Received: header:
> Sounds very reasonable.  (The same apply to my "whoson" info, BTW).

In CVS now:

* smtpserver/smtpserver.h, smtpserver/cfgread.c,
  smtpserver/smtpserver.c, smtpserver/smtptls.c,
  smtpserver/smtpsmds.c, proto/smtpserver.conf.in:
    Much work again, now to parametrize ways of selectively adding
    pieces of "Received:" header contained commentary information.
    Features: ident, whoson, auth-username, tls-cipher, tls-client-cert
    ( Last one is a FIXME item :-| )

I still don't know how to pull out the client certificate -- sure,
it is in 'peer' item, but *which* of the fields..  (see smtptls.c)
I don't have (myself) any personal "official" client certificate,
which I could use to test the thing.

> > Yep, it isn't 0.9.2b, it is something towards 0.9.3 ...
> The bad thing is that "openssl/ssl.h" is hardcoded in smtpserver.h, so
> you cannot workaround with configure options.  Ideally, configure should
> find the header file and set either -I$(openssl_prefix)/include or
> -I$(openssl_prefix)/include/openssl in the Makefile.  smtpserver.h would
> only have "#include <ssl.h>".

	I did consider that for about entire 2 minutes while reading
	OpenSSL CVS sources a week ago.  Now that 0.9.3a is out, the
	point is moot in my opinnion:


  *) Change #include filenames from <foo.h> to <openssl/foo.h>.
     [Bodo Moeller]

	I would like to see that system to develope into such that
	you can construct a packet with  --prefix=/usr  and have
	everything drop into the standard environment without

	Apparently I need to add some autoconfig tests to autodetect
	the setup in that case --  AC_CHECK_HEADER(openssl/ssl.h)  ?
	I will put that into the TODO list.

> Another question: how do you actually use auth?  Can you, e.g., require
> auth for a specific set of networks?  How do you tell to the policy
> checker that if auth is used, then the source is "trusted"?  Any docs?

	Sorry, docs (manual) is way out of date..

	The problem I begun to solve with the "AUTH LOGIN" facility
	are people who are subscribers at our email services, and
	who want to send email thru our outbound email relay server(s)
	when they are traveling somewhere -- our local networks are
	listed at the policy datasets allowing relaying, but when
	they are somewhere else...

	The policy code contains a simple test: "authentication has
	been successfull ("authuser" variable is non NULL), allow
	open relaying."

	Thinking at that, I would like to offer to crypt the username
	(and ident, and whois, and ..) so that with e.g. abuse evidence
	containing those data, local sysadmin can decrypt the user info,
	but other people can't deduce same information.

	The crypted message should contain 'simple' authentication
	items so that 1) each cryptogram is unique by virtue of e.g.
	a timestamp, 2) it contains some sort of reference id to the
	local system.


	Damn, I just realized that I made ZMailer into a "forbidden to
	(re-)export from USA" item, because now it contains hooks for
	traffic encryption, never mind that it is a side result from
	allowing secure "AUTH LOGIN" with plaintext passwords...

> Eugene

/Matti Aarnio <mea@nic.funet.fi>