On Sun, Apr 20, 2014 at 6:21 AM, Jeremy Harris <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
