Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 2 subscribers
  • Views 3922 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

Quick Question - Checking Setup not used to Sophos Terminology

StephanieGelder

So ISP does a basic Pre filter on email then it comes into out email server.

 

So new scenario is ISP Still pre filtering they have two email server and we forward all email to these two servers currently outgoing..... This is before the sophos appliance.

 

Now i'm just setting up the sophos appliance.

Please see my config below.  It's the Trusted Relay i've got a question about.

So:-

Mail Delivery Servers - our existing internal email server with SMTP easy to understand added this fine.

Mail Domains - sorted love this being able to dump different domains to different servers we don't use this yet but it's nice might in the future

Internal Mail Hosts - That's clear i've just put in our internal SMTP server as that has other devices doing similar all going to it.. So instead of configuring on sophos point everything to those and they can shove it all through to Sophos.

(So when live we change our SMTP from forwarding to the two ip addresses of our ISP to forwarding to our Sophos appliance)

Outbound nail Proxy - left this blank.

Trusted Relays!! - THIS IS MY QUESTION Do I put the ip addresses of our ISP's email servers in here. Is this where we forward outbound to from our Sophos server (so that it emulates what we currently are doing in your standard SMTP Server).



This thread was automatically locked due to age.
Parents
  • 0

    Hi Stephanie,

    Trusted relays are designed to allow you to bypass spam checking from an upstream relay.  Normally you should not need any trusted relays, except perhaps in the case you mentioned where you have an upstream mail provider accepting mail and relaying it downstream.

     

    for example:

    an email header may have 2-10 "received by" headers, during the spam checking process we care about whats referred to as the "first un-trusted relay" or fur  if you set your upstream relay as trusted when the appliance is looking at received by headers it will "start" checking from the FUR .. witch will be the last relay before anything that is set as trusted..

     

    received by 4

    received by 3

    received by 2

    received by 1

     

    normally spam checking would start with relay 1 and work its way back.. if relay 1 is your isp doing upstream checking of mail and you set it as a trusted relay .. then spam checking will start with relay 2.

     

    important note:

    setting relays as trusted should be used only if necessary, setting a spammer ip or a range that is used as an open relay will result in all of that mail been delivered.   I recommend only setting it as trusted if you are having issues that can not be resolved by sending in samples to the labs team. 

     

    other cases where trusted relays would be used.

    for an upstream loadbalancer that is tagging emails with its ip. (ideally you don't want your load balancer touching headers) 

    if you had more than one appliance in line.. or say a firewall that's accepting mail with an mta vs port forwarding 25  (anything that port forwards should not be a trusted relay)

     

    ideally you would only want one point of spam checking to avoid having 2 quarantines, and or false positives/negatives between the two or more appliances. 

  • 0 in reply to Red_Warrior

    Thanks.

    We are essentially all within our own private cloud which all our sites are in, which then go out via our ISP.  

    So the email comes into the ISP's anti-spam (which doesn't do a very good job) but it's inital list of those that it completely blocks that we never hear about seems fine.  So we are going to leave that in place but then tell it not to do anything more complicated than that... Then send it onto us on our sophos appliance that is on one of our sites.  So if they cull say 25% of emails in the above method it saves bandwidth as well. 

    Then outgoing our SMTP Server will send to the sophos appliance on our internal network, which will then forward to the two mail gateways hosted by our ISP which won't do any outbound checking and will then just send it on it's way.

    If that makes any sense :)

     

    EDIT: Also as it's a single point of failure if it does die for any reason we can then forward it from our SMTP Server directly to the ISP.  

    I guess I could setup a second virtual appliance as we have the physical one but i think a license as well for virtual

Reply
  • 0 in reply to Red_Warrior

    Thanks.

    We are essentially all within our own private cloud which all our sites are in, which then go out via our ISP.  

    So the email comes into the ISP's anti-spam (which doesn't do a very good job) but it's inital list of those that it completely blocks that we never hear about seems fine.  So we are going to leave that in place but then tell it not to do anything more complicated than that... Then send it onto us on our sophos appliance that is on one of our sites.  So if they cull say 25% of emails in the above method it saves bandwidth as well. 

    Then outgoing our SMTP Server will send to the sophos appliance on our internal network, which will then forward to the two mail gateways hosted by our ISP which won't do any outbound checking and will then just send it on it's way.

    If that makes any sense :)

     

    EDIT: Also as it's a single point of failure if it does die for any reason we can then forward it from our SMTP Server directly to the ISP.  

    I guess I could setup a second virtual appliance as we have the physical one but i think a license as well for virtual

Children
  • 0 in reply to StephanieGelder

    couple of considerations.

     

     

    I recommend one spam solution, in the case where your isp is doing upstream spam checking that means that the original mta is not connecting to your appliance.  The problem with this is that features like delay queue and filtering options such as the blocker require the sending mta to connect to the appliance.  In the case of the blocker, just set it to "use policy level blocking" this will scan all the headers of the email to see if a relay is black listed.. the down side is your accepting the message. vs if the mta is connecting and its blacklisted the connection would be dropped.

    in regards to delay queue, having the sending mta connect is required.

    real easy way to tell, just look at the headers of any email that traveled the expected route from external > internal ..  "received by" headers are in reverse order.. 

    IE

    received by: exchange

    received by: loop back

    received by: appliance

    received by: connecting mta

     

    if all your mail is coming from the isp's IP address then that may hamper delay queue.  Part of that feature collects information about the relay / ip connecting.. so if the only ip connecting is your isp then it wont work very well.

    in this case you would leave delay queue to collect and set the ip as trusted, and change your filtering options to "via policy level"  this will force the appliance to rdns all received by headers and if one of them is blacklisted the mail would be dropped. 

     

    In regards to your licencing..

     

    Email and web appliances are licensed by # of users.. NOT by an amount of VM's installed (I believe the activation limit is 10 per code, if you need more talk to your AM and get another activation code)  

    so for DR I recommend you set up another appliance and build a cluster, then create dns for both of them with equally weighted a records.  This will give you the redundant dns load balancing you need.   As you mentioned you could also set up this infrastructure and keep the appliance powered off if you wish.

     

    last note:

    imo, if your already not happy with the isp spam filtering I would remove it and change the isp rules to port-forward 25 to your forward facing firewall, then port-forward that to the appliance directly.   this will ensure public mtas are connecting and allow you to use the features of the appliance.  It will also ensure you don't have 2 separate quarantines and allow users to manage all of their own spam/bulkmail 

Unfiltered HTML