Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 5 subscribers
  • Views 23285 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

Allow/Exclude Non-Existent Domain

AndrewDorre

We have an email that is sent by one of our parent groups using a mainframe batch job. The email domain does not exist, and so it is being discarded on arrival.

Is there a way to do this without turning off the "Block mail from non-existent domains" option in the SMTP Options area? That would be way too broad and probably a huge security risk.

I'm including a screenshot of the message log, from one of the blocked emails.

And here is the "View log details" info. I removed the email addresses and IP's because they're not relevant:

2017-02-07 09:37:54 mx3 postfix/smtpd[1682]: NOQUEUE: reject: RCPT from mail-dm2gcc01on0061.outbound.protection.outlook.com[--.---.---.--]: 450 4.1.8 <-----@------.--->: Sender address rejected: Domain not found; from=<-----@---------.---> to=<-------@-----------.---> proto=ESMTP helo=<gcc01-dm2-obe.outbound.protection.outlook.com>



This thread was automatically locked due to age.
  • 0

    Evening Andrew,

    I don't believe what you want to do is possible. The setting to block emails from non-existent domains is set at the perimeter, before rules are processed, so the email is dropped before any rule allowing the non-existent domain could be run.

    Hopefully someone from Sophos will tell me I'm an idiot and explain how it can be done.

    Regards,

    Neil.

  • 0

    I have the same problem.  Did you ever find a solution?

  • 0 in reply to dhbennett

    Unfortunately no. Oddly enough, we just spoke to the group in charge of that email address with a non-existent domain, and this time they just decided to change the address to a real domain.

     

    Would have been nice if Sophos replied though, or provided a workaround, like a whitelist function for this.

  • +1

    Unfortunately DNS is really an RFC issue.. doping mail from domains/mta's with no dns is very common with mail devices.  In this case that check box is a postfix feature.. so the connection is been dropped at connection level before any message is received.   Hence creating a policy would not work.  The feature its self is "all or nothing" and I defiantly do not recommend disabling it. 

    really there are two choices.

    #1 - add a mx/a record for the mta sending the mail so that it resolves properly. (this is the "best" solution)

    #2 - add the ip of the mta the mail to the internal mail hosts.  This will allow your notification server to "relay" mail .. the appliance will think mail coming from this host is from internal > external .. but will still work fine for you.  (so if you were to make a data control rule, it would be on the outbound tab vs the inbound) 

     

    on a side note:

    The appliance will blindly accept and relay all mail from ip's listed as "internal mail hosts" to the internet ... so adding the ip or a cidar range could be a potential issue and is why I recommend option 1

     

  • 0 in reply to Red_Warrior

    Ok, thank you for the response!

  • 0 in reply to Red_Warrior

    #1 - add a mx/a record for the mta sending the mail so that it resolves properly. (this is the "best" solution)

    Is this correct? Can you confirm that only one of A/MX record need in this case?

    I tried this but SEA accept message only if both records present in DNS Forward Lookup Zone and PTR-record in Reverse Lookup Zone.

  • 0 in reply to Denis Rotar

    that's correct, you would need both.. an mx record for the domain and an a-record for the server sending.

    then all of that would have to be reversible.

    the SEA will query the host name of the mta that is connecting to it, it will then look up the domain its been presented with.. that will need to reverse dns correctly.  Chances are this server may not have a SMTP banner configured, it could be incorrect or something totally different.. It may not be using one at all or has $hostname as its banner... this may in-turn not rdns properly if it wasn't set up.

     

    everything will have to jive and work properly.. if it fails, then the connecting would be dropped as expected.

Unfiltered HTML