Exchange Server 2007 Webcast Series Part 13 – Correction


During Friday’s Exchange 2007 Webcast on Managing Anti-Spam I made a couple of “boo boos”.


The first one is in reference to Sender ID.  I cautioned everyone on choosing to delete or reject messages because not everyone has implemented the DNS records necessary for this yet.  The reason for this was if no record was found, then the check would fail and the message would not make it through even if it was from a valid sender.  This is INCORRECT!  In actuality, if no record is found in DNS, then no check can be performed and therefore it doesn’t fail.  The message will be allowed in.


The second one is more around mentioning actual company names or websites and such.  I have a rule that I don’t mention actual companies because I’ve learned the hard way that it’s not a good idea.  I used examples like “blocklistprovider.org” and “safelistprovider.org” when referencing Block List Providers and Safe List Providers rather than actual companies.  In another example, I made a big boo boo and mentioned an actual company when it came to words to filter on for spam.  I do apologize for doing that as I did not mean to disparage this company in any way as the company itself does indeed make a valid product that is important for their customers.  I hope I did not offend anyone with this, and if I did, once again, I’m very sorry.


I am still working on the Q&A Log for this part (as well as some of the past ones) and will get them posted as soon as I can.  Thanks for your patience!


Harold Wong
harold.wong@microsoft.com


 

Comments (6)

  1. Sender ID is not worthless; in fact, I can tell you from my own personal experience that it works quite well.

    Sender ID is a domain authentication feature.  It matches the PRA and PRD with information in a TXT record (the SPF record) in DNS.  If there is no record in DNS, there is nothing to match, and Sender ID returns a value of no record.  If there is a record in DNS then Sender ID verifies the record against the PRA/PRD of the message.  If it matches, life is good, and the message continues through the transport stack.  If it does not match, the configured Sender ID action is taken.

    You can find more information about Sender ID at http://www.microsoft.com/mscorp/safety/technologies/senderid/overview.mspx.

  2. Keith Combs says:

    Then Sender ID is pretty worthless.  

    Any spammer can attempt to be your domain and if you haven’t created the SPF record (which is the case for most domains), then the email flows right past the Sender ID check and further processing is required to block it.

    Why would it be implemented this way?

  3. Keith Combs says:

    Regarding Sender ID, if you turn on Sender ID processing in Exchange Server 2003 or 2007, that is the default behavior.  However, looking up and not finding a SPF record isn’t considered authentication, it’s a failure.  You could silently drop all messages on such failures if desired.  Other behaviors are also available.

  4. Harold Wong says:

    Thanks Keith for playing "Devils Advocate" in questioning how Sender ID works.  I’m sure you didn’t mean that technologies we expose in our products are "worthless", but was just expressing a concern that customers may or do have regarding this technology.  Hopefully, we all understand this better and companies in general will start taking advantage of this and enter their SPF records into DNS.

    Harold Wong

    harold.wong@microsoft.com

  5. Harold Wong says:

    The correction I received is straight from the Exchange Product Group (Scott Schnoll).  They specifically told me I was WRONG.  The way Sender ID is implemented in Exchange 2003 SP2 and Exchange 2007 is that if there is no SPF record found, then no check is performed and therefore there is no failure.  Even if I choose to delete the message or reject the message, the fact that no SPF record is found means the email will not be deleted or rejected by the Sender ID filter.

    Harold Wong