Meng Weng Wong wrote:
A patent application is not a patent; I understand that
nowadays applications are filed containing many claims that
the filer doesn't actually expect to be approved, but if
they are approved, bonus! So let's look at which claims we
can realistically expect to survive into patent form, and do
our best to educate the patent office about the rest. The
ones that do make it into the patent may not turn out to be
an encumbrance after all, or if they are an encumbrance at
least we have a solid idea of how to route around them.
That's important. Also, isn't anything that's provably prior art that
makes it into the patent not an encumberance either? In other words,
what will make it into the patent and can be successfully defended is
the relevant question, yes?
CSV alone is not sufficient because it has a weaker
deployment driver than SPF / Sender ID. To wit:
I don't disagree with your arguments in support of this claim, but I
disagree with the conclusion because of strong counterarguments.
Here are some arguments that the opposite is true (an edited version of
Meng's post):
SPF / Sender ID alone is not sufficient because it has a weaker
deployment driver than CSV / SPF3. To wit:
Suppose we have lazy.example.com. We want to encourage
lazy.example.com to deploy whatever we come up with. But
they're lazy, so they naturally want to know the
consequences of noncompliance.
"If I don't publish CSV records, what have I got to lose?"
"Spammers might spoof with your HELO domain name. Besides,
it's quicker to do it than to spend a few minutes discussing
'why bother?'. Heck, if you don't run your own mail servers,
you can just publish an empty record, which will ensure you
have a good reputation when you decide you want to have your
own mail servers. It's much, much easier than creating a
good SPF1 record."
"Will people reject my server's mail simply because I have no CSV
record?"
"If spammers spoof with your HELO domain name, it'll get blacklisted.
They're going to reject your server's mail once that happens."
"Oh, then yes, that is a problem. I'd better make a CSV record.
There'll be CSV records on
every legitimate HELO hostname in the world soon,
so as to close that loophole, huh?"
The SPF story goes like this:
"If I don't publish SPF records, what have I got to lose?"
"Spammers might spoof with your domain name in the
return-path or the headers."
"How do I create an SPF record to prevent this? My users
send mail through servers like smtp.comcast.com. According
to AOL's Hutzler, 'AOL already gets >85% of our spam from
other ISPs main outbound MTAs.'
"You can't. (Unless you force your users to use servers you control.)"
"Will people reject my mail simply because I have no SPF
record?"
"No..."
So it seems to me that the average domain owner has a more
compelling case to do *CSV than SPF*. I'm not saying nobody
will do SPF...
I have been observing a pattern of fallacious debate which
can perhaps be called "winner takes all". In this pattern,
when you are given a choice of N options, you are allowed to
pick only one: so proponents fight tooth and nail for their
favourite choice. This happens a lot because winning feels
good; many of us are trained to try very hard to win; and
besides, people who do not subscribe to this pattern of
living tend to be interest themselves in things other than
IETF working groups.
Yes, the wannabe-standards can be seen as complementary. The IETF can
endorse (so to speak) several of them.
However, there's a cost to implementation of each one (and they vary!).
To the extent that we can standardize on the minimum number that is
sufficient to accomplish the goals best (in terms of, e.g. the amount of
effort needed to implement them) we reduce the total cost of
implementation. Given that all the proposals require A&R (Accredidation
and Reputation Services) to be effective*, the amount of work needed for
A&R should be considered important as well.
(*notwithstanding Doug argument that that SPF-style A&R is nigh
impossible.) Hence it's appropriate for you and I to argue, as we are
doing, which is better.
Remember all the effort that sysadmins went through to close open
relays? It was thought that this would go a long way toward solving the
spam problem. It failed to stem the tide. We need to have some
confidence that when we go to sysadmins and ask 'em to do something else
to solve the problem that it WILL stem the tide. Hence the urgent need
for a *closely scrutinized / debugged* BCP on how M.A.R.I.D.s should be
used.
(Yes, I'm agreeing with William - we should choose one MARID scheme.
I am implementing a next-generation system based on the
Aspen model of authentication, reputation, accreditation.
In that system, I'll check authentication on SPFv1, SPFv2,
CSV, and Domain Keys. I'll check Spamhaus and Cloudmark
Rating and the VDL. Two heads are better than one, and
yellow and blue go very nicely together.
Cool. I expect SpamAssassin will be doing much of this as well (not the
SenderID bit!).
OT: How does one access the VDL?
David Woodhouse said:
We need to stop disingenuously selling SPF/SenderID
Yup.
Claus Färber wrote:
...
Some time later:
"I'm getting more rouge bounces."
It's 'rogue'; folks keep misspelling it or I wouldn't mention it.
"That's because some servers bounce messages when the SPF check
failed."
"I thought they should not do that."
That's true but the spec itself doesn't say whether they should or not.
Anyone want to work on the BCP? I'm thinking of putting it up on a wiki
(the ASRG wiki, so that contributions are covered by needed policy) for
collaborative improvement.