Thank you, Wayne, for the impromptu comparison. Obviously, we take a
somewhat different view.
SPF and Caller ID do have important similarities.
- Both proposals request email senders to publish the IP addresses of
their outbound email servers in a DNS TXT record.
- Both have mechanisms to let senders express a variety of email server
configurations and topologies when they publish their outbound email
server IP addresses.
- Both detect spoofing by checking the IP address from which a message
is received against the list of outbound email server IP addresses
published in DNS
- Both verify the MTA responsible for the message's last hop
However, there are important differences too.
1. User experience: SPF checks the 2821 MAIL FROM address, Caller ID
checks a set of 2822 headers. As I've noted in other posts, Caller-ID
performs validation on headers that are included in the message body
itself, that is, on headers the end user can see. Caller ID attempts to
determine as accurately as possible who was responsible for actually
sending the message. We believe checking headers the recipient can see
and identifying the real sender leads to results that make more
intuitive sense to the recipient, and most importantly, helps directly
address some phishing scenarios (see below). Lastly, when there is a
discrepancy between the 2822 From line and the address of the purported
sender, this discrepancy can be an indicator that greater scrutiny of
the message is required, and it can presented to the user to alert them
to a possible problem, even if evidence of spoofing is not conclusive.
Some clients already do this in the case where the Sender: header
differs from the From.
To be sure, the Caller ID mechanism could be used to validate the 2821
MAIL FROM. In fact we actually had the 2821 MAIL FROM as the first
identity on our list, ahead of the 2822 headers, in early drafts of
Caller ID. In the end we dropped it because it either added no useful
information that was not already contained in the 2822 headers or led to
incorrect or misleading conclusions from an end user perspective. In
other words, 2821 MAIL FROM adds nothing useful so why use it?
2. Better protection against "phishing": With SPF, a spammer could
register their own domain name and publish an outbound IP address, yet
still spoof the 2822 From. With Caller ID, these message headers get
checked. Furthermore, Caller ID provides an extra measure of protection
for senders who only transmit mail directly to recipients and never to
mailing lists. Business-to-consumer mail such as account statements and
transaction confirmations fall into this category. With Caller ID,
senders can declare that a mail from a particular domain is always sent
in this "direct-only" manner. Caller ID then specifies an extra check
on the 2822 From whenever there are multiple headers in a message and a
discrepancy between their domains.
We're not claiming Caller ID will stop all phishing attacks. Social
engineering attacks using domain names like security_microsoft.com won't
be detected. Stopping this type of spoofing requires legal action.
3. Fewer false positives: Because of the variety of delivery paths,
and spammers' propensity to adapt, we are realistic about the amount of
spam that can be blocked solely on the basis of a spoofing check.
Avoiding false positives is very important to our customers and Caller
ID has been designed with this goal in mind. We believe that blocking
mail on the basis of the 2821 MAIL FROM *in the absence of any other
evidence of spam* is very likely to generate many false positives.
Another reason to focus on the 2822 headers.
4. Ease of adoption: We believe our proposal will be much easier for a
broader range of senders to adopt, including list servers, electronic
greeting and invitation services, and mail forwarding services. Many of
these services today do not use their own domain names in the 2821 MAIL
FROM because they do not want to handle bounce messages. In order to
comply with Caller ID all they need to do is ensure that at least one of
the body headers we check has their domain name on it. Some of these
services are already compliant today with no changes. Under SPF, these
services will have to modify the 2821 MAIL FROM according to the Sender
Rewriting Scheme (SRS) or VERP, plus handle any bounce messages that
come back. We believe this is a more extensive change and could place a
heavier workload on these services. To put it another way, SPF really
means adopting TWO new standards. Caller ID has no such requirement.
5. Extensibility: We believe extensibility is a critical element of
our proposal. Over time we believe domains will want to publish more
information about their email policies. This could include:
- information about abuse reporting,
- pointers to 3rd party safelists or other services that might attest to
the sender's compliance with particular email policies,
- whether or not a domain always signs its outbound mail
- whether or not a domain honors investment by the sender in
computational proofs,
- public keys used for S/MIME or other signing schemes list Yahoo's
Domain Keys proposal,
- future enhancements to MTA validation
Caller ID's email policy document has been designed as a logical place
to publish that kind of information. That is why we chose XML as the
encoding format. XML is the internet standard for representing textual
data in a structured, extensible way. Tools for reading and creating
XML are readily available on a variety of computing platforms.
Furthermore, XML permits independent extensibility. No central
authority is required. This allows for both industry-wide extensions
plus private extensions that individual organizations or groups of
organizations might wish to make. Systems that don't yet understand
newer elements can ignore them and continue to act on those elements
they do understand.
I recognize that all these future enhancements are outside the scope of
MARID. However, we believe its important to define a format that can be
easily extended in a standard way.
6. Potential denial of service attack in SPF macro language. Using
SPF's macro language, in particular the &t parameter, it is possible for
senders to create a non-cacheable TXT record that forces receivers to do
a DNS lookup on every message. By creating such a record and sending a
high volume of email to a target system, a malicious sender could
potentially tie up substantial resources on that system.
Thanks,
Harry
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of wayne
Sent: Friday, April 09, 2004 10:21 AM
To: IETF MXCOMP
Subject: Re: Microsoft submitting Caller ID as draft RFC
In <4076D557(_dot_)5090602(_at_)Royer(_dot_)com> Doug Royer
<Doug(_at_)Royer(_dot_)com> writes:
I just read this document.
It seem to me to be SPF except in XML. What are the advantages of
Caller-ID over SPF?
MS C-ID deals with RFC2822 identities, while SPF deals with
RFC2821 identities. In this respect, SPF and C-ID are
complementary technologies rather than competing technologies.
C-ID also doesn't have as many different mechanisms to
validate against (e.g. no a:, ptr:, exists:, etc. mechanism.
The C-ID <a> mechanism is equivalent to the SPF ip4:/ip6:
mechanisms, not the SPF a:
mechanism). C-ID also doesn't have things like
macro-variables, the include/redirect stuff, softfail result
codes, etc. If I recall correctly, C-ID records have the
choice of returning the SPF equivalents of "pass"/"fail" or
returning "unknown" for everything.
An SPF record can be constructed to return any of the status.
For example, "v=spf1 +mx -exists:dnsbl.example.org
~ptr:isp.dialup.com ?all".
For those that see SPF as too complicated, this is a feature.
For those that want this functionality, this is a problem.
Choose your poison.
While C-ID is not an exact subset of SPF, there are programs
around that will translate many C-ID records into SPF
records. Also, over the last 6 months or so, people have
played with using SPF records to validate the RFC2822 data,
but nothing solid has come from it. Once upon a time, the
SPF spec even had the "scope=" modifier to let domain owners
choose whether they wanted RFC2821 checking, RFC2822
checking, or both. This was removed because RFC2822 checking
was not well enough understood.
Oh, take this comparison with a grain of salt, it was done
off the top of my head and there are likely things I forgot
about and/or misremembered.
-wayne