Dick St.Peters wrote:
What do you mean when you describe spf2.0/mfrom as
"non-existing"?
There's no document defining it. It was defined for a very
short time in draft-ietf-marid-mailfrom-00 by Mark Lentczner.
Days after he submitted it MARID was closed, and Mark wrote
draft-lentczner-spf-00, because Meng's old v=spf1 spec. was
expired. That "emergency draft" was again v=spf1, and later
replaced by Wayne's drafts.
It's part of draft-lyon-senderid-core-01.txt, and it
appears in some domains' spf2.0 records.
It's unspecified. Nobody knows for sure what it does, is
it simply v=spf1 plus positional modifiers, or is it v=spf1
plus positional modifieres minus spf2.0/helo. If it's the
latter, where's the spf2.0/helo draft, and how exactly does
the unspecified spf2.0/mfrom handle an empty Return-Path
or the macro %{h} ?
You can guess, but draft-lyon-senderid-core doesn't specify
it. It only offers the *possibility* of additional scopes,
with a pointer to the existing PRA spec for spf2.0/pra, and
no pointer to a corresponding spf2.0/mfrom spec.
This sounds to me almost like your goal is to pick a
deliberate fight.
No, I want an explanation for the missing link spf2.0/mfrom.
It _is_ v=spf1 + positional modifiers, and because there is
no positional modifier it is in practice the same as v=spf1.
What would be your purpose in adding new conflict between
SPF and SenderID?
That's no conflict, it's reality. The MAAWG speculations
about what the diference between v=spf1 and spf2.0/mfrom
might be if there is in practice no difference confuse all
users.
PRA is not at all interested in esoteric questions about a
potential separate HELO scope, or the internal details of
"mfrom", PRA is for DATA and 2822 header fields.
No conflict at all, they have a pointer to the existing
v=spf1 spec. replacing the former marid-protocol draft _and_
the former marid-mfrom draft.
AFAIK they forgot to say what a %{h] does in a PRA-policy,
but that's none of our business. I'd specify / implement
it as a PermError. Maybe they fix it in their AUTH48, it's
a minor issue.
Imagining that mfrom and helo scopes can be described by
a single SPF policy is ludicrous IMO.
There were no serious requests (by users) for different
policies in all those years. No developer ever said that
now is the time to do spf2.0/helo or op=helo + op=nohelo
(see 6-3-options draft).
Nobody wants or needs this separation in practice, because
it makes no sense. Any decent sending MTA has its own host
name not used as LHS of mail addresses, therefore it never
needs its own HELO scope, it already has its own name.
The only theoretical disadvantage of the "unified 2821
scope" (v=spf1 and spf2.0/mfrom alike), a pure HELO scope
could do with less mechanisms and less qualifiers. But in
that case interpreting spf2.0/mfrom,helo would be tricky.
In essence you'd get the same effect as with op=nohelo and
op=helo as the most exotic cases, we have this already (in
theory, as a paper), but in practice nobody wanted it.
SenderID's spf2.0 records allow domains to specify what
scope(s) their SPF records cover.
Nothing wrong with two scopes, 2822 vs. 2821, and if they
want more on the 2822 side they can add it. But for 2821
there are only HELO and MAIL FROM, and as shown it makes
no technical sense to split them. The old MAY (now SHOULD)
about HELO was no error or accident, it was and is sound.
If you don't want your MFROM scope used for PRA, you
can say so.
Yes, spf2.0/mfrom does this. As shown that's the same as
v=spf1, unless you can produce a cute positional modifier.
So now there are more than a million (1) v=spf1 published,
nothing's wrong with those policies, and your hypothetical
positional modifier must offer something extraordinary if
you want users to migrate this to spf2.0/mfrom.
After developers implemented it. But they won't do this
without a proper spec. for spf2.0/mfrom explaining how stuff
is supposed to work wrt HELO and %{h} and MAIL FROM:<>.
That's why I think that we should specify it as almost the
same as v=spf1. After all that's what lyon-senderid-core
silently assumes, "almost" limited to positional modifier,
otherwise identical.
After the theory is clear it's also simple to give advise
why that's unrelated to common practice, and what users who
seriously want only PRA, or only v=spf1, or both identical,
or both different, should do.
Obviously those wanting both identical are forced to have
four almost identical records (2*TXT + 2*SPF), that's not
nice, but OTOH it's also no serious issue.
Bye, Frank
(1) Where does the number "1,700,000 domains" come from ?
-------
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