-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
* Please add a short "document history" with the modifications since
draft -00. Especially list modifications caused by IESG [Discuss]
votes. Add the usual note that this part should be removed by the
RfC editor in the final document - xml2rfc supports this kind of
note, but I've never tested how.
Frank Ellermann wrote:
[Adding a document history to the spec.]
Wayne Schlitt wrote:
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.
I do try to list the differences in the announcements and I do provide
diffs.
The IESG won't read your announcements or diffs. [...]
I agree with Frank that such a "document history" section (if such a thing
is customary) would be good.
==========================================================================
Frank Ellermann wrote:
* "Checking other identities against SPF records is NOT RECOMMENDED"
| Checking other identities against the SPF records defined in this memo
| is NOT RECOMMENDED
It's perfectly okay to check the PRA against spf2.0/pra policies, or a
"submitter identity" against spf2.0/submit, etc.
Frank Ellermann wrote:
Wayne Schlitt wrote:
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.
I think "Checking other identities against the SPF records defined in this
memo is NOT RECOMMENDED" sounds awkward. If you ask me, I don't
acknowledge the legitimacy of any non-"v=spf1" SPF records.
But I agree that a slight clarification might be in order. I propose:
| Checking other identities against v=spf1 records is NOT RECOMMENDED.
This is as neutral and clear as it gets.
==========================================================================
Frank Ellermann wrote:
* "many MTAs will still accept such things as source routes (see
[RFC2821] appendix C), the %-hack (see [RFC1123]) and bang paths (see
[RFC1983]). These archaic features have been maliciously used to bypass
security systems."
They MUST accept source routes, archaic or not, it's a MUST in 2821,
[...]
There is no point in asserting (or even just assuming) that most or all of
the MTAs out there are fully compliant to RFC 2821. Some are, but others
simply don't support source routes, like it or not.
==========================================================================
Frank Ellermann wrote:
* If for a domain both types are obtained but their contents do not
match, the SPF client SHOULD return a "PermError" result.
| match, the SPF client MAY return a "PermError" result.
It could simply pick SPF before TXT and be done with it. I still
think that there can be valid reasons for different records, e.g. no
exp= in the TXT version due to size limits.
No, this is too fragile and unpredictable. If a client issues two DNS
queries (TXT and SPF), it should wait for both responses, and if they
don't match, throw an error so as to provide the administrator with an
as-early-as-possible warning about the inconsistency.
No "size limits" tricks, please. Admins are always free to say "v=spf1
redirect=_spf.example.com" if they need more TXT UDP package space than is
left for example.com.
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.
How this works? You issue two DNS queries, the one right after the other.
Then you wait for both replies. Short-circuiting is bad, see above.
IMO the current text (as of -01pre5) is just fine.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCfBqowL7PKlBZWjsRApXpAKCic61RLEiZwr4OL1H9Bxo/odd22ACgwr/2
4MuLi16VDuscSrnZYaKP/YE=
=eE5s
-----END PGP SIGNATURE-----