[ietf-clear] First Cut

There is more here than likely expected. Let me know what should be
removed or added. Removal is an easy process. Something I did not show
was combining the CSA-CSV Version/Weight fields into a single field that
utilizes the same versioning as found within the CSP draft.

-Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mipassoc.org/pipermail/ietf-clear/attachments/20041220/e77f91a0/draft-otis-clear-policy-00a-0001.html
-------------- next part --------------

CLEAR / SMTP D. Otis
Internet-Draft Mail Abuse Prevention System
Expires: June 20, 2005 D. Crocker
Brandenburg InternetWorking
J. Leslie
JLC.net
December 20, 2004

Client SMTP Policy (CSP)
draft-otis-clear-policy-00

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.

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 June 20, 2005.

Abstract

For domains sending mail, there is often a desire to publish policies
indicating types of mail sent. Need for a domain based mail policy
facility has become pronounced as many find their server and mailbox
domains forged to usurp and thus potentially damage reputations. It

Otis, et al. Expires June 20, 2005 [Page 1]

Internet-Draft CS-Policy December 2004

could be advantageous, as example, to request refusal of mail where
the [RFC2821] HELO/EHLO does not reference a [ID-CSVCSA] record.
These policies may include other prescriptions, such as to request
refusal of mail not digitally signed. This document also
standardizes Name and IP address lists useful for whitelisting to
implement policy exceptions.

Table of Contents

1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Policy Records . . . . . . . . . . . . . . . . . . . . . . . 4
5. Client SMTP Policy . . . . . . . . . . . . . . . . . . . . . 5
6. Mail Channel Name List . . . . . . . . . . . . . . . . . . . 5
7. Mail Channel Address List . . . . . . . . . . . . . . . . . 6
8. Domain administrator advice . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1 Normative References . . . . . . . . . . . . . . . . . . . 7
10.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . 10

Otis, et al. Expires June 20, 2005 [Page 2]

Internet-Draft CS-Policy December 2004

1. Overview

Terminology: Terminology conforms to [ID-mail-arch].

Terms used in the context of this document:
Mail Channel- a prescribed set of Mail Transfer Agents identified
by either a list of HELO/EHLO domains or IP addresses in CIDR
notation.

Mailbox Domain- the portion of the mailbox address on the right
hand side of the "@" symbol.

Discussion: The venue for discussing this proposal is the CLEAR
working group. <http://mipassoc.org/clear/>

2. Introduction

The CSP policy proposed is published in the Port field within the
[ID-CSVCSA] record. Domains MAY publish a Client SMTP Policy (CSP)
indicating policies that express compliance with various email
authentication mechanisms. There MAY be the presents of a Mail
Channel Name List (MCNL) or the Mail Channel Address List (MCAL)
records, for lists of associated HELO/EHLO names or client IP
addresses respectively, to assist assessments by the mail recipient.

Domains wishing to assert a level of compliance for their domain, or
to assist recipients in creating whitelist exceptions, express this
by publishing compliance and mail channel information. In addition
to the CSP compliance information, there are and two types of records
to prescribe nominal HELO/EHLO names or IP addresses that may assist
name or address based whitelisting. The Mail Channel Address List
(MCAL) enables an exception or whitelisting that may be applied. The
Mail Channel Name List (MCNL) may be applied to assert HELO/EHLO
names to check whether [RFC2821] or [RFC2822] Mailbox Domains are
within their nominal Mail Channels.

3. Background

To prevent the spoofing of a domain for sending mail, by indicating a
higher level of compliance with new authentication mechanisms, this
offers protections with a determinate burden for the recipient.
Together with asserted compliance, a means to prescribe the nominal
Mail Channel is provided. The Mail Channel Name List delegates to
other domains without requiring follow-on queries by utilizing the
name authenication made available from Client SMTP Validation (CSV)
[ID-Clear-CSV]. By listing authenticated and authorized HELO/EHLO
domains to prescribe the Mail Channel, there is no need to resolve to

Otis, et al. Expires June 20, 2005 [Page 3]

Internet-Draft CS-Policy December 2004

