locked
Block my own domain at the Edge? RRS feed

  • Question

  • We are seeing an increase in the number of spam messages getting into our system that appear to be from internal clients, (user@mydomain.com), but which are obviously being spoofed from the outside. i do know that spammers will insert a fake address on the from line, while placing another in the MAIL FROM SMTP in the message header.

    We previously had an appliance at the edge, and didn't have this problem, however since migrating to Exchange 2007 with a pair of edge servers at the perimeter, we have many more of these type of spam getting in.

    We are currently at Exchange 2007 SP1 code level with Forefront running at the edge and hub and mailbox.

    I have been having my users place their own addresses into the blocked senders in Outlook, and that is a remedy on an individual basis.

    At one point there was a discussion about setting our own domain as a blocked sender on the internet facing Edge servers. I believe that the information we got back from MS stated that this could have unintended consequences.

    What is the current recommendation regarding blocking our own domain at the edge?

    It would seem that this would eliminate this vector for unwanted messages gaining entry to the system. Would this have any effect on internal email flow?

    The internal users should be unaffected sending out, as the anti spam rules apply inbound.

    or should I pursue other means of blocking this traffic?

     

    Thank you

     

     

    Thursday, August 5, 2010 7:31 PM

Answers

  • Thank you everyone for the input.

    This fix has been complicated by the fact that our client population has varied requirements and practices already in place.

    We are a local government organization with 30+ client departments. There are web sites which have begun life hosted in our own web farm, then have been transferred to external hosting solutions, while retaining the need to send out acknowledgements and receipts signed as if they were coming from our internal domain. Other client departments have implemented vendor solutions which require desktop workstations, (where users log in and browse the internet), to serve as SMTP servers also, neither of which are ideal in my view.

    However, we have to deal with what is in place, and address changing the process later.

    The primary complaint I hear is " This spam stuff is getting increasingly graphic and offensive, and it appears to be coming from me"

    While having the users put their own email address into the Blocked Senders List was having some effect, the process was manual.

    I had tested using the Anti-spam sender Filtering to block out domain, but the options are only stamp or reject. I couldn't be sure valid email was not being thrown out.

    I have since moved that function to a transport rule, where any email from outside that contains our domain name in the from field is quarantined, allowing me to review blocked messages and create exceptions for valid ones, then release them for delivery.

    So far, this is functioning ok.

    While we would like to move forward with SPF and Sender ID, or another appliance based solution, those will be projects and will take time to work through the Change Control committee.

     

    Thank you all again for the input.

    It is helpful to hear how others are approaching the same issue.

     

    Nova

    • Marked as answer by Novaphreek Wednesday, August 11, 2010 9:46 PM
    Wednesday, August 11, 2010 9:42 PM

