Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 3 subscribers
  • Views 17637 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Domain Verification

HashimAlsaihati

Hello,

I am evaluating Sophos Email Appliance and I noticed some behavior that is really annoying.

I receive a complaint that a spam was received and when I checked the sender's domain I discovered that there is no MX record what so ever for that domain. 

In another case, the IP is completely different than the published MX record.

I opened a ticket with the support, but unfortunately, they failed to understand what is RDNS and failed to understand the basics of doamin-to-IP verification.

In used to work with UTM and RDNS was applied strictly and it will never allow "wrong" IP to pass.

 

Any suggestion ? do not you think IP-Domain verification is essential ?

Am I missing something ?

 

 

 

 

 

  



This thread was automatically locked due to age.
Parents
  • +1

    It is common for mail to come from a different IP address than the MX record.   In a big environment, one group of machines handles incoming traffic, another group of machines handles outgoing traffic.   SPF may provide a complete list of known senders, MX will not.  I have found so many problems with SPF causing false positives that I do not use it.

    Some email domains are send-only, so they do not publish an MX record.   This may or may not indicate spam.   Some mail receiving systems block a non-MX domain, but not all have this feature.   I have legitimate mail coming daily, from a business partner, which is a send-only domain.

    Requiring Reverse DNS or requiring Forward-confirmed reverse DNS are strategies that have been tried.   IETF does not seem to think them very useful by themselves.   See RFC 7601, the "iprev" section, for a discussion on this topic.  Follow the references in that RFC for more detail.

    I am currently using UTM and another spam filter device together, neither of which understand DMARC.   My next solution must have DMARC support.   SEA is a possibility because it has DMARC, but it seems to lack other of my must-have features, like configuring whitelist rules that require matching on multiple criteria  (e.g. email domain and server RDNS).

    There are vendors doing interesting work on domain reputation, matching known spam sources to other email domains and IP addresses based on Whois information and other data.  

    I think the future of spam filtering is going to be in cloud services, because they will have the best databases of information, including domain reputation.

  • 0 in reply to DouglasFoster

    Thanks Doglas for the useful comment.

    I have been suffering from Spoofing for long time and have opened multiple support cases without a solution that is "Ideal"

    I just recently realized the differentiation between sending-host and receiving-host, and that MX record is used for receiving.

    I used to believe that MX servers are the ones whose IPs are expected to be seen when doing sender verification.   

    RDNS as per the protocol will ONLY check if the sender IP has an MX record, which will, mainly , filter dynamic IPs, and THATS IT.

     

    However,  I believe a good email protection solution should do something beyond that.

    for example:  

    1- The sender's domain in the "Mail From" SMTP header, should match the domain in the PTR for the sending IP (exceptions can be configured manually) 

    2-  The sender in the "FROM" at the DATA  section, should also be verified against the either the "mail-from" or the domain in the PTR.

    The letter one, was PITA and not implemented by many vendors. The bad news is that this Sender is the one displaued to the user when using MS Outlook   

     

    I will read more about 

    Forward-confirmed reverse DNS

     

    Speaking for SEA, I agree that it has some extra features like DMRAC and also control of DKIM verification (like forcing DKIM verification for certain domains like Paypal), But on the other hand lack some features that are already applied in the UTM, like granular exceptions control. 

Reply
  • 0 in reply to DouglasFoster

    Thanks Doglas for the useful comment.

    I have been suffering from Spoofing for long time and have opened multiple support cases without a solution that is "Ideal"

    I just recently realized the differentiation between sending-host and receiving-host, and that MX record is used for receiving.

    I used to believe that MX servers are the ones whose IPs are expected to be seen when doing sender verification.   

    RDNS as per the protocol will ONLY check if the sender IP has an MX record, which will, mainly , filter dynamic IPs, and THATS IT.

     

    However,  I believe a good email protection solution should do something beyond that.

    for example:  

    1- The sender's domain in the "Mail From" SMTP header, should match the domain in the PTR for the sending IP (exceptions can be configured manually) 

    2-  The sender in the "FROM" at the DATA  section, should also be verified against the either the "mail-from" or the domain in the PTR.

    The letter one, was PITA and not implemented by many vendors. The bad news is that this Sender is the one displaued to the user when using MS Outlook   

     

    I will read more about 

    Forward-confirmed reverse DNS

     

    Speaking for SEA, I agree that it has some extra features like DMRAC and also control of DKIM verification (like forcing DKIM verification for certain domains like Paypal), But on the other hand lack some features that are already applied in the UTM, like granular exceptions control. 

Children
No Data
Unfiltered HTML