Verified Hello SMTP extension
draft-vesely-vhlo-06
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Alessandro Vesely | ||
| Last updated | 2010-06-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Verified Hello (VHLO) is an SMTP extension for managing authorization by policy, as done for whitelisting messages. The VHLO command verb provides for weak authentication of SMTP clients and policy negotiation. Policies and reputation are being increasingly used to identify messages worthiness. However, they are currently enforced by rejecting SMTP transactions, or discarding messages. Feedback is scarce, also because reply codes are difficult to interpret automatically. Negotiation is not provided for. VHLO is designed so that servers can provide feedback to their clients about which vouching services or authentication methods they require. Credentials can also be negotiated on the fly, in order to allow clients to learn whether messages will be whitelisted by the receiving server before actually transmitting them. Negotiation and feedback are intended to ease rapid diffusion of popular reputation systems and authentication methods. A IANA register is defined for extending the set of available methods. The VHLO command is similar to EHLO, but accepts a series of parameters. The sender communicates the mail domain name of the organization on whose behalf it operates, along with any vouching services (VBR) for its reputation. On the other hand, the sending host's affiliation with that mail domain is checked by DNS lookups (MX, PTR, or SPF) or using DKIM. DNSBLs and Greylisting are also considered. Weakly authenticated clients enjoy an intermediate level of trust: they have no relying privileges, but may attempt to deliver mail to local users, are whitelisted from some filters, and may receive DSNs and feedback-loop abuse reports as needed. However, failing to succesfully negotiate VHLO authentication does not preclude a client's ability to relay mail: It may relay as usual; that is to say, without knowing whether the credentials it tries to provide have any meaning for the receiving server.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)