Differences

This shows you the differences between two versions of the page.

--- bind_-_senderid:senderid_introduction [2016/11/29 10:48] – peter
+++ bind_-_senderid:senderid_introduction [2020/07/15 09:30] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
 ====== Bind - SenderID - SenderID Introduction ======
-SenderID is a standard proposed by Microsoft which protects against spoofing the RFC5322.From address, the one that the user sees in their email client. However, SenderID does not have the same level of widespread industry deployment that SPF or DKIM do.
+Sender ID is similar to Sender Policy Framework (SPF), but with one main difference; Sender ID verifies sender identity based on the Purported Responsible Address (PRA) using the From: or Sender: header fields.
-SenderID was primarily used in Hotmail and on-premise Exchange servers deployed locally within organizations. However, during the past year, Hotmail has stopped checking SenderID and starting checking SPF as that is what is what is required by DMARC. This leaves only on-premise Exchange servers.
+SenderID tries to improve on a principal deficiency in SPF: that SPF does not verify the header addresses that indicates the sending party.  SPF verifies only the "MAIL FROM" address (also called the envelope sender).
-The Exchange server MTA has its own built-in spam filter, Smartscreen. However, it is not dynamically updated the way that other services do (like Hotmail, Yahoo, Gmail, or our own service Forefront Online/Exchange Online). Therefore, most on-premise Exchange deployments will probably augment their filtering with another service that updates regularly. The reliance upon SenderID is then diminished since the other spam filter will already catch most of the spam. Therefore, many Exchange administrators may not even have the SenderID agent enabled, although others may enable it as a fail-safe against spoofed email.
+Sender ID was developed by Microsoft to protect against spoofing the RFC5322.From address, the one that the user sees in their email client.  However, SenderID does not have the same level of widespread industry deployment that SPF or DKIM do.  There had been some talk that Sender ID was dead, but Sender ID continues to provide important benefits to both senders and receivers.
+Sender ID is almost identical to SPF except that v=spf1 is replaced with one of:
+  * **spf2.0/mfrom** - meaning to verify the envelope sender address just like SPF.
+  * **spf2.0/mfrom,pra** or **spf2.0/pra,mfrom** - meaning to verify both the envelope sender and the PRA.
+  * **spf2.0/pra** - meaning to verify only the PRA.
+===== Examples =====
-But if SenderID is not used by Hotmail and may or may not be used by on-premise Exchange installations, senders may decide that it is not worthwhile complying with SenderID because the potential fallout is small.
 <code>
@@ Line 15: / Line 22: @@
 OR
-news.example.com
+For news.example.com,
 <code>
@@ Line 23: / Line 30: @@
   * **spf2.0/pra** means that this is a SenderID record.
   * **pra** means to apply this to the domain in the Purported Responsible Address, which is either the domain in the Sender: (rarely) or RFC5322.From (usually)."
+===== How Sender ID Works =====
+Sender ID verifies the origin of the email address based on IP address and domain, and then uses the validation results to determine email delivery. When a sender deploys a message, the inbound mail server checks the DNS entries to obtain the SPF Record.  It then checks the record to see if the IP address matches the sending server.  If there is a match, then the messages pass authentication and can be delivered.  However, if there is no match, authentication will fail and the email will either be rejected or delivered to the spam folder.
+===== Sender ID vs. SPF =====
+Sender ID addresses a very different problem than SPF.
+  * SPF validates the HELO domain and the MAIL FROM address against the policies published via DNS (SPF record).
+  * Sender ID validates one of the message's address header fields defined by [[http://tools.ietf.org/html/rfc2822|RFC 2822]].  Since it was derived from SPF, Sender ID can also validate the MAIL FROM.  But it defines the new PRA identity to validate, and defines new sender policy record tags that specify whether a policy covers MAIL FROM (called MFROM by Sender ID), PRA, or both.
+Unlike SPF which validates against the envelope’s return-path address which is the root or subdomain, Sender ID validates based on the PRA and uses the header field with the email address to identify the visible sender of the message. Since headers are not required by the SMTP protocol, Sender ID uses the content of the message to provide an extra layer of protection against spammers and phishers that is very different from SPF which validates on the domain or connection level.
+Sender ID and SPF should both be adopted along with DKIM.  These methodologies complement each other and in doing so, provide the best protection against phishing.
+Neither is better because they solve different problems:
+  * SPF can be compared to other SMTP layer protocol like CSV/CSA.
+  * Sender ID can be compared to other RFC 2822 layer protocols like DomainKeys IM(DKIM)
+===== Advantages of using SenderID =====
 It does mean that you must create and delegate a subdomain for 3rd parties to send on behalf of you and publish their SPF records in that subdomain's SenderID record.  If you ever change 3rd parties, you must update this SenderID record.  And if this 3rd party ever starts sending spam using your subdomain, it will pass a SenderID check (it can also pass an SPF check).
 However, even if it does go rogue, it can only pass a SenderID check for this delegated subdomain.  In this example, it can only SenderID pass news.example.com.  It will not pass example.com, confirmations.example.com, and so forth.  The damage is contained (and can be revoked by unpublishing the IPs from the SenderID record).