On Fri, Oct 10, 2003 at 05:36:29PM -0400, Meng Weng Wong wrote:
| Well, that was a productive flight.
Here's what my altitude-addled brain was able to produce. Any mistakes
are solely the fault of hypoxia. Please do not laugh at my attempts at
BNF syntax; I plead absence of Google at 30,000 feet.
1. Introduction
SMTP allows any client host to assert any sender email address.
Over time this vulnerability has been exploited to the extent that
it should be considered a significant security flaw. The Sender
Permitted From protocol introduces a voluntary convention which
helps to plug this hole.
The SPF protocol provides mechanisms for domain owners to designate
legitimate outbound mail servers; SMTP recipients may test the
designated status of an incoming SMTP transaction accordingly.
Using these mechanisms, SMTP servers may verify that the SMTP
transaction is approved by the domain of the envelope sender.
This authentication is weaker than cryptographic systems
but stronger than the current SMTP model.
This RFC does not obsolete RFC2821; it is a voluntary extension.
SMTP servers and Mail Delivery Agents may choose to test incoming
email according to the technical specification defined in this
proposal and to accept, classify, discard, or reject messages on
the basis of that test.
2. Designating SMTP Clients
Participating domains publish SPF records to indicate that only
certain hosts are permitted to send mail using that domain in the
envelope sender. In the case of a null envelope sender, the domain
from the HELO/EHLO command is tested instead.
"Designation", in this document, means that a host is permitted to
use a domain name in the sender address or in the HELO/EHLO command.
2.1 The _smtp_client domain.
DNS domains create TXT records in a special subdomain called
"_smtp_client".
The "_smtp_client" subdomain is hereby reserved; domains shall use
it to publish its SMTP policies which it requests other domains to
respect.
Participating domains are REQUIRED to respond to certain TXT
queries in that subdomain.
2.2 The policy label
Domains wishing to describe themselves as SPF-compliant MUST
publish the following record:
policy._smtp_client.${DOMAIN} IN TXT "v=spf1 DIRECTIVES"
"v=spf1" indicates compliance with version 1 of the SPF protocol.
"DIRECTIVES" obey the following syntax:
(todo: look up BNF syntax)
DIRECTIVES := [Negation] Mechanism [ " " [Negation] Mechanism ] [...]
[ Scope [...] ]
Default
[ Explanation ]
Default := "default=" ( "unknown" | "softdeny" | "deny" | "allow" )
Scope := "scope=" ( ( "" | "envelope" ) | "header-from" | "errors-to" ) )
By default, envelope scope is assumed.
Explanation := "exp=" ( literal string of maximum length 128 characters )
this string MAY be used by SPF clients in an SMTP rejection
message.
it should contain text explaining the policy decision or a
URL to such text.
Mechanism := MX | A | PTR | DNSL | IPv4 | IPv6 | INCLUDE | LocalPart
MX := "mx" ( ( ":" domain-name ) | default-esd )
A := "a" ( ( ":" domain-name ) | default-esd )
PTR := "ptr" ( ( ":" domain-name ) | default-esd )
DNSL := "dnsl" ( ( ":" domain-name ) | default-esd )
IPv4 := "ipv4" ":" ipv4-cidr-spec
IPv6 := "ipv6" ":" ipv6-cidr-spec
INCLUDE := "include" ":" domain-name
domain-name := standard DNS domain name, eg. "example.com"
default-esd := ""
expanded by the SPF client to the sender-domain.
ipv4-cidr-spec := standard IP number "/" cidr-range, eg. "127.0.0.1/8"
ipv6-cidr-spec := uh, the same thing, but for IPv6. I really have no idea
about this.
sender-domain : if a domain is present in the envelope sender, the
envelope sender domain; otherwise, if a domain is present in the
HELO/EHLO command, the HELO/EHLO domain; otherwise, SPF returns
unknown.
LocalPart := "localpart" ":" ( localpart-mechanism )
2.2.5 Example
policy._smtp_client.example.com IN TXT
"v=spf1 mx ptr:example.net dnsl:example.com default=deny exp=This is a
test of SPF"
2.3 Modifiers
2.3.1 Scope
By default, envelope scope is assumed. In envelope scope, the
sender domain used for lookups is taken from the envelope sender
domain, or from the HELO/EHLO where the envelope sender has no
domain. If other scopes are specified, an SPF client SHOULD
perform tests using the indicated RFC2822 headers.
In practice, this is only meaningful if an SPF client tests message
header address domains and discovers that the domains in question
did desire protection for the message headers.
2.3.2 Default
The default response if none of the mechanisms provide an explicit
allow, softdeny, or deny opinion.
2.3.3 Explanation
Provides a space for the publishing domain to communicate further
information about its policy: for instance, a short message, or a
URL pointing to a longer message. Maximum of 128 characters.
Designates a domain's MX servers.
2.4 Mechanisms In Detail
2.4.1 MX
If a host is an MX server for example.com, it is also designated to
send mail on behalf of example.com; this mechanism then returns "allow".
2.4.1.1 Example
policy._smtp_client.example.com IN TXT
"v=spf1 mx:example.com default=deny exp=This is a test of SPF"
2.4.2 A
2.4.2.1 Example
policy._smtp_client.example.com IN TXT
"v=spf1 a default=deny exp=This is a test of SPF"
Because the RHS of the "a" mechanism is null, the sender domain is
used for this lookup. If a host appears in the A lookup for
example.com, it is considered designated, and this mechanism
returns "allow".
2.4.3 PTR
First, perform a PTR lookup on the connecting client IP; then
perform an A lookup back to an IP address. If one of the PTR names
resolves back to the original IP address, the PTR response is
considered valid. Then, if that resolving PTR entry ends in the
specified domain-name, this mechanism returns "allow".
2.4.3.1 Example
policy._smtp_client.example.com IN TXT
"v=spf1 ptr default=deny exp=This is a test of SPF"
SMTP client comes from the IP address 1.2.3.4.
PTR(1.2.3.4) returns two results: "foo.example.net" and "bar.example.com"
A(foo.example.net) returns two results: 2.3.4.5 and 3.4.5.6.
This is an invalid result because the A record does not point back
to the original IP.
A(bar.example.com) returns two results: 1.2.3.4 and 2.3.4.5.
This is a valid result because the A record does point back to the
original IP.
bar.example.com does end in example.com; therefore this mechanism
returns "allow".
2.4.4 DNSL
DNS lists: (from the convention of blacklists and whitelists)
Additional records are OPTIONAL and identify the network hosts
designated as SMTP clients:
${ADDRESS}.${ADDR-TYPE}._smtp_client.${DOMAINNAME}. TXT "spf=allow"
${ADDRESS} represents a reversed network IP address.
${ADDR-TYPE} represents the address type: "in-addr" for IPv4 and
"ip6" for IPv6.
${DOMAINNAME} represents the domain of a SMTP mail sender
envelope.
2.4.4.1 Example
policy._smtp_client.example.com IN TXT
"v=spf1 dnsl:example.com default=deny exp=This is a test of SPF"
An SMTP connection from 1.2.3.4 using the sender envelope
"user(_at_)example(_dot_)com" would be DNSL tested with
4.3.2.1.in-addr._smtp_client.example.com
If 1.2.3.4 were a permitted sender for example.com, a TXT query
would return "spf=allow", and the mechanism would return "allow".
If it were not, no response would be returned.
2.4.x LocalPart
the LocalPart specification is EXPERIMENTAL and may be defined
in future RFCs.
It is intended to provide a way for individual users to specify a
policy that differs from the rest of the domain: for example, if a
roaming user wishes to send mail from any SMTP server, he may opt
out of SPF using this mechanism.
2.5 Negation
Usually, lookup mechanisms return positive "allow" responses,
indicating that a host is designated.
If the lookup mechanism is prefixed with a "!" symbol, the result
is negated, and a "deny" response obtains.
2.6 Evaluation order
Mechanisms MUST be evaluated in the order they are presented.
A response of "allow", "deny", or "softdeny" short-circuits evaluation.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