Mercurial > dnsbl

comparison xml/dnsbl.in @ 407:29d54e7028f6 stable-6-0-54

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
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
comparison
equal deleted inserted replaced
406:ca4ef407588e 407:29d54e7028f6
23 </para> 23 </para>
24 </partintro> 24 </partintro>
25 25
26 <refentry id="@PACKAGE@.1"> 26 <refentry id="@PACKAGE@.1">
27 <refentryinfo> 27 <refentryinfo>
28 <date>2017-03-07</date> 28 <date>2017-03-30</date>
29 <author> 29 <author>
30 <firstname>Carl</firstname> 30 <firstname>Carl</firstname>
31 <surname>Byington</surname> 31 <surname>Byington</surname>
32 <affiliation><orgname>510 Software Group</orgname></affiliation> 32 <affiliation><orgname>510 Software Group</orgname></affiliation>
33 <personblurb><para></para></personblurb>
33 </author> 34 </author>
34 </refentryinfo> 35 </refentryinfo>
35 36
36 <refmeta> 37 <refmeta>
37 <refentrytitle>@PACKAGE@</refentrytitle> 38 <refentrytitle>@PACKAGE@</refentrytitle>
295 milter (dccm), then connections from clients that use SMTP AUTH are 296 milter (dccm), then connections from clients that use SMTP AUTH are
296 still subject to greylisting. If you use the dcc via dccifd and this 297 still subject to greylisting. If you use the dcc via dccifd and this
297 milter, then connections from clients that use SMTP AUTH are never 298 milter, then connections from clients that use SMTP AUTH are never
298 subject to greylisting. As part of this per-user greylisting, you need 299 subject to greylisting. As part of this per-user greylisting, you need
299 to move the dnsblnogrey file from the config directory to something 300 to move the dnsblnogrey file from the config directory to something
300 like /var/dcc/userdirs/local/dnsblnogrey/whiteclnt so the dccifd will 301 like /var/dcc/userdirs/dnsblnogrey/whiteclnt so the dccifd will
301 properly ignore greylisting for those recipients that don't want it. 302 properly ignore greylisting for those recipients that don't want it.
302 </para> 303 </para>
303 </refsect1> 304 </refsect1>
304 305
305 <refsect1 id='definitions.1'> 306 <refsect1 id='definitions.1'>
387 <listitem><para> 388 <listitem><para>
388 If the answer is black, mail to this recipient is rejected with "no such 389 If the answer is black, mail to this recipient is rejected with "no such
389 user", and the dns lists are not checked. 390 user", and the dns lists are not checked.
390 </para></listitem> 391 </para></listitem>
391 <listitem><para> 392 <listitem><para>
392 If the answer is white, mail to this recipient is accepted and the dns 393 If the answer is white, and the envelope from domain name is
393 lists are not checked. However, if the envelope from domain name is 394 listed in the current (or parents) filtering contexts dkim_from with
394 listed in the current filtering context (or parents) dkim_from with 395 "required_signed", we downgrade this white answer to unknown.
395 "required_signed", 396 If the answer is still white, mail to this recipient is accepted and the dns
396 we downgrade this to white answer to unknown. 397 lists are not checked.
397 </para></listitem> 398 </para></listitem>
398 <listitem><para> 399 <listitem><para>
399 If the answer is unknown, we don't reject yet, but the dns lists will be 400 If the answer is unknown, we don't reject yet, but the dns lists will be
400 checked, and the content may be scanned. 401 checked, and the content may be scanned.
401 </para></listitem> 402 </para></listitem>
531 We also scan for excessive bad html tags, and if a &lt;configurable&gt; 532 We also scan for excessive bad html tags, and if a &lt;configurable&gt;
532 limit is exceeded, the mail is rejected. 533 limit is exceeded, the mail is rejected.
533 </para> 534 </para>
534 </refsect1> 535 </refsect1>
535 536
537 <refsect1 id='dmarc.1'>
538 <title>DMARC vs dkim_from require_signed</title>
539 <para>
540 Note that DNSBL does not implement rfc7489 DMARC. We do not look for
541 _dmarc.$DOMAIN txt records.
542 </para>
543 <para>
544 The restrictions imposed by require_signed are similar but not
545 identical to a DMARC reject policy with strict identifier alignment.
546 When doing SPF fallback, DMARC checks SPF based on the rfc5321
547 envelope from domain. DNSBL checks SPF based on the rfc5322 header
548 from domain. DMARC does not allow mail from good.example.com to be
549 signed by trusted.example.net - which is a common case. Both Microsoft
550 Office365 and Google run mail for customer domains, but use DKIM
551 signing domains in onmicrosoft.com and gappssmtp.com, which are
552 unrelated to the customer domain. DMARC in the default relaxed
553 alignment mode allows evil.example.com to sign mail from
554 good.example.com. DNSBL specifies the exact list of acceptable signing
555 domains, rather than inferring it from child/parent relationships, or
556 using public
557 suffix lists to find the organizational domain. We can block mail
558 from marketing.example.com while accepting mail from
559 billing.example.com, even if both are DKIM signed by example.com.
560 </para>
561 <para>
562 Suppose we have:
563 <literallayout class="monospaced"><![CDATA[
564 rfc5321 envelope from = one@evil.example.com
565 rfc5322 header from = two@good.example.com
566 authentication results = dkim pass header.d=other.example.com
567 _dmarc.good.example.com txt = "v=DMARC1; p=reject; adkim:s aspf:s"
568 dkim_from {good.example.com require_signed other.example.com;}
569 ]]></literallayout>
570 DMARC would fail the strict identifier alignment. DNSBL allows
571 us to require DKIM signatures that are unrelated
572 to the rfc5322 header from, so we accept this message.
573 </para>
574 <para>
575 Suppose we have:
576 <literallayout class="monospaced"><![CDATA[
577 rfc5321 envelope from = one@evil.example.com
578 rfc5322 header from = two@good.example.com
579 authentication results = dkim pass header.d=other.example.net
580 _dmarc.good.example.com txt = "v=DMARC1; p=reject; adkim:r aspf:r"
581 dkim_from {good.example.com require_signed other.example.net;}
582 ]]></literallayout>
583 DMARC would pass the relaxed spf identifier alignments,
584 and would check the evil.example.com spf record. If that
585 allowed the source ip, DMARC would accept the message.
586 DMARC would not check DKIM since example.com and example.net
587 do not pass even the relaxed identifer alignment requirement.
588 DNSBL allows us to require DKIM signatures that are not
589 related to the rfc5322 header from domain, so we accept
590 the message based on the DKIM signature and don't need to
591 fall back to SPF.
592 </para>
593 <para>
594 Suppose we have:
595 <literallayout class="monospaced"><![CDATA[
596 rfc5321 envelope from = one@evil.example.com
597 rfc5322 header from = two@good.example.com
598 authentication results = dkim fail header.d=other.example.net
599 _dmarc.good.example.com txt = "v=DMARC1; p=reject; adkim:r aspf:r"
600 evil.example.com txt = "v=spf1 ... including the source ip
601 good.example.com txt = "v=spf1 ... not including the source ip
602 dkim_from {good.example.com require_signed other.example.net;}
603 ]]></literallayout>
604 DNSBL allows us to require DKIM signatures that are not
605 related to the rfc5322 header from domain. In this case
606 the signature fails, so we fall back to an SPF check.
607 We check SPF based on the rfc5322 header from, and
608 good.example.com does not allow the source ip, so we reject
609 this message.
610 DMARC would accept that message based on the SPF check
611 for evil.example.com
612 </para>
613 </refsect1>
614
536 <refsect1 id='access.1'> 615 <refsect1 id='access.1'>
537 <title>Sendmail access vs. DNSBL</title> 616 <title>Sendmail access vs. DNSBL</title>
538 <para> 617 <para>
539 With the standard sendmail.mc dnsbl FEATURE, the dnsbl checks may be 618 With the standard sendmail.mc dnsbl FEATURE, the dnsbl checks may be
540 suppressed by entries in the /etc/mail/access database. For example, 619 suppressed by entries in the /etc/mail/access database. For example,
688 </refentry> 767 </refentry>
689 768
690 769
691 <refentry id="@PACKAGE@.conf.5"> 770 <refentry id="@PACKAGE@.conf.5">
692 <refentryinfo> 771 <refentryinfo>
693 <date>2017-03-07</date> 772 <date>2017-03-30</date>
694 <author> 773 <author>
695 <firstname>Carl</firstname> 774 <firstname>Carl</firstname>
696 <surname>Byington</surname> 775 <surname>Byington</surname>
697 <affiliation><orgname>510 Software Group</orgname></affiliation> 776 <affiliation><orgname>510 Software Group</orgname></affiliation>
777 <personblurb><para></para></personblurb>
698 </author> 778 </author>
699 </refentryinfo> 779 </refentryinfo>
700 780
701 <refmeta> 781 <refmeta>
702 <refentrytitle>@PACKAGE@.conf</refentrytitle> 782 <refentrytitle>@PACKAGE@.conf</refentrytitle>