All replies

  • On Thu, 5 Aug 2010 19:31:21 +0000, Novaphreek wrote:
     
    >
    >
    >We are seeing an increase in the number of spam messages getting into our system that appear to be from internal clients, (user@mydomain.com), but which are obviously being spoofed from the outside. i do know that spammers will insert a fake address on the from line, while placing another in the MAIL FROM SMTP in the message header.
    >
    >We previously had an appliance at the edge, and didn't have this problem, however since migrating to Exchange 2007 with a pair of edge servers at the perimeter, we have many more of these type of spam getting in.
    >
    >We are currently at Exchange 2007 SP1 code level with Forefront running at the edge and hub and mailbox.
    >
    >I have been having my users place their own addresses into the blocked senders in Outlook, and that is a remedy on an individual basis.
    >
    >At one point there was a discussion about setting our own domain as a blocked sender on the internet facing Edge servers. I believe that the information we got back from MS stated that this could have unintended consequences.
    >
    >What is the current recommendation regarding blocking our own domain at the edge?
     
    Why not start by use SPF or SenderID? You hlp not only yourself, but
    everyone else that receives messages from spoofed addresses.
     
    >It would seem that this would eliminate this vector for unwanted messages gaining entry to the system. Would this have any effect on internal email flow?
     
    That depends on whether you allow people to use their work e-mail
    address to send SMTP messages from outside the confines of your
    intrnal LAN.
     
    >The internal users should be unaffected sending out, as the anti spam rules apply inbound.
    >
    >or should I pursue other means of blocking this traffic?
     
    Try the SPF/SenderID rout first.
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Friday, August 6, 2010 2:04 AM
  • Hello Novaphreek, 

    Install the Anti Spam on the edge server and configure it

    Content Filter --> Action Tab - 8 & 7

    IP block list providers --> Spamhaus - Lookup domain: zen.spamhaus.org

    Recipient Filtering --> Block Recipient Tab - Check message block sent

    Sender filtering --> Block senders tab - Check Block messages from blank sender  

    Sender filtering (Add the Self Domain)

    After that restart the Transport Service on the server.

     

    o    => And then updated the AntispamUpdates

    Enable-AntispamUpdates -Identity <SERVERNAME> -IPReputationUpdatesEnabled $True -MicrosoftUpdate RequestNotifyDownload -UpdateMode Automatic -SpamSignatureUpdatesEnabled $True

     

    After that restart the Transport Service on the server.

     

    It will fix the issue.

     


    EXCHANGE2010, MCSE, MCTS, MCSA MESSAGING, CCNA & GNIIT
    Friday, August 6, 2010 1:52 PM
  • On Fri, 6 Aug 2010 13:52:08 +0000, PKT_ wrote:
     
    >It will fix the issue.
     
    I like SPF and SenderID a lot better for this.
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Friday, August 6, 2010 9:44 PM
  • Would enabling SenderID rejection have the effect of blocking inbound messages from all servers who don't have SPF set up (and there are lots of valid email servers who don't have an SPF record)? I posed a question in this forum recently asking about both "Stamp messages with Sender ID result..." vs. "Reject..." settings.  Eric Sun (MSFT) indicated the following answer:

    4. I currently have Sender ID set to "Stamp messages with Sender ID result and deliver..." but would like to change it to "Reject Messages". However, there is a web-based SaaS accounting application that sends notifications to us via email, whereby the "from" address is a user's email address within our domain, but it is coming from their mail servers (they are not sending email to 3rd parties using our domains).  Is there a way to set this to "Reject" but set an exception so that they are not rejected if it is from the SaaS domain's mail servers?

    No, Sender ID is global action and we don't have a way to make exception. For now, I do not recommend to enable "Reject" option, because this will block the email from any other email domain whose sender ID is not registered on internet. Sender ID mechanism is not an email mandatory option, and nowadays, lots of email servers on the internet still remain unregistered and this will result in all emails from those domains unregistered being blocked.

    The full thread can be found at:

    http://social.microsoft.com/Forums/en-US/partnerwinserverebs/thread/03146d8d-5816-41fa-b81d-616e847c779c

    Kelly

    Saturday, August 7, 2010 8:12 PM
  • On Sat, 7 Aug 2010 20:12:45 +0000, Kelly AZ wrote:
     
    >Would enabling SenderID rejection have the effect of blocking inbound messages from all servers who don't have SPF set up (and there are lots of valid email servers who don't have an SPF record)?
     
    No. The lack of a DNS TXT record with SPF information is a "Neutral"
    condition that will not interfere with inbound e-mail.
     
    >I posed a question in this forum recently asking about both "Stamp messages with Sender ID result..." vs. "Reject..." settings. Eric Sun (MSFT) indicated the following answer:
    >
    >4. I currently have Sender ID set to "Stamp messages with Sender ID result and deliver..." but would like to change it to "Reject Messages". However, there is a web-based SaaS accounting application that sends notifications to us via email, whereby the "from" address is a user's email address within our domain, but it is coming from their mail servers (they are not sending email to 3rd parties using our domains). Is there a way to set this to "Reject" but set an exception so that they are not rejected if it is from the SaaS domain's mail servers?
     
    SenderID can handle that condition -- if the e-mail contains one of
    the "Resent-*" headers, or a "Sender" header that contains an address
    in the sender's domain.
     
    The practice of "spoofing" a domain is not something to be encouraged,
    whether it's done by clueless 3rd-party e-mailer that should know
    better (it's their business to ensure that the e-mail they send gets
    delivered), or by spammers.
     
    >No, Sender ID is global action and we don't have a way to make exception. For now, I do not recommend to enable "Reject" option, because this will block the email from any other email domain whose sender ID is not registered on internet.
     
    That's not true.
     
    >Sender ID mechanism is not an email mandatory option, and nowadays, lots of email servers on the internet still remain unregistered and this will result in all emails from those domains unregistered being blocked.
     
    Nope. That's just wrong.
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Sunday, August 8, 2010 12:00 AM
  • Thank you everyone for the input.

    This fix has been complicated by the fact that our client population has varied requirements and practices already in place.

    We are a local government organization with 30+ client departments. There are web sites which have begun life hosted in our own web farm, then have been transferred to external hosting solutions, while retaining the need to send out acknowledgements and receipts signed as if they were coming from our internal domain. Other client departments have implemented vendor solutions which require desktop workstations, (where users log in and browse the internet), to serve as SMTP servers also, neither of which are ideal in my view.

    However, we have to deal with what is in place, and address changing the process later.

    The primary complaint I hear is " This spam stuff is getting increasingly graphic and offensive, and it appears to be coming from me"

    While having the users put their own email address into the Blocked Senders List was having some effect, the process was manual.

    I had tested using the Anti-spam sender Filtering to block out domain, but the options are only stamp or reject. I couldn't be sure valid email was not being thrown out.

    I have since moved that function to a transport rule, where any email from outside that contains our domain name in the from field is quarantined, allowing me to review blocked messages and create exceptions for valid ones, then release them for delivery.

    So far, this is functioning ok.

    While we would like to move forward with SPF and Sender ID, or another appliance based solution, those will be projects and will take time to work through the Change Control committee.

     

    Thank you all again for the input.

    It is helpful to hear how others are approaching the same issue.

     

    Nova

    • Marked as answer by Novaphreek Wednesday, August 11, 2010 9:46 PM
    Wednesday, August 11, 2010 9:42 PM
  • Thanks, sounds like an interesting thread.

    Unfortunately, the link is not available.

     

    Nova

    Wednesday, August 11, 2010 9:45 PM
  • Hmm....I just checked the link and for me it opens to the thread...

    You could search on the message title "Tuning anti-spam & enabling spam quarantine in EBS" or look for my original posting on June 21, 2010.

    However, please be aware that some of the information provided by MFST (Eric Sun) conflicts with information from Rich Matheisen in this thread. I suspect that Rich is correct in his assertion that the "Sender ID Reject" setting will not reject mail sent by a server with no corresponding SPF record ("neutral" response"). Therefore, only if there is an SPF record, and the mail server is not listed on it will the message be rejected.

    I am in the process of testing this and hope to confirm this behavior soon.

    Kelly

    Wednesday, August 11, 2010 10:14 PM
  • Hi Kelly

    Yes, I saw that Rich's answer was different than Eric's.

    We will also be testing SPF / Sender ID.

    I just needed an immediate solution, even if only a band-aid, to get us through the test and eval period.

    we are also debating going the appliance way, Barracuda or Ironport.

     

    Nova

    Wednesday, August 11, 2010 10:53 PM