Using terms like 'break' is inappropriate here. If the protocol does not have the desired behavior then it is being fixed, not broken.
The whole point of IETF protocols is that you can extend them and adapt them. If the protocol gets in the way, fix the protocol. One option here would be to define a new flag to announce a client cert availability on some different basis. Another would be to publish the cert through DKIM. On Thu, Jan 10, 2013 at 3:26 PM, Martin Rex <[email protected]> wrote: > The problem with Client certs for smtpd is that basically you will > have to violate the TLS protocol to not run into connection failures. > > SSLv3 and TLSv1.0 *REQUIRE* the TLS server to send a list > of (acceptable) certificate_authorities (distinguished names) > in the CertificateRequest handshake message, and sending an empty > list is a protocol violation. While there was a silent change > in the CertificateRequest PDU definition in TLSv1.1 (rfc4346) > that appears to allow an empty list, there are no semantics > defined in TLSv1.1 and TLSv1.2, so this PDU change is a defect > in the TLS v1.1+v1.2 spec and must not be used. > > http://tools.ietf.org/html/rfc2246#section-7.4.4 > > opaque DistinguishedName<1..2^16-1>; > > struct { > ClientCertificateType certificate_types<1..2^8-1>; > DistinguishedName certificate_authorities<3..2^16-1>; > } CertificateRequest; > > > If you really believe that you want to violate the TLS protocol > in this fashion, please state > > (a) that you're intentionally violating the TLS protocol > (b) what the exact desired semantics of this behaviour are > > -Martin > > > James Cloos wrote: > > > > TF> Client certificates? I thought they were nonexistent for mail to MXs. > > > > Yes. An example from lists.debian.org: > > > > Received: from bendel.debian.org (bendel.debian.org [82.195.75.100]) > > (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) > > (Client CN "bendel.debian.org", Issuer "ca.debian.org" (verified > OK)) > > by pao.uu.jhcloos.net (Postfix) with ESMTPS id 1CAFE23CC56 > > for <[email protected]>; Tue, 8 Jan 2013 06:22:46 +0000 (UTC) > > > > and from mail from a goog group: > > > > Received: from mail-ie0-f191.google.com > > (mail-ie0-f191.google.com[209.85.223.191]) > > (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) > > (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" > (verified OK)) > > by pao.uu.jhcloos.net (Postfix) with ESMTPS id 3D04E23C010 > > for <[email protected]>; Thu, 10 Jan 2013 07:04:25 +0000 (UTC) > > > > OTOH, mail from a list at alioth.debian looks like: > > > > Received: from wagner.debian.org (wagner.debian.org [217.196.43.132]) > > (using TLSv1 with cipher AES256-SHA (256/256 bits)) > > (Client did not present a certificate) > > by pao.uu.jhcloos.net (Postfix) with ESMTPS id 9498E23C034 > > for <[email protected]>; Thu, 10 Jan 2013 07:58:00 +0000 (UTC) > > > > I have pf configured to request but not require a cert. > > > > Primarily just to see what they do. > > > > TF> ... I turned on an option for the server to request a client > > TF> certificate. ... This was supposed to be optional, but many clients > > TF> treated it as a demand and aborted the connection, which was not > > TF> what I wanted. > > > > I've not seen any such issue since I turned on the requests. > > > > I just added smtpd_tls_ask_ccert = yes to my postfix main.cf. > > > > -JimC > > -- > > James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6 > > _______________________________________________ > > dane mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dane > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane > -- Website: http://hallambaker.com/
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
