X-ASVP: Extensible Anti-spam Verification Protocol draft-ietf-ASVP-Anti-spam-Verification-Protocol-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English, other than to extract section 1.1 as-is for separate use. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright: This document is copyright 2007 (c) X-ASVP Committee and the latest version is posted at http://www.x-asvp.org The methods discussed in this document are all copyleft to their individual contributors. This document may be copied, forwarded, reposted or otherwise reproduced as long as it is not modified in any way, and this Copyright notice is left intact. Abstract This document describes a protocol for filtering and blocking unwanted and unsolicited e-mail, commonly known as "spam" while providing greater levels of documentation in order to track the source of the unwanted messages. This protocol is designed primarily to be extensible, taking into account several principles designed to make it maximally functional across a broad range of possible applications with little or no impact to the user and offering a broad range of customizability to the administrators/implementers while requiring few changes to existing infrastructure. This protocol may be implemented in both e-mail client software (MUA) and/or in Mail Transfer Agents (MTA). If the protocol is enabled in either the end user mail client software or his ISP MTA (or both) then the protocol is automatically applied to SMTP mail messages with no further end user interaction. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. The X-ASVP Method 1.1. Introduction 4 1.2. Committee 5 1.3. X-ASVP Header 5 1.3.01. Level 0: No Effort Made 6 1.3.02. Level 1: Extensions 7 1.3.03. Level 2: Basic X-ASVP 17 1.3.04. Level 3: Client X-ASVP 17 1.3.05. Level 4: Message ID 19 1.3.06. Level 5: X-SFP 19 1.3.07. Level 6: DKIM 20 1.3.08. Level 7: SPF 20 1.3.09. Level 8: Hashcash/E-stamps 20 1.3.10. Level 9: PKI 20 1.4. Further Discussion 21 2. Security Considerations 22 3. IANA Considerations 22 4. Conclusions 22 5. Acknowledgments 22 6. References 23 6.1. Normative References 23 Author's Addresses 23 Intellectual Property Statement 23 Disclaimer of Validity 24 Copyright Statement 24 Acknowledgement 24 1.1 Introduction As the use of e-mail has become more popular, so has the incidence of unwanted or unsolicited e-mail, commonly known as "spam". There are multiple proposals for adding authentication to e-mail (such as DKIM and S/MIME) and multiple methods used to filter spam. All proposals for authenticating e-mail suffer from two seemingly insurmountable problems: 1. The "chicken and egg" syndrome: Who will invest in creating software that requires infrastructure support that doesn't yet exist? And, who will invest in infrastructure for a protocol where the software doesn't exist? 2. Many user communities actually desire anonymous e-mail. Meanwhile, all spam filtering technology suffers from two seemingly insurmountable problems: 1. Lack of e-mail authentication: Filters cannot rely on any data in e-mail headers to provide authentication separate from some other supporting method (see above). 2. Each recipient has a different view of what constitutes spam, and different tolerance for false-positives and false-negatives. Some people would rather reject some "real" messages than receive spam. Other people are willing to accept more spam if it means a lesser chance of rejecting "real" messages. The X-ASVP method was written to provide an extensible framework that will allow that balance to be determined by the end points of the communication, the individual senders and receivers of e-mail messages. The protocol is designed to take into account many different classes of users, giving each a level of choice and control that will allow the involved parties to find the unique balance for their particular needs. This protocol is designed primarily to be extensible, taking into account the following principles: 1. Utilize as much existing infrastructure as possible 2. Utilize open protocols whenever possible 3. Ensure that end users can implement the protocol for their individual e-mail account without the cooperation of their ISP. 4. Ensure that ISP's can implement the protocol on behalf of (read invisible to) their users. 5. Make it extensible for enterprises that wish to make rules and tests more stringent for external communications. 6. Allow a method for end users to accept unauthenticated e-mail should they choose to do so. 7. Create a system that is incrementally more difficult for spammers to abuse and provide a new toolset for tracking, identifying and stopping spammers, or at least to increase their level of effort. The Anti-Spam Verification Protocol (ASVP) is implemented as a method for locating end-user preferences about receiving e-mail (a "meta- document"), formats for an SMTP e-mail Header "X-ASVP:", and a rule- set governing the creation of method extensions for X-ASVP Level 1. 1.2. Committee Maintenance of this protocol belongs to the X-ASVP committee (XCOM) Each registrant of a X-ASVP.tld domain is a committee member. Note: The Chair is elected annually by committee members. 1.3. X-ASVP Header The X-ASVP: header is defined as follows: Level 0 - No effort made, user does not recognize ASVP Level 1 - Extensions - methods proposed for implementation Extension methods are posted at the X-ASVP website. This document discusses 3 such extensions: - ASVP-TOKEN - static, configurable ASVP-TOKEN per recipient - ASVP-FAX - a proposal to store static ASVP-tokens per recipient in the Contacts list - ASVP-WEB - a proposal to utilize web servers to distribute dynamically generated tokens Level 2 - Basic X-ASVP - utilizes DNSBL queries to assign a "trust- level" to From address Level 3 - Client X-ASVP - allows clients to implement Basic X-ASVP using 3rd party "notary" Level 4 - Message-ID - Uses prior Message-ID as a dynamic token between senders and recipients Level 5 - X-SPF - Extension for Client use of OpenSPF Level 6 - DKIM - Gateway implementation of DKIM (TBD) Level 7 - SPF - Strict SPF (X-SPF is not Supported) Level 8 - HASHCASH or e-stamps Level 9 - PKI - PKI announce Support flag Order of Precedence: Note that multiple X-ASVP headers are allowed. In the event that action of defined X-ASVP headers conflict, the order of precedence is: Level 1 when found in the body of a message Level 9 to 0 in DESCENDING numerical order FIFO order (top-down) when more than one header is at same definition level. 1.3.01. Level 0 - No effort made Usage: No header, or a Header MAY be inserted as X-ASVP:V0 Function: Provide 'opt-out' capability for users and ISP's. Note: "anonymous" e-mail can be sent with a Level 1 header using the "ASVP-WEB" extension. Benefit: Should an ISP decide that it does not wish to implement X-ASVP and wishes to prevent X-ASVP queries to its DNS servers, an ISP can choose to insert this Header into outgoing e-mail headers, thus preventing -compliant- mail clients from performing X-ASVP DNS lookups. Since this "turns off" the protocol at the recipient client, most users will likely choose to flag any e-mail that uses the "X-ASVP:0" Header as likely spam. Implementation: Compliant client software MUST NOT perform DNS blocklist queries when the X-ASVP:V0 header is specified unless over-ridden by a secondary higher level option. (See order of precedence for application of options V1 and V2.) 1.3.02. Level 1 - Reserved for extensions Usage: X-ASVP:V1[extenstionname,string-data] Function: Extensible framework that will allow interested parties to create filters, token-exchanges, or proprietary protocols using a standard, open protocol for parameter data exchange. Implementation: To be considered "X-ASVP Level 1 Compliant", mail client software MUST accept the header starting with 'X-ASVP:V1'when it appears as the first non-whitespace characters in the body of a message. (This allows mail senders to insert V1 extensions with mail clients that don't support the insertion of custom Headers into the standard SMTP headers block. (Such as most web-based mail systems.) Mail client software developers are encouraged to register extensions they create at http://www.x-asvp.org/ While mail clients can be considered "Level 1 Compliant" simply by identifying 'X-ASVP:V1' as described above, developers are encouraged to create a "plug-in" system for support of new extensions. The "X-ASVP" committee provides technical review and assigns "handles" for extensions that the developer community wishes to promote. While not required to be considered "Level 1 Compliant", developers are encouraged to build support for the defined extension-3 "ASVP- WEB" Extension-1) ASVP-TOKEN ASVP-TOKEN defined: X-ASVP:V1[ASVP-TOKEN,token_value] Client: Mail clients should have a configurable parameter "ASVP- TOKEN=value" if the recipient has chosen to accept mail evaluated to TRUE with this extension then when an e-mail arrives where the value of "ASVP-TOKEN" in the message X-ASVP:V1 header matches the configured value of "ASVP-TOKEN" in the client configuration, then the mail should be accepted as "whitelist" or "non-spam". (This allows recipients to have a "password" to "authenticate" incoming mail from known parties.) Extension-2) ASVP-FAX Suppose that GJK, a software developer, wishes to create an extension that goes a step further than "ASVP-TOKEN". GJK wants users of his mail client software, both senders and receivers, to store individual token_values in the Contact list of his e-mail client. Since he knows that his Contact database structure doesn't currently support a "ASVP-TOKEN" field to store the values, and since he wishes for other software clients to be compatible, he proposes an extension that uses the field "FAX number" in his e-mail client Contact list database as a unique "ASVP-TOKEN" for each recipient. He registers with http://www.x-asvp.org where his proposed extension is scheduled for review and once accepted by the X-ASVP steering committee is assigned the handle "ASVP-TOKEN". The X-ASVP website posts the ASVP-TOKEN extension definition and if the extension is considered to still be experimental, will link to a webpage for the "ASVP-TOKEN extension working group". All extension definitions filed and posted with X-ASVP will be either open license or copyleft. The working definition for "ASVP-TOKEN": ASVP-TOKEN defined: X-ASVP:V1[ASVP-TOKEN,faxnumber] faxnumber = 1 to 20 characters numeric only Implementation: Client-sender: MUST insert a configurable "faxnumber" (identifies the SENDER) into outgoing SMTP messages. For example, suppose john.q@public.tld has configured his local client to know that his FAX number is '9165551234'. (This could be stored as a contact record for himself in the local Contacts database, or a vCard, or a configuration option, it doesn't matter as long as John Q. knows where to go to change it.) If John Q. enables this extension in his mail client, then all outgoing SMTP messages will contain an e-mail header that contains his FAX number (or whatever has been put into that field) X-ASVP:V1[ASVP-TOKEN,9165551234] Client-recipient: MUST have a field within a local contacts database editable by the user that stores 'faxnumber'. When e-mail is received with the "ASVP-TOKEN" extension, and the extension is enabled, then the the local contacts database is searched for the record that corresponds to the incoming "From:" header. (In this case, that is "john.q@public.tld ) The value parsed from "ASVP- TOKEN" header ('9165551234') is compared to the value stored in the local contacts database, and if there is a match, the client software shall accept for delivery (or disposition per other available options). Optional: "passcode option": If a record exists in the local Contacts database for e-mail address ASVP-TOKEN@x-asvp.org (and the "passcode" option is enabled) then the value parsed from the X-ASVP header should be compared to the faxnumber for ASVP-TOKEN@x-asvp.org and evaluate to TRUE if they match. (i.e., for evaluation purposes, the value stored is a wildcard for any sender "From:" address.) Benefits: For persons who normally exchange e-mail only with people that are listed in their contacts list, enabling this one rule would establish a "shared-token" system with any contacts who use a mail client that also supports this extension. If a user was confident that all of the people they communicate with use this extension, they could filter out all other mail and likely eliminate 100% of spam. By enabling the "passcode option", they could configure a "passcode" that would allow persons they gave the "passcode" to to construct an e-mail that would get through the filter. The "passcode option" would first look in the Contacts list for the e-mail address parsed from the "From:" header, if that address were not found, or the Contact record did not have a FAX number stored, then the FAX number stored in the record for passcode@x-asvp.com would be used. Extension-3) ASVP-WEB After reading about the copyleft ASVP-TOKEN extension, another developer submits a new extension that proposes a method for making the ASVP-TOKEN be dynamic on the web, thus leaving a log record for those who use the extension. The X-ASVP definition for ASVP-WEB reads: ASVP-WEB defined (extended from ASVP-TOKEN): X-ASVP:V1[ASVP-WEB,sequence_number,LHS_@RHS_] Where sequence_number = 1 to 200 alpha-numeric characters In Augmented Backus-Naur Form (ABNF) [RFC4234] grammar, sequence_number = 1*200mech-char mech-char = ALPHA / DIGIT / UNDERSCORE / HYPHEN / ATSIGN ; mech-char is restricted to A-Z, a-z, 0-9, _, -, and @ ; all from ASCII character set. ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 UNDERSCORE = %x5F ; underscore (_) HYPHEN = %x2D ; hyphen (-) ATSIGN = %x40 ; at sign (@) ; Reserved word = REFERENCE (Used as keyword for extensibility.) ; Reserved word = DEFAULT (Used when the DEFAULT value is required.) ; Reserved word = CONTINUE (Allow trivial implementation for ISP's.) Implementation: Note: This extension can be performed by either an end-user or an ISP on behalf of a user, or both. (Note: Order of precedence rules allow more than one such header.) Client-sender: Client performs an http call (following normal web redirects) of the URL created by the right hand side (RHS) of the recipient e-mail address prepended by "http://x-asvp." and appended by "/RHS_/LHS_.html" where "RHS_" is the domain name with all lowercase alpha converted to UPPER, and all non-alphanumeric characters converted to underscores and where "LHS_" is the left-hand side (i.e. the user-name) similiarly converted. After following appropriate HTTP redirects the client MUST parse the sequence_number value from element value delivered in the returned HTML or XML document.(i.e. a "meta- document") (Note: Expect that some enterprises may redirect HTTP to an HTTPS page.)(Note: sequence_number = REFERENCE is an escape sequence. When REFERENCE is specified the client SHOULD expect the returned document to also include a element and an element. See http://www.x-asvp.org/ for descriptions of common implementations.) This example shows the use of REFERENCE ---snip REFERENCE example--- This document explains the "cost of entry" is a 30-bit hashcash: REFERENCE HASHCASH,30 X-HASHCASH defined This one says to use the "passcode" of extension ASVP-TOKEN: REFERENCE ASVP-TOKEN,9165551111 ASVP-TOKEN extension defined ) ---end snip REFERENCE example--- (Note: sequence_number = DEFAULT is a shorthand command that instructs the client to send the DEFAULT header as defined by the rules for purely offline mode mailers. Such mail could be "anonymous". ) (Note: sequence_number = CONTINUE is a command that instructs the client to check the secondary URL path for an updated sequence_number value. This allows ISP's to be trivially compliant.) While recognition of REFERENCE and DEFAULT reserved-words are not required to be considered compliant, it should be expected that recipients who request either will reject mail that does not follow the specified DEFAULT or REFERENCE method. For each recipient in the To: header a separate X-ASVP:V1 header should be inserted (or the client MAY separate SMTP connections per recipient and insert the one header required for the individual delivery address). For each such recipient the compliant sender will parse the domain name (or RHS) and the user ID (or LHS) from the recipient e-mail address. For example, if the intended recipient is john.q@public.tld then the RHS is "public.tld", and the LHS is john.q". In the special case where the From: header is null, then LHS = NULL and RHS = X-ASVP.tld where tld is the top level domain of the recipient e-mail address. (Note: Optional DNSBL of primary and secondary URL here, allows protective response for hostile domains. The X-ASVP committee suggests that secondary member registrars host cached copies of the XCOM DNSBL (nsx-asvp.x-asvp.at) for their TLD at nsx-asvp.x-asvp.tld ) For our example recipient, the client will request http://x- asvp.public.tld/PUBLIC_TLD/JOHN_Q.HTM If the DNS query for x-asvp.public.tld returns NXDOMAIN, or if the request returns an error code, or if the parsed value of sequence_number = CONTINUE , then the client should then attempt the URL http://www.x-asvp.tld/PUBLIC_TLD/JOHN_Q.HTM (where tld is the top level domain from the RHS of the recipient e-mail address) If the DNS query for www.x-asvp.tld returns NXDOMAIN, or if the request returns an error code then the client should then attempt the URL http://www.x-asvp.info/TLD/PUBLIC_TLD/JOHN_Q.HTM Assuming that one of the above URL's returns a document containing 1234567890 Then the client should insert a "ASVP-WEB" header X-ASVP:V1[ASVP-WEB,1234567890,JOHN_Q@PUBLIC_TLD] If none of the above web-servers exist, or if they fail to answer, or for mailers that work purely in offline mode, or when the parsed sequence_number = DEFAULT, then the "DEFAULT" value for sequence_number should be inserted. The DEFAULT value is based on an n-bit hash calculated using the methodology of http://www.hashcash.org (The common value of n is expected to be increased as the cost of computing cycles declines. The common value expectation algorithm will always be posted on http://www.x-asvp.org ) At the time of this writing, n is dependent on the current date year in YYYY format. n = floor( (yyyy - 2000) * 2/3 ) + 20 So, for the year 2007, n = 24. In 2009 n will be 25. In 2010, 26. To create the DEFAULT sequence_value, one should calculate the current n-bit hashcash value on the e-mail address of the intended recipient in LHS_@RHS_ (i.e., all upper case alpha and all non- numerics converted to underscore) concatenated with the mailing date of the SMTP message in format YYYYMMDD. For our example, recipient John.Q@public.tld such a DEFAULT will be calculated by initiating the hashcash executable on June 11, 2007 with options: hashcash -m JOHN_Q@PUBLIC_TLD20070611 -b 24 which will return a sequence like this hashcash stamp: 1:20:070611:john_q@public_tld:\ :jhQarRVOKEQsjyWY:000000000000000000000000000000000000000000002jjA Concatenate the calculated stamp to a header stub "X-ASVP:V1[ASVP-WEB,DEFAULT" (this allows trivial filtering) In this case, the "DEFAULT" ASVP-WEB header will be X-ASVP:V1[ASVP-WEB,DEFAULT:1:20:070611:john_q@public_tld:\ :jhQarRVOKEQsjyWY:000000000000000000000000000000000000000000002jjA,\ JOHN_Q@PUBLIC_TLD] Note: The above header is all on one line, the backslash followed by carriage return is used only for formatting in this document. Note: Obviously, many end-users will filter out such DEFAULT e-mail as likely spam since these do not leave a web-server log record. Implementation: Client-recipient: If the ASVP-WEB filter is enabled, the recipient e- mail client should return TRUE (and disposition accordingly) messages that contain an X-ASVP: header that contain the string they have specified within the document. For our example. Where the URL http://x-asvp.public.tld/PUBLIC_TLD/JOHN_Q.HTM returned a document with 1234567890 Then John Q.'s recipient mail client would have a mail rule that reads If header X-ASVP contains "V1[ASVP-WEB" and contains "JOHN_Q@PUBLIC_TLD" and does not contain "1234567890" then move to Review-Delete folder. Implementation: Mail Transfer Agent (MTA) Administrators (aka: ISP's ) For-profit ISP: Trivial implementation: 1. In DNS, point X-ASVP to your webserver 2. On the webserver add a virtual host for X-ASVP.yourdomain 3. Put a default document that includes the "CONTINUE" value, i.e. CONTINUE Suggested implementation: 1. In DNS, point X-ASVP to webserver 2. On the webserver create a virtual host for X-ASVP.domainname 3. Create a redirect or rewrite rule to search individual user "web publishing" directory for a sub-directory "X-ASVP" if exists, deliver (or redirect to) the LHS_.HTM document there. 4. Host a Redirect for your domain with the "secondary" search path provider (x-asvp.tld) as your back-up webserver. 5. Create a "X-ASVP" mail account. (review and distribute "friendly bounces" according to local policy. Bounce messages for all ISP users go to x-asvp account; first whitespace includes intended recipient address concatenated with two newlines.) 6. Create a asvp.[.*] mail alias (i.e., anything starting with "asvp.") aliased to /dev/null (deals with the "cc" implementation) 7. Create meta-document for x-asvp@yourdomain.com that includes element YES (see details at x- asvp.org ) (Either user or ISP can "turn-off" FRIENDLYBOUNCE.) For Enterprises: Trivial implementation: 1. In DNS, point X-ASVP to your webserver 2. On the webserver add a virtual host for X-ASVP.yourdomain 3. Put a default document that includes some ASVP-TOKEN value, for example, suppose that is 123456, then serve all requests 123456 Suggested implementation: 1. In DNS, point X-ASVP to webserver 2. On the webserver create a virtual host for X-ASVP.domainname 3. For all requests to this webserver, return the current Enterprise ASVP-TOKEN value, then train your MTA to not accept mail without this ASVP-TOKEN. Change the ASVP-TOKEN regularly. If at all possible make the ASVP-TOKEN a "random" number generator and your MTA trained to recognize it. (Like solutions to an elliptical function configured in both the .ASP and MTA ) 4. Host your ASVP-TOKEN with the "secondary" search path provider (x- asvp.tld) for redundancy purposes. Note to MTA coders: Expect requests for a rule to reject messages should the proper Header not arrive in DATA prior to "/n./n" Note to Apache developers: expect demand for a DNSBL module, both to check DNSBL before delivering a meta-document, and to send request-by-IP count statistics to specialty DNSBL.) 5. Create a "X-ASVP" mail account. (review and distribute according to local policy.) 6. Create a asvp.[.*] (i.e., anything starting with "asvp.") mail alias to /dev/null 7. Create meta-document for x-asvp@yourdomain.com that includes element (see details at x-asvp.org ) Benefit: The overhead of compliance with this extension depends on the method that is used to generate the data element. The trivial implementation for recipients is to make sure that a document exists in the URL search path and then regardless of the defined value, just test for existence of the header. The elegance of trivial implementation is that the sender does not know whether or not the client actually uses the header to filter. Thus, ISP's that set up a X-ASVP web-server are building a toolset for identifying spam (tracking spammer IP's) whether or not their clients utilize the filter. ISP's that do NOT set up a X-ASVP web-server will become easy targets for spammers and will lose customers to other ISP's that do implement X-ASVP header methods. (Expect an Apache module implementation that correlates multiple requests from one IP and sends notification to DNSBL as well as another module that requires DNSBL look-up before delivery of meta-document.) Further discussion and implementation suggestions can be found on the X-ASVP website: http://www.x-asvp.org/ Special Implementation Note: While already "DEPRECATED", some end users provide an easy implementation path. Until client software and ISP's recognize the X-ASVP header, some users have chosen to consider a special form of the CC: header to be equivalent to "X-ASVP:V1[ASVP- WEB". They will manually search the ASVP URL search path and then create an e-mail address from the recipient's sequence_number by prepending with "asvp." and appending their own ISP as the domain. They send a Carbon Copy (i.e. include as CC: in distribution) the address asvp.sequence_number@senderISP.tld which recipients then equate to X-ASVP:V1[ASVP-WEB,sequence_number,WILDCARD@RECIPIENTISP_TLD] To indicate this, they start their sequence_number with "CC". 1.3.03. Level 2 - Basic X-ASVP Function: Inverse logic of SPF ( http://www.openspf.org ) ISP's set up a DNS server "NSX-ASVP" that lists in DNSBL-style lookup addresses that are NOT allowed to send e-mail with the domain name in the mail header 'From:' address. Usage: X-ASVP:V2[string] i.e. IP of sending MX IP in DNSBL format xx4.xx3.xx2.xx1.nsx- asvp.domain.tld - leverage existing RDBL lookup protocol - could aid ISPs in limiting domain name hijacks (e.g. domain.com could specifically list problem netblocks) - Can be done by ISP's with little effort - Recipients would configure RDBL for common communication domains - Lookup of sending IP at listed domain - "Aware" mailers could choose to implement if Hsender!=RHfrom!=RHMID 1.3.04. Level 3 - Client X-ASVP An implementation like Level 2 but allows an end-user to enable the functionality when their ISP doesn't by using a 3rd party DNS service. X-ASVP:V3[DNS,Sender,token] Implementation: DNS host: As with the DNSBL protocol, look-ups return an IP address (typically 127.0.0.1) when a record exists, or NXDOMAIN when a record does not exist. X-ASVP recommends that ISP's set up a dedicated DNS server named "NSX-ASVP" to perform this function. (Any DNSBL will work, but setting up their own gives ISP's control related to their customers. Recommended implementation is to cache from X-ASVP.tld DNSBL server.) Client-recipient: Would have specific DNSBL configured to perform a lookup of the specific DNS server provided in the V3 header.(Note: While any of the common DNSBL providers can work, nsx-asvp.x-asvp.tld is expected to be a "specialty" lookup with the first octet of the return IP representing a ranking from 1 to 250 of the level of confidence in the DNS provider.) Once the client has determined whether or not to trust the DNS server provided in the V3 header. The client would then nslookup the IP of the RHS of the parsed "From:" header (RHSIP) Like DNSBL queries, the client would perform a lookup of the RHSIP in reverse dotted notation, further qualified by the LHS_ (as defined in ASVP-WEB) and the supplied token. For example suppose an e-mail arrived with headers: From: john.q@public.tld X-ASVP:V3[nsx-asvp.someotherisp.com,1234abc6789] (Note that the client is suggesting a different DNS provider than that of their e-mail host ISP.) Step 1: The client does a DNSRBL lookup of nsx-asvp.someotherisp.com with return of some IP or NXDOMAIN Step 2: If return = some IP address then stop, flag as spam [option for Step 3: Parse first octet of IP address (127) and compare to mail client "tolerance" setting for trust level of DNS provider. It is expected that some mail clients will allow a trust setting of 1 to 250 and that clients will choose DNSBL service that utilizes the first octet as a "shade of gray" rating of the DNS rather than a pure "black" or "white"] Step 3: Note: return = NXDOMAIN (or optional "tolerance" is TRUE) Perform DNSBL style lookup at the provided DNS of the reverse format "hostname" token.LHS_.RHSIP.DNS in our example: nslookup of public.tld gives IP 216.117.151.36 so client performs DNSBL at nsx- asvp.someotherisp.com of 'hostname' 1234abc6789.JOHN_Q.36.151.117.216 Step 4: If return = some IP then disposition accordingly (spam) Pro: - Can be done by individuals without ISP cooperation - Recipient can choose to use current RBL filter to limit mail to known domains - Does not require new infrastructure - Would give incentive for next generation mail clients to enable "dynamic RBL's" 1.3.05. Level 4 - message-ID check Usage: X-ASVP:V4[prior-MID,MID(YYYYMMDD),cachesize] X-ASVP:V4[SUPPORTED, cachesize] prior-MID = a Message-ID from a received SMTP e-mail MID(YYYYMMDD) = date associated to the prior-MID in YYYYMMDD format cachesize = the number of Message-ID's a client keeps in cache for comparison SUPPORTED = Flag to indicate compliance to Function: Clients use an SMTP MESSAGE-ID: Header from a previously received message as a rolling token. Implementation: Client-sender: If enabled, clients that support V4 will insert X- ASVP:V4[SUPPORTED,cachesize] in all outgoing messages. If a client has previously received an e-mail with a V4 header from the recipient, then client should Implementation:ID#.x-asvp http://archives.neohapsis.com/archives/postfix/2006-12/0738.html Function: - Uses prior Message-ID as a dynamic token between senders and recipients 1.3.06. Level 5 - X-SPF - Extension for Client use of OpenSPF X-ASVP:V5[SUPPORTED] Function: Uses OpenSPF protocol, but allows individual users to supplement the TXT record supplied by their ISP. Implementation: Client-sender: Places additional records in the document returned at "ASVP-WEB" search path in element Client-recipient: A compliant client will search the "ASVP-WEB" search path, parse the X-SPF value and append that to the TXT record returned using the OpenSPF protocol ( http://www.openSPF.org ) Example: The document returned at "ASVP-WEB" search path may contain: ip4:146.114.192.201 mx:somedynamicdns.com If the recipient client has enabled V5, then in addition to the MTA's listed in SPF record by the client's ISP, the recipient SHOULD also accept mail sent from the specified sources. 1.3.07. Level 6 - DKIM - Gateway implementation of DKIM - TBD (http://www.dkim.org ) X-ASVP:V6[SUPPORTED,DKIM] 1.3.08. Level 7 - SPF - Strict SPF (X-SPF is not Supported) X-ASVP:V7[SUPPORTED] 1.3.09. Level 8 - HASHCASH or e-stamps X-ASVP:V8[SUPPORTED,bit-length] X-ASVP:V8[SUPPORTED,Advenge,0.05] X-ASVP:V8[SUPPORTED,CoinACME,003] X-ASVP:V8[Supported,CoinBankM,010] 1.3.10. Level 9 - PKI, OpenPGP, S/MIME, AMTP X-ASVP:V9[SUPPORTED,implementation] Example: X-ASVP:V9[SUPPORTED,PGP] Implementation: Use "ASVP-WEB" search path to locate PGP public key. It will be in returned document within element (PGP Could be implemented in both forward and reverse directions to verify sender address.) 1.4. Further Discussion There are many benefits possible from having a predictable URL associated to an e-mail address. There are any number of data elements that could be defined for public distribution. Suppose that Joe@sacto.com wanted to publish these elements associated to SMTP mail: The ASVP URL search path for Joe's e-mail is 1. http://x-asvp.sacto.com/SACTO_COM/JOE.HTM 2. http://www.x-asvp.com/SACTO_COM/JOE.HTM 3. http://www.x-asvp.info/COM/SACTO_COM/JOE.HTM Here are some other possibilities of data elements that Joe may choose to post in his meta-document: someURL PST 4122 If Joe were a do-it-yourself programmer type that uses a "trivially compliant" ISP, Joe may wish to host a Redirect page on the secondary search path provider. (i.e. Since http://x- asvp.sacto.com/SACTO_COM/JOE.HTM does not exist, or returns the ASVP- WEB value = DEFAULT ) The secondary search path for Joe is http://www.x-asvp.com/SACTO_COM/JOE.HTM If Joe already has his own website, he could have the secondary provider host a "redirect" to his own site where he places an automated ASVP-TOKEN generation script. He might do something like create a script on his own website that generates tokens on the fly using his own function. Joe could set up a script that creates a dynamic page with the value of element generated by a call to the Operating System date command. He could do something like generate a four digit number that changes once per month. 'abcd'.'date-month'.'100 - date-month' 2. Security Considerations This protocol can provide the front-end "handshake" necessary for several other e-mail authentication systems that previously required prior knowledge of public key location or recipient toolset choice. In that sense, this protocol is not intended to make a better anti- spam "mousetrap", this protocol is about describing to a sender the "mousetrap" that a recipient uses, and what it takes to get around it. It is expected that this protocol will improve the overall security of SMTP mail, as it provides for front end data exchange necessary to use systems that can include authentication, encryption and non-repudiation. 3. IANA Considerations The new infrastructure required for this to be operational is minimal. The domain name "X-ASVP" in each top level domain SHOULD be operated by a "friendly" owner who will automatically be a member of the X-ASVP controlling committee (http://www.x-asvp.org ), or redirected to the X-ASVP committee. However, even if ALL such domains are not operational or "friendly", the protocol includes a DNSBL check prior to search path initiation that can exclude such hosts from -compliant- software. 4. Conclusions The Internet community will easily leverage this standard method for locating a meta-document ("web page") based on an e-mail address. Since the meta-document is XML, it can easily be extended to include other data elements. The first use of this method is expected to be anti-spam, but that is only the beginning. Note that as more ISP's implement the protocol on behalf of their users, this becomes a peer to peer protocol with only "backup" provided by the TLD hosts and Global host. 5. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. 6. References a. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. Author's Addresses Gerald Klaas, CISSP; Paul Choate; Vincent Klaas; Eva Tanner X-ASVP Committee members 2443 Fair Oaks Blvd #147, Sacramento, CA 95825 Phone: 916-204-7695 Email: chair@x-asvp.org
Phone: Email: Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright 2007 (c) X-ASVP Committee This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Internet-Draft X-ASVP Mail Management Protocol July 2007 Klaas Expires January 5, 2008 [Page 21] X-ASVP Committee Internet Draft & X-ASVP Committee Intended status: Informational June 30, 2007 Expires: January 2008 Klaas Expires January 5, 2008 [Page 1]