an address which requires subsequent lookups. As an alternative to
name based whitelisting, the forwarding domain may publish its
whitelist using a CIDR based record list.

4. Policy Records

There is the Client SMTP Policy (CSP) found within the Port field
within [ID-CSVCSA] record and two additional DNS records defined by
this document. Each of these additional records are obtained by also
prepending the "_client._smtp." sub-domains to a domain reference.
The record types delineate their content. The CSP is defined as a
single 16 bit value, the list of HELO/EHLO domain names (MCNL) is
defined using PTR records, and the address list of the Mail Channel
(MCAL) is defined using APL records defined in A DNS RR Type for
Lists of Address Prefixes [RFC3123].

Reference to a MAIL Channel Name List based upon Mailbox Domains may
allow exceptional handling for mail determined to be within a
prescribed Mail Channel.

The process of deciding on the policies indicated by the CSP field
and two channel records requires performing a series of conceptually
discrete steps:

Client SMTP Policy:
What are the asserted policies for the domain?

This is obtained by obtaining and decoding the Client SMTP Policy
(CSP). Does this domain require compliance with CSV or a Digital
Signature method? Should compliance with either CSV or a Digital
Signature be lacking, the message SHOULD be rejected with either
"550 CSV Compliance Failure." or "550 Digital Signature Compliance
Failure." depending upon the reason for the rejection.

Nominal Mailbox Domain Channel:
Mail handling may be assisted by determining the nominal Mail
Channel for Mailbox Domains by performing a MCNL PTR record lookup
and finding a match with the current CSV HELO/EHLO domain name.

Exceptions would occur with forwarded mail. Alternative rules may
apply when the Mailbox Domain is not within the perscibed Mail
Channel in the case where the mail has been forwarded.

Otis, et al. Expires June 20, 2005 [Page 4]

Internet-Draft CS-Policy December 2004

Nominal Client IP Address:
Recipients may wish to apply exceptions based upon the IP address
for specific Mailbox Domains are assisted by being able to compile
these addresses using the Mail Channel Address List Record for the
specific Mailbox Domain.

5. Client SMTP Policy

The Client SMTP Policy (CSP) is an encoded 16 bit value used to
indicate authentication compliance.

The Version and Compliance components are summed together within the
field and are treated independently. The most significant nibble
represents the current version of this document shifted left 12
places or multipled by 4096. The Version component defines the
revision level of this mechanism starting at 1. The Compliance
component comprise a summation of values used to provide various
indications.

+--------------+----------------------------------------------------+
| Compliance | Meaning |
| Bit Value | |
+--------------+----------------------------------------------------+
| 1 | CSV: This domain uses CSV for all SMTP clients. |
| 2 | Signed: This domain uses public key digital |
| | signatures for all sent messages. |
| - | Other bit values are reserved for expansion and |
| | must be set to zero. |
+--------------+----------------------------------------------------+

The value 4097 decimal would be an example of Version 1 with CSV
compliance.

6. Mail Channel Name List

The Mail Channel Name List RR is comprised of a series of PTR
records. As example:

_client.smtp.domain. IN PTR our-domain.com
_client.smtp.domain. IN PTR our-access-provider.com

The target of the PTR record should be treated as a wildcarded record
when doing a comparison with the HELO/EHLO domain presented by the

Otis, et al. Expires June 20, 2005 [Page 5]

Internet-Draft CS-Policy December 2004

CSV process. Taking the example our-domain.com would then match with
the HELO/EHLO domain mx01.sjc.our-domain.com.

7. Mail Channel Address List

The Mail Channel Address List RR is comprised of a series of APL
records. As example:

_client.smtp.domain. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28

The use of the address negation "!" is to exclude a range of
addresses from a larger list. These lists of CIDR blocks are used to
enable the whitelisting of this domain for the purposes of
selectively enabling this domain to bypass content processing.

8. Domain administrator advice

Placement of Policy and Mail Channel information should be at the
root of the domain being protected. To ensure reputation is best
protected, the entire zone should be in compliance. Those recipients
wishing to discover this information may need to investigate each
node within the domain tree.

