Greg Connor wrote:
I think we ended up talking past each other.
Yes, no problem, the list isn't crowded at the moment, we have
the time to sort it out.
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'm *not* looking for clever ways to modify v=spf1.
But you are looking at message/rfc822, aren't you ? For
many other "objects", especially XML, all I know is that
there are already standards to sign them.
it's intended to be a brainstorming session for a future
superset/extended application of SPF's ideas.
I like brainstorming, but I don't know any details of what
DNSSEC, IRIS, Jabber, LDAP, ... do against forgeries. But
I'd bet that they won't need SPF for whatever they do. ;-)
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.
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.
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").
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... ;-)
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.
"Peanut-Butter-Coating-Applied-By" could be a special case,
if it's done short before the final delivery. E.g. if it
is a Received-SPF header protected by its very own spf2.0
"rec-spf" scope record.
But actually I don't get what you're dreaming about, where
is the difference from PRA ? Where precisely does it avoid
the PRA problems ? We could invent new fun identities like
the Message-Id or Reply-To, but they are all worse than PRA.
Replacing something bad by something worse is pointless -
so what _is_ your point ? I need an example.
If we're having excellent dreams of an excellent future,
why confine ourselves to just HELO and MAIL FROM?
Because that already "breaks" traditional forwarding. Why
"break" it more than once ? PRA tries this stunt, demanding
that all lists / forwarders worldwide add Resent-* headers
to mails.
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.
My first posted article here (May 30) was of course off topic:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200405/0554.html
But two days later GMaNe had spf.help, sometimes it's fast ;-)
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.
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... :-)
[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>
[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.
Removed together with op=pra, but I've added that again later,
just in case for Julian's and Wayne's missions to MAAWG and
some antispam summit. For details see the version history.
I fully realize that the result of the "Unified" exercise
will most likely produce something that is not backward-
compatible with anything.
If it ain't broken... What's wrong with spf2.0 ? Bye, Frank
-------
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