[MS-OXPSVAL]:
Email Postmark Validation Algorithm
Intellectual Property Rights Notice for Open Specifications Documentation
§ Technical Documentation. Microsoft publishes Open Specifications documentation for protocols, file formats, languages, standards as well as overviews of the interaction among each of these technologies.
§ Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you may make copies of it in order to develop implementations of the technologies described in the Open Specifications and may distribute portions of it in your implementations using these technologies or your documentation as necessary to properly document the implementation. You may also distribute in your implementation, with or without modification, any schema, IDL’s, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications.
§ No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation.
§ Patents. Microsoft has patents that may cover your implementations of the technologies described in the Open Specifications. Neither this notice nor Microsoft's delivery of the documentation grants any licenses under those or any other Microsoft patents. However, a given Open Specification may be covered by Microsoft Open Specification Promise or the Community Promise. If you would prefer a written license, or if the technologies described in the Open Specifications are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting .
§ Trademarks. The names of companies and products contained in this documentation may be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. For a list of Microsoft trademarks, visit www.microsoft.com/trademarks.
§ Fictitious Names. The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in this documentation are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.
Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than specifically described above, whether by implication, estoppel, or otherwise.
Tools. The Open Specifications do not require the use of Microsoft programming tools or programming environments in order for you to develop an implementation. If you have access to Microsoft programming tools and environments you are free to take advantage of them. Certain Open Specifications are intended for use in conjunction with publicly available standard specifications and network programming art, and assumes that the reader either is familiar with the aforementioned material or has immediate access to it.
Revision Summary
Date / Revision History / Revision Class / Comments /04/04/2008 / 0.1 / Initial Availability.
06/27/2008 / 1.0 / Initial Release.
08/06/2008 / 1.01 / Updated references to reflect date of initial release.
09/03/2008 / 1.02 / Revised and edited technical content.
12/03/2008 / 1.03 / Revised and edited technical content.
03/04/2009 / 1.04 / Revised and edited technical content.
04/10/2009 / 2.0 / Updated technical content and applicable product releases.
07/15/2009 / 3.0 / Revised and edited technical content.
11/04/2009 / 3.1.0 / Minor / Updated the technical content.
02/10/2010 / 4.0.0 / Major / Updated and revised the technical content.
05/05/2010 / 5.0.0 / Major / Updated and revised the technical content.
08/04/2010 / 5.1 / Minor / Clarified the meaning of the technical content.
11/03/2010 / 5.2 / Minor / Clarified the meaning of the technical content.
03/18/2011 / 6.0 / Major / Significantly changed the technical content.
08/05/2011 / 7.0 / Major / Significantly changed the technical content.
10/07/2011 / 7.0 / No change / No changes to the meaning, language, or formatting of the technical content.
01/20/2012 / 8.0 / Major / Significantly changed the technical content.
04/27/2012 / 9.0 / Major / Significantly changed the technical content.
07/16/2012 / 9.0 / No change / No changes to the meaning, language, or formatting of the technical content.
10/08/2012 / 10.0 / Major / Significantly changed the technical content.
02/11/2013 / 11.0 / Major / Significantly changed the technical content.
07/26/2013 / 12.0 / Major / Significantly changed the technical content.
11/18/2013 / 12.0 / No change / No changes to the meaning, language, or formatting of the technical content.
1/1
[MS-OXPSVAL] — v20131118
Email Postmark Validation Algorithm
Copyright © 2013 Microsoft Corporation.
Release: November 18, 2013
Table of Contents
1 Introduction 5
1.1 Glossary 5
1.2 References 5
1.2.1 Normative References 5
1.2.2 Informative References 6
1.3 Overview 6
1.4 Relationship to Protocols and Other Algorithms 6
1.5 Applicability Statement 7
1.6 Standards Assignments 7
2 Algorithm Details 8
2.1 Common Algorithm Details 8
2.1.1 Abstract Data Model 8
2.1.1.1 Input Parameters for Generating the Puzzle 8
2.1.1.1.1 Number of Recipients 8
2.1.1.1.2 Message "To: " and "Cc: " Recipients 8
2.1.1.1.3 Algorithm Type 9
2.1.1.1.4 Degree of Difficulty 9
2.1.1.1.5 Message Identifier 9
2.1.1.1.6 Message "From: "Address 9
2.1.1.1.7 DateTime 9
2.1.1.1.8 Subject Line 9
2.1.1.2 Pre-Solver Output Values 9
2.1.1.2.1 "X-CR-PuzzleID" X-Header Property 10
2.1.1.2.2 "X-CR-HashedPuzzle" X-Header Property 10
2.1.2 Initialization 10
2.1.3 Processing Rules 10
2.2 Submit Message Algorithm Details 10
2.2.1 Abstract Data Model 10
2.2.2 Initialization 10
2.2.3 Processing Rules 10
2.2.3.1 Generating X-CR-HashedPuzzle 10
2.3 Son-Of-SHA-1 Hash Algorithm Details 11
2.3.1 Abstract Data Model 11
2.3.2 Initialization 12
2.3.3 Processing Rules 12
2.4 Message Delivery Algorithm Details 13
2.4.1 Abstract Data Model 13
2.4.2 Initialization 13
2.4.3 Processing Rules 13
2.4.3.1 Determining When to Validate 13
2.4.3.2 Validating the Puzzle 13
3 Algorithm Examples 15
3.1 Postmark for a Message with One Recipient Using Son-of-SHA-1 Algorithm 15
3.2 Postmark for a Message with Two Recipients Using Son-of-SHA-1 Algorithm 15
3.3 Hash Values from Son-of-SHA-1 Algorithm 16
4 Security 18
4.1 Security Considerations for Implementers 18
4.2 Index of Security Parameters 18
5 Appendix A: Product Behavior 19
6 Change Tracking 20
7 Index 21
1/1
[MS-OXPSVAL] — v20131118
Email Postmark Validation Algorithm
Copyright © 2013 Microsoft Corporation.
Release: November 18, 2013
1 Introduction
The Email Postmark Validation Algorithm enables a client to create an e-mail message with a postmark header. This algorithm also enables a client to validate the postmark property on an incoming e-mail message to determine whether it is spam.
Section 2 of this specification is normative and can contain the terms MAY, SHOULD, MUST, MUST NOT, and SHOULD NOT as defined in RFC 2119. Section 1.6 is also normative but cannot contain those terms. All other sections and examples in this specification are informative.
1.1 Glossary
The following terms are defined in [MS-GLOS]:
ASCII
GUID
resource
Unicode
The following terms are defined in [MS-OXGLOS]:
base64 encoding
binary large object (BLOB)
message transfer agent (MTA)
messaging object
Multipurpose Internet Mail Extensions (MIME)
non-Unicode
recipient
Simple Mail Transfer Protocol (SMTP)
spam
The following terms are specific to this document:
postmark: A computational proof that is applied to outgoing messages to help recipient messaging systems distinguish legitimate email messages from junk email messages, which reduces the chance of false positives.
presolution header: A string that contains the prepended solutions for the puzzle.
Pre-Solver: A component that, given specific inputs, generates a message postmark.
MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as described in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.
1.2 References
References to Microsoft Open Specifications documentation do not include a publishing year because links are to the latest version of the documents, which are updated frequently. References to other documents include a publishing year when one is available.
1.2.1 Normative References
We conduct frequent surveys of the normative references to assure their continued availability. If you have any issue with finding a normative reference, please contact . We will assist you in finding the relevant information. Please check the archive site, http://msdn2.microsoft.com/en-us/library/E4BD6494-06AD-4aed-9823-445E921C9624, as an additional source.
[FIPS180] FIPS PUBS, "Secure Hash Standard", FIPS PUB 180-1, April 1995, http://www.itl.nist.gov/fipspubs/fip180-1.htm
[MS-OXCMSG] Microsoft Corporation, "Message and Attachment Object Protocol".
[MS-OXCNOTIF] Microsoft Corporation, "Core Notifications Protocol".
[MS-OXOABK] Microsoft Corporation, "Address Book Object Protocol".
[MS-OXOMSG] Microsoft Corporation, "Email Object Protocol".
[MS-OXPROPS] Microsoft Corporation, "Exchange Server Protocols Master Property List".
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989, http://www.ietf.org/rfc/rfc1123.txt
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, http://www.rfc-editor.org/rfc/rfc2119.txt
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", STD 10, RFC 2821, April 2001, http://www.ietf.org/rfc/rfc2821.txt
[RFC2822] Resnick, P., Ed., "Internet Message Format", STD 11, RFC 2822, April 2001, http://www.ietf.org/rfc/rfc2822.txt
1.2.2 Informative References
[MS-GLOS] Microsoft Corporation, "Windows Protocols Master Glossary".
[MS-OXGLOS] Microsoft Corporation, "Exchange Server Protocols Master Glossary".
[MS-OXPROTO] Microsoft Corporation, "Exchange Server Protocols System Overview".
1.3 Overview
Postmark validation is a computational proof that a client applies to outgoing e-mail messages. Postmarks help recipients (1) distinguish legitimate e-mail from spam. When a recipient (1) has postmark validation enabled, its spam filter parses each incoming e-mail message for a postmark header.
An e-mail message with a postmark header is less likely to be spam than one without a postmark header. This is because a computer does not require significant processing time to solve an individual computational postmark, but the processing time required to do so for large numbers of messages is expected to be prohibitive. This computational cost is expected to discourage spam senders. For examples of postmarked e-mails, see sections 3.1 and 3.2.
1.4 Relationship to Protocols and Other Algorithms
When the e-mail client and recipient (1) server are communicating via the Email Object Protocol, as specified in [MS-OXOMSG], the Email Postmark Validation Algorithm uses two properties that the client attaches to an e-mail message. Therefore, the Email Postmark Validation Algorithm relies on the underlying message structures and the handling specified in [MS-OXOMSG].
The Core Notifications Protocol, as specified in [MS-OXCNOTIF], provides more information about the properties that are used to send and receive messages.
The Exchange Server Protocols Master Property List, as specified in [MS-OXPROPS], provides more information about the data types that are used by this algorithm.
For conceptual background information and overviews of the relationships and interactions between this and other protocols, see [MS-OXPROTO].
1.5 Applicability Statement
This algorithm specification defines how e-mail messaging clients can generate and understand computational postmarks. By using this algorithm, the client can reduce the number of false positives detected by the recipient (1) server when it tries to identify spam e-mail messages.
1.6 Standards Assignments
None.
2 Algorithm Details
2.1 Common Algorithm Details
The following sections specify the properties that are used by the Email Postmark Validation Algorithm. Before sending these requests to the server, the messaging client MUST be logged on to the server.<1> The client MUST open/acquire handles to all messaging objects and properties that are set or retrieved by this algorithm.
2.1.1 Abstract Data Model
2.1.1.1 Input Parameters for Generating the Puzzle
The input parameters specified in the following sections are used to calculate the puzzle.
All string values, unless otherwise specified, MUST be in Unicode format UTF-16 or UCS-2. It is up to the client implementation to choose which format to use; the algorithm treats both formats identically.<2>
2.1.1.1.1 Number of Recipients
This parameter specifies the total count of SMTP message recipients (1) on the "To:" and "Cc: " lines.
This parameter MUST be a decimal value formatted as type string.
Message recipients (1) other than SMTP message recipients (1) MUST NOT be counted.
2.1.1.1.2 Message "To: " and "Cc: " Recipients
This parameter is a string that contains a semicolon separated list of SMTP [RFC2821] addresses that are found on the "To: " and "Cc: " lines.
This parameter MUST be formatted as type string and MUST be encoded with base64 encoding. Addresses on the "Bcc:" lines MUST NOT be used. Accounts that are compatible with [MS-OXOMSG] MUST reference the following properties:
§ PidTagEmailAddress ([MS-OXOABK] section 2.2.3.14)
§ PidTagAddressType ([MS-OXOABK] section 2.2.3.13)
The recipient (1) string is calculated by means of the following pseudologic:
For each of the recipients in the [Recipient List] {
Get the PidTagAddressType and PidTagEmailAddress properties.
if (PidTagAddressType == "SMTP") {
Append PidTagEmailAddress value, followed by a semi-colon,
to recipient string.
}
}
Remove the last semi-colon at the end of the recipient string.
2.1.1.1.3 Algorithm Type
This parameter contains the algorithm type that is used to generate the puzzle.
This parameter MUST be a formatted as type string.
The puzzle-solving system MUST use "sosha1_v1", as it is currently the only valid algorithm type.
2.1.1.1.4 Degree of Difficulty
This parameter contains the degree of difficulty for which a puzzle solution is sought. A larger Degree of Difficulty value indicates that the puzzle-generating application used more computing resources to create the puzzle. Therefore, the receiving system typically assumes that a larger Degree of Difficulty value corresponds to a lower likelihood that the message is spam. This is only a generally accepted guideline, and is not a protocol requirement.
This parameter MUST be a positive integer value that is formatted as type string.<3>
2.1.1.1.5 Message Identifier
This parameter contains a unique identifier that is represented by a GUID.
This parameter MUST be formatted as type string and MUST be enclosed in brackets "{}".
2.1.1.1.6 Message "From: "Address
This parameter contains the sender's SMTP e-mail "From: " address.
This parameter MUST be formatted as type string and MUST be encoded with base64 encoding.
Accounts that are compatible with [MS-OXOMSG] MUST use the PidTagSenderEmailAddress property ([MS-OXOMSG] section 2.2.1.49).
2.1.1.1.7 DateTime
This parameter contains the creation time of the puzzle.
This parameter MUST consist of ASCII characters, MUST be formatted as type string, and MUST be formatted as specified in [RFC1123].