At 18:08 -0000 Giuliano Gavazzi wrote:
>>It's relatively cosmetic, allowing "P=asmtp A=external:my.client.cert" in
>>your logs so something which might otherwise look like unwanted relaying
>>is explicable.
>
>so, if I understand well, presumably you have a "fake" CA root
>certificate with which you sign a number of client certs that you
>then distribute to your users.
Yes, kind of. We have a hidden root CA which has signed our "server CA"
and our "user CA". The private key of the "server CA" is kept off-line.
The "server CA" signs all our server certs, and the public bit of it is
what our clients get to import. The "user CA" can sign, and (if required)
revoke user certificates, and it is known by (eg in Exim):
tls_verify_certificates = /usr/share/ssl/certs/user-CA.pem
None of our CAs have ever been within a whiff of Verisign etc..
>This is good but also restrict the choice of client software, unless
>these users are only other servers...
One application we have for such certificates is for our users who run
MTAs at home. Stick something like the following very near the top of your
RCPT ACL, and all your users' mails can be relayed through your virus
scanner (and what other "policies" one may have :)
# for MUAs
accept authenticated = *
# for MTAs
accept encrypted = *
verify = certificate
Another application is for off-site backup MXes.
"Send me a client cert I like and I won't bother doing my evil
RBL/fake-Hotmail/etc.. tests on you."
Maybe an RBL to bypass local_scan() too (or choose which ones to invoke
and which ones to skip, if they're going to be DSOs) would be nice in the
long term. The system load on our (primary) mailer goes nuts after a
network outage ;)
Matt
PS I'm not the SSL/TLS expert in my Dept. I hope what I've said is at
least vaguely how It Is.. Our set-up is nowhere near as bullet-proof as
you may have at first thought; it merely provides protection for those who
want it--but there are plenty (who shall remain nameless, but Nigel called
one of them an "idiot" on this list ;) who don't realise that encryption
is neither a subset nor a superset of security!
