Greg Connor wrote:
here is where I diverge from most scope-zealots: my firm
belief is that cases where scope is really *needed* will
be very, very rare.
On Thu, 12 Jan 2006, Frank Ellermann wrote:
Out of curiosity, who are the many scope-zealots, William ?
To my knowledge there don't seem to be "many" of us in the zealot camp, but I
still want to differentiate myself. Over email you can't see my aluminum
anti-mind-control helmet :)
I want to encourage people to use the *same* spf code for
multiple identities.
Well, and here we're stuck. Those who don't want PRA have no
reason to migrate from v=spf1 to spf2.0/mfrom. Those who want
both cannot simply say only spf2.0/mfrom,pra, because many SPF
implementations supporting v=spf1 won't look for a "mfrom" in
spf2.0, let alone support the spf2.0 positional modifiers.
I think you're right here... I think there's no good way to shoehorn true
scopes into the v=spf1 world, and spf2.0/* is tainted enough by S-ID to be
pretty irrelevant to me. If a future SPF spec actually defines what to do
with spf2.0/mfrom, I suppose I would be happy with that, and I would
eventually shut up about how it's less optimal than %{e} and get on with my
tiny life.
Given the above beliefs, I envision scopes as either
positional modifiers (reasonably OK) or as macros (best).
[...]:
"a mx ip4:10.1.2.0/24 redirect=%{scope}.spf.%{d}"
I know a lot of people don't like macros because they are
complicated, but if you believe as I do, that people will
rarely need diverging scopes, it makes some sense.
IIRC that idea was Meng's %{e} in MARID discussions. I'm not
sure, in the last marid-protocol-03 draft there is no %{e},
and I don't have the older drafts anymore.
Perhaps in the "future" SPF we could have both "spf3.0/x,y,z" and also support
%{e} - there's no rule that says we can't have both (Occam be damned!)
Something to talk about in the coming year, perhaps. Anyway I totally agree
that it should be considered a major change. I would even go so far as to say
that if "proper scope" is the only advantage to "New SPF" it probably wouldn't
be enough for implementers to bother updating.
Anyway, that's a part of my "vision" for the future of SPF...
practically speaking, a small part, but still somewhat
important. I look at it as an opportunity for SPF to "branch
out" in the future.
Curious minds still want to know what scopes you have in mind.
Ah, the typical reply of the non-zealot! Come on, drink the "Unified"
Kool-aid with me!
While I hate PRA in practice (and the IESG / DEA / MARID issue
is on a level as what happened in Korea), I still think that
the PRA is a valid _theoretical_ concept, and in fact the best
you can do without keys (like DKIM) for any 2822 "identities"
and the existing 2822 header fields.
Seriously though, I think you might be right about PRA being the best possible
case for 2822, but I'm not confident enough in that answer to say that PRA is
the only thing we might want to check in 2822. Maybe there are special cases
we haven't thought of. For example, consider these fringe cases:
1. If mydomain.com should never appear in From: maybe that's enough reason to
reject the message, even if Resent-From: is something apparently legal.
2. If mydomain.com appears in From: and happens to give a Pass, great! For
users who don't have their mail forwarded, they could get a lot of the
positive value that a PRA-Pass gives you, but with fewer side effects.
This could be used along with whitelisting, maybe.
3. What about spotting forged Received: lines like these
. Received: from Tue, 17 Jan 2006 23:08:49 +0300 ([Tue, 17 Jan 2006 23:08:49
+0300]) by smtp.endend.nl with QMQP; Tue, 17 Jan 2006 23:08:49 +0300
. Received: from unknown (154.143.19.90) by mail.gimmicc.net with ESMTP; Tue,
17 Jan 2006 22:50:17 +0300
. Received: from [Tue, 17 Jan 2006 22:48:58 +0300] by mail.gimmicc.net with
SMTP; Tue, 17 Jan 2006 22:48:58 +0300
. Received: from unknown (HELO relay37.vosimerkam.net) (Tue, 17 Jan 2006
22:40:25 +0300) by public.micromail.com.au with NNFMP; Tue, 17 Jan 2006
22:40:25 +0300
Any of the domains mentioned could publish spf3.0/receivedby to state that
their domain is never used in Received:.* by (.*). Or perhaps Received: from
heloname (ptr-name [ip]) could check heloname against HELO scope, and ptr-name
or IP.in-addr.arpa for any blanket "-all" statements that say the IP should
never be used for outgoing mail.
4. If the message coming in already contains a Received-SPF: line, check to
see if it was added by a trusted forwarder, and if the domain name for the
trusted forwarder matches with the SPF-authorized IPs for the name. If so,
you can choose to trust the information added by the forwarder and use it
instead of adding your own Received-SPF line. If a Received-SPF line already
exists, but it's not from a trusted source, strip it out; if it claims to be
from a trusted source but the IP doesn't match, strip it out and possibly
reject the message as a forgery.
All of these are admittedly fringe, maybe even wacko cases, but my hope is
that if we give people enough tools, someone will hit upon a really cool way
of using one of them in a way we didn't plan on, and it will turn out to be
helpful. Who knows? :)
Bye, Frank
Talk to you later. And thanks.
--
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://www.openspf.org/
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