5 Replies Latest reply: Sep 20, 2013 5:41 PM by Brad McGarr RSS

    Another sender getting NDRs with 554 Denied error

    manning

      We recently (1 month ago) moved our domain from one IP subnet to another from a different ISP. More or less all went smoothly, except now we can't send to recipients behind McAfee Saas security. I reported this to Saas_falsepositives@mcafeesubmissions.com and was told it had been resolved, but it doesn't appear to be the case. And when I lookup our domain using the TrustedSource site it shows the correct IP for our MX record, but on the Associated IP Addresses tab it also shows an old IP we haven't used in ages listed for our MX A record.

       

      So my question - where is this information being pulled from, and how long before stale records are flushed? DNS all appears to be correct, so I can't imagine reverse lookup is the issue, and we aren't on any RBLs. Does SaaS pull data from (now stale) ARIN entries?

       

      thank you

        • 1. Re: Another sender getting NDRs with 554 Denied error
          Brad McGarr

          Manning,

           

          The 554 Denied error indicates the message scored high for spam based on one or more criteria, including but not limited to IP Reputation and/or Content matching spam fingerprints. This information is pulled from various sources, including propreitary filtering algorithms, information shared in data-sharing networks with ISP partners. There are multiple datapoints that can be causing an issue, and a reset of a spam score does not indicate any permanence as it can re-appear.

           

          McAfee also does block connections from dynamic IPs, or IPs listed as dynamic by the ISP. Each message that is blocked or quarantined must be researched independently because they may or may not be triggering the same rule on the filter, so forwarding the NDR to saas_falsepositives@mcafeesubmissions.com is the best option. Beyond that, any indended recipient's administrator can contact their SaaS support team to open a service request.

          • 2. Re: Another sender getting NDRs with 554 Denied error
            manning

            I submitted another false positive email and got the following repsonse:

             

             

            Thank you for contacting McAfee Messaging Security.

             

            We have adjusted the filters to allow messages to be delivered normally.

             

            The relevant spam fingerprint was for the IP -**.**.**.**.


            So moving our domain to a new subnet was the issue as suspected. Our assigned subnet is static, though perhaps viewed as dynamic? I know we had some lag with other recipients due to rdns mismatch, but those cleared up when stale records flushed. Neither IP nor FQDN are in any blocklists

             

            In any event mail is flowing to recipients who use SaaS now.

             

            Thank you

            • 3. Re: Another sender getting NDRs with 554 Denied error
              Brad McGarr

              Manning,

               

              Just to clarify, the SaaS product does not work in the same manner as traditional DNS Blacklists. The Product is looking for a combination of many items, ranging from IP Reputation and Content, to whether or not the IP is dynamic. The last item, dynamic IPs, are prevented from even connecting, where as Content (and an IP address can be identified as the unique content in a message header) is the most common trigger, followed by IP reputation. This is how a message may be blocked on McAfee for an IP but the IP not be blacklisted anywhere else.

              • 4. Re: Another sender getting NDRs with 554 Denied error
                frankm

                What would be nice to see, is a flow chart on how McAfee processes email.

                • 5. Re: Another sender getting NDRs with 554 Denied error
                  Brad McGarr

                  Frank,

                   

                  A graphical decription would not detail the levels of filtering and the filtering order, both because the detailed information is confidential and proprietary, but also because the order of the stack may be changed at any time during development process.