Client SMTP Authorization is a way of publishing in the DNS which machines are permitted to send email and who is responsible for them. CSA is not based on email addresses, so it does not say anything about who is responsible for individual messages. CSA is not based on IP addresses, so it does not say anything about who is responsible for providing the machine with connectivity. Instead, CSA is based on the machine's host name, which identifies who controls the software running on the machine.
When sending email an SMTP client starts a new session with an SMTP
server by saying EHLO followed by its host name.
Traditionally this host name has been purely for diagnostic purposes,
and recipients are not supposed to reject messages if the client states
an invalid one. This means that a large proportion of viruses and
spamware lie about their host name; however it isn't possible to simply
start rejecting email from SMTP clients that use invalid host names,
because about 1/3 of legitimate senders are misconfigured. CSA allows a
sending site to state that its SMTP clients are correctly configured and
that recipients are allowed to strictly validate their host names.
SRV record formatCSA uses specially-formatted SRV records in the DNS.
SRV records are looked up using three parameters. The
Name that is being queried is prefixed with two extra labels,
which identify the Service and Protocol that is
being asked about. For CSA these labels are _client._smtp,
and the Name is the host name from the client's
EHLO command.
The record returned by the DNS SRV query has four
fields. The first three are numbers, called the Priority,
Weight, and Port. CSA uses the Priority
field to identify the version of CSA, which must be 1.
The Weight field is used to indicate whether or not clients using the Name are authorized to send email. If it is 1 the Name is not authorized. If it is 2 the Name is authorized. Other Weight values are not useful.
The Port field is used to make assertions about the
Name and all of its subdomains. If it is 0 nothing special is
asserted. If it is 1 then all legitimate email senders that use a host
name which is a subdomain of the Name must be explicitly
authorized with their own CSA SRV record. That is, if a
client's host name doesn't have a positive CSA SRV record
and one of its parent domains states that explicit authorization is
required, then the client is not authorized. At the moment no other
assertions are defined.
Finally, after the numerical fields is the Target. This is relevant if the Weight field is 2 (i.e. authorized). The SMTP client must use an IP address belonging to the Target in order to be able to legimately use the Name. The Name usually has appropriate address records, so the Target is usually the same as the Name.
Your domain name is example.com. You have an email
server called mail.example.com and a web server called
www.example.com, plus some other miscellaneous computers.
Your DNS currently looks like this:
example.com. MX 10 mail.example.com. mail.example.com. A 192.0.2.65 www.example.com. CNAME web.example.com. web.example.com. A 192.0.2.66 pc1.example.com. A 192.0.2.71 mac2.example.com. A 192.0.2.72
Most of your outgoing email comes from your email server, but your web server also sends a few messages. You do not have any other computers that send email. You can publish this information by adding the following CSA records to your DNS:
_client._smtp.example.com. SRV 1 1 1 example.com. _client._smtp.mail.example.com. SRV 1 2 1 mail.example.com. _client._smtp.web.example.com. SRV 1 2 1 web.example.com.
Cambridge University's central email relays have names like
ppsw-0.csi.cam.ac.uk. These should obviously have CSA
records that state that they are authorized (Weight = 2).
They have no subdomains, so the CSA records should also state that all
legitimate subdomains have explicit CSA records (Port = 1) -
i.e. no subdomains are legitimate. So the DNS setup for one of them will
look like:
_client._smtp.ppsw-0.csi.cam.ac.uk. SRV 1 2 1 ppsw-0.csi.cam.ac.uk. ppsw-0.csi.cam.ac.uk. A 131.111.8.130
Cambridge University's central email service (which provides a
message store and webmail and so forth) is called Hermes. It has an
email domain for its users called hermes.cam.ac.uk. No
systems legitimately use this as their host name, though it's quite
common for viruses and spamware to do so. Therefore it would be useful
to give it a negative CSA record (Weight = 1). There are a
number of host names under hermes.cam.ac.uk, but none of
them are used to send email (Port = 1); instead email goes
out via the central relays. So its DNS setup will look like the
following. Note that CSA ignores the target IP address in this case.
_client._smtp.hermes.cam.ac.uk. SRV 1 1 1 hermes.cam.ac.uk. hermes.cam.ac.uk. MX 7 mx.cam.ac.uk. hermes.cam.ac.uk. A 131.111.8.59
Cambridge University's top level domain is cam.ac.uk,
and this is also used as an email domain. It should not be authorized
for the same reasons as hermes.cam.ac.uk (Weight
= 1). However there are many host names under cam.ac.uk
which are permitted to send email, but we have not yet identified all of
them and given them CSA records (Port = 0). So its DNS setup
will look like the following. The lack of target IP addresses does not
matter.
_client._smtp.cam.ac.uk. SRV 1 1 0 cam.ac.uk. cam.ac.uk. MX 7 mx.cam.ac.uk.
One of my friends has a co-located computer called Chiark. Its email
domain and its host name are both the same: chiark.greenend.org.uk.
Its DNS setup will look like the following. Other machines are prevented
from claiming to be Chiark because CSA will check that they are coming
from the correct IP address.
_client._smtp.chiark.greenend.org.uk. SRV 1 2 1 chiark.greenend.org.uk. chiark.greenend.org.uk. MX 10 chiark.greenend.org.uk. chiark.greenend.org.uk. A 193.201.200.170
Exim versions 4.51 and greater will support CSA. You can configure to to check CSA by adding the following clause to your access control lists, near where you do DNS blacklist checks.
require verify = csa
?
?
?
?
It's quite common for viruses and spamware to get the semantics of
the EHLO command wrong, so that instead of stating their
own host name they use the email domain of the recpient. Therefore if
you publish CSA records in the DNS and check CSA in your MTA, you will
stop a significant proportion of junk email (5% - 10%).
You can deploy CSA in stages. You can start off by adding positive
CSA records for your main outgoing email servers, and negative records
for any invalid EHLO host names that are commonly used by
viruses and spamware, for example your email domains. Once you have
audited your network to find all the machines that send email - such as
web servers or application servers - you can add an explicit
authorization assertion to your top level domain (Port = 1).
If your network is large and has many sub-domains, you can add the
assertions one at a time to each of the subdomains as they are
audited.
CSA can be used to correct errors in DNS blacklists. You might be blocking email using a DNSBL that is supposed to list only consumer grade IP addresses. If this DNSBL is sometimes wrong, you might want to let an SMTP client through if it passes CSA. For example, in Exim:
require verify = csa
deny condition = ${if !eq{$csa_status}{ok} }
dnslists = dul.mail-abuse.com
CSA can be used as the basis for a distributed whitelist system. This system can be based on host names rather than IP addresses, so can be easier to maintain. For example, email system administrators in the UK academic community might like to exempt legitimate email from other universities from anti-spam checks:
require verify = csa
deny condition = ${if !and{{ eq{$csa_status}{ok} } \
{ match{$sender_host_name}{[.]ac[.]uk\$} }} }
dnslists = dul.mail-abuse.com
An ISP might wish to restrict its users from sending email directly
from their home computers, but blocking port 25 is often too harsh.
Instead the ISP can use CSA to provide a default restriction, but its
customers will still be able to send email directly if they take
responsibility by using their own host names instead of the ISP's. Say
the ISP is called example.net and its ADSL host names are
subdomains of adsl.example.net. Then the ISP can publish
the following CSA record to implement the default restriction:
_client._smtp.adsl.example.net. SRV 1 1 1 example.net.
This will allow recipients to block email from the more competent
types of viruses and spamware that use a correct EHLO
hostname.
If our example ISP has a customer that wants to send email directly,
e.g. a not-for-profit organization called customer.example.org,
then that customer can avoid being blocked by configuring its email
server to use a host name in its own domain. The server thereby states
that it is the responsibility of the customer, not the ISP. The customer
publishes the following CSA record, which refers to the customer's ADSL
address.
_client._smtp.customer.example.org. SRV 1 2 1 192-0-2-95.adsl.example.net.
By itself CSA says nothing about whether an SMTP client is well-behaved. However it does give you a solid identification of the organization responsible for the SMTP client, in the form of a domain name. CSA relies on reputation and accreditation services to deal with irresponsible SMTP client operators. Client ratings are published using "RHSBL"s, which are like traditional DNSBLs but are based on domain names rather than IP addresses. Other new email authentication protocols, such as SPF and DomainKeys, also rely on RHSBLs.
$Cambridge: hermes/doc/antiforgery/csa.html,v 1.9 2005/05/06 20:14:51 fanf2 Exp $