On Tue, 10 May 2005, Frank Ellermann wrote:
william(at)elan.net wrote:
sc.example=no <==== This domain being queried is never used
with example identity (way of saying
"-all" but just for that scope)
That's like op=nohelo in the case of a "HELO identity".
sc.helo=no is equivalent of that. Note that its universally useful syntax
for any scope
sc.example=ema <==== [EMA = Equivalent Mail Address]
This means that all source systems
enforce rules so that Example Identity
address is always equivalent to SMTP2821
MAIL FROM (default) identity
No idea what you're talking about. You need an enumeration of
"scopes" or "identities", and how they are determined.
Enumeration of scopes and documents defining their use is indeed needed.
Possibly IANA or similar registry may have to be created.
What is a sc.helo=ema or a sc.mfrom=ema ? (Assuming that "mfrom" is
what I think it could be)
If we have identity "sender" ("Sender" or "From") header, then
sc.sender=ema (or its full variant is sc.sender=ema.mfrom)
means that all mail sources listed enforces submission in a way that
RFC2821.MAILFROM is always the same address as "Sender:" header or
"From:" header.
sc.mfrom=ema is same as sc.mfrom=ema.mfrom - and so its always true
sc.helo=ema would mean all emails coming from domain must have
postmaster(_at_)example(_dot_)com in RCC2821 MAIL FROM. In theory outbound mail
servers only sending bounces could make such an asertion
In general ema is good assertion to know (if somebody can make it) and it
also saves the time of doing extra spf lookup if mailfrom hasalready been
verified.
sc.example=dom <==== [DOM = Equivalent Domain]
This means that all sources systems
enforce rules so that a Example Identity
would have an address in same domain as
SMTP2821 MAIL FROM (default) identity
So sc.helo=dom could mean that MAIL FROM:<user(_at_)an(_dot_)example>
always comes from a HELO an.example ? And sc.mfrom=dom would
be bogus, because that's obvious ? Maybe mfrom is not what
you have in mind,
Ok, I hope you still remember Logic 101 :) But just in case -
Equivalence operators are not true "==" but "<=". So asertion
for "sc.helo=dom" is that whenever you see EHLO example.com, you
should expect that RFC2821.MAILFROM would also be address @example.com
Above does not necessarily mean that for every RFC2821.MAILFROM its
always going to have EHLO of example.com, such an assrtion would be
"sc.mfrom=dom.ehlo".
sc.example=net <==== [NET = Equivalent Network]
This means that Example Identity would
have sources in same networks as MAIL
FROM identity (this is basicly what PRA
presumes by default)
That's PRA ? Where ? And why is it better than an op=pra ?
Sorry, I meant its what "MS Sender ID" draft presumes by by default, i.e.
"sc.pra=net" which means that all networks for PRA identity are the same
as those of MAIL FROM identity.
sc.example=spf('spf2.0/exa') <=== Do spf-style lookup using
record in separate text or spf dns record
which has a prefix of "spf2.0/exa"
Oops, is that stuff about spf2.0 ? Then I won't discuss it at
the moment, I'm preparing for a war aka "last call schlitt".
SPF is general inclusion operator for scoping syntax, it basicly
says that actual spf operation should be done on spf record (with
specified version number, but here we presume it all to be spf1)
from such and such location (location can be macro BTW) and
additionally allows for spf to be done against spf versions.
Note that "version number" does not really need to be anything defined
and can be anything user likes to use and this allows for separating
into multiple records that are all pulled down together as part
of same TXT or SPF dns lookup
But spf2.0 certainly allows spf2.0/mfrom,exa for all defined
values of exa, i.e. pra, submit, (undocumented) helo, and more
on demand.
"v=spf1 ... -all sc.pra.submit=net" would be same as
"spf2.0/mfrom,pra,submut ..."
Note that "v=spf1 ... -all sc.pra.submit=spf('spf2.0/mfrom')" would not
cause use of "spf2.0/mfrom,pra,submit" record above as prefix must fully
match up until first FWS
example.com. IN SPF "v=spf1
sc.example1=spf('x-spf/shared'),spf('x-spf/example1')
sc.example2=spf('x-spf/shared'),spf('x-spf/example2')"
example.com. IN SPF "x-spf/shared ip4:192.168.0.0/20 -all"
example.com. IN SPF "x-spf/example1 ip4:127.0.0.1 -all"
example.com. IN SPF "x-spf/example2 ip4:127.0.0.2 -all"
That gives you the default ?all with v=spf1 implementations.
Its an example. I did not bother showing actual spf1 record to
show how scoping and inclusion works for all other scopes.
What's the point, saving a query in a backwards compatible
"version 3" implementation ?
Don't know what you mean here. The proposed syntax is best I could come
up with that would be consistant with spf1 specified syntax and yet
allow to do almost as much as I wanted. If we had scopes or positional
modifiers, things would have been easier.
The "hunting for records" issue ? But you get _all_ SPF records for a
q=spf, there's no need to squeeze completely new concepts behind a
"v=spf1", and you could also use the spf2.0 positional parameter style:
"spf3.0/example1,example2 ip4:192.168.0.0/20
ip4:127.0.0.1 only=example1 ip4:127.0.0.2 only=example2 -all"
I would be very glad to start working on SPF3, but I do not see enough
interest in the community for new version of spf yet. So in the mean
time I've worked out what is spf1 compatible scoping syntax (which is
exactly what subject of the post said).
Shorter and all in one record. Note spf3.0, stuff like "only="
can't be added to spf2.0, same problem as stated in the "op="
memo. Of course spf3.0 can do whatever it wishes, e.g. use
your syntax. But this is not the time to discuss spf3.0 or
scopes or fantasy identities like submit or weird "op=" stuff
for the 1000 and first time. It's the time to get an RfC for
v=spf1 as is. More precisely it's one year after this time.
It so happens, I agree. I was actually hoping to bring this up after
new spf draft has been published by Wayne and we would have some pause
to discuss other things. But you and Julian continued talking about
scopes, so I thought I might as well say something about what I had.
P.S. My apologies to Wayne - I told him I'd not bring up anything new
until spf-classic-01 draft is published.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net