spf-discuss
[Top] [All Lists]

Re: -01pre5

2005-05-04 01:53:41
wayne wrote:

I think it would be more productive to discuss them here

Yes, that matches what I said in this mail (early March):

| I'll also post them when or if you decide to publish 01pre2
| for a SPF community review.

When you later mentioned Julian's or my old proposed changes I
thought that you've somehow already integrated all "important"
points - "important" from my POV is anything where somebody
wanting to derail SPF could attack your draft.

 ["document history"]
I could easily have missed it, but I haven't found that to
be a requirement.

It's not required, it's just a polite way to indicate that you
have seen the IESG [Discuss] notes and addressed them by some
modifications like the "Version 1" in the title.

They reviewed -00 in February.  Nobody knows when they review
-01, let's say September, and then they won't remember what the
problem (if any) with -00 was.

I do try to list the differences in the announcements and
I do provide diffs.

The IESG won't read your announcements or diffs.  A "document
history" is also a nice place to explain v=spf1 vs. spf2.0/* -
that apparently confused at least one IESG member.

The RfC 2119 key words REQUIRED, SHALL, SHALL NOT, and
OPTIONAL are not used.  Probably irrelevant, but Bruce
apparently checks this.

Uhmm...  I'm guessing this is a joke?

Ask Bruce, I'm not sure - it's apparently not mentioned in the
rfc-author-guide-01 or the 1idguidelines.  Bruce knows _all_
relevant RfCs by heart including the errata.  Maybe.  But I'm
sure that he doesn't like SPF.

| Checking other identities against the SPF records defined
| in this memo is NOT RECOMMENDED

I'm not going to touch "spf2.0" records.

Yes, that's exactly the point of adding "defined in this memo".

You have only "against SPF records".  That's not precise, it
could be (mis)read as "all versions of SPF including spf2.0",
and then the NOT RECOMMENDED would be incorrect.

It's the IESG.  They don't know why there is a "version 1" and
an obscure "spf2.0".  But they have drafts for both versions
tabled at the same time with the same coauthor.  Your coauthor
might say "delete this sentence" when asked.  Or whatever the
problem with this NOT RECOMMENDED in -00 was.  Nobody answered
this question, only William risked a guess.

I changed the %-hack reference to your suggested RFC1123.

Yes, but there's still something odd with this paragraph.

backbone!cabal%schlitt(_dot_)net(_at_)midwestcs(_dot_)com is inherently
ambiguous about which "domain" is being dealt with.

The RHS = domain is clearly midwestcs.com.  The LHS local part
suggests that this might be a gateway to a host schlitt.net.

Maybe schlitt.net is a UUCP host knowing another UUCP host
backbone with a user cabal, but that's not sure, and besides
irrelevant for SPF and the receiver.

Where a bounce would end up is anyone's guess.

Let midwestcs.com guess, and let the receiver check the policy
of midwestcs.com.  If the receiver checks schlitt.net it's a
bad case of a broken SPF implementation.

I think it is worth a short sentence to make sure that SPF
implementors are aware of these kinds of issues.

But it's confusing, do you want them to extract schlitt.net ?
If not, why mention it at all ?

And why pretend that accepting source routes, a MUST in 2821,
is somehow "optional" ?  "Many MTAs will still accept" - yes,
of course they accept source routes, because they MUST.  They
are free to reject the %-hack etc., but where is this related
to SPF ?

 [the text is provided by the sender's domain]
Better?

Sure, typos are not so important, just ignore it if it's only
me or my stoneage dictionary.  BTW, Bruce prefers US spelling.

Of course you can use OED, but you're better prepared to say
why.  His first fire is the worst, if it's more than 5 KB in
one mail the draft is hit badly.  Maybe we get a WG like LTRU
(3066bis) to fix it.

The language dealing with the SPF vs TXT DNS RRs was hashed
out between MarkL and (unamed) "DNS gurus".  I don't see this
as being worth battling them on it, but I'm also not sure if
the "DNS gurus" will care.

Okay, let's assume that these gurus wanted identical records.
You could still s/SHOULD/MAY/ if the records are different.

Or just say SPF before TXT, and don't mention this "parallel
query" with different results.  Excl. -q=any I'm not sure how
this works.  Send a -q=spf followed by a -q=txt and then wait
for the first answer ?   But whatever the first answer is, you
would use it, and not wait for a different / identical answer
for the 2nd query, or a timeout.
                                 Puzzled, Frank