-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wayne Schlitt wrote:
Julian Mehnle wrote:
But considering that, like you said, most receivers probably reject
messages with non-existent sender domains right away anyway, without
subjecting them to SPF checks, I think defining
SPF(non-existent-domain) == "PermError" is unproblematic and is
logically the right thing to do.
People just shouldn't expect SPF to work on invalid input data.
I'm interested in hearing what others have to say on this issue.
Right now, I'm not convinced that the draft should be changed. Please
feel free to bring this issue up for a vote on the council.
I may do this, but before that, I'm also much interested in others'
opinions.
----------------------------------------------------------------------
--- draft-schlitt-spf-classic-01pre1.xml
+++ draft-schlitt-spf-classic-01pre1+mehnle.xml
@@ -1299,5 +1313,5 @@
<t>
If <domain-spec> is empty, or there are any processing
- errors (any RCODE other than 0), or if no records are
+ errors (any RCODE other than 0 or 3), or if no records are
returned, or if more than one record is returned, then
proceed as if no exp modifier was given.
#
# Fix semantics. Note that this is essentially unrelated to the
# "SPF(non-existent-domain) == PermError" series of changes.
#
----------------------------------------------------------------------
You rejected it. Could you please elaborate why?
a DNS RCODE of 3 means the domain doesn't exist. Why shouldn't we go
ahead and use the default exp processing? What are we supposed to do
with it?
Uhm, you're right, this change of mine is inappropriate. I thought that
RCODE 3 (NXDOMAIN) were already covered by "no records are returned", but
now that I think about it, NXDOMAIN rather is a "processing error". So
this would also be consistent with my view that SPF(non-existent-domain)
should be handled as a processing error, i.e. PermError. Thanks for
pointing it out.
Also, I suggested renaming "prefix" to "sign" in the grammar:
[...]
In any case, "prefix" is not very descriptive. It describes the
"prefix"'s syntactical function but not its semantical one. This is
bad style in a formal grammar.
I disagree. Feel free to bring this up for a council vote. I'm
interested in hearing other people's opinions on this though.
You disagree that in a formal grammar, elements should be named after their
semantical function instead of their syntactical one?
Or you disagree that "sign" is a good substitute name? If so, feel free to
suggest any other name you want for the thing. Perhaps "mode"?
[...] But this does not point out the implications for trying to use
SRS (i.e. potentially >=64 chars) localparts in "exists" mechanisms.
With the 63 character limit, the according option 1.ii suggested in
section 9.3 is of questionable use for deployment purposes. I think
a warning statement should be included there. Perhaps:
----------------------------------------------------------------------
--- draft-schlitt-spf-classic-01pre2.xml
+++ draft-schlitt-spf-classic-01pre2+mehnle.xml
@@ -1872,4 +1872,9 @@
While this requires an extra DNS lookup, this only
happens when the e-mail would otherwise be rejected.
+ Note that due to the 63 character limit for domain
+ labels, this approach only works reliably if the
+ localpart signature scheme is guaranteed either to
+ only produce localparts with a maximum of 63
+ characters or to gracefully handle truncated
+ localparts.
</t>
<t>
----------------------------------------------------------------------
Like MarkL, I don't think the RFC should be a "How-To guide". The
stuff in section 9 is non-normative and is intended to give very brief
suggestions about how to solve certain problems that SPF adoption will
cause.
So, what is section 9 about? Not giving "How-To" guidelines, but giving
"very brief suggestions about how to solve certain problems [...]"? If
item 1.ii in section 9.3 is supposed to be of any value whatsoever, its
only valid interpretation can be a hint to cryptographic sender signing
schemes such as SES or SRS. If that is what 1.ii is about, it _should_
warn that the 63 character limit for domain labels limits this solution.
If you want the warning to be shorter, it might even read: "Note that a
domain label, and as such, subject data for the localpart signature
scheme, is limited to 63 characters."
I'm not convinced that this information is useful enough to justify
being in the spec. Feel free to bring it up for a vote on the
council.
I will, if you insist on rejecting it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCfBFDwL7PKlBZWjsRAkwqAJ0ZJtyK3TMT7fwdohAJCHIjOtgctgCggnzD
24DPwTvRuM2Ofm9Q7Jibb0Y=
=+YU6
-----END PGP SIGNATURE-----