There've been a lot of press releases from groups like the WSIS (World Summit on the Information Society) about "internet governance" and similar topics, but what they're really doing is using the near-universal dislike for ICANN to accomplish other goals. Typical announcements talk about several things:
Both WSIS and WGIG have some odd bedfellows. The registrars hate ICANN because of their perception that ICANN's methods for expanding the number of TLDs and assigning registries are contrary to their interests. The ITU hates ICANN because it assigns no power to governments (and despite all other parties that play in ITU, it is the vote of "sovereign states" that really counts). These people are playing together because of the old "enemy of my enemy" dictum, but it's mighty clear that they would not play well together once the enemy was gone. Most of the registrars would hate dealing on ITU terms (the few state monopoly ccTLD registrars excepted).
The ITU also dislikes that all of the protocol work came out of the IETF, rather than its own study groups. It's now working with ETSI to create what it calls "NGN" (for Next generation Network", which is really an adaptation of the work done in 3gpp and 3gpp2 for wireless (and those are largely adaptations of IETF core protocols, and much of the actual engineering of things like ROHC and SIP was done in the IETF). The crazy thing is that this is really just a service overlay network that they somehow believe will subsume the services currently running on the bit-pipe Internet we have now (where anyone can offer you content or services without a special deal with the operators). There is only one way that could happen, really--massive regulation that eliminated everything but the operator's approved services. They could try it and watch it fail, of course, but I personally am pretty concerned about the attempt.
Actually, that's not quite true. ICANN also provides the funding for IANA's other registries. Those registries are used by multiple protocols (SMTP, SIP, XMPP, and a long list of others). Go to http://www.iana.org/numbers.html for a full list. Those are assigned, however, under rules set up by the IETF and generally do not have the same kinds of political and property issues at stake.
Geoff Huston, former Executive Director of the Internet Architecture Board, has proposed splitting those off from ICANN, so that political issues related to ICANN's other roles don't affect them. http://mirrors.isc.org/pub/www.watersprings.org/pu b/id/draft-huston-iana-00.txt has a copy of the -00 version of his proposal.
The IETF's CRISP working group has developed a replacement for whois: IRIS (Internet Registry Information Service). IRIS allows for different levels of access, so that you don't have whois's "all or nothing" response any more. This will help protect record details like addresses from harvest by J. Random Abuser (spammer, what have you). This is goodness.
I assume that the law enforcement agencies in the country in which the registry is domiciled would have to provide the highest level of access (equivalent to the current whois), but that other LEAs would have to go through the country of domicile. This is speculation, though; ICANN/registry/registrar policies may make it easier or harder.
The main point in the above is correct: Sender-ID/Caller-ID/SPF is about forgery. Forged spam is a use case, but there never was an illusion that this would stop spam--a spammer can simply buy a $9 domain, enter a record, and send the mail. The spammer just can't send it as user@protected.example.net any more.
But the "Microsoft can sue SPF out of existence" piece is not correct (sorry, dude!). SPF protects part of the envelope: the bounce address coded in the RFC 2821 MAIL-FROM; Caller-ID/Sender-ID protect the headers in the RFC 2822 message (From:, Resent-From:, and the like). They do different things. The working group discussed which one to prioritize and picked the latter after Meng Wong and Mark Lentczner (SPF authors) met with the Microsoft authors (Harry Katz and Jim Lyons); this was discussed at the MARID Campbell interim meeting.
Both are still interesting, but killing Sender-ID in favor of SPF, as many are now advocating means you're changing strategy; you're fundamentally changing what you're protecting.
To go back to the main point, neither will stop spam. Write that down..
Anyone who can't spell Jon Postel's name right shouldn't be trying to give a historical perspective on this problem.
Yakov missed a great deal of previous activity on this topic in the IETF (viz. Sally Hambridge's efforts in the 90s), and his take on the recent events is heavily colored by his previous position as the _IRTF_'s co-chair for the Anti-Spam Research Group. Note Well: _previous_ position.
The group, like all IETF groups, is public, and all of its email archives are available for your perusal. Why not read for yourself and make up your own mind?
There are lots of other examples at http://ietf.org/ipr.html with fairly similar "don't sue me and you can use it" terms. The IPR terms being offered here almost look like a cut and paste job, to be honest, and that may not be a bad thing. There actually can be advantages to someone holding a defensive patent:
It means someone who wants to use a submarine patent to control this technology has to fight Microsoft's lawyers.
Microsoft's grant is: 1) subject to any denial of claims by the USPTO, 2) Royalty-free (as in beer), 3) Non-discriminatory (anyone, anywhere, any time). Other submarine patents might not be nearly so nice, and I'd rather have the next guy along sue Microsoft than me.
There are some pain in the rump aspects; it is not: sublicensable (everyone has to get their own free thing).
It does require you license back whatever you have claims on that is needed for Sender-ID to get their thing needed for Sender-ID (this is common in the IPR declarations given to the IETF). That, in my humble not-a-lawyer opinion is why you have to let them know your use is under the free, global, yadda-yadda license rather than being an infringement of the patent.
The good news: this does not require those deploying Sender-ID records to do anything. It does not require anyone using packaged binary software to do anything. It does not require anyone distributing packaged binary software to do anything.
It's a minor pain for implementors and a hassle for distributors (who may, like Sendmail, have to put the Sender-ID code in a different distribution). Not ideal, but not enough of a pita, in my opinion, to go without the technology. Especially if their claims cover things like "storing MTA authorization records in the DNS" (and they could), rejecting this could mean rejecting the whole ball of wax as an anti-forgery tool.
SenderID and the LMAP proposals on which it is based are focussed on anti-Forgery, not anti-Spam. This is intended to make joe-jobs and phishing harder.
Note that S/MIME and PGPMail (also standardized in the IETF) are better for this because they confirm it was a specific individual, rather than sourced from a specific domain. But this is a useful incremental step that may cut down things like spurious bounces *exactly because the SPAMMERS can work around it*. Since it does nothing agains the 9 dollar throwaway domain, it is not going to stop SPAM--just make SPAM purporting to be coming from you just a bit harder.
The MASS birds of a feather session at the upcoming IETF is intended to look at cryptographic DNS records for a similar purpose (think DomainKeys).
Both are things that reputation services can use as a substrate for further work.
So, it is a useful piece of technology, but please don't judge it by "stops all Spam", or you will conclude it failed at a task it did not take on.
The general approach taken by SPF and friends does nothing directly to stop SPAM. As numerous other posters have pointed out, the throw-away domain is still available to spammers and it is easy for them to generate valid SPF records for those throw-away domains, even using zombie networks (with dynamic DNS, you can even limit the number of IP addresses in the records to mask the size of the network).
It is useful, though, both immediately and in the medium term. The immediate usefulness is in bounce processing. An MTA whose role is to generate or forward bounces can check the SPF record before action and not send those for which there is no connection between the message and the target of the bounce. That's very useful, since it removes the clutter from the mailboxes of those who were the targets of joe jobs. (Note that an MTA forwarding a bounce can do this, as well as one originating a bounce--that means an enterprise can do this at the MTAs listed in the MX records).
In the medium term, the SPF record can be used to limit certain kinds of forgery, making it harder for social engineering attacks to work. It's not perfect, by any means, since registration of domains like "companyname-support.com" will still fool some users. It also relies to some extent on the first MTA in a series to perform the checks, as the scheme gets weaker and weaker with the need to grovel through more headers to make an association. In other words, it works well when it is ORIGINMTA--DESTMTA, but less well when it is ORGINMTA--IntermediateMTA-IntermediateMTA-DESTMTA, since the RFC 2822 header (From:, Resent-From:, etc.) processing gets more complicated. Since the latter is a core part of the design of email (store and forward), there are limits to SPFs role in this arena--especially when spammers decide to pass there messages through multiple MTAs under their own control to generate the appearance of this complexity.
In the long term, the hope is that it starts folks toward a more generic mechanism that allows the sending domain to describe the characteristics of its email (e.g. all mail is signed as S/MIME and all signatures derive from this CA) and the receiving domain to check the characteristics of the messages it's received against those.
Again, though, this is all about forgery, not SPAM.
>The reason why it has not been done is just that, IETF can't get their act together.
The IETF is like a lot of other open-source communities: it depends on contributions from folks who have identified a problem and developed a solution to it. Unlike a lot of other communities: it is completely open, and it is consensus driven. Completely open means you can contribute your solution and get heard by the rest of the community as easily as, say, Harald Alvestrand. That's the upside. The downside is everyone else who has an interest can contribute gets to as well, and some of them may have solutions which don't work, are just as good as yours but different, or which have a different set of engineering trade-offs than yours so that different folks have an interest in seeing different ones succeed.
And did I mention, the IETF was consensus driven? Though this is "rough consensus", the core idea of the IETF is still that you take the *intersection* of what people feel is a good idea rather than the *union* (common in many other groups). That has a lot of consequences when combined with completely open.
That doesn't mean the IETF can't work on a problem. It does mean it probably isn't the place to engage in an arms race. In my humble opinion, spammers and anti-spammers are in an arms race.
So you're not too discouraged, if you look at the development of protocols like SIMPLE or XMMP in the IETF, you'll see neat stuff like e2e message integrity and encryption, and (with the IMPP docs finally out) even some ability to pass things from one to the other. Passing a message in IM, in other words, will soon be better than email for things that make a lot of difference to spam diffusion. Those are new protocols, and a *new* any-to-any message protocol might get a lot of traction. But expecting the work on an existing protocol with millions of deployed nodes to be as quick misses how the entrenched interests of developers (many open source, some commercial) can affect a consensus driven process.
But if you want to contribute, just do it. The IETF is still open enough and technical enough that a good hack from just about anyone will get its just props.
Slashdot Mirror
There've been a lot of press releases from groups like the WSIS (World Summit on the Information Society) about "internet governance" and similar topics, but what they're really doing is using the near-universal dislike for ICANN to accomplish other goals. Typical announcements talk about several things:
Both WSIS and WGIG have some odd bedfellows. The registrars
hate ICANN because of their perception that ICANN's methods
for expanding the number of TLDs and assigning registries
are contrary to their interests. The ITU hates ICANN because it
assigns no power to governments (and despite all other parties
that play in ITU, it is the vote of "sovereign states" that really
counts). These people are playing together because of the
old "enemy of my enemy" dictum, but it's mighty clear that
they would not play well together once the enemy was gone.
Most of the registrars would hate dealing on ITU terms
(the few state monopoly ccTLD registrars excepted).
The ITU also dislikes that all of the protocol work came out
of the IETF, rather than its own study groups. It's now working with ETSI to create what it calls "NGN" (for Next generation Network", which is really an adaptation of the work done in
3gpp and 3gpp2 for wireless (and those are largely adaptations
of IETF core protocols, and much of the actual engineering
of things like ROHC and SIP was done in the IETF). The crazy
thing is that this is really just a service overlay network that
they somehow believe will subsume the services currently
running on the bit-pipe Internet we have now (where anyone
can offer you content or services without a special deal with
the operators). There is only one way that could happen,
really--massive regulation that eliminated everything but
the operator's approved services. They could try it and watch
it fail, of course, but I personally am pretty concerned about
the attempt.
Actually, that's not quite true. ICANN also provides the
u b/id/draft-huston-iana-00.txt
funding for IANA's other registries. Those registries are
used by multiple protocols (SMTP, SIP, XMPP, and a long
list of others). Go to http://www.iana.org/numbers.html for
a full list. Those are assigned, however, under rules set
up by the IETF and generally do not have the same kinds
of political and property issues at stake.
Geoff Huston, former Executive Director of the Internet
Architecture Board, has proposed splitting those off from
ICANN, so that political issues related to ICANN's other
roles don't affect them. http://mirrors.isc.org/pub/www.watersprings.org/p
has a copy of the -00 version of his proposal.
The IETF's CRISP working group has developed a replacement for whois: IRIS (Internet Registry Information Service). IRIS allows for different levels of access, so that you don't have whois's "all or nothing" response any more. This will help protect record details like addresses from harvest by J. Random Abuser (spammer, what have you). This is goodness.
I assume that the law enforcement agencies in the country in which the registry is domiciled would have to provide the highest level of access (equivalent to the current whois), but that other LEAs would have to go through the country of domicile.
This is speculation, though; ICANN/registry/registrar policies may make it easier or harder.
The main point in the above is correct: Sender-ID/Caller-ID/SPF
.
is about forgery. Forged spam is a use case, but there never was an illusion that this would stop spam--a spammer can simply buy a $9 domain, enter a record, and send the mail. The spammer just can't send it as user@protected.example.net
any more.
But the "Microsoft can sue SPF out of existence" piece is not correct (sorry, dude!). SPF protects part of the envelope:
the bounce address coded in the RFC 2821 MAIL-FROM;
Caller-ID/Sender-ID protect the headers in the RFC 2822
message (From:, Resent-From:, and the like). They do different
things. The working group discussed which one to prioritize
and picked the latter after Meng Wong and Mark Lentczner
(SPF authors) met with the Microsoft authors (Harry Katz and
Jim Lyons); this was discussed at the MARID
Campbell interim meeting.
Both are still interesting, but killing Sender-ID in favor of
SPF, as many are now advocating means you're changing
strategy; you're fundamentally changing what you're protecting.
To go back to the main point, neither will stop spam.
Write that down.
Anyone who can't spell Jon Postel's name right shouldn't
be trying to give a historical perspective on this problem.
Yakov missed a great deal of previous activity on this
topic in the IETF (viz. Sally Hambridge's efforts in the
90s), and his take on the recent events is heavily colored
by his previous position as the _IRTF_'s co-chair for
the Anti-Spam Research Group. Note Well: _previous_
position.
The group, like all IETF groups, is public, and all of its
email archives are available for your perusal. Why not
read for yourself and make up your own mind?
There are lots of other examples at http://ietf.org/ipr.html with
fairly similar "don't sue me and you can use it" terms. The IPR
terms being offered here almost look like a cut and paste job, to
be honest, and that may not be a bad thing. There actually
can be advantages to someone holding a defensive patent:
It means someone who wants to use a submarine patent to
control this technology has to fight Microsoft's lawyers.
Microsoft's grant is: 1) subject to any denial of claims by
the USPTO, 2) Royalty-free (as in beer), 3) Non-discriminatory
(anyone, anywhere, any time). Other submarine patents might
not be nearly so nice, and I'd rather have the next guy along
sue Microsoft than me.
There are some pain in the rump aspects; it is not:
sublicensable (everyone has to get their own free thing).
It does require you license back whatever you have claims on
that is needed for Sender-ID to get their thing needed
for Sender-ID (this is common in the IPR declarations given
to the IETF). That, in my humble not-a-lawyer opinion is
why you have to let them know your use is under the free,
global, yadda-yadda license rather than being an
infringement of the patent.
The good news: this does not require those deploying
Sender-ID records to do anything. It does not
require anyone using packaged binary software to do
anything. It does not require anyone distributing
packaged binary software to do anything.
It's a minor pain for implementors and a hassle for distributors
(who may, like Sendmail, have to put the Sender-ID code in a
different distribution). Not ideal, but not enough of a pita,
in my opinion, to go without the technology. Especially if
their claims cover things like "storing MTA authorization records
in the DNS" (and they could), rejecting this could mean rejecting
the whole ball of wax as an anti-forgery tool.
Who wins then?
SenderID and the LMAP proposals on which it is based are focussed on anti-Forgery, not anti-Spam.
This is intended to make joe-jobs and phishing harder.
Note that S/MIME and PGPMail (also standardized in the IETF)
are better for this because they confirm it was a specific
individual, rather than sourced from a specific domain. But this
is a useful incremental step that may cut down things like
spurious bounces *exactly because the SPAMMERS can work
around it*. Since it does nothing agains the 9 dollar throwaway
domain, it is not going to stop SPAM--just make SPAM purporting to be coming from you just a bit harder.
The MASS birds of a feather session at the upcoming
IETF is intended to look at cryptographic DNS records for a similar purpose (think DomainKeys).
Both are things that reputation services can use as a substrate for further work.
So, it is a useful piece of technology, but please don't judge it by "stops all Spam", or you will conclude it failed at a task it did not take on.
The general approach taken by SPF and friends does
,
nothing directly to stop SPAM. As numerous other posters
have pointed out, the throw-away domain is still available
to spammers and it is easy for them to generate valid
SPF records for those throw-away domains, even using
zombie networks (with dynamic DNS, you can even limit
the number of IP addresses in the records to mask
the size of the network).
It is useful, though, both immediately and in the medium
term. The immediate usefulness is in bounce processing.
An MTA whose role is to generate or forward bounces
can check the SPF record before action and not send
those for which there is no connection between the
message and the target of the bounce. That's very
useful, since it removes the clutter from the mailboxes
of those who were the targets of joe jobs. (Note that
an MTA forwarding a bounce can do this, as well as
one originating a bounce--that means an enterprise
can do this at the MTAs listed in the MX records).
In the medium term, the SPF record can be used to
limit certain kinds of forgery, making it harder for
social engineering attacks to work. It's not perfect,
by any means, since registration of domains like
"companyname-support.com" will still fool some
users. It also relies to some extent on the first
MTA in a series to perform the checks, as the scheme
gets weaker and weaker with the need to grovel
through more headers to make an association.
In other words, it works well when it is
ORIGINMTA--DESTMTA, but less well when it
is ORGINMTA--IntermediateMTA-IntermediateMTA-DESTMTA
since the RFC 2822 header (From:, Resent-From:, etc.)
processing gets more complicated. Since the latter is a core
part of the design of email (store and forward), there
are limits to SPFs role in this arena--especially when
spammers decide to pass there messages through multiple
MTAs under their own control to generate the appearance
of this complexity.
In the long term, the hope is that it starts folks toward
a more generic mechanism that allows the sending domain
to describe the characteristics of its email (e.g. all mail
is signed as S/MIME and all signatures derive from this CA)
and the receiving domain to check the characteristics
of the messages it's received against those.
Again, though, this is all about forgery, not SPAM.
URKI writes:
>The reason why it has not been done is just that, IETF can't get their act together.
The IETF is like a lot of other open-source communities: it depends on contributions from folks who have identified a problem and developed a solution to it. Unlike a lot of other communities: it is completely open, and it is consensus driven. Completely open means you can contribute your solution and get heard by the rest of the community as easily as, say, Harald Alvestrand. That's the upside. The downside is everyone else who has an interest can contribute gets to as well, and some of them may have solutions which don't work, are just as good as yours but different, or which have a different set of engineering trade-offs than yours so that different folks have an interest in seeing different ones succeed.
And did I mention, the IETF was consensus driven? Though this is "rough consensus", the core idea of the IETF is still that you take the *intersection* of what people feel is a good idea rather than the *union* (common in many other groups). That has a lot of consequences when combined with completely open.
That doesn't mean the IETF can't work on a problem. It does mean it probably isn't the place to engage in an arms race. In my humble opinion, spammers and anti-spammers are in an arms race.
So you're not too discouraged, if you look at the development of protocols like SIMPLE or XMMP in the IETF, you'll see neat stuff like e2e message integrity and encryption, and (with the IMPP docs finally out) even some ability to pass things from one to the other. Passing a message in IM, in other words, will soon be better than email for things that make a lot of difference to spam diffusion. Those are new protocols, and a *new* any-to-any message protocol might get a lot of traction. But expecting the work on an existing protocol with millions of deployed nodes to be as quick misses how the entrenched interests of developers (many open source, some commercial) can affect a consensus driven process.
But if you want to contribute, just do it. The IETF is still open enough and technical enough that a good hack from
just about anyone will get its just props.