Thanks for taking the time to reply. We're definitely getting closer...
sounds like we agree on more than we disagree.
On Tue, 11 Oct 2005, Frank Ellermann wrote:
As the subject suggests, I am looking for a future scheme
that "unifies" SPF with other identities that might be
checked against IP.
Okay, I tried to find other interesting areas, but it's
apparently limited to "messages". For say Web pages you'd
use the A of the FQDN (or a proxy, but that's your choice),
you normally get what you want, and for the critical stuff
there's https (SSL, now TLS).
I know sh*t about IM, Jabber, SIP, etc., but this was all
invented after spam hit first news and later mail, I hope
that they got it right.
Therefore the "other identities" you talk about are most
probably message/rfc822 identities (mail or news), because
we have already covered everything else that's available
in SMTP (hello + MAIL FROM) - unless somebody introduces
another ESMTP identity like William's or Harry's "submitter".
I agree, let's deal with identities normally found in mail, and keep an eye
out for news. News is not really the target area, so we don't want to go too
far out of the way to support it, but at the same time we don't want to
do anything that makes later application to news impossible.
So if we can agree to limit this braistorming strictly to
"any 'identity' you might find in a message/rfc822" we have
reduced the problem to PRA^W2822.
My big problem with PRA is that it's not really "an identity". It's a
collection of identities with a complex algorithm attached.
It may seem like a fine line, but what if From: has a policy that conflicts
with the Sender: policy, and they are in two different domains? For example,
if a domain should *never* be used in outgoing email, the domain owner should
make a strong assertion that the domain should not appear in any header, and
the receiver should find that interesting and relevant, even if Sender:
checking might give it a pass.
PRA is one possible answer to 2822, but I don't think it's the only one, even
if it's both interesting and sexy. If someone wants to just check From: and
not Sender, that might sound silly from where we are standing, but let's not
go out of our way to make a tool that's incompatible with that.
I predict v=spf1 will probably be replaced by something
else (hopefully something better) in the next 1-2 years.
I don't see why that should be the case, at its core v=spf1
is KISS. I'd love to make it more KISS, but I disgress.
It's a great tool for what it does, but if another tool comes along that does
the same, and also does more, v=spf1 could certainly become redundant.
spf2.0 is already somewhat better, it has those positional
modifiers, that was a really cute idea, and it has scopes.
As far as I'm concerned that's good enough for everybody,
we could write a proper "protocol" document (v=spf1 minus
the stuff only relevant for HELO and MAIL FROM), strictly
compatible with senderid-core of course, and a proper
"mfrom" document, i.e. finish Mark's MARID work. With
some leaway to integrate HELO into "mfrom", or to add a
separate "helo" document - the latter could restrict the
rich SPF language to a + mx + ip4 + ip6 + all, no macros
(maybe, as you said "brainstorming").
I like the sound of that, on the whole. That is very close to what I was
expecting would happen with spf-next. I didn't use the name "spf2.0" because
it's been used by Sender-ID and I thought that would leave a bad taste in some
people's mouths. But it's close to what I am thinking.
We talked briefly about getting rid of macros during Marid.. there was some
support for it, but the consensus seemed to be that there are a handful of
problems that macros can solve that have no solution otherwise. Normal people
should not have to use them, but if you're in a rare case that needs them,
there is no workaround.
While we're at it we could also restrict "mfrom", e.g.
deprecate the dubious exp=, only PRA and v=spf1 may use
it, spf2.0 implementations are free to ignore it anyway.
But that's more or less a laborious task, and not really
innovative, parts of the stuff needed when we try again
to get a PS (proposed standard) for SPF. More important
parts will be the results of this (pseudo-) "experiment",
interoperability and implementation reports (precisely
183 days after an SPF PS I'd want a Draft Standard... ;-)
:-) Yes, as creative as we all are, reality will almost always turn out to be
stranger than what we imagined. The best we can do would be to make it as
flexible as possible and give our future selves the flexibility to do cool
stuff that our past selves could not dream.
I'm dreaming of something generic enough to be used by
HELO, MAIL FROM, RCPT TO, Received, From, Sender, Reply-to,
X-Originating-IP, Message-Id, or even
Peanut-Butter-Coating-Applied-By: -- basically anything
that might benefit from a DNS record that states sender
policies (usually IP-based).
Forget RCPT TO, Received, and X-Originating-IP. For From
and Sender you'd get again PRA, right or wrong, that part
is ready. If you want to define sets of IPs allowed to
use your domain (we're talking about domains, aren't we ?)
in Reply-To, how's that supposed to work with lists or
forwarders ? Same problem with the RHS of Message-Ids.
Back in the Unified discussion (seems like years ago now) there were a whole
raft of identities that could be checked. Some of them could be strongly tied
to IP (HELO is the strongest). Some were weakly tied to IP because they
correlated to the originating site and didn't change over forwarding.
However, there is still some merit in checking those identities that usually
don't survive over mailing lists and forwarding: the advantage is that if
they DO match, we can fast-track the email past most other tests. Most users
get a lot of email from various sources, mailing lists, confirmations,
reminders, whatever... but the mail they care about the most is usually direct
to them from someone they know. If it's from someone they know, and the IP
matches, that ought to get a gold star, or green checkmark, or something. It
can't be used to reject, but it does give something of value, and gives a
starting point to build other stuff onto later.
I'm imagining over time that there will be a list of identities that receivers
can check, in a certain order and with certain results for each test, and that
the list will change over time, and will change based on the preferences of
the receiver.
PRA is one possible combination of tests, or really it's one test selected out
of a wide range of possible tests. PRA makes a best guess as to which test
will likely yield the best result, and then performs that one test. But
wouldn't it be cooler if multiple of those tests could be performed against
various identities, with different results leading down different paths?
I'm not sure if you were around when Unified was first
proposed.
IIRC I joined this list in April 2004, shortly after MyDoom.
My subscription list is still in chronological order, ASRG
before SURBL before MXCOMP before SPF - LOL, so I started to
read MARID before SPF, now here's a true IETF + RMX believer.
That's what I thought...
suffice it to say that I like Unified SPF theory and I think
it's a great idea.
Yes, I think that it's a horrible idea, because 2822 is user
territory. Absolutely nobody has a right to manipulate what I
say there, they also have no right to restrict my freedom to
use "my" addresses in 2822 where- and whenever it pleases me.
Ouch. Do you mean that nobody should be able to say when your domain may be
used in 2822 space -- not even you?
I'm only here (SPF) because I thought that Meng and AOL have
implemented RMX, it's all an accident, I'm an RMX fan... :-)
I think we come from a similar background. I remember finding a draft on MS
records by Andrew Church, before I even heard of RMX or DMP. It's a good
idea... it's just having a little trouble getting off the ground :)
[about DKIM]
what is SSP?
"Sender Signing Policy", one of the now three DKIM drafts:
<http://ietf.org/internet-drafts/draft-allman-dkim-ssp-00>
OK that shows my ignorance of DKIM... I haven't been tracking it closely. I
should do so.. There are opportunities for integration there, but if they
invent one wheel and we invent the other without talking to each other,
chances are they won't fit well on the same car.
You can perhaps help to keep me honest in this area. If there are ways dkim
and spf might possibly work well together, we should be trying.
[back to SPF]
I want something that will replace both v=spf1 and Sender-ID,
and be flexible enough to apply to other headers too
Nothing's seriously wrong with spf2.0, so why replace it ? If
you have a better idea than PRA for 2822 let's hear it. It's a
long time after William proposed eh= --- and it's also a long
time that I've removed op=rfc822 formerly known as op=william
in version 3 of the op draft, because it got no traction here.
As long as spf2.0 can be used for other scopes, and is flexible enough to have
more scopes added to it later, I'm good with that.
I personally don't care for the syntax of spf2.0/TAG,TAG because it
discourages people from adding/checking new tags later. Even if they happen to
use the same mailserver to send their 2821 mail and their 2822 mail :) they
are discouraged from publishing one policy and having it apply to all scopes.
(unless spf2.0 with no slash is assumed to be spf2.0/*, then perhaps I could
live with it, but I would still want a scope macro for some situations)
For example, most people will not need to publish a different policy for their
HELO usage than for their MAIL FROM usage, but there have been people who
asked for it. Luckily we had that situation covered, we assume that if they
are checking HELO, then %{l} will expand to "postmaster".
In general I like spf2.0, but it has the stigma of being associated with
MS/PRA. Is it possible to use spf2.0 to specify a From: policy that's
different from the Sender: policy? Or is 2822 wrapped into a
one-size-fits-most package? We can try to predict the future, but we won't
predict it accurately. The best we can do is to prepare for multiple
eventualities as best we can. "PRA is the best thing for 2822 short of dkim"
is one possible future, but I don't think it's the only one. Let's try to
build some extensibility into spf2.0, save a few bits for future expansion,
that kind of thing...
Thanks again for taking the time to write. Be well.
gregc
--
Greg Connor
gconnor(_at_)nekodojo(_dot_)org
Everyone says that having power is a great responsibility. This is a lot
of bunk. Responsibility is when someone can blame you if something goes
wrong. When you have power you are surrounded by people whose job it is
to take the blame for your mistakes. If they're smart, that is.
-- Cerebus, "On Governing"
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com