[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 (firstname.lastname@example.org) 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,
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>.
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
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
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...
/Matti Aarnio <email@example.com>