Network Working Group A. Vesely Internet-Draft March 1, 2009 Intended status: Standards Track Expires: September 2, 2009 Verified-Hello SMTP extension draft-vesely-vhlo-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on September 2, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This memo defines an extension to the SMTP service whereby an SMTP client can know beforehand the reputation and whitelisting treatment for the messages that it is about to transmit. By formalizing the Vesely Expires September 2, 2009 [Page 1] Internet-Draft VHLO March 2009 trust that the receiving part grants to the sending one, using the VHLO command a sender recovers reliability at the expenses of flexibility. Table of Contents 1. Context and notes for this draft . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.1. Prime delivery . . . . . . . . . . . . . . . . . . . . 3 2.2.2. ADMDs and DNS domains . . . . . . . . . . . . . . . . 4 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. Definition and Registration of the VHLO Extension . . . . . . 4 4. Behavior of SMTP client and server . . . . . . . . . . . . . . 5 4.1. Syntax of the VHLO command . . . . . . . . . . . . . . . . 5 4.2. Server side checks on the Domain . . . . . . . . . . . . . 6 4.2.1. DNSBL check . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. SPF check . . . . . . . . . . . . . . . . . . . . . . 6 4.2.3. MX check . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.4. PTR and 'iprev' checks . . . . . . . . . . . . . . . . 7 4.2.5. VBR check . . . . . . . . . . . . . . . . . . . . . . 7 4.2.6. DKIM check . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Responses to the VHLO command . . . . . . . . . . . . . . 8 4.3.1. Positive response . . . . . . . . . . . . . . . . . . 8 4.3.1.1. VHLO parameter and MAIL FROM command . . . . . . . 9 4.3.2. Temporary error responses . . . . . . . . . . . . . . 9 4.3.3. Negative responses . . . . . . . . . . . . . . . . . . 9 4.3.4. Diagnosis of failed VHLO commands . . . . . . . . . . 10 4.4. Restrictions and further server side checks . . . . . . . 11 4.4.1. MAIL FROM restriction . . . . . . . . . . . . . . . . 11 4.4.2. VBR restriction . . . . . . . . . . . . . . . . . . . 12 4.4.3. DKIM-Signature headers existence and verification . . 12 5. Forwarding of messages accepted under VHLO . . . . . . . . . . 12 6. Submission strategy . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 16 A.1. Prime delivery message transfer . . . . . . . . . . . . . 16 A.2. Failure after DNSBL check . . . . . . . . . . . . . . . . 17 A.3. Failure on the MAIL FROM restriction check . . . . . . . . 17 A.4. Automatically finding a common vouching service . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Vesely Expires September 2, 2009 [Page 2] Internet-Draft VHLO March 2009 1. Context and notes for this draft This section is to be removed in case this document ever makes it to the RFC Editor. The ideas presented in this document stem from suggestions made by John Klensin on the ietf-smtp mailing list maintained at imc.org. Therefore, they shall be discussed on the same mailing list. Two messages bearing such suggestions: http://www.imc.org/ietf-smtp/mail-archive/msg05423.html http://www.imc.org/ietf-smtp/mail-archive/msg05444.html 2. Introduction 2.1. Rationale Email Service Providers targeting general public have to resort to anti-spam filters to limit the damage caused by spam. Such filters apply heuristic criteria, possibly including statistical analysis of the words in the message body, for determining a message's worthiness. Messages that are deemed not worth the recipient's attention, may happen to be delivered inside hidden folders, or quarantined, so that the recipient may not notice them. (Reporting a delivery failure is not an option when the sender is not trusted, because the Return-Path is most likely forged.) In order to avoid mistakenly hiding messages that may be relevant, the reputation of the sending domain is often used. Senders who enjoy a good reputation at the receiving SMTP server can have their messages whitelisted; that is to say, filtering is skipped and mail messages are delivered to the recipient's prime folders. The problem to ascertain the sender reputation and the resulting deliverability is important for reliable message transmission. 2.2. Terminology 2.2.1. Prime delivery The term "prime delivery" is used to indicate that a message is not tagged as spam, quarantined, silently dropped, or delivered in folders that are not the recipients' prime folders. In addition, the message is not edited by changing or altering its headers so as to make it less visible or discourage displaying its content, and no part of its content is dropped or replaced. Vesely Expires September 2, 2009 [Page 3] Internet-Draft VHLO March 2009 Prime delivery implies strict [RFC5321] conformance, rather than acceptance of the message. In case the message has to be forwarded to another internal or external server, its transmission SHALL attempt to preserve the trust and reputation that was granted on acceptance, as detailed in Section 5. Failure to do so MUST be reported as indicated by [RFC5321]. 2.2.2. ADMDs and DNS domains The concept of an ADministrative Management Domain (ADMD) is described in [I-D.crocker-email-arch] as an actor having its own administrative authority. For the purposes of this document, an ADMD may be identified as a set of hosts sharing the same policies and possibly coordinated with one another. DNS domain names are delegated to organizations or individuals. Thus, in the simple cases, an ADMD corresponds to one or more DNS domain names, the association being recognizable by registrant name in whois databases records. However, privacy concealments and virtual hosts complicate this topic enough to discourage easy categorizations. 2.3. Requirements Language 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 [RFC2119]. 3. Definition and Registration of the VHLO Extension According to [RFC5321] provisions, the definition for this extension goes as follows: o the textual name of this extension is "Verified Hello"; o the EHLO keyword associated with the extension is "VHLO"; o the parameter associated with the EHLO keyword is a random value up to 16 octets long (see Section 4.3.1.1); o this extension defines one additional verb, VHLO, whose only mandatory parameter is the Domain name of the sender's ADMD, possibly followed by one parameter for each reputation tag (see Section 4.1); o VHLO is also defined as one additional parameter to the MAIL verb (see Section 4.3.1.1), none are defined for the RCPT verb; Vesely Expires September 2, 2009 [Page 4] Internet-Draft VHLO March 2009 o supporting the extension affects the behavior of a server and client SMTP as described in Section 4; and o the maximum length of the MAIL command is increased by 22 octets, while the RCPT command is not affected. In addition, as required by [RFC4409], this extension MAY be valid on the Submission port. 4. Behavior of SMTP client and server The VHLO command is used by a client to request prime delivery of messages. If the server accepts the command by giving a positive response (see Section 4.3.1), all messages transmitted thereafter until either the end of the session or a further successful VHLO command are considered in the framework of the former VHLO command. An SMTP client MAY issue the VHLO command as part of a session initiation, before initiating a mail transaction. That is to say, right after the EHLO command, or instead of it. (In the latter case, of course, the client has to infer that the server supports this extension by some other means.) Clients may attempt the VHLO command various times with different parameters (see Section 4.3.3). After successfully transmitting one or more messages in the framework of a successful VHLO command, a client MAY issue another VHLO command to transmit more messages on behalf of a different Domain. The server MUST ensure prime delivery of the messages accepted in the framework of a successful VHLO command. These messages are subject to MAIL FROM restriction, and, possibly, to DKIM-Signature headers existence and verification and VBR restriction (see Section 4.4). 4.1. Syntax of the VHLO command The only mandatory argument to VHLO is Domain. The syntax is as follows: vhlo = "VHLO" SP Domain *( SP auth-rept-claim) CRLF auth-rept-claim = auth-rept-tag [ ":" tag-spec-param ] auth-rept-tag = "MX" / "PTR" / "VBR" / "DKIM" / further-tag tag-spec-param = vbr-param / dkim-param / further-param where the Domain is the fully-qualified DNS domain name delegated to the entity or organization that is responsible for sending the Vesely Expires September 2, 2009 [Page 5] Internet-Draft VHLO March 2009 message(s) that will be transmitted in the framework of this command. Note that, unlike the EHLO command, the Domain is not necessarily the host name of the SMTP client. The maximum line length of the VHLO command is 1000 octets, including the terminating CRLF. A number of arguments MAY be supplied to authenticate the domain name or provide hints for its reputation. These arguments are supplied spontaneously by the client, up to the maximum line length. 4.2. Server side checks on the Domain The receiving server SHOULD check that the supplied domain is valid and reckon its reputation. The server is not limited by the checking methods indicated in the parameters. In particular, it is RECOMMENDED that DNSBL, 'iprev', and SPF checks are carried out anyway. While this section indicates circumstances for the failure of each single check, it is up to the local policy to establish what combinations of successful checks yield positive responses. 4.2.1. DNSBL check The server SHOULD check any relevant DNSBL, and, if a DNSBL that the server, according to its policy, considers trustworthy for either rejecting messages or degrading their worthiness, gives a positive match, then the server SHOULD issue a negative response. See [I-D.irtf-asrg-dnsbl] for details on this check. 4.2.2. SPF check If the server carries out SPF checks, it SHOULD check the supplied Domain using the method described in [RFC4408], and, if that results in a "fail", the server SHOULD issue a negative response. According to its policy, the server MAY issue a negative response when the result is anything but "pass". Note that the so-called "helo check" often gets a result of "none" because [RFC4408] does not provide for SPF (or TXT) RRs to be valid for a whole zone, and many hostmasters omit to define an SPF policy for each host. Unlike EHLO, the Domain argument taken by VHLO points to the sending domain, not the host. Because of the MAIL FROM restriction, no further SPF checks are required for transactions in the framework of this VHLO command. Vesely Expires September 2, 2009 [Page 6] Internet-Draft VHLO March 2009 4.2.3. MX check The MX auth-rept-tag suggests that the client is connecting from an IP address that belongs to one of the Domain's MX servers. The receiving server SHOULD lookup the MX records of the given Domain and successively lookup the addresses (A or AAAA depending on the connection) of each of the hosts listed therein, until it finds a matching address or the list is exhausted. If no match was found, the server SHOULD issue a negative response. 4.2.4. PTR and 'iprev' checks The PTR auth-rept-tag suggests that the client is connecting from an IP address that can be resolved backward to an host name under the given Domain's hierarchy. Note that this also works for Top Level Domains or branches of ccTLDs whose ADMDs run no mail services, hence the added delegation check. The receiving server SHOULD lookup the PTR records for the connecting address and verify that at least one of the returned RRs contains a host name whose rightmost part matches the Domain. In addition, the authoritative Name Server for the domain must match the NS for the host name thus found. If no match was found, the server SHOULD issue a negative response. The server SHOULD also check that the name found thereby resolves forward, possibly through a CNAME, to the connecting address, as indicated by the 'iprev' Authentication Method described in [I-D.kucherawy-sender-auth-header]. 4.2.5. VBR check The VBR auth-rept-tag provides a list of vouching services: vbr-param = [ "mc=" type-string ";" "mv=" ] certifier-list certifier-list = domain-name *( ":" domain-name ) The receiving server SHOULD carry out the VBR validation process as it would be done for a VBR-Info header containing the corresponding elements, see [I-D.hoffman-dac-vbr]. 4.2.6. DKIM check The DKIM auth-rept-tag asserts that all messages transmitted in the framework of this VHLO command (in case it is successful) have a DKIM-Signature header whose domain (d) tag matches the Domain in the VHLO command. The parameter contains additional properties of such Vesely Expires September 2, 2009 [Page 7] Internet-Draft VHLO March 2009 signatures: See [RFC4871] for imported ABNF dkim-param = sig-s-tag *( ";" sig-tag ) where the sig-tag's are selected parts of the DKIM-Signature header. Note that the parameter MUST NOT contain any whitespace. At least the sig-s-tag for the selector (and the sig-q-tag if a query method different than "dns/txt" is used) MUST be provided. The algorithm (a) and the header list (h) tags might also possibly be used by the server to reckon reputation. The receiving server MAY fetch the public key required to verify the DKIM signatures. If the key does not exist, the server SHOULD issue a negative response. 4.3. Responses to the VHLO command An ADMD accepts incoming mail messages according to some policies. The requisites for according a positive reply to a VHLO command SHOULD NOT be less strict than those for accepting an incoming message. In particular, if a policy states that certain conditions imply that a message would be accepted with some reserves, it should likely state that VHLO is denied under the same conditions. When processing the optional auth-rept-claim's parameters, the server MUST ignore any parameter whose tag it does not support or understand. In case of unsuccessful response, the server retains its previous state. 4.3.1. Positive response If the checks carried out on the Domain and the connection indicate that the server will wholeheartedly accept messages from the client, the server returns a 250 reply code. The response is a multi-line response with the same format as the EHLO response (ehlo-ok-rsp in [RFC5321]), with the keywords for all the SMTP extensions available as a consequence of entering this VHLO framework. Upon a positive response, the client MUST reset any flags and variables associated to SMTP extensions that it may have since previous EHLO or VHLO commands in the same session. Vesely Expires September 2, 2009 [Page 8] Internet-Draft VHLO March 2009 4.3.1.1. VHLO parameter and MAIL FROM command The server response to the VHLO and EHLO commands includes the VHLO keyword along with a randomly generated token of up to 16 octets. The format of the relevant line is as follows: ehlo-line = "VHLO" SP random-string random-string = 1*16( %d33-60 / %d62-126 ) ; any CHAR excluding "=", SP, and control ; characters. The random string supplied by the server MUST be repeated by the client as the value of the VHLO parameter to the MAIL command, for each transaction in the framework of this VHLO command. This is meant to guard against blind attacks. 4.3.2. Temporary error responses If the the server is temporarily unable to carry out any required check on the Domain, it SHOULD return the 451 reply code. Then, the client SHOULD quit the session and retry at a later time. The server MAY return the 450 reply code to indicate that it is not able or willing to reckon the client's reputation during this section, irrespectively of any parameter supplied. In this case, the client MAY try an EHLO command instead, to transmit messages outside of any VHLO framework. The server MAY return the 455 reply code to indicate that it is temporarily unable to carry out the checks implied by one or more specific parameters. It is possible that a positive response is given if the client repeats the command using different auth-rept- claim's or different tag-spec-param's. The text of the response SHOULD indicate the missing parameters as described in Section 4.3.4. 4.3.3. Negative responses If the the server cannot grant prime delivery because of a missing parameter or parameter's value in the VHLO command, it SHOULD return the 555 or 550 reply codes indicating the missing parameters and arguments as described in Section 4.3.4. The server MAY return the 553 reply code to indicate that it will never grant prime delivery for the given Domain to the current client, whatever auth-rept-claim's the client may supply. The server MUST return the 503 reply code (bad sequence of commands) Vesely Expires September 2, 2009 [Page 9] Internet-Draft VHLO March 2009 if a VHLO command is issued while a transaction is active. The server MAY also return the 500 or 502 reply codes to indicate that it does not support this extension. After a 555 reply code, the client MAY retry a VHLO command with the parameters modified accordingly. Otherwise, if it is unable to satisfy the server requirements, the client SHOULD proceed as if it obtained a 500 reply code. It is RECOMMENDED that the application logs the missing requirements, so that administrators know how to gain access to the given server. After reply codes 500, 502, 550, and 553, the client MUST NOT attempt more VHLO commands during the current session. In addition, after reply codes 550 and 553, the client SHOULD NOT attempt further VHLO commands to this server until human intervention updates its configuration. After reply codes 500, 502, 550, 553, and 555, the client MAY quit the session and send the message through an alternative relay as described in Section 6. Alternatively, the client MAY try an EHLO command instead, to transmit messages outside of any VHLO framework. 4.3.4. Diagnosis of failed VHLO commands Normally, a client supplies all the claims that can possibly result in increased reputation, except for line length limitations. VBR's certifier-list's, for example, might grow quite long and clients may be unable to store them on a single line. However, servers can issue multi-line responses containing the complete list, so that a client can select the correct certifiers to include in the next attempt. As some failures can be worked around automatically, failure responses SHALL contain both human readable text and machine readable text. Formally: Vesely Expires September 2, 2009 [Page 10] Internet-Draft VHLO March 2009 Failure-resp = *( Failure-code "-" [ diag-text ] CRLF ) Failure-code [ SP diag-text ] CRLF Failure-code = %x34-35 %x30-35 %x30-39 diag-text = [ hread-text ] [ "+" mread-text ] hread-text = *( %d09 / %d32-57 / %d59-126 ) ; regular characters except ":" mread-text = auth-rept-claim / check-failed check-failed = check-keyword ":" check-spec-info check-keyword = "DNSBL" / "SPF" check-spec-info = hread-text A server SHOULD NOT vary its requirements during a given session. If a client manages to issue a successful VHLO command for a given Domain after a previous attempt failed, it MAY store the parameters for future reuse. However, the server requirements MAY be changed in future sessions. 4.4. Restrictions and further server side checks Messages transmitted in the framework of a successful VHLO command are subject to the restrictions detailed in this section. Clients MUST NOT attempt to break these restrictions. Servers SHOULD check that clients comply. 4.4.1. MAIL FROM restriction Non-empty arguments of the MAIL FROM commands are restricted to addresses whose domain part is compatible with the Domain given in the relevant VHLO command. Compatible here means that either the two domains names are identical, or they share at least one primary mail exchanger. Formally, the two domain names match a caseless comparison; or one [or both] of them is a CNAME label of a DNS RR whose value eventually refers to the other [or, respectively, a common canonical name]; or the two domain names, after resolving any CNAME aliasing, both have MX RRs and the respective lists of primary (lowest preference) hosts have a common element, i.e. two host names that match a caseless comparison. Note that no IP address comparison is involved. Vesely Expires September 2, 2009 [Page 11] Internet-Draft VHLO March 2009 In addition, the server MUST check that the VHLO parameter is included and that the corresponding value matches the random string that the server generated on giving the positive response to the VHLO command. 4.4.2. VBR restriction If the VHLO command in whose framework the message is received contained a VBR tag, the message MAY have a VBR-Info header. If that header is present, it MUST be compatible with the given vbr-param. Compatible here means that it mentions at least the certifier that the server trusts and verified before accepting the relevant VHLO command. If a VBR-Info header is not present, the receiving server MAY add one based on the Domain given, the certifiers it trusts and verified, and its guess of the type of content. 4.4.3. DKIM-Signature headers existence and verification If the VHLO command in whose framework the message is received contained a DKIM tag, the message MUST have a DKIM-Signature header compatible with the given dkim-param. Compatible here means that the domain (d) of the DKIM-Signature is the same, the selector (s) is the same one given in the parameter, the signed header fields in the DKIM-Signature contain at least the ones given in the parameter, and the signing algorithm given in the parameter, if any, matches the one actually used. In addition, if the server verifies signatures on the fly, the verification fails, and such failure would prevent the message from having a prime delivery, the server SHOULD reject the message instead. 5. Forwarding of messages accepted under VHLO A message accepted in the framework of a VHLO command deserves prime delivery. However, the receiving server possibly does not host the mailboxes of the relevant recipients directly. For example, it may be a boundary or secondary exchanger, a vanity address server, or it may be following user-specific forwarding instructions. For this specification, we just distinguish if the message is forwarded within the same ADMD or to an external domain. If the message is forwarded internally, all hosts MUST be configured so as to honor the promise of prime delivery that border or secondary exchangers grant on their behalf. If, for whatever reason, prime Vesely Expires September 2, 2009 [Page 12] Internet-Draft VHLO March 2009 delivery is not possible, a failure notification MUST be sent to the Return-Path address, if any. Even if sending notifications is expected to be fairly safe at this point, it is RECOMMENDED that any ADMD-wide policy that can be applied on acceptance produces an on- line rejection rather than a delayed failure notification. If the message if forwarded to an external domain, the SMTP client MUST attempt to issue a VHLO command, unless either it can determine that the target host does not implement this SMTP extension, or it has some other arrangement with the target host that grants prime delivery (e.g. using [ff]). Note that, if VHLO is used for forwarding, unless the ADMD is an authorized sender for the original Domain, the Return-Path MUST be changed to that of a Domain delegated to the ADMD that is doing the forwarding (e.g. using [srs]). 6. Submission strategy Small and medium organizations may lack the global reputation that would ensure high deliverability to their SMTP relays. To increase the deliverability of their messages, they may use an MSA from a larger organization. However, privacy concerns and mail flow optimization would suggest to resort to external MSAs only when that is necessary for message deliverability. The VHLO command, by allowing to check deliverability in advance, enables clients to use smart hosts optionally. Rather than configuring a fixed mail out path for certain target domains, relays can dynamically adjust their strategy according to the target host's response to the VHLO command. The list of preferred VBR certifiers provided by a negative response may be used as keys to build a corresponding list of smart hosts that can be used as Mail Submission Agents, provided that the certifiers of each smart host are known. 7. IANA Considerations This extension will have to be inserted in the mail-parameters assignments IANA registry. The keyword VHLO may appear o as a service type (possibly), o as an SMTP extension keyword, and o as an SMTP extension keyword that has a parameter. (Apparently, there is no registry of the MAIL command parameters that are used by various extensions.) Vesely Expires September 2, 2009 [Page 13] Internet-Draft VHLO March 2009 A registry is needed for tracking the auth-rept-tag / check-keyword that must be unique in the diagnostic text. This document defines DKIM DNSBL MX PTR SPF VBR 8. Security Considerations This document proposes an intermediate level of trust. An SMTP client is being authenticated based on weak evidence, originating from the DNS and the TCP layer: o The IP address of the remote client is known from the TCP layer. Verification of the random string implies it is fairly difficult to forge it. o Any of the MX, PTR, or SPF checks confirms that the IP address is somehow authorized by the domain's ADMD. o The DNSBL check implies that the IP address is not that of a known attacker. The two remaining checks, DKIM and VBR, may provide two additional characterizations of the messages being transmitted. DKIM ensures that messages have passed through the domain's signing process, which presumably implies that any sender's local policy has been enforced. In this respect, DKIM is most useful if the sending ADMD does not have a fine grained control on their PTR, MX, or SPF settings. VBR, depending on the certifier's policy, may generically ensure that the sending domain is well behaved. A vouching service may scrutinize the DNS settings of a given domain, check their spam rate using honeypots, investigate the domain's users, or otherwise establish the domain reputation. The possibility to communicate the preferred vouching services may work as an incentive for the advertised service providers. The authentication provided by this extension is weaker than SMTP Vesely Expires September 2, 2009 [Page 14] Internet-Draft VHLO March 2009 Authentication [RFC4409]. Therefore, it SHOULD NOT be used instead of it. Diagnostic messages provided with negative responses to the VHLO command may disclose acceptance policies of the target domain. This is not considered harmful, since such policies are usually public. However, in case the security structure depends on keeping that information secret, the server should carefully consider what diagnostic messages it provides to what clients. It is possible to provide VHLO services to selected domains only, and discarding the rest with the reply code 553. 9. References 9.1. Normative References [I-D.hoffman-dac-vbr] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", draft-hoffman-dac-vbr-07 (work in progress), February 2009. [I-D.kucherawy-sender-auth-header] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", draft-kucherawy-sender-auth-header-20 (work in progress), January 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. Vesely Expires September 2, 2009 [Page 15] Internet-Draft VHLO March 2009 9.2. Informative References [I-D.crocker-email-arch] Crocker, D., "Internet Mail Architecture", draft-crocker-email-arch-11 (work in progress), October 2008. [I-D.irtf-asrg-dnsbl] Levine, J., "DNS Blacklists and Whitelists", draft-irtf-asrg-dnsbl-08 (work in progress), November 2008. [ff] FixForwarding.org, "solution proposed", 2009, . [srs] Libsrs2.org, "libsrs2 - Home", 2004, . Appendix A. Examples Some examples showing the relevant snippet of client-server dialog. A.1. Prime delivery message transfer Complete example where the client successfully transfers a message S: 220 example.com SMTP server ready C: VHLO example.net S: 250-example.com greetings example.net 250 VHLO 0123456789ABCDEF C: MAIL FROM: VHLO=0123456789ABCDEF S: 250 Ok C: RCPT TO: S: 250 Ok C: DATA S: 354 Go ahead S: From: author@example.net To: dest@example.com Subject: test This is transmitted with prime delivery! . S: 250 Ok C: QUIT S: 221 Bye Vesely Expires September 2, 2009 [Page 16] Internet-Draft VHLO March 2009 A.2. Failure after DNSBL check Colons have been replaced in the automatic message to formally preserve machine readability C: VHLO example.net S: 555-You are blacklisted 555 :DNSBL:see http_//www.dnsbl.example/query/bl?ip=192.0.2.3 C: QUIT S: 221 Bye A.3. Failure on the MAIL FROM restriction check In this snippet, the domain names are mismatched C: VHLO example.net S: 250-example.com greetings example.net 250 VHLO 0123456789ABCDEF C: MAIL FROM: VHLO=0123456789ABCDEF S: 550 Domain origin mismatch C: QUIT S: 221 Bye A.4. Automatically finding a common vouching service In this snippet, the client finds a valid VBR name C: VHLO example.net MX VBR:vouch1.example:vouch2.example S: 555-we only accept these :VBR:vouch97.example:vouch98.example 555-:VBR:vouch99.example:vouch100.example:vouch101:example 555 :VBR:vouch102:example:vouch103:example:vouch104:example C: VHLO example.net MX VBR:vouch100.example:vouch101.example S: 250-example.com greetings example.net 250 VHLO 0123456789ABCDEF Author's Address Alessandro Vesely via L. Anelli 13 20122 Milano (MI) Italy Email: vesely@tana.it Vesely Expires September 2, 2009 [Page 17]