Mercurial > dnsbl
diff xml/dnsbl.in @ 407:29d54e7028f6 stable-6-0-54
document dmarc vs dnsbl dkim/spf; switch to . rather than " " for dkim impossible signer
author | Carl Byington <carl@five-ten-sg.com> |
---|---|
date | Thu, 30 Mar 2017 10:26:30 -0700 |
parents | d08da4b058e8 |
children | e018ed19a1cc |
line wrap: on
line diff
--- a/xml/dnsbl.in Fri Mar 17 15:29:40 2017 -0700 +++ b/xml/dnsbl.in Thu Mar 30 10:26:30 2017 -0700 @@ -25,11 +25,12 @@ <refentry id="@PACKAGE@.1"> <refentryinfo> - <date>2017-03-07</date> + <date>2017-03-30</date> <author> <firstname>Carl</firstname> <surname>Byington</surname> <affiliation><orgname>510 Software Group</orgname></affiliation> + <personblurb><para></para></personblurb> </author> </refentryinfo> @@ -297,7 +298,7 @@ milter, then connections from clients that use SMTP AUTH are never subject to greylisting. As part of this per-user greylisting, you need to move the dnsblnogrey file from the config directory to something - like /var/dcc/userdirs/local/dnsblnogrey/whiteclnt so the dccifd will + like /var/dcc/userdirs/dnsblnogrey/whiteclnt so the dccifd will properly ignore greylisting for those recipients that don't want it. </para> </refsect1> @@ -389,11 +390,11 @@ user", and the dns lists are not checked. </para></listitem> <listitem><para> - If the answer is white, mail to this recipient is accepted and the dns - lists are not checked. However, if the envelope from domain name is - listed in the current filtering context (or parents) dkim_from with - "required_signed", - we downgrade this to white answer to unknown. + If the answer is white, and the envelope from domain name is + listed in the current (or parents) filtering contexts dkim_from with + "required_signed", we downgrade this white answer to unknown. + If the answer is still white, mail to this recipient is accepted and the dns + lists are not checked. </para></listitem> <listitem><para> If the answer is unknown, we don't reject yet, but the dns lists will be @@ -533,6 +534,84 @@ </para> </refsect1> + <refsect1 id='dmarc.1'> + <title>DMARC vs dkim_from require_signed</title> + <para> + Note that DNSBL does not implement rfc7489 DMARC. We do not look for + _dmarc.$DOMAIN txt records. + </para> + <para> + The restrictions imposed by require_signed are similar but not + identical to a DMARC reject policy with strict identifier alignment. + When doing SPF fallback, DMARC checks SPF based on the rfc5321 + envelope from domain. DNSBL checks SPF based on the rfc5322 header + from domain. DMARC does not allow mail from good.example.com to be + signed by trusted.example.net - which is a common case. Both Microsoft + Office365 and Google run mail for customer domains, but use DKIM + signing domains in onmicrosoft.com and gappssmtp.com, which are + unrelated to the customer domain. DMARC in the default relaxed + alignment mode allows evil.example.com to sign mail from + good.example.com. DNSBL specifies the exact list of acceptable signing + domains, rather than inferring it from child/parent relationships, or + using public + suffix lists to find the organizational domain. We can block mail + from marketing.example.com while accepting mail from + billing.example.com, even if both are DKIM signed by example.com. + </para> + <para> + Suppose we have: +<literallayout class="monospaced"><![CDATA[ +rfc5321 envelope from = one@evil.example.com +rfc5322 header from = two@good.example.com +authentication results = dkim pass header.d=other.example.com +_dmarc.good.example.com txt = "v=DMARC1; p=reject; adkim:s aspf:s" +dkim_from {good.example.com require_signed other.example.com;} +]]></literallayout> + DMARC would fail the strict identifier alignment. DNSBL allows + us to require DKIM signatures that are unrelated + to the rfc5322 header from, so we accept this message. + </para> + <para> + Suppose we have: +<literallayout class="monospaced"><![CDATA[ +rfc5321 envelope from = one@evil.example.com +rfc5322 header from = two@good.example.com +authentication results = dkim pass header.d=other.example.net +_dmarc.good.example.com txt = "v=DMARC1; p=reject; adkim:r aspf:r" +dkim_from {good.example.com require_signed other.example.net;} +]]></literallayout> + DMARC would pass the relaxed spf identifier alignments, + and would check the evil.example.com spf record. If that + allowed the source ip, DMARC would accept the message. + DMARC would not check DKIM since example.com and example.net + do not pass even the relaxed identifer alignment requirement. + DNSBL allows us to require DKIM signatures that are not + related to the rfc5322 header from domain, so we accept + the message based on the DKIM signature and don't need to + fall back to SPF. + </para> + <para> + Suppose we have: +<literallayout class="monospaced"><![CDATA[ +rfc5321 envelope from = one@evil.example.com +rfc5322 header from = two@good.example.com +authentication results = dkim fail header.d=other.example.net +_dmarc.good.example.com txt = "v=DMARC1; p=reject; adkim:r aspf:r" +evil.example.com txt = "v=spf1 ... including the source ip +good.example.com txt = "v=spf1 ... not including the source ip +dkim_from {good.example.com require_signed other.example.net;} +]]></literallayout> + DNSBL allows us to require DKIM signatures that are not + related to the rfc5322 header from domain. In this case + the signature fails, so we fall back to an SPF check. + We check SPF based on the rfc5322 header from, and + good.example.com does not allow the source ip, so we reject + this message. + DMARC would accept that message based on the SPF check + for evil.example.com + </para> + </refsect1> + <refsect1 id='access.1'> <title>Sendmail access vs. DNSBL</title> <para> @@ -690,11 +769,12 @@ <refentry id="@PACKAGE@.conf.5"> <refentryinfo> - <date>2017-03-07</date> + <date>2017-03-30</date> <author> <firstname>Carl</firstname> <surname>Byington</surname> <affiliation><orgname>510 Software Group</orgname></affiliation> + <personblurb><para></para></personblurb> </author> </refentryinfo>