RE: [semi-OT] any test results for SenderID?

[Markley, M. <Mik...@ba...>]

> I think the general idea with the suggestion of the use of ${verify}
is
> that if your site has allocated client certs to all of your users for
use
> in restricting connections or relaying - or as in this example, if
you're
> generating signatures based on a specifically recognized  client cert
- that
> the site also probably signed all those client certs with its own CA
cert.
> 
> I'm interested in more feedback on this. But typically, what I've seen
in
> the field that in the case of client certs, a site (or company) does
not
> typically pay for a public CA to sign all of those client certs, as
this
> could get expensive.

It seems like this could make using ${verify} less useful, then, if
you're not using a CA cert; other organizations' CA certs would be
authenticated while your users' wouldn't (unless, of course, you used a
self-generated CA, but then you still have the original issue).

> That said, with the rise of CAcert.org, perhaps that whole model is
> changing, and we'll have to think of something else. From the filter's
> perspective (whether it be dk- or sid-), it needs a simple macro from
> the MTA which states that message should be dk signed or have the
> sender-id/spf check pass.
> 
> Related specifically to STARTTLS, then, which macro can we use? The
MTA
> has to have some way to identify the specific client cert, without
> getting so detailed as to require the TLS_Clt macros often used in the
> access.db (although it might be also possible to hack some additional
> logic in tls_client to reference the access.db and then set a 
> different macro which would be (certifiably) verifiable to then pass
on to
> dk-/sid-filter).

The only reasonable way to do this may be to allow the admin to specify
an acceptable set of ${cert_issuer}, ${cert_subject}, and/or ${verify}
(with maybe even ${cn_issuer} and ${cn_subject}, with the caveat that
-D_FFR_TLS_1 must be set at compiletime). For example, if ${cert_issuer}
is ou=Your Company *and* ${verify} checks out okay, then allow the user
to pass.

This is probably complicated to explain and use, but it's the only thing
I can think of that would work, short of adding new macros :).

It's probably also worth pointing out that, by default, none of those
macros are passed to envfrom callbacks, which means they'd need to be
added to confMILTER_MACROS_ENVFROM.

- Mike

-- 
Mike Markley <mik...@ba...> 
UNIX Email Admin, Electronic Communications