-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Stephen Farrell
Sent: Tuesday, July 08, 2008 6:52 AM
To: DKIM
Subject: Re: [ietf-dkim] Issue 1576: Revise wildcard discussion
So, trying to get to closure on this, rather than go
'round and 'round. There seem to be 3 things being
discussed here, as listed below.
Even if you disagree and think there's a 4th thing - please
hold your fire until we bottom out on these three.
We'd like to close out on these things by Friday (11th) so
if you do care, you need to suggest text asap. If some
suggested text seems to be getting a bunch of +1's then we
won't be v. strict about that deadline, but if nothing is
getting support then I think we'll declare victory on this
one then.
Thing 1:
Charles Lindsey (and others) wrote (things like):
Having all genuine ADSP records
start with some string such as "dkim=" will make such checks easier
(though not foolproof because even a randomly created TXT record could
start with "dkim-", though with low probability :-) ).
I think the counter John is making is that parsing the entire
ADSP record is equally easy, so his argument as I read it is that
the above is an optimization that isn't worthwhile.
Is it really significantly better/easier to check starts-with("dkim=")
rather than matches(the-ABNF-from-4.2.1")? The ABNF from 4.2.1. is:
adsp-dkim-tag = %x64.6b.69.6d *FWS "=" *FWS
("unknown" / "all" / "discardable")
(If responding, please ignore the [FWS] vs. *FWS issue.)
If you think the optimization is worthwhile, please post
text (and not discussion) and we'll see if that gets +1's
or -1's or gets ignored (at this stage I think the latter
two are the same). If you do post text for that please put
"dkim=" in the subject as well as 1576.
Thing 2:
Currently ssp-04 says that "ADSP records use the "tag=value"
syntax..." and also says that only one ADSP record is to be
published.
So if that means that records returned because of wildcards that
don't match eactly one instance of the ABNF are ignored then we seem
to be ok. If however, the current text isn't explicit enough about
how to handle records that don't parse correctly, or multiple records
then maybe there's more to say.
If you think there is, then please post text (and not discussion)
and we'll see if that gets +1's or -1's or gets ignored (at this
stage I think the latter two are the same). If you do post text
for that please put "handling" in the subject as well as 1576.
Thing 3:
The last thing that seems to be involved in this thread is a
concern that the current description of the dangers of wildcards
is not sufficiently well explained. If you think that that is
the case then please post text (and not discussion)
and we'll see if that gets +1's or -1's or gets ignored (at this
stage I think the latter two are the same). If you do post text
for that please put "caveats" in the subject as well as 1576.
Thanks,
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html