-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wayne Schlitt wrote:
[Julian wanted] to vote on:
[...]
* the "section 9.3.1.2 does not warn about the 63 character limit"
issue.
The last item was not discuss or voted on because it is a complicated
issue, we had already been in the meeting for 3 hours, and it was
getting very late in Europe.
This is what it is about:
Section 9.3.1.2 of the spec reads:
| 9.3. Forwarding Services and Aliases
|
| [Description of SPF's "forwarding" problem]
|
| There are three places that techniques can be used to ameliorate this
| problem.
|
| 1. The beginning, when e-mail is first sent.
|
| 1. [...]
|
| 2. The "MAIL FROM" identity could have additional information in
| the localpart that cryptographically identifies the mail as
| coming from an authorized source. In this case, such an SPF
| record could be used:
|
| "v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
|
| Then, a specialized DNS server can be set up to serve the
| _spf_verify subdomain which validates the localpart. While
| this requires an extra DNS lookup, this only happens when the
| e-mail would otherwise be rejected as not coming from a known
| good source.
The problem with this is that it suggests the use of localpart crypto
schemes (like SRS and SES), but many of these schemes will not honor the
63 characters limit for domain labels imposed by performing a DNS lookup
using the %{l} (localpart) macro.
In -01pre2, Wayne added to section 8.1, "Macro definitions", the following:
| Note: Care must be taken so that macro expansion for legitimate
| e-mail does not exceed the 63 character limit on DNS labels. The
| localpart of e-mail addresses, in particular, can have more than 63
| characters between dots.
So far, so good. But this does not really help much for pointing out the
implications for trying to use, for instance, SRS (i.e. potentially >=64
chars) localparts in "exists" mechanisms. With the 63 character limit,
the option suggested in section 9.3.1.2 is of questionable use for
deployment purposes. I think a warning statement should be added there.
Perhaps:
- --- draft-schlitt-spf-classic-01.xml
+++ draft-schlitt-spf-classic-01+mehnle_localpart_crypto_63chars_limit.xml
@@ -1940,4 +1940,9 @@
happens when the e-mail would otherwise be rejected
as not coming from a known good source.
+ 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>
I had suggested this change before (as a patch to -01pre1), but this is
what Wayne replied on spf-discuss:
Wayne Schlitt wrote:
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.
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 hereby request that the council decide on this issue.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFClLw5wL7PKlBZWjsRAnfUAJ4rhD3PShU+nkRFyZ7KuO1KgaYp7ACdFzpr
oKqe8luJdufFL2hwH4FnKzc=
=dmD3
-----END PGP SIGNATURE-----