Currently the DNS structures within the UDP packet has a limit of 512
octets. Replies requiring more than 512 octets may create UDP
fragmentation and, depending upon the connection and handling, in
addition to a higher rate of packet loss, may also cause truncated or
partial replies. Furthermore, delivery and resolver handling of
truncated and partial responses varies, leading to additional delays
and queries. Domain administrators are strongly advised to keep DNS
replies below 512 octets for these reasons.

With a complete response to an MCAL or MCNL query, the SMTP server is
able to implement whitelisting. To help ensure complete and coherent
answers are obtained from cached records, TTL values of the MPR, MCAL
and MCNL records should be the same. Beware some DNS server
implementation consider the SOA TTL as a default rather than a
minimum.

9. Security Considerations

The nature of the security requirements for Mail Policies are
significantly different from typical, "strong" methods required for
most Internet security functions.

This proposal also relies on security of the underlying IP network
and on the integrity of DNS data.

Otis, et al. Expires June 20, 2005 [Page 6]

Internet-Draft CS-Policy December 2004

There is no way a site can keep its hosts from being referenced as
servers. This could lead to denial of service.

DNS spoofers can supply false addresses. Because this vulnerability
exists already with names and addresses, this is not a new
vulnerability, merely a slightly extended one. However, as the
Client SMTP Policy records are used in an authorization context, the
DNS servers can be protected by DNSSEC [RFC3008] should this
vulnerability become intractable.

The proposal relies on the integrity and authenticity of DNS data.

10. References

10.1 Normative References

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.

