On Sun, Apr 20, 2014 at 6:21 AM, Jeremy Harris <jgh@???> wrote: > We should also consider promoting some EXPERIMENTAL_FOO features:
>
> - TPDA and PRDR seem noncontroversial.
TPDA seems to be getting exercised, so I think that would be good.
But PRDR, I'm not sure if anybody is actually using it, I'd like to
see a little bit of feedback before we promote an essentially untested
feature to mainline.
> - OCSP is more complicated. We have support for OCSP-stapling
> per. RFC 6066 under OpenSSL, and I've been running this in production
> with no issues. GnuTLS support isn't there, and isn't feasible with
> pre-3.0.0 gnutls libraries (adding this support with the later
> library versions is on my list). This RFC provides for assurance
> of non-revocation of the server cert; it does nothing for the
> rest of the certificate chain.
> There is an rfc (6961) for addressing this; OpenSSL and Mozilla have
> open RFEs for implementations. I've not seen any hint of gnuTLS support.
> We won't be able to do anything with this until either OpenSSL or gnuTLS
> support arrives.
> We don't support traditional (non-stapled) OCSP at all. RFC 6960
> defines the reqest/response protocol and RFC 5280 a certicate extension
> field for publishing an http ocsp responder's URL. I don't think it
> is Exim's place to have all the support required inbuilt, but we
> might wish to provide enough hooks to enable use of external facilities.
> I'm making a start with cert-field extractor expansions (bug 1358);
> also needed would be access to all certs of a chain, and means for
> denying validation of any one such.
> I don't want to touch CRLs with a bargepole.
OCSP is highly evolving, but I have really no opinion, I've not used
any of it yet.
> - Other features, on which I have no opinion:
> -- DCC
No opinion, no experience with it. It's been in exim for quite some
time, anybody using it in production? I prefer that we get feedback
from at least someone using it in production.
> -- SPF
I use this, but it's an external library. [1]
> -- SRS
No opinion. I build it, but I don't use it.
> -- BRIGHTMAIL
No opinion, I don't use it. [1]
> -- DMARC
I use this heavily, and am comfortable with promoting it, but it's an
external library. [1]
> -- REDIS
New, needs to be in at least one full release before it can go main,
and I prefer that we get feedback from at least someone using it in
production. It's also an external library. [1]
> -- PROXY
New, needs to be in at least one full release before it can go main,
and I prefer that we get feedback from at least someone using it in
production.
...Todd
[1] The test suite has to be able to run for all main options. We
have a testdns.exim.org zone that was created with the intention of
being able to provide DNS during test suite runs for parts that cannot
use exim's stub-dns to fake the DNS data. One person suggested
looking at possibly replacing all stub-dns type calls used in the test
suite with live DNS, putting the required records for the entirety of
the test suite in that zone. I personally like that. Is there
anybody who runs the test suite where no network/DNS is available?
That's about the only thing I can come up with that would break that.
Or can resolvers possibly screw up the results to the point that it
can affect the test suite results?
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine
