<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML
><HEAD
><TITLE
>Sender Authorization Schemes</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="Spam Filtering for Mail Exchangers"
HREF="index.html"><LINK
REL="UP"
TITLE="Techniques"
HREF="techniques.html"><LINK
REL="PREVIOUS"
TITLE="Greylisting"
HREF="greylisting.html"><LINK
REL="NEXT"
TITLE="Message data checks"
HREF="datachecks.html"></HEAD
><BODY
CLASS="section"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Spam Filtering for Mail Exchangers: </TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="greylisting.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 2. Techniques</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="datachecks.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="section"
><H1
CLASS="section"
><A
NAME="senderauth"
></A
>2.5. Sender Authorization Schemes</H1
><P
> Various schemes have been developed for sender verification
where not only the validity, but also the authenticity, of
the sender address is checked. The owner of a internet
domain specifies certain criteria that must be fulfilled in
authentic deliveries from senders within that domain.
</P
><P
> Two early proposed schemes of this kind were:
</P
><P
></P
><UL
><LI
><P
> <TT
CLASS="option"
>MAIL-FROM</TT
> MX records, conceived by Paul
Vixie <TT
CLASS="email"
><<A
HREF="mailto:paul (at) vix.com"
>paul (at) vix.com</A
>></TT
>
</P
></LI
><LI
><P
> Reverse Mail Exchanger (RMX) records as an addition to DNS
itself, conceived and published by Hadmut Danisch
<TT
CLASS="email"
><<A
HREF="mailto:hadmut (at) danisch.de"
>hadmut (at) danisch.de</A
>></TT
>.
</P
></LI
></UL
><P
> Under both of these schemes, all mails from
<TT
CLASS="email"
><<A
HREF="mailto:user@domain.com"
>user@domain.com</A
>></TT
> had to come from the hosts
specified in <TT
CLASS="email"
><<A
HREF="mailto:domain.com"
>domain.com</A
>></TT
>'s DNS zone.
</P
><P
> These schemes have evolved. Alas, they have also forked.
</P
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="spf"
></A
>2.5.1. Sender Policy Framework (SPF)</H2
><P
> <SPAN
CLASS="QUOTE"
>"Server Policy Framework"</SPAN
> (previously
<SPAN
CLASS="QUOTE"
>"Sender Permitted From"</SPAN
>) is perhaps the most
well-known scheme for sender authorization. It is loosely
based on the original schemes described above, but allows
for a bit more flexibility in the criteria that can be
posted by the domain holder.
</P
><P
> SPF information is published as a <TT
CLASS="option"
>TXT</TT
>
record in a domain's top-level DNS zone. This record can
specify:
</P
><P
></P
><UL
><LI
><P
> which hosts are allowed to send mail from that domain
</P
></LI
><LI
><P
> the mandatory presence of a GPG (GNU Privacy Guard)
signature in outgoing mail from the domain
</P
></LI
><LI
><P
> other criteria; see
<A
HREF="http://spf.pobox.com/"
TARGET="_top"
>http://spf.pobox.com/</A
> for details.
</P
></LI
></UL
><P
> The structure of the <B
CLASS="command"
>TXT</B
> record is still
undergoing development, however basic features to accomplish
the above are in place. It starts with the string
<TT
CLASS="option"
>v=spf1</TT
>, followed by such modifiers as:
</P
><P
></P
><UL
><LI
><P
> <TT
CLASS="option"
>a</TT
> - the IP address of
the domain itself is a valid sender host
</P
></LI
><LI
><P
> <TT
CLASS="option"
>mx</TT
> - the incoming mail exchanger for
that domain is also a valid sender
</P
></LI
><LI
><P
> <TT
CLASS="option"
>ptr</TT
> - if a rDNS lookup of the
sending host's IP address yields a name within the
domain portion of the sender address, it is a valid
sender.
</P
></LI
></UL
><P
> Each of these modifiers may be prefixed with a plus sign (+),
minus sign (-), question mark (?), or tilde (~) to indicate
whether it specifies an authorative source, an non-authorative
source, a neutral stance, or a likely non-authorative source,
respectively.
</P
><P
> Each modifier may also be extended with a colon, followed by
an alternate domain name. For instance, if you are a Comcast
subscriber, your own DNS zone may include the string
<SPAN
CLASS="QUOTE"
>"<TT
CLASS="option"
>-ptr:client.comcast.net
ptr:comcast.net</TT
>"</SPAN
> to indicate that your
outgoing e-mail never comes from a host that resolves to
<TT
CLASS="parameter"
><I
>anything</I
></TT
>.client.comcast.net, but could
come from other hosts that resolve to
<TT
CLASS="parameter"
><I
>anything</I
></TT
><TT
CLASS="option"
>.comcast.net</TT
>.
</P
><P
> SPF information is currently published for a number of
high-profile internet domains, such as aol.com,
altavista.com, dyndns.org, earthlink.net, and google.com.
</P
><P
> Sender authorization schemes in general and SPF in particular
are not universally accepted. In particular, one objection is
that domain holders may effectively establish a monopoly on
relaying outgoing mail from their users/customers.
</P
><P
> Another objection is that SPF breaks traditional e-mail
forwarding - the forwarding host may not have the authority to
do so per the SPF information in the envelope sender domain.
This is partly addressed via <A
HREF="http://spf.pobox.com/srs.html"
TARGET="_top"
>SRS</A
>, or
<EM
>Sender Rewriting Scheme</EM
>, wherein the
forwarder of the mail will modify the <A
HREF="gloss.html#envfrom"
><I
CLASS="glossterm"
>Envelope Sender</I
></A
> address to the format:
<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="screen"
><TT
CLASS="parameter"
><I
>user</I
></TT
>=<TT
CLASS="parameter"
><I
>source.domain</I
></TT
>@<TT
CLASS="parameter"
><I
>forwarder.domain</I
></TT
></PRE
></FONT
></TD
></TR
></TABLE
>
</P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="ms-cide"
></A
>2.5.2. Microsoft Caller-ID for E-Mail</H2
><P
> Similar to SPF, in that acceptance criteria are posted
via a TXT record in the sending domain's DNS zone.
However, rather than relying on simple keywords, MS CIDE
information consists of fairly large structures encoded in
XML. The XML schema is published under a license by
Microsoft.
</P
><P
> While SPF would nominally be used to check the <A
HREF="gloss.html#envfrom"
><I
CLASS="glossterm"
>Envelope Sender</I
></A
> address of an e-mail, MS CIDE is
mainly a tool to validate the RFC 2822 header of the
message itself. Thus, the earliest point at which such a
check could be applied would be after the message data has
been delivered, before issuing the final
<B
CLASS="command"
>250</B
> response.
</P
><P
> Quite frankly, dead on arrival. Encumbered by patent issues
and sheer complexity.
</P
><P
> That said, Recent SPF tools posted on <A
HREF="http://spf.pobox.com/"
TARGET="_top"
>http://spf.pobox.com/</A
> are capable of checking MS
Caller-ID information in addition to SPF.
</P
></DIV
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="rmxplus"
></A
>2.5.3. RMX++</H2
><P
> (part of <EM
>Simple Caller Authorization Framework -
SCAF</EM
>). This scheme is developed by Hadmut Danisch,
who also conceived of the original RMX.
</P
><P
> RMX++ allows for dynamic authorization by way of HTTP servers.
The domain owner publishes a server location via DNS, and the
receiving host contacts that server in order to obtain an
<EM
>authorization record</EM
> to verify the
authenticity of the caller.
</P
><P
> This scheme allows the domain owner more fine-grained control
of criteria used to authenticate the sender address, without
having to publicly reveal the structure of their network (as
with SPF information in static TXT records). For instance, an
example from Hadmut is an authorization server that allows no
more than five messages from a given address per day after
business hours, then issues an alert once the limit has been
reached.
</P
><P
> Moreover, SCAF is not limited to e-mail, but can also be used
to provide caller authentication for other services such as
Voice over IP (VoIP).
</P
><P
> One possible downside with RMX++, as noted by Rick Stewart
<TT
CLASS="email"
><<A
HREF="mailto:rick.stewart (at) theinternetco.net"
>rick.stewart (at) theinternetco.net</A
>></TT
>, is its
impact on machine and network resources: Replies from HTTP
servers are not as widely cached as information obtained
directly via DNS, and it is signifcantly more expensive to
make an HTTP request than a DNS request.
</P
><P
> Further, Rick notes that the dynamic nature of RMX++ makes
faults harder to track. If there is a five-message-per-day
limit, as in the example above, and one message gets checked
five times, then the limit is hit with a single message. It
makes re-checking a message impossible.
</P
><P
> For more information on RMX, RMX++, and SCAF, refer to: <A
HREF="http://www.danisch.de/work/security/antispam.html"
TARGET="_top"
>http://www.danisch.de/work/security/antispam.html</A
>.
</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="greylisting.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="datachecks.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Greylisting</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="techniques.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Message data checks</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
