Sender ID Framework
verifying the domain name from which e-mail messages are sent. Sender ID validates the origin of e-mail messages by verifying the IP address of the sender against the alleged owner of the sending domain.
You can not implement Sender ID Filter feature in lab. From the e-mail I got from Microsoft Senderid team, you should find out a clue.
=======
Thank you for writing to the Sender ID Management Team. This is Paul and I gather that you would like to have your itsme.com domain to be added to the Sender ID program.
We have added your itsme.com domain to the Sender ID queue. However, we were not able to add this domain to the Sender ID program as we were unable to find any SPF record associated with this domain. If the domain provided to us is not the correct name please let us know, by replying to this email.
It is possible that you have made the changes to your DNS information, but this has not fully replicated throughout the Internet. The good news is that you do not need to notify us when you create any revisions to your SPF record since we will automatically pull the current record from the DNS daily. Once a SPF record is found your domain will leave the Sender ID queue and be added to the Sender ID program.
You can find technical information on the Sender ID program at http://www.microsoft.com/senderid.
=============
Create a SPF record in Windows DNS server
- Forward lookup zone --a resource record type, click Text (TXT), and then click Create Record.
- If you add a record for the parent domain, leave the Record name box blank. If you do not add a record for the parent domain, type the single part name of the domain in the Record name box.
- In the Text box, type v=spf1 mx -all.
Even if your domain has no outbound e-mail servers, you can help protect your domain from spoofing by publishing an SPF record in the DNS that states this.
Ensure that your domain can be correctly identified as the purported responsible domain (PRD) for each message you send. This means that the sender's domain must be shown in certain headers of the e-mail message. ???
As long as sending servers use their own domain name in the ―From‖ header of the message and publish an SPF record, they are already compliant with Sender ID.
Therefore, e-mail senders must ensure that their domain is the one that is identified as the PRD--Purported Responsible Domain
How does Sender ID Framework work?
- Sender sends an e-mail to Receiver.
- Receiver’s inbound e-mail server receives e-mail and calls its Sender ID Framework.
- The Sender ID Framework looks up the SPF record of the domain that Sender is using for sending the mail.
- The receiving Mail Transfer Agent (MTA) determines if the outbound Mail Server IP address (Sender side) matches IP addresses that are authorized to send mail for the user.
If there is a SPF record for the sender, the IP address of the sending server is checked against the IP addresses listed in SPF record. If there's a match, the message is validated as authentic. If, on the other hand, the SPF record on the sender's domain does not match the IP address the message came from, it fails, resulting in a negative score and potential placement in the junk mail folder.
Microsoft DNS: text record for SPF
-------------
Mail may legitimately originate from IP addresses not identified above, however, use of such IP addresses is discouraged and may not be permitted in the future.
v=spf1 a mx ptr mx:exclientserver.itsme.com mx:artwork.itsme.com ~all
---------
Only exclientserver.itsme.com and artwork.itsme.com send outgoing mail.
v=spf1 mx mx:mx:exclientserver.itsme.com mx:artwork.itsme.com -all
--------------
The above record shows that exclientserver.itsme.com and artwork.itsme.com deliver out-bound e-mail for itsme.com domain.
Enable a Reverse DNS Lookup
SMTP virtual server-- Properties--Delivery tab, click Advanced == select the Perform reverse DNS lookup on incoming messages check box.
If you select this option, Microsoft SMTP Service tries to verify that the IP address of the client (Sending SMTP server???) matches the host or domain that is submitted by the client in the EHLO or HELO command.
If the reverse DNS lookup is successful, the Received header remains intact.
If the verification is unsuccessful, "unverified" appears after the IP address in the Received header of the message.
SMTP service does not reject the "unverified" message. But it can be used in Intelligent Filter (I assume).
Sender ID
http://technet.microsoft.com/en-us/magazine/cc160870.aspx
Sender ID seeks to verify that every e-mail message originates from the Internet domain from which it claims to have been sent. This is accomplished by checking the address of the server sending the e-mail against a registered list of servers that the domain owner has authorized to send e-mail. Verification is performed automatically by the Internet service provider (ISP) or the recipient's mail server before the message is delivered to the user's Inbox.
Authentication notifies the inbound mail system of whether the message can be validated as coming from the claimed sender. It does not reject the message.
You should publish an SPF record for your SMTP server. See http://www.microsoft.com/senderid for detail. SPF refers to Sender Policy Framework. SIDF refers to Sender ID Framework.
The Sender ID Framework SPF Record Wizard (http://www.microsoft.com/senderid/wizard) provides a step-by-step process for surveying a domain's mail servers and creating customized records ready for posting.
When Sender ID is enabled on the receiving SMTP mail server, the receiving SMTP mail server pings the domain's zone file in the DNS for the existence of an SPF record. Once found, the IP address of the sending server is checked against the IP addresses listed. If there's a match, the message is validated as authentic. If, on the other hand, the SPF record on the sender's domain does not match the IP address the message came from, it fails, resulting in a negative score and potential placement in the junk mail folder.
Exchange 2007 transport Architecture
SMTP Receive
When messages are received at a Hub Transport server, transport rules are applied and, if anti-spam and antivirus agents are configured, these agents provide an additional layer of anti-spam and antivirus protection. The SMTP session has a series of events that work together in a specific order to validate the contents of a message before it is accepted into the organization. After a message has passed completely through SMTP Receive and is not rejected by receive events or by an anti-spam and antivirus agent, it is put in the Submission queue.
Submission
Submission is the process of putting messages into the Submission queue.
- SMTP submission through a Receive connector
- Submission through the Pickup directory or the Replay directory. These directories exist on the Hub Transport server or Edge Transport server. Correctly formatted message files that are copied into the Pickup directory or the Replay directory are put directly into the Submission queue.
- Submission by the Store driver, which picks up messages from a sender’s Outbox as they are sent
- Submission by an agent
