[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: per-person SMTP client



On Wed, Jan 26, 2005 at 01:59:45PM +0100, martin f krafft wrote:
> also sprach Craig Sanders <cas@taz.net.au> [2005.01.26.1249 +0100]:
> > > However, so far I have been using 1 year expiration on the
> > > certificates, and it's a major pain to get new certificates out to
> > > each of about 280 clients,
> > 
> > so use 5 year or 10 year expiration.
> 
> What's the advantage of using that over passwords?

only that i've found sasl to be extremely difficult to set up (and very poorly
documented).  setting up certificate-based relaying is quite easy.

also, i just don't like the sasl code - whereas i do like the postfix/tls
code, it's well-written and elegant.

and pop-before-smtp, while it works and works well, is an ugly kludge.

> > installing the cert is up to the end-user, unless their machine is
> > a *nix/postfix (or whatever) box that you have root on.
> 
> I am root on their machines. If they were all accessible at all
> times, no problem. As it stands, I get a call from xyz behind
> a fascist firewall in need of a new certificate. What to do if
> I cannot SSH into the box? Hand them the root password? I don't
> think so...

a couple of possibilities spring to mind:

write a script that will fetch and install a new certificate, and give
them sudo access to that.

or a script which sets up an ssh tunnel or similar that you can use to login.
when they need a new cert (or any other help from you), you get them to run
that script with sudo.  tunnel it over port 80 or port 443 or some other port
likely to be open in any firewall.  443 is probably best, then you can write
an alternate version which copes with proxying (even transparent proxying) by
issuing a "CONNECT host:443" instruction to the proxy.

of course, both of these (and most other possible solutions) require advance
planning.

> > e.g wghat exactly is a /usr/sbin/sendmail provider? and how does
> > it differ from having an MTA on the client host? or even an
> > smtp-capable MUA?
> 
> I want a /usr/sbin/sendmail which uses ~/.sendmailrc or the like of
> the calling user to determine what to do with the message. Some
> users may want to use SASL, others may want to use a local
> forwarder...

ah.  now i understand what it is you want. ok, you want an MTA which is
directly controllable by end-users.

i don't think you'll find any.

you might be able to hack one of the simple smtp agents like ssmtp
to do that.  

alternatively, modify the mini-sendmail script (which is a replacement for
/usr/sbin/sendmail that sends all mail via smtp rather than by local
submission).  the trouble with this is that you'd have to implement your own
queueing system - otherwise, the user wouldn't be able to send mail when the
relay was unreachable.

hacking ssmtp would be better because it already has the ability to queue
mail.

craig

-- 
craig sanders <cas@taz.net.au>           (part time cyborg)



Reply to: