In <200609191405.35624.julian@mehnle.net> Julian Mehnle <julian@mehnle.net> writes:
>
> So, I think we should set up an issue tracker for the specification ASAP so
> we don't make the same problems in 4408bis or SPFv3. Comments?
Yes, creating a list of known issues with SPFv1 that we would like to
see fixed in SPFng would be a good idea.
Along with this issue, I can think of a few more that I really would
like to see changed:
* macro expansions that create DNS labels that are longer than 63
characters should be truncated to 63 characters. Right now, they
trigger DNS errors and result in a TempError. An error that
actually isn't temporary. The spammer controls the localpart of an
email address and put stuff into it that they know will generate
this error. While generating a TempError isn't really a
security problem, it does prevent a domain owner from having their
SPF record completely evaluated.
* Similarly, creating empty lables due to marco expansion, especially
with the split char stuff, should remove the empty labels.
* I would be very tempted to get rid of the split characters entirely
and replace them with a default set. I seem to recall from my SPF
record surveys that they are almost never used, with the exception
of pobox.com and a few others. Unlike unknown mechanisms, I could
find a few cases of legitimate use, so I couldn't argue for
eliminating them from RFC4408.
* Get rid of the distinctionn between ip4: ip6: and a:. This is a
common source of errors when people construct SPF records and they
can all be unambigous distinguished. This is one case were
Caller-ID got it right, Microsoft used one XML tag for both A and
IP4. Strangly, MS used a seperate tag when a CIDR notation was
needed, which SPF got right.
* rename include: to something like if-pass. It is *really* badly
named right now and causes a lot of confusion.
Stuff I feel less certain about:
* redirect= used to be a mechanism, and was changed to a modifier. I
think it might be best to converted it back to being a mechanism.
Then, no modifiers would ever change the SPF result. In libspf2, I
accepted both redirect: and redirect=. If redirect: had a prefix
(+, -, ?), it would be used as the default result if the target
didn't exist. I could also see the prefix being ignored or having a
special case of redirect: being one mechanism that doesn't have a
prefix.
* maybe create a call: mechanism that works like you would expect
include: to work: It would return the SPF result of whatever the
other record was, and only not match if there wasn't a -all or
something on the end. The prefix to the call: mechanism would have
to be made consistent with whatever we decide for redirect.
* There should be ways of specifing older versions or other scopes. I
think these can both be handled unambigiously by putting /<version>
or /<scope> tags on the end of the include:, redirect= and, if we
add it, call:.
E.g. "v=spf7 a:bonzo.org redirect=%{d}/spf1" would create an SPFv7
policy that would be the same as the SPFv1 policy, with the
exception of an additional check for bonzo.org. Similarly, you
could have "v=spf7/mfrom a:bonzo.org redirect=%{d}/helo" and the
SPFv7 mfrom policy would be almost the same as the SPFv7 HELO
policy.
Ok, that said, I really don't think we should do anything serious with
SPFng until the IETF allows us to create a WG that can put SPFng on
the standard track. That is, about 1.5 years from now. Collecting
ideas is a good idea though.
-wayne
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
>
> So, I think we should set up an issue tracker for the specification ASAP so
> we don't make the same problems in 4408bis or SPFv3. Comments?
Yes, creating a list of known issues with SPFv1 that we would like to
see fixed in SPFng would be a good idea.
Along with this issue, I can think of a few more that I really would
like to see changed:
* macro expansions that create DNS labels that are longer than 63
characters should be truncated to 63 characters. Right now, they
trigger DNS errors and result in a TempError. An error that
actually isn't temporary. The spammer controls the localpart of an
email address and put stuff into it that they know will generate
this error. While generating a TempError isn't really a
security problem, it does prevent a domain owner from having their
SPF record completely evaluated.
* Similarly, creating empty lables due to marco expansion, especially
with the split char stuff, should remove the empty labels.
* I would be very tempted to get rid of the split characters entirely
and replace them with a default set. I seem to recall from my SPF
record surveys that they are almost never used, with the exception
of pobox.com and a few others. Unlike unknown mechanisms, I could
find a few cases of legitimate use, so I couldn't argue for
eliminating them from RFC4408.
* Get rid of the distinctionn between ip4: ip6: and a:. This is a
common source of errors when people construct SPF records and they
can all be unambigous distinguished. This is one case were
Caller-ID got it right, Microsoft used one XML tag for both A and
IP4. Strangly, MS used a seperate tag when a CIDR notation was
needed, which SPF got right.
* rename include: to something like if-pass. It is *really* badly
named right now and causes a lot of confusion.
Stuff I feel less certain about:
* redirect= used to be a mechanism, and was changed to a modifier. I
think it might be best to converted it back to being a mechanism.
Then, no modifiers would ever change the SPF result. In libspf2, I
accepted both redirect: and redirect=. If redirect: had a prefix
(+, -, ?), it would be used as the default result if the target
didn't exist. I could also see the prefix being ignored or having a
special case of redirect: being one mechanism that doesn't have a
prefix.
* maybe create a call: mechanism that works like you would expect
include: to work: It would return the SPF result of whatever the
other record was, and only not match if there wasn't a -all or
something on the end. The prefix to the call: mechanism would have
to be made consistent with whatever we decide for redirect.
* There should be ways of specifing older versions or other scopes. I
think these can both be handled unambigiously by putting /<version>
or /<scope> tags on the end of the include:, redirect= and, if we
add it, call:.
E.g. "v=spf7 a:bonzo.org redirect=%{d}/spf1" would create an SPFv7
policy that would be the same as the SPFv1 policy, with the
exception of an additional check for bonzo.org. Similarly, you
could have "v=spf7/mfrom a:bonzo.org redirect=%{d}/helo" and the
SPFv7 mfrom policy would be almost the same as the SPFv7 HELO
policy.
Ok, that said, I really don't think we should do anything serious with
SPFng until the IETF allows us to create a WG that can put SPFng on
the standard track. That is, about 1.5 years from now. Collecting
ideas is a good idea though.
-wayne
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
