spf-discuss
[Top] [All Lists]

Re: Re: Scoping Syntax for spf1 records

2005-05-10 06:20:30

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