1 Reply Latest reply on Apr 4, 2014 5:58 AM by mdnramos

    How to block domains that do not exist with MEG ?

    dukebox

      I am looking for a way to block non existent domain (NXDOMAIN) from reaching our users.

       

      Lots of spoofed emails are using non-existent domain and the MEG antispam do not block them all!

       

      I stumble on a fix on 7.5 p2, 7.0p4 that seems to cover this area.

       

      Did anyone have tried this XML config change?

      Is this the settings that will allowed me to block domains that do not exist without causing more harm than good ?

       

      https://kb.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/ 24000/PD24865/en_US/MEG-704-2795100_readme_en_US.pdf

       

      https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/ 24000/PD24991/en_US/MEG_7_5_2_ReleaseNotes.pdf

       

      add an option for the Sender Policy Framework (SPF) check to reject email

      from any domain which does not exist (authoritative NXDOMAIN DNS response

      from the parent domain).

      (Reference: KB78097. Supersedes: 7.0h878182, 7.0h882667, 7.0h894243,

      7.0h903899.)


      Add an option for the Sender Policy Framework (SPF) check to reject

      email from any domain which does not exist (authoritative NXDOMAIN

      DNS response from the parent domain).

      (Reference: KB78097.)

       

      Correct an error where the Sender Policy Framework (SPF) library could return

      an NXDOMAIN (non-existent status) for a valid domain when the SPF record for

      the domain has entries that are non existent and if SPF_FailOnNXDomain /

      PRA_FailOnNXDomain is enabled in the SMTP configuration.

      (Low severity. Reference: KB79079.)

        • 1. Re: How to block domains that do not exist with MEG ?

          Hi dukebox,

           

          The KB articles and documentation you are referring to are accurate.

           

          When using SPF you may need to keep an open mind as to what the outcome will be. The problem is that, in practice, it is quite common to find SPF records that are not set in accordance with the RFC. This comment is also very much the same for SenderID or FCrDNS.

           

          You will also find genuine senders that do not have either type of record availabie, so you need to make a decision on whether your policy will be strict or relaxed about enforcing SPF or any other form of DNS-based sender checks you choose to use.

           

          It is difficult to cover all cases, so the best advice would be to test and monitor any policies you create and see if they cover your requirements.

           

          As an aside, please have a look at this blog post, where I discuss options to prevent spoofing of internal domains with MEG by using permitted/blocked sender lists and SPF.

           

          Hope this helps.