Hey there !
I'm trying to validate my DANE records against my SMTP server, but I'm facing something that I cannot understand, because I believe I'm lacking some details about the validation failure : I'm trying to validate smtp.hoggins.fr. It gives me an error on the validator (https://dane.sys4.de/smtp/smtp.hoggins.fr), but I don't know what I need to change about that.
Is there a way to be more verbose about the validation failure ? Maybe some client-side checking I can do manually ?
Thanks.
Hoggins!
Le 07/09/2015 14:09, Hoggins! a écrit :
Hey there !
I'm trying to validate my DANE records against my SMTP server, but I'm facing something that I cannot understand, because I believe I'm lacking some details about the validation failure : I'm trying to validate smtp.hoggins.fr. It gives me an error on the validator (https://dane.sys4.de/smtp/smtp.hoggins.fr), but I don't know what I need to change about that.
Is there a way to be more verbose about the validation failure ? Maybe some client-side checking I can do manually ?
Thanks.
Hoggins!
Well, it seems to be a false alarm. My peer just issued a posttls-finger test with Postfix and the problem seems solved. Maybe there are other validators in the sea ?
Cheers!
Hoggins!
Hoggins! skrev den 2015-09-07 14:53:
Well, it seems to be a false alarm. My peer just issued a posttls-finger test with Postfix and the problem seems solved. Maybe there are other validators in the sea ?
you should just run postfix, not sendmail, hehe
Hoggins! skrev den 2015-09-07 14:09:
Hey there !
I'm trying to validate my DANE records against my SMTP server, but I'm facing something that I cannot understand, because I believe I'm lacking some details about the validation failure : I'm trying to validate smtp.hoggins.fr. It gives me an error on the validator (https://dane.sys4.de/smtp/smtp.hoggins.fr [1]), but I don't know what I need to change about that.
Is there a way to be more verbose about the validation failure ? Maybe some client-side checking I can do manually ?
posttls-finger smtp.hoggins.fr posttls-finger hoggins.fr
both shows here Verified
Le 07/09/2015 15:04, Benny Pedersen a écrit :
Hey there !
I'm trying to validate my DANE records against my SMTP server, but I'm facing something that I cannot understand, because I believe I'm lacking some details about the validation failure : I'm trying to validate smtp.hoggins.fr. It gives me an error on the validator (https://dane.sys4.de/smtp/smtp.hoggins.fr [1]), but I don't know what I need to change about that.
Is there a way to be more verbose about the validation failure ? Maybe some client-side checking I can do manually ?
posttls-finger smtp.hoggins.fr posttls-finger hoggins.fr
both shows here Verified
Thanks Benny !
Cheers!
On Mon, Sep 07, 2015 at 02:09:35PM +0200, Hoggins! wrote:
I'm trying to validate my DANE records against my SMTP server, but I'm facing something that I cannot understand, because I believe I'm lacking some details about the validation failure : I'm trying to validate smtp.hoggins.fr. It gives me an error on the validator (https://dane.sys4.de/smtp/smtp.hoggins.fr), but I don't know what I need to change about that.
Is there a way to be more verbose about the validation failure ? Maybe some client-side checking I can do manually ?
The MX host for a domain is required by DNS standards to not be a CNAME alias.
hoggins.fr. IN MX 1 smtp.hoggins.fr. smtp.hoggins.fr. CNAME mailer.hoggins.fr. mailer.hoggins.fr. A 5.196.52.52
The validator tries to be more strict than some MTAs, because there may be other MTAs for which CNAMEs in MX records are not valid. Change your MX hostname to "mailer.hoggins.fr" or make "smtp" be an "A" record with the same IP addresses as "mail", rather than an alias.
Once you do that, the mail server's TLSA records are fine:
smtp.hoggins.fr. IN CNAME mailer.hoggins.fr. ; NOERROR AD=1 mailer.hoggins.fr. IN NOTMX 0 smtp.hoggins.fr. ; NOERROR AD=1 _25._tcp.mailer.hoggins.fr. IN TLSA 3 1 2 05460499a59db40f0015caffef33eecb6e6121ee35afd87ee4daf88d3f9d0946a2af16db33ba3fb964d15b8a9018ec6b87e54a4aaa804cd31b20f62026d2314e ; passed
The alias may be exposing a minor bug in the web interface, which may be querying for success with "smtp.hoggins.fr", but the ultimate DANE verification is of "mailer.hoggins.fr".
Avoid aliases in email domain names and MX hosts.
Le 07/09/2015 18:02, Viktor Dukhovni a écrit :
I'm trying to validate my DANE records against my SMTP server, but I'm facing something that I cannot understand, because I believe I'm lacking some details about the validation failure : I'm trying to validate smtp.hoggins.fr. It gives me an error on the validator (https://dane.sys4.de/smtp/smtp.hoggins.fr), but I don't know what I need to change about that.
Is there a way to be more verbose about the validation failure ? Maybe some client-side checking I can do manually ?
The MX host for a domain is required by DNS standards to not be a CNAME alias.
hoggins.fr. IN MX 1 smtp.hoggins.fr. smtp.hoggins.fr. CNAME mailer.hoggins.fr. mailer.hoggins.fr. A 5.196.52.52The validator tries to be more strict than some MTAs, because there may be other MTAs for which CNAMEs in MX records are not valid. Change your MX hostname to "mailer.hoggins.fr" or make "smtp" be an "A" record with the same IP addresses as "mail", rather than an alias.
Once you do that, the mail server's TLSA records are fine:
smtp.hoggins.fr. IN CNAME mailer.hoggins.fr. ; NOERROR AD=1 mailer.hoggins.fr. IN NOTMX 0 smtp.hoggins.fr. ; NOERROR AD=1 _25._tcp.mailer.hoggins.fr. IN TLSA 3 1 2 05460499a59db40f0015caffef33eecb6e6121ee35afd87ee4daf88d3f9d0946a2af16db33ba3fb964d15b8a9018ec6b87e54a4aaa804cd31b20f62026d2314e ; passedThe alias may be exposing a minor bug in the web interface, which may be querying for success with "smtp.hoggins.fr", but the ultimate DANE verification is of "mailer.hoggins.fr".
Avoid aliases in email domain names and MX hosts.
Will do, thanks !
Hoggins!
Hi Hoggins.
I am developing an alternative TLSA tester. Viktor Dukhovni has been providing me some assistance and my tester is not fully operational yet.
Both my tester and Viktor's tester say that your mail server smtp.hoggins.fr verifies.
However, in both cases you actually want to validate hoggins.fr (unless you want people to send email to user@smtp.hoggins.fr) Both testers also say that hoggins.fr is acceptable.
If you want to give my tester a try, you can try it at:
http://ec2.simson.net/dane_check.cgi?host=hoggins.fr
It is much more verbose than the sys4.de tester.
Simson
On Sep 7, 2015, at 8:09 AM, Hoggins! fuckspam@wheres5.com wrote:
Hey there !
I'm trying to validate my DANE records against my SMTP server, but I'm facing something that I cannot understand, because I believe I'm lacking some details about the validation failure : I'm trying to validate smtp.hoggins.fr. It gives me an error on the validator (https://dane.sys4.de/smtp/smtp.hoggins.fr https://dane.sys4.de/smtp/smtp.hoggins.fr), but I don't know what I need to change about that.
Is there a way to be more verbose about the validation failure ? Maybe some client-side checking I can do manually ?
Thanks.
Hoggins!
Simson Garfinkel skrev den 2015-09-07 19:02:
http://ec2.simson.net/dane_check.cgi?host=hoggins.fr
It is much more verbose than the sys4.de tester.
just small fail it says try all ips, but it does not test ipv6
else it seems to do good job, thanks for shareing it
On Mon, Sep 07, 2015 at 07:13:55PM +0200, Benny Pedersen wrote:
Simson Garfinkel skrev den 2015-09-07 19:02:
http://ec2.simson.net/dane_check.cgi?host=hoggins.fr
It is much more verbose than the sys4.de tester.
just small fail it says try all ips, but it does not test ipv6
else it seems to do good job, thanks for shareing it
It still needs a bit of work. For example, when a domain is only partly protected (some MX hosts don't have TLSA records), you have to scroll down a bunch to see that, the summary info does not show this.
I would also recommend a cache (like dnsviz.net, and dane.sys4.de), with revalidation only on user request. Don't want to bang away at the most popular sites.
I am in the process of adding ipv6 support.
On Sep 7, 2015, at 1:13 PM, Benny Pedersen me@junc.eu wrote:
Simson Garfinkel skrev den 2015-09-07 19:02:
http://ec2.simson.net/dane_check.cgi?host=hoggins.fr It is much more verbose than the sys4.de tester.
just small fail it says try all ips, but it does not test ipv6
else it seems to do good job, thanks for shareing it
On Mon, Sep 7, 2015 at 1:02 PM, Simson Garfinkel simsong@acm.org wrote:
If you want to give my tester a try, you can try it at:
I appears that you are using "\r\n" in your smtp test commands. "\n" should be sufficient and won't cause logged errors on the systems you are testing.
-Jim P.
Jim,
Thanks for giving my tester a try.
I'm confused by your comment, though. I was pretty sure that SMTP commands were supposed to be followed by CRLF.
Here's the quote from RFC 2821:
2.3.7 Lines
SMTP commands and, unless altered by a service extension, message data, are transmitted in "lines". Lines consist of zero or more data characters terminated by the sequence ASCII character "CR" (hex value 0D) followed immediately by ASCII character "LF" (hex value 0A). This termination sequence is denoted as <CRLF> in this document. Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator. Limits MAY be imposed on line lengths by servers (see section 4.5.3).
In addition, the appearance of "bare" "CR" or "LF" characters in text (i.e., either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool. SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a <CRLF> sequence.
https://www.ietf.org/rfc/rfc2821.txt https://www.ietf.org/rfc/rfc2821.txt
Am I missing something?
On Sep 7, 2015, at 2:28 PM, Jim Popovitch jimpop@gmail.com wrote:
On Mon, Sep 7, 2015 at 1:02 PM, Simson Garfinkel simsong@acm.org wrote:
If you want to give my tester a try, you can try it at:
I appears that you are using "\r\n" in your smtp test commands. "\n" should be sufficient and won't cause logged errors on the systems you are testing.
-Jim P.
On Mon, Sep 7, 2015 at 2:39 PM, Simson Garfinkel simsong@acm.org wrote:
Jim,
Thanks for giving my tester a try.
I'm confused by your comment, though. I was pretty sure that SMTP commands were supposed to be followed by CRLF.
Here's the quote from RFC 2821:
2.3.7 Lines
SMTP commands and, unless altered by a service extension, message data, are transmitted in "lines". Lines consist of zero or more data characters terminated by the sequence ASCII character "CR" (hex value 0D) followed immediately by ASCII character "LF" (hex value 0A). This termination sequence is denoted as <CRLF> in this document. Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator. Limits MAY be imposed on line lengths by servers (see section 4.5.3).
In addition, the appearance of "bare" "CR" or "LF" characters in text (i.e., either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool. SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a <CRLF> sequence.
I think the CRLF vs CR debate is older than the Emacs vs Vi debate. :-) Others can probably speak better as to which to use, I'll stand on the sidelines and share with you Wietse's feelings: :-)
Sep 7 17:04:13 svr2 postfix/smtpd[17157]: improper command pipelining after HELO from ec2-52-7-167-73.compute-1.amazonaws.com[52.7.167.73]: HELO TEST\r\nQUIT\r\n Sep 7 17:04:52 svr2 postfix/smtpd[17157]: improper command pipelining after HELO from ec2-52-7-167-73.compute-1.amazonaws.com[52.7.167.73]: HELO TEST\r\nQUIT\r\n Sep 7 17:18:15 svr2 postfix/smtpd[17634]: improper command pipelining after HELO from ec2-52-7-167-73.compute-1.amazonaws.com[52.7.167.73]: HELO TEST\r\nQUIT\r\n Sep 7 17:21:58 svr2 postfix/smtpd[17871]: improper command pipelining after HELO from ec2-52-7-167-73.compute-1.amazonaws.com[52.7.167.73]: HELO TEST\r\nQUIT\r\n
You probably should also get a matching PTR for 52.7.167.73, you can request that on this form: https://aws.amazon.com/forms/ec2-email-limit-rdns-request?catalog=true&i... (yes I know it says "Request to Remove Email Sending Limitations", but it's also for rDNS requests)
-Jim P.
Hi,
On Mon, Sep 07, 2015 at 02:56:50PM -0400, Jim Popovitch wrote:
I think the CRLF vs CR debate is older than the Emacs vs Vi debate. :-) Others can probably speak better as to which to use, I'll stand on the sidelines and share with you Wietse's feelings: :-)
There is nothing to stand aside here - the RFC is more than clear.
Sep 7 17:04:13 svr2 postfix/smtpd[17157]: improper command pipelining after HELO from ec2-52-7-167-73.compute-1.amazonaws.com[52.7.167.73]: HELO TEST\r\nQUIT\r\n
This has nothing to do with CR+NL (except that it shows up) but with, as the error message says, "improper command pipelining" - you're not supposed to send QUIT right away, but you're supposed to wait for the reply to HELO, and only *then* send the next command (here: QUIT).
Gert Doering -- NetMaster
Thanks. I've fixed the sequencing issue.
On Sep 7, 2015, at 3:03 PM, Gert Doering gert@space.net wrote:
Hi,
On Mon, Sep 07, 2015 at 02:56:50PM -0400, Jim Popovitch wrote:
I think the CRLF vs CR debate is older than the Emacs vs Vi debate. :-) Others can probably speak better as to which to use, I'll stand on the sidelines and share with you Wietse's feelings: :-)
There is nothing to stand aside here - the RFC is more than clear.
Sep 7 17:04:13 svr2 postfix/smtpd[17157]: improper command pipelining after HELO from ec2-52-7-167-73.compute-1.amazonaws.com[52.7.167.73]: HELO TEST\r\nQUIT\r\n
This has nothing to do with CR+NL (except that it shows up) but with, as the error message says, "improper command pipelining" - you're not supposed to send QUIT right away, but you're supposed to wait for the reply to HELO, and only *then* send the next command (here: QUIT).
Gert Doering -- NetMaster -- have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
On Mon, Sep 07, 2015 at 03:47:27PM -0400, Simson Garfinkel wrote:
Thanks. I've fixed the sequencing issue.
There may also be some DNSSEC issues.
The DNS for the TLSA records of openssl.org is fine, modulo a minor inconsistency of NS RRs at the delegation from .org vs. the zone apex.
http://dnsviz.net/d/_25._tcp.mta.openssl.org/dnssec/
And yet the validator claims the TLSA RRset is "bogus", reports failure:
http://ec2.simson.net/dane_check.cgi?host=openssl.org
BOGUS DNS CNAME lookup _25._tcp.mta.openssl.org. = wildcard._dane.openssl.org.
Something's not quite right here...
On Mon, Sep 07, 2015 at 08:10:38PM +0000, Viktor Dukhovni wrote:
And yet the validator claims the TLSA RRset is "bogus", reports failure:
http://ec2.simson.net/dane_check.cgi?host=openssl.orgBOGUS DNS CNAME lookup _25._tcp.mta.openssl.org. = wildcard._dane.openssl.org.
Something's not quite right here...
The issue seems to be systemic:
http://ec2.simson.net/dane_check.cgi?host=nlnetlabs.nl
BOGUS DNS CNAME lookup _25._tcp.nlnetlabs.nl = 3.1.1._dane-both.nlnetlabs.nl.
http://ec2.simson.net/dane_check.cgi?host=spodhuis.org
BOGUS DNS CNAME lookup _25._tcp.mx.spodhuis.org. = _globnix-tlsa.spodhuis.org.
http://ec2.simson.net/dane_check.cgi?host=wizmail.org
BOGUS DNS CNAME lookup _25._tcp.wizmail.org. = _cert301.wizmail.org.
All three are in fact fine. So the handling of TLSA CNAMEs seems to be broken.
Viktor Dukhovni skrev den 2015-09-07 22:46:
All three are in fact fine. So the handling of TLSA CNAMEs seems to be broken.
+1
openssl.net and openssl.net is still same ssl/tls, skip restriction on subdomains then ? (include cname mx check or not)
but if openssl.net and openssl.org make subdomain restriction ?
cname to another tls/ssl is worst, where i think cname to same tls/ssl is still ok
no ?
i am just no expert yet
On Mon, Sep 07, 2015 at 10:59:24PM +0200, Benny Pedersen wrote:
openssl.net and openssl.net is still same ssl/tls, skip restriction on subdomains then ? (include cname mx check or not)
but if openssl.net and openssl.org make subdomain restriction ?
cname to another tls/ssl is worst, where i think cname to same tls/ssl is still ok
Sorry, no idea what you're saying. Much too cryptic.
All I can say about openssl.net is that this domain is not DNSSEC signed, so DANE is out of scope for openssl.net. In any case, it has neither MX records, nor A or AAAA records, so it receives no email.
Viktor Dukhovni skrev den 2015-09-07 23:06:
All I can say about openssl.net is that this domain is not DNSSEC signed, so DANE is out of scope for openssl.net. In any case, it has neither MX records, nor A or AAAA records, so it receives no email.
i should have sayed example.org example.net, it was just a example, not a real problem
On Mon, Sep 07, 2015 at 11:10:59PM +0200, Benny Pedersen wrote:
All I can say about openssl.net is that this domain is not DNSSEC signed, so DANE is out of scope for openssl.net. In any case, it has neither MX records, nor A or AAAA records, so it receives no email.
I should have said example.org example.net, it was just an example, not a real problem.
In that case, if you were asking a question, wanted feedback, or wanted to bring something to list's attention, you might want to post something much less cryptic. If it was just a throw-away remark, no big deal...
Thanks for the email.
According to the report, the CNAME lookup of _25._tcp.open.nlnetlabs.nl is bogus. However it is not, so there is a problem with my CNAME chaser.
I'll check it out.
On Sep 7, 2015, at 4:46 PM, Viktor Dukhovni ietf-dane@dukhovni.org wrote:
On Mon, Sep 07, 2015 at 08:10:38PM +0000, Viktor Dukhovni wrote:
And yet the validator claims the TLSA RRset is "bogus", reports failure:
http://ec2.simson.net/dane_check.cgi?host=openssl.org
BOGUS DNS CNAME lookup _25._tcp.mta.openssl.org. = wildcard._dane.openssl.org.
Something's not quite right here...
The issue seems to be systemic:
http://ec2.simson.net/dane_check.cgi?host=nlnetlabs.nl
BOGUS DNS CNAME lookup _25._tcp.nlnetlabs.nl = 3.1.1._dane-both.nlnetlabs.nl.
http://ec2.simson.net/dane_check.cgi?host=spodhuis.org
BOGUS DNS CNAME lookup _25._tcp.mx.spodhuis.org. = _globnix-tlsa.spodhuis.org.
http://ec2.simson.net/dane_check.cgi?host=wizmail.org
BOGUS DNS CNAME lookup _25._tcp.wizmail.org. = _cert301.wizmail.org.
All three are in fact fine. So the handling of TLSA CNAMEs seems to be broken.
-- Viktor.
Viktor,
Thanks for finding this.
The problem appears to with getdns... it's returning that CNAME lookups are bogus when in fact they are not.
I have filed a ticket request with the getdns team.
https://github.com/getdnsapi/getdns-python-bindings/issues/33 https://github.com/getdnsapi/getdns-python-bindings/issues/33
Until this is resolved, people should not use my validator, as the results are untrustworthy with regards to CNAME records.
Simson
On Sep 7, 2015, at 4:46 PM, Viktor Dukhovni ietf-dane@dukhovni.org wrote:
On Mon, Sep 07, 2015 at 08:10:38PM +0000, Viktor Dukhovni wrote:
And yet the validator claims the TLSA RRset is "bogus", reports failure:
http://ec2.simson.net/dane_check.cgi?host=openssl.org
BOGUS DNS CNAME lookup _25._tcp.mta.openssl.org. = wildcard._dane.openssl.org.
Something's not quite right here...
The issue seems to be systemic:
http://ec2.simson.net/dane_check.cgi?host=nlnetlabs.nl
BOGUS DNS CNAME lookup _25._tcp.nlnetlabs.nl = 3.1.1._dane-both.nlnetlabs.nl.
http://ec2.simson.net/dane_check.cgi?host=spodhuis.org
BOGUS DNS CNAME lookup _25._tcp.mx.spodhuis.org. = _globnix-tlsa.spodhuis.org.
http://ec2.simson.net/dane_check.cgi?host=wizmail.org
BOGUS DNS CNAME lookup _25._tcp.wizmail.org. = _cert301.wizmail.org.
All three are in fact fine. So the handling of TLSA CNAMEs seems to be broken.
-- Viktor.
On Mon, Sep 07, 2015 at 05:19:51PM -0400, Simson Garfinkel wrote:
The problem appears to with getdns... it's returning that CNAME lookups are bogus when in fact they are not.
Pity. In most cases however, you don't need to chase CNAMEs explicitly. Most validating resolvers (as shown by the example you included with the bug report) will automatically chase the CNAME for you.
So when you ask for the TLSA records of _25._tcp.mta.openssl.org, you get a validated response with both the CNAME and the final answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30434 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;_25._tcp.mta.openssl.org. IN TLSA _25._tcp.mta.openssl.org. CNAME wildcard._dane.openssl.org. _25._tcp.mta.openssl.org. RRSIG CNAME 8 5 <...> wildcard._dane.openssl.org. TLSA 3 1 1 687C07FBE2491E7035D0567FA42A503E1F163312B310B47B7B64B911C93ECACA wildcard._dane.openssl.org. RRSIG TLSA 8 4 <...>
So unless the resolver leaves you with a "dangling" CNAME (no answer for the RHS of the CNAME), you generally don't need to explicitly resolve CNAME RRs.
So if you parse the getdns replies for TLSA looks with more care, you don't have to wait for the bug fix. You can "chase" the CNAME expansion within the provided initial reply without additional queries.
On Mon, Sep 07, 2015 at 02:56:50PM -0400, Jim Popovitch wrote:
SMTP commands are <CRLF> terminated.
Sep 7 17:04:13 svr2 postfix/smtpd[17157]: improper command pipelining after HELO from ec2-52-7-167-73.compute-1.amazonaws.com[52.7.167.73]: HELO TEST\r\nQUIT\r\n
The problem is improper pipelining. After STARTTLS, the tester is supposed to send EHLO (not HELO) wait for a reply, and *then* send QUIT<CRLF> (and wait for a reply).
On Mon, Sep 7, 2015 at 3:03 PM, Viktor Dukhovni ietf-dane@dukhovni.org wrote:
On Mon, Sep 07, 2015 at 02:56:50PM -0400, Jim Popovitch wrote:
SMTP commands are <CRLF> terminated.
Sep 7 17:04:13 svr2 postfix/smtpd[17157]: improper command pipelining after HELO from ec2-52-7-167-73.compute-1.amazonaws.com[52.7.167.73]: HELO TEST\r\nQUIT\r\n
The problem is improper pipelining. After STARTTLS, the tester is supposed to send EHLO (not HELO) wait for a reply, and *then* send QUIT<CRLF> (and wait for a reply).
Ahh, thank you for the correction Viktor, Gert too.
-Jim P.
On Mon, Sep 07, 2015 at 02:09:35PM +0200, Hoggins! wrote:
By the way your other domain is the first time my curated list of working DANE-enabled domains has crossed the 2000 mark. Congratulations on helping cross the milestone.
[ There are many more domains that I don't know exist, so the exact number is not really significant, but it is still good to see ongoing adoption. Now all you have to do is not forget to do key rotation right when you next replace your certificate.
https://dane.sys4.de/common_mistakes#3 ]
participants (6)
-
Benny Pedersen -
Gert Doering -
Hoggins! -
Jim Popovitch -
Simson Garfinkel -
Viktor Dukhovni