> I can't answer all your questions immediately, but as long as smtpd
> can read the certificate it needs for TLS (typically
> /sys/lib/ssl/smtpd-cert.pem), tcp25 can reside in /rc/bin/service.
Hm, /rc/bin/service/tcp25 runs as "none" and where as it can read the
certificate *that's easy), but I could have sworn it could not access the "eve"
factotum (I use "proxima" as a replacement for "bootes", I have a feeling there
are namespace issues that Bell Labs ought to take into consideration - but
that's just a shot in the dark). I fixed it initially by running factotum
within tcp25 and adding the essential keys to it, which improved things, but
left me with the "protocol botch". My problem is that I cannot identify the
casue of the botch (factotum's diagnostics - here's me looking a gift horse in
the mouth - are no adequate) and that is where everything sticks. I don't want
to mess with the factotum code unless it becomes essential, but I guess it's
one route to identify the problem.
> There needs to be a corresponding key in your cpu server(s)'s bootes's
> factotum. We load ours automatically from bootes's secstore factotum
> file. It and our ssh server key look like this:
>
> key proto=rsa service=tls owner=* size=1024 ek=10001 n=[many hex digits] !dk?
> !p? !q? !kp? !kq? !c2?
> key proto=rsa service=sshserve owner=* size=1024 ek=91 n=[many hex digits]
> !dk? !p? !q? !kp? !kq? !c2?
>
The alternative here is:
key proto=rsa service=tls owner=* role=client size=1024 ek=1 n=[...] !dk? !p?
!q? !kp? !kq? !c2?
key proto=rsa service=sshserve size=1024 ek=17 n=[...] !dk? !p? !q? !kp? !kq?
!c2?
key proto=rsa service=tls role=client size=1024 ek=10001 n=[...] !dk? !p? !q?
!kp? !kq? !c2?
Is it possible that the "owner=*" instance is messing up things? It
is a different entry. I note, incidentally:
term% ssh -l proxima huddle
server huddle not on keyring.
add key to keyfile (a), continue without adding key (c), or exit (e)
[e]c
ssh: client authentication failed
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
and especially
term% telnet huddle
connected to tcp!huddle!telnet on /net/tcp/1
user: proxima
authentication failure:auth server protocol botch
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
whereas
term% cpu -h huddle -u proxima
huddle# cat
> Our tcp25 for the outside world ends with this invocation of smtpd:
>
> exec upas/smtpd -n $3 -gD -m /mail/lib/vfsend.alt -c
> /sys/lib/ssl/smtpd-cert.pem
I have:
exec upas/smtpd -d -a -c /sys/lib/tls/virtual.pem -n $3 >[2]
/sys/log/smtpd
or, by shuffling the options:
exec upas/smtpd -n $3 -d -a -c /sys/lib/tls/virtual.pem >[2]
/sys/log/smtpd
now I have to understand all the differences, I do presume that "-c"
implies "-a" or that lack of "-a" makes authentication optional. I
was going to put -gD in later and of course "-d" is temporary (and not
terribly useful, for some reason I need to understand better).
Oh, "-m" is undocumented. I see it selects a mailer with default
"send" and, yes, "-a" makes authentication mandatory, which is as I
want it.
Thank you for all your help.
++L