[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.

[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.

[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.

[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.

[RFC2554] Myers, J., "SMTP Service Extension for Authentication",
RFC 2554, March 1999.

[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.

[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.

[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
Signing Authority", RFC 3008, November 2000.

[RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes",

Otis, et al. Expires June 20, 2005 [Page 7]

Internet-Draft CS-Policy December 2004

RFC 3123, June 2001.

10.2 Informative References

[ID-CLEAR-CSVDNA]
Leslie, J., Crocker, D. and D. Otis, "Domain Name
Accreditation (DNA)", July 2004.

[ID-CSVCSA]
Otis, D., Crocker, D. and J. Leslie, "sending SMTP client
Authorization (CSA)", June 2004.

[ID-Clear-CSV]
Crocker, D., Otis, D. and J. Leslie, "Client SMTP
Validation (CSV)", July 2004.

[ID-mail-arch]
Crocker, D., "Internet Mail Architecture", May 2004.

Authors' Addresses

Douglas Otis
Mail Abuse Prevention System
1737 North First Street, Suite 680
San Jose, CA 94043
USA

Phone: +1.408.453.6277
EMail: dotis(_at_)mail-abuse(_dot_)org

Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086
USA

Phone: +1.408.246.8253
EMail: dcrocker(_at_)brandenburg(_dot_)com

Otis, et al. Expires June 20, 2005 [Page 8]

Internet-Draft CS-Policy December 2004

John Leslie
JLC.net
10 Souhegan Street
Milford, NH 03055
USA

Phone: +1.603.673.6132
EMail: john(_at_)jlc(_dot_)net

Appendix A. Acknowledgements

John Levine, Tony Finch, and Sam Silberman provided helpful comments.

Otis, et al. Expires June 20, 2005 [Page 9]

Internet-Draft CS-Policy December 2004

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(_at_)ietf(_dot_)org(_dot_)

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 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 (C) The Internet Society (2004). 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.

Otis, et al. Expires June 20, 2005 [Page 10]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-otis-clear-policy-00a.xml
Type: text/xml
Size: 41979 bytes
Desc: not available
Url :
http://mipassoc.org/pipermail/ietf-clear/attachments/20041220/e77f91a0/draft-otis-clear-policy-00a-0001.xml
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mipassoc.org/pipermail/ietf-clear/attachments/20041220/e77f91a0/draft-otis-clear-csv-csa-02b-0001.html
-------------- next part --------------

CLEAR / SMTP D. Otis
Internet-Draft Mail Abuse Prevention System
Expires: June 20, 2005 D. Crocker
Brandenburg InternetWorking
J. Leslie
JLC.net
December 20, 2004

Client SMTP Authorization (CSA)
draft-otis-clear-csv-csa-02

Status of this Memo

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 June 20, 2005.

Abstract

Internet operation has typically required no public mechanism for
announcing restriction or permission of particular hosts to operate
clients or servers for particular services on behalf of particular
domains. What is missing is an open, interoperable means by which a

Otis, et al. Expires June 20, 2005 [Page 1]

Internet-Draft Mail-CSA December 2004

trusted agency can announce authorization for a host to operate a
service. The current specification supports this capability for
sending SMTP clients. Specifically, is a sending SMTP client
permitted to act as a client MTA? Has a separate authority given it
permission to perform this service? Client SMTP Authorization (CSA)
specifies a DNS-based record that states whether an associated host
has permission to operate as a client MTA.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Client SMTP Authorization SRV Record . . . . . . . . . . . . 5
6. Domain administrator advice . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
9. Working Group Evaluation . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1 References - Normative . . . . . . . . . . . . . . . . . . 9
10.2 References - Informative . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . 12

Otis, et al. Expires June 20, 2005 [Page 2]

Internet-Draft Mail-CSA December 2004

1. Introduction

Internet mail suffers from the operation of hosts acting as mail
transfer agents (MTA) without any meaningful cross-net
accountability. This makes it impossible to vet MTAs or find
recourse when their operations cause problems. Many of these hosts
have been compromised and turned into unwilling participants in large
networks of hostile MTAs that send spam and worms, and contribute to
denial of service attacks. Enhancing the Internet mail transfer
service to deal with these issues requires identification,
authentication, authorization and accreditation capabilities about
the sending SMTP client, as per [ID-Clear-CSV]. The current
specification addresses the requirement for explicit authorization.

It is important to distinguish this security function from
authentication. Authentication establishes that a name is being used
legitimately. Authorization establishes that the name is permitted
to perform a particular service. The relationship between these two
functions is that once a client of an exchange is authenticated, then
it is possible to query the permission of that client to perform
specific services.

This specification defines a mechanism to permit session-time
verification that a connecting SMTP client is authorized to request
service as a mail transfer client. The mechanism uses a DNS SRV
[RFC2782] record as a basis for verifying that the associated domain
name is authorized to act as an SMTP client. The mechanism is small,
simple and useful. Separate mechanisms provide the means of
authenticating that the domain name is associated with the connecting
host, and accrediting the agency that is authorizing the sending
host's operation as an SMTP client.

Use of the mechanism specified here MAY also satisfy the
authentication requirement. This can occur as a side-effect of the
DNS server response optimization that returns IP Address mappings in
the Additional Information portion of a response.

Terminology: Terminology conforms to [ID-email-arch].

2. Definitions

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 [RFC2119].

Otis, et al. Expires June 20, 2005 [Page 3]

Internet-Draft Mail-CSA December 2004

3. Model

The SMTP [RFC2821], [RFC0821] protocol permits a client to declare
its affiliation, by asserting a domain name in the HELO or EHLO
announcement.

The current proposal has a receiving SMTP server take the domain name
associated with an SMTP client and do a forward query of the DNS.
The returned DNS information indicates whether that domain name is
authorized by the domain administrator to be an SMTP client.

For efficiency, the DNS response MAY also return authentication
information, as per [ID-Clear-CSV]. However the authentication
functionality is outside the scope of this specification.

4. Mechanism

The receiving SMTP server's authorization procedure is:

1. Obtain a domain name that is associated with the sending SMTP
client.

2. Perform a DNS lookup of:
QNAME = _client._smtp.<name>
QCLASS = IN
QTYPE = SRV
where <name> is associated with the host attempting to obtain
service as an SMTP client.

3. If there is no SRV RR matching this QNAME, the CSA information is
Unknown; otherwise at least one CSA record exists.

4. If there is a matching QNAME:

Target addresses MAY be returned in the Additional Data
section, or a query for address records of the target name may
be needed to determine the associated address(es). This MAY
be used to satisfy the authentication function specified in
Client SMTP Validation [ID-Clear-CSV].

Examine Priority, Weight, and Port, to assess whether the
client address is authorized as an SMTP client.

The results of this mechanism will provide the following
authorization levels about sending SMTP clients:

Otis, et al. Expires June 20, 2005 [Page 4]

Internet-Draft Mail-CSA December 2004

5. Client SMTP Authorization SRV Record

The SRV CSA Record has the following contents:

_Service._Proto.Name:TTL:Class:SRV:Priority:Weight:Port:Target

Service:
_client

Protocol:
_smtp

Name:
Domain name asserted in SMTP EHLO announcements.

(These first three fields become the QNAME _client._smtp.Name.)

TTL:
Standard DNS meaning [RFC1035].

Class:
Standard DNS meaning [RFC1035]. SRV-CSA records are only defined
for the IN Class.

Priority:
The intended use of [RFC2782] SRV records was to aid discovery and
selection of servers by prospective clients. Implementing this
client authentication mechanism for the server, the Priority,
Weight, and Port fields are no longer used for either discovery or

Otis, et al. Expires June 20, 2005 [Page 5]

Internet-Draft Mail-CSA December 2004

selection. Thus only one SRV-CSA record is needed and these three
fields are assigned different meanings. Priority defines the
revision level of this mechanism starting at 1.

Weight:
Weight is a group of bit-fields, as follows:

The resulting unsigned integer values for weight are:

Port:
The meaning of Port is defined by [ID-Clear-Policy]. This field
is defined within a separate policy document that describes
functions not related to the authorization or authentication
provided by CSV.

Target:
A domain name (typically the same as the EHLO domain) that
resolves to the correct list of IP addresses. If this record is
defined with the "Ignore Target" bit value, this field should be
set to the Name portion of the QNAME, rather than the "."
mentioned in [RFC2782], as a means to prevent excessive traffic on
root DNS servers by errant implementations.

Otis, et al. Expires June 20, 2005 [Page 6]

Internet-Draft Mail-CSA December 2004

6. Domain administrator advice

Although a conceptual framework might list the accreditation step as
logically following the authorization step, these steps MAY run in
parallel. Thus, those responsible for maintaining CSV DNS records
should make allowance for the fact that the response of the
accreditation service (which depends only on the EHLO string or the
client address) is likely to arrive at the receiving MTA before the
response to the DNS SRV query detailed here. As a result, the
receiving SMTP server may not follow-up partial or truncated UDP
responses for expediency. Regardless of what is specified, this
receiving SMTP server may decide to refuse the client if their chosen
accreditation service returns "Unknown". The following
recommendations explain how to ensure that the complete list of IP
addresses reaches the receiving SMTP server in the response to its
SRV query.

Currently UDP has a limit of 512 octets. Replies requiring more than
512 octets may create UDP fragmentation and, depending upon the
connection and handling, in addition to a higher rate of packet loss,
may also cause truncated or partial replies. Furthermore, delivery
and resolver handling of truncated and partial responses varies,
leading to additional delays and queries. Domain administrators are
strongly advised to keep DNS replies below 512 octets for these
reasons.

With a complete response to an SRV-CSA query, the SMTP server is able
to employ Right Hand Side Black List (RHSBL) services based upon the
domain name rather than address alone and as well as the
accreditation services detailed in [ID-Clear-CSVDNA]. These
domain-based services will not suffer from the same outdated-record
problems as the IP-Address-based services widely used at the time of
this writing. Also, of course, domain-based services will be able to
accredit those domains which must periodically change their IP
address. Reliance on the HELO/EHLO response allows isolation of
domains which may share common address space as with virtual hosting
or allow detection of domains for which there is insufficient history
which may invoke a go-slow approach as example.

In some cases, domains advertising SRV records will benefit by
reassigning some EHLO strings so as to limit the number of IP
addresses to be reported in SRV responses. Owing to the efficient
nature of the SRV record, the mechanism discussed here calls for a
single DNS query per SMTP session (not counting an out-of-band
accreditation query), which is substantially less network traffic
than per-message methods.

To help ensure complete answers are obtained from cached records, TTL

Otis, et al. Expires June 20, 2005 [Page 7]

Internet-Draft Mail-CSA December 2004

values of the SRV-CSA and related address records should be the same.
Beware some DNS server implementation consider the SOA TTL as a
default rather than a minimum.

7. Security Considerations

This proposal pertains to security, namely authentication and
authorization of peer MTAs.

The proposal also relies on security of the underlying IP network and
on the integrity of DNS data. It performs a basic authentication of
the peer MTA, based on domain name registration of the peer's IP
Address. As such, the mechanism provides a basic building block to a
larger repertoire of email security services.

There is no way a site can keep its hosts from being referenced as
servers. This could lead to denial of service.

With SRV, DNS spoofers can supply false addresses. Because this
vulnerability exists already with names and addresses, this is not a
new vulnerability, merely a slightly extended one. However, as
SRV-CSA records are used in an authorization context, the DNS servers
can be protected by DNSSEC [RFC3008] should this vulnerability become
intractable.

8. IANA Considerations

The tokens "_client" as _Service and "_smtp" as _Proto labels needs
to be registered as used with DNS SRV records [RFC2782].

9. Working Group Evaluation

This section contains responses to the issues put forward by the
MARID working group chairs.

1. Amount of change in software components
DNS administration, servers and clients MUST support SRV queries.
Client MTA's MUST put their registered domain name in EHLO
announcements.
Server MTA's MUST implement the validation procedure described in
this specification.

2. Configuration complexity
Requires registering each IP Address of an authorized Client MTA,
whenever the set of Addresses changes. No other configuration is
required.

3. Current use cases that will no longer be viable

Otis, et al. Expires June 20, 2005 [Page 8]

Internet-Draft Mail-CSA December 2004

All current use cases will still be viable. This mechanism is
only enabled by the explicit presence of the defined SRV record
for the domain name in the EHLO announcement.

4. Needed infrastructure changes
Explicit registration of Client MTAs.
Considerations for use in both IPv4 and IPv6
Validation mechanism is based on IP Addresses and requires the
usual query and handling of address types that will be
encountered from the IP module and the DNS.

10. References

10.1 References - Normative

[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.

[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.

[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.

[RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.

[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.

[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.

[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.

[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.

[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,

Otis, et al. Expires June 20, 2005 [Page 9]

Internet-Draft Mail-CSA December 2004

April 2001.

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.

[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
Signing Authority", RFC 3008, November 2000.

[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.

10.2 References - Informative

[ID-Clear-CSV]
Crocker, D., Otis, D. and J. Leslie, "Client SMTP
Validation (CSV)", July 2004.

[ID-Clear-CSVDNA]
Leslie, J., Crocker, D. and D. Otis, "Domain Name
Accreditation (DNA)", July 2004.

[ID-Clear-Policy]
Otis, D., Crocker, D. and J. Leslie, "Client SMTP Policy
(CSP)", July 2004.

[ID-email-arch]
Crocker, D., "Internet Mail Architecture", May 2004.

Authors' Addresses

Douglas Otis
Mail Abuse Prevention System
1737 North First Street, Suite 680
San Jose, CA 94043
USA

Phone: +1.408.453.6277
EMail: dotis(_at_)mail-abuse(_dot_)org

Otis, et al. Expires June 20, 2005 [Page 10]

Internet-Draft Mail-CSA December 2004

Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086
USA

Phone: +1.408.246.8253
EMail: dcrocker(_at_)brandenburg(_dot_)com

John Leslie
JLC.net
10 Souhegan Street
Milford, NH 03055
USA

Phone: +1.603.673.6132
EMail: john(_at_)jlc(_dot_)net

Otis, et al. Expires June 20, 2005 [Page 11]

Internet-Draft Mail-CSA December 2004

Intellectual Property Statement

Disclaimer of Validity

Copyright (C) The Internet Society (2004). 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.

Otis, et al. Expires June 20, 2005 [Page 12]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-otis-clear-csv-csa-02b.xml
Type: text/xml
Size: 51355 bytes
Desc: not available
Url :
http://mipassoc.org/pipermail/ietf-clear/attachments/20041220/e77f91a0/draft-otis-clear-csv-csa-02b-0001.xml