[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SSL/TLS client?
( I have again learned what it is to be a meeting animal ... I can
not do my own work/interests, when I have to push others around.
I am sure Dilbert has a strip or two about the topic ... )
( A song-contest final at Helsinki Opera is presented live at TV,
sopranos doing Mozart :) I rather listen good HIFI sound at home,
than sit at the Opera with people around me... And I can hack at
the same time too ;) )
On Wed, Aug 18, 1999 at 01:39:43PM +0000, Alexey Lobanov wrote:
> > And I don't think anybody has given a good reason for all that work yet...
> May I ask why? Seems, the "last mile" (MUA - provider) communications
> are (normally) more safe than long-distance ones.
As Andy said, circa a month ago there was a brief discussion about
this at the ZMailer list - findable from the yearly list archive file.
( ftp://ftp.funet.fi/pub/unix/mail/zmailer/listlog/zmailer )
I was then running around to prepare for sailing vacation, or already
(motivation/need discussion aside)
Anyway, to do it one must rework current FILE* abstraction based
SMTP/TCP socket write buffering to use some other means. You can't
tell STDIO library (except perhaps at glibc 2.x) that instead of
write(2) one should use function xyz() (and likewise for read(2)).
Thus you can't easily use low-level SSL/TLS SSL_read() and SSL_write()
routines underneath the standard-IO FILE* abstraction.
(If you could, it would be wonderfull..)
Because ZMailer isn't intended to be tightly coupled with some particular
version of glibc, rather be usable at *any* UNIX (-like) platform, we
can't use such tricks.
That pre-requisite aside: Doing SSL/TLS client is fairly trivial
once that buffering stuff is reworked.
When doing the rework, I would suggest doing also a heavy handed code
split. The smtp.c is now circa 5100 lines long. I think it is a high
time to split the beast into N files. (Like I did years ago to smtpserver)
Also, I think I (or some other contributor) need to write a ZFILE*
abstraction which can do at least all buffered write things what
fwrite()/putc()/fputs() (and possibly fprintf()) use.
Adding there then a method to hook on arbitary backend stream (e.g.
thin wrapper to use write(2) to a fd, or SSL_write() to a SSL object,
or ..) would make it pretty generic.
/Matti Aarnio <email@example.com>