,
for email or, I believe, any other Internet protocol. This means that we need
to be extremely clear about the reason that any such a record is absolutely
essential.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: Thi
So is this still a real problem for DKIM?
Yes, it still is, because we didn't say (and should not have said) "MUST
NOT implement any other signature algorithm".
How is that a problem?
d/
--
Dave Crocker
Brandenburg InternetWor
ism that is designed to cover an event that has no
precedent in 35 years of Internet history, and to embed it in a system that is
explicitly intended to provide security features that are limited in time and
scope.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
__
Paul Hoffman wrote:
At 8:48 AM -0800 2/26/07, Dave Crocker wrote:
The proposed mechanism incurs an additional lookup for every signed
message.
You keep saying this without justifying it. Others have shown it to be
wrong. Please stop repeating it or support your statement.
Actually, they
Paul Hoffman wrote:
At 10:10 AM -0800 2/26/07, Dave Crocker wrote:
Paul Hoffman wrote:
At 8:48 AM -0800 2/26/07, Dave Crocker wrote:
The proposed mechanism incurs an additional lookup for every signed
message.
You keep saying this without justifying it. Others have shown it to
be wrong
.>| REPUTATION|
. | |
+-+--+ +-+
||
| Reputation |
||
++
5. Is the query made for:
a) All signed messages
b) All unsigned messages
c) Other (please describe the conditions)
d/
--
Dave Crocke
rithm transitions are acceptable and
can be handled in the same way as we handle other transitions on the Internet.
None of them include a publication mechanism.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This
atments to different
types of "other".
Wietse
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
igning
Service Overview
Author(s) : T. Hansen, D. Crocker, P. Hallam-Baker
Filename : draft-ietf-dkim-overview-04.txt
Pages : 35
Date : March 4, 2007
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
__
fication, to allow the case
that has appeared in the field, but then, we might not.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
version of the draft.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
s are cautioned
to ensure that selector TXT records conform to this specification.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
dkim-ops <http://mipassoc.org/mailman/listinfo/dkim-ops>.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
to conform to it. I'd suggest deleting
the last sentence.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
understand the idea of delaying something that can be
of significant use for early-stage -base adoption, and waiting for some
unknown moment in the problematic future, when SSP might eventually converge
and get approved.
d/
--
Dave Crocker
Brandenburg InternetWor
Jeff Macdonald wrote:
I don't think the 'world' understands that DKIM is just a building
block.
That is one of the reasons for wanting to get the Overview document out
sooner, rather than later.
d/
--
Dave Crocker
Brandenburg InternetWor
, or an
overview section in the SSP specification itself is added strikes me as a
decision to make at the time we need the additional writing.
I'm certainly happy to commit to putting in the effort to make sure there is
text of an overview style for SSP.
d/
--
Dave Crocker
Brand
are I note that even within the working group, there
is often disparity on basic point about DKIM, which -overview ought to be
useful in settling?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operate
;.
And, of course, additions and corrections are eagerly sought.
Thanks.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Dave Crocker wrote:
> Take a look at <http://dkim.org/deploy/index.html#production>.
Sorry.
That should have been <http://dkim.org/index.html#production>.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE
Stephen Farrell wrote:
This is also Issue #1386 in the tracker [2].
Your choices:-
1) Exclude this requirement (don't mention it)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates accordi
gs change considerable if a new RR is used, since regular DNS
wildcards come back into consideration.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
which
themselves are a pain.
Given that zones are administrative constructs for use by operators, and
are not intended to be visible to client DNS activities -- and well
might not be visible, no matter the intent -- then how does the upward
tree-walk know when to stop?
d/
--
Dave Cr
it's possible that in some
cases where the stars align
Horoscopic Internet standards effort? Horror scope-ic...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim
e DNS.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Michael Thomas wrote:
Dave Crocker wrote:
2) if you don't get a ssp rr, check to see if it gave
you a NS or SOA authority records.
Michael: Zones are not part of the user-visible DNS semantics. They
are strictly an administrative construct. Using anything that relies
on parti
rs.
What I am trying to make clear is that the fact that some packages might
give access to this information, it is nonetheless inappropriate for a
user-visible function to be based on access to zone boundary information.
d/
--
Dave Crocker
Brandenburg InternetWorking
much of our
technology would be deprecated...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
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
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Tony Finch wrote:
On Tue, 15 May 2007, Dave Crocker wrote:
So that is a total of at most 2 documented cases in 10-30 years.
And keep in mind that the issue is not that the rule "does not work" but that
it is very rarely mis-used.
Did you miss my post linking to a description of LW
Eric Allman wrote:
2. How about the differences between DK and DKIM?
I've got that on my to-do list, but I'm not going to be able to get to
it before next week.
The FAQ includes this as an explicit entry. If it needs changing, let me know.
--
Dave Crocker
B
pamops>. (The IETF announcement
will follow.)
Comments and discussion of this document should be addressed to the
[EMAIL PROTECTED] mailing list.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
Folks,
pdf and html versions of RFC 4871 are available via: <http://dkim.org#sign>
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
a new record just isn't that hard to get out there.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Folks,
Pretty versions of the latest dkim-overview draft are at:
<http://dkim.org/ietf-dkim.htm#overview>
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dki
wow. problem with the pdf version.
i'll let you know when it's fixed.
d/
Dave Crocker wrote:
Folks,
Pretty versions of the latest dkim-overview draft are at:
<http://dkim.org/ietf-dkim.htm#overview>
d/
--
Dave Crocker
Brandenburg InternetWo
Well, that was fun.
The xml2rfc processor for pdf has a problem with hanging indent spacing.
I fixed the problems that were breaking the page, but some of the spacing is
still a bit extreme.
Both pdf and html versiona are now usable.
d/
Dave Crocker wrote:
wow. problem with the pdf
-06-18
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
e mailed to try get it fixed, dunno where that's at.
S.
[1] http://tools.ietf.org/wg/dkim/
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Dave Crocker
Brandenburg
ate a bounce message to that address.
By 'safe' I mean that one can be confident that the mail will not go to an
unwitting victim of a spoofed address.
Am I missing something?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
. granularity of control within a domain. not automatic. grrr.
so, perhaps, an SSP record by the signing domain that says MailFrom is valid?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
How can a potential bounce generator know whether this particular message has
a validated return address? Note that the mere presence of a DKIM signature
does not guarantee this particular validation issue.
That's why the SSP-type record might be necessary.
d/
--
Dave Crocke
" SSP record, I'll generate it since the
return address domain has said it's valid.
John Levine wrote:
> Personally, I'd rather use BATV.
That filters at the destination, not the source.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
his extra mechanism
to prevent generation of specious bounces?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ts on rfc2821.From values that are being discussed.
So, yeah, if the SSP associated with the MailFrom says "rfc2821.MailFrom" must
match a DKIM signature, or somesuch, then a mailing list that inserts its own
MailFrom, without adding its own signature, could break bounces.
d/
--
on the definition of 'this flag' and what range of
assertions is permits. If it is a one-bit flag, then you are no-doubt correct.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
antics that we
have given to a DKIM signature, versus "asserting correctness" or the like.
My suggestion to deal with this is to define the basic DKIM sematnic that
all DKIM-* headers are asserted to be valid, if they are included in the
signature.
.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wallace-ta-mgmt-problem-statement-01.txt
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
<<< Message/External-body; name="draft-wallace-ta-mgmt-problem-statement-01.txt&
Stephen Farrell wrote:
> Dave Crocker wrote:
Of possible interest to the DKIM community:
To the community, quite possibly. But I don't see much
to do with the DKIM protocol, as currently spec'd. If,
however, someone started using X.509 certs, XKMS or
DNSSEC to support DKIM, t
ertion of an
underlying principle.
I think we need to look at the actual language in the document and decide what
is important for the current work.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates acc
guage and
note that much of it seems like reasonable directives to folks seeking to
integrate a DKIM service component into their email software and operations.
That might well qualify as a service specification, along the lines that the
IETF frequently publishes as standards-track.
d/
--
Michael Thomas wrote:
Dave Crocker wrote:
I think a simple and appropriate model, here, is that the
receive-side should be given information that permits it to detect
external attacks -- that is, misbehaviors by actors external to the
origin-side.
...
In which case, the bob and jane
to
place on him that it's not his fault that he viewed DKIM as too complicated
and risky...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
n with Mars probes
*Improve telephony
*Optimize video transmission
*Adjust technology to allow basic functions (like e-mail) in Africa,
South America
___
69ATTENDEES mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/69attendees
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
n with Mars probes
*Improve telephony
*Optimize video transmission
*Adjust technology to allow basic functions (like e-mail) in Africa,
South America
___
69ATTENDEES mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/69attendees
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Practices Protocol
Author(s) : M. Thomas
Filename: draft-ietf-dkim-ssp-requirements-05.txt
Pages : 24
Date: 2007-8-15
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL
is designed to permit participants from North America to be away
from home for only one night, traveling the morning of the first day and
returning the evening of the second.
Ten organizations have already indicated their intent to participate.
d/
--
Dave Crocker
Brandenburg Inter
e (standardized) semantics. Note
that DKIM -base declares that the purpose of DKIM is to "permit a signing
domain to assert responsibility for a message".
So the purpose of this survey is to ask what string you believe is intended to
represent that responsibility?
Thank
Dave Crocker wrote:
Simply put:
When you validate a DKIM signature, what information do you
(intend to) use for querying your reputation/accreditation
data bases?
Folks,
I appreciate the responses I'm getting. Unfortunately I was not clear enough
about w
Folks,
Last August, Dave Crocker wrote:
I've had a brief exchange, with a few folks recently, that suggests
quite a bit of ambiguity about the DKIM-related information to be used
for assessing reputation/accreditation.
Simply put:
When you validate a DKIM signature,
uot;correct" or
"truthful"?
I ask because I believe it does not carry any such claim and that,
rather, a DKIM signature asserts a very generic degree of signer
"responsibility" which does not extend to formal claims of correctness.
d/
--
Dave Crocker
ar view
one way or the other.
I'm not suggesting "fixing" DKIM. I'm seeking clarity among the community.
(It's a California thing.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
up and came up
with a design far spiffier than we had. Many thanks to them!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
tween participants’ products and services. Progress was tracked on a large
matrix, which recorded each successful interoperability test. By the
conclusion of the event, the matrix was nearly 100% complete!
...
Complete article:
<http://dkim.org/news/DKIM%20Interop%20Event%20PR%2011_06_07.htm>
t question might be why such a
flag is needed...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
David Mayne wrote:
Dave Crocker wrote:
Given that most protocols do not have a 'testing' flag -- and they manage
to move into production quite nicely -- a different question might be why
such a flag is needed...
Hrm, let's see - the SMTP protocol has EXPN, VRFY, and, well
John Levine wrote:
If you're going to send back reports about messages, via SSP or
otherwise,
Just realized I did not understand one tidbit in your note:
What does it mean to send back a report "via" SSP?
d/
--
Dave Crocker
Brandenburg InternetWor
loping,
or deploying DKIM.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dkim-overview-07.txt
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
nisms into SSP.
Thoughts?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ent is invalid" and "I make no assertion about the content".
Discussions about SSP seem to conflate From field domain name correlations
with "brand" representation authenticity in the message. That type of issue
is what prompted my sending my note.
d/
--
Dave Crocker
receive how
to handle a message with the potential signer's domain name in the From field
is rather directly targeting brand protection.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ps. Having this list discuss Sender-ID seems a bit odd. Worse is the idea
that Sender ID or DKIM or any adjunct protocol enhancement could be viewed as
modifying anything as basic as the content of rfc2822 Originator fields...
--
Dave Crocker
Brandenburg Intern
. What features of RFC2821 are problematic for your implementation?
5. Please add any other comments you wish to share:
Thank you!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
the original author.
That difference between actual responsibility, versus reader-perceived
responsibility, is the issue.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipasso
Address
[[Assuming 3rd party signature is based on Sender header field]] If
the Sender Signing Practices sanction third-party signing, an
attacker can create a message with a From header field of an
Michael Thomas wrote:
Dave Crocker wrote:
3. Scope and scale of query traffic
SSP originally was constrained to apply only to unsigned mail. The
current specification applies to unsigned messages *and* signed messages
where the DKIM i= domain name does not match the rfc2822.From
Michael Thomas wrote:
Dave Crocker wrote:
On reviewing the working group archive, I have not succeeded in finding
any discussion either of changing the SSP paradigm to apply to signed
message or of the problematic selection of the rfc2822.From field, rather
than rfc2822.Sender field domain
how completely the implication of this seems to
have been missed by quite a few participants.
I'l continue to repeat that I haven't found the working group discussion of
this implication.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
ely add
confusion and complexity rather than benefit.
Frankly I think it should be deprecated, because it causes so much trouble.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
ated by the recipient as suspect.
Given that adoption of a new mechanism, like DKIM's base signing, takes many
years, it should be assumed that use of SSP will almost always result in a
failed DNS query, for every message with a new (un-cached) domain name in the
From field.
d the choice of From is problematic.
Question: Is DKIM for transit validation or is it for content
authentication?
This is a false dilemma.
No it is not. In fact it is basic and salient.
Perhaps the difference between the two is not clear to you?
d/
--
Dave Crocker
Bra
Michael Thomas wrote:
Override? No. That is the receiver's decision, and SSP is silent on
that.
So, you are comfortable with the rest of the text?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list ope
needs mention of what sort of assertions
an SSP record may make, in clear english
For example:
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
h review. This means that you can point me to the archives of the
working group consideration of the issue?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
u describe what they do do?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
scale -- by which I mean broad adoption with
massive breadth of use and no prior arrangement among the users -- it is a
perfectly credible capability, albeit one that needs to be treated as a
specialized facility, rather than a general one.
d/
--
Dave Crocker
Brandenburg Intern
tory of being considered to
be important.
At base, you seem to be suggesting that statements about overhead and failures
isn't all that important. My view is that it is necessary to know such things
in order to formulate a proper opinion about the mechanism.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
mplementing. And it's clearly out of step
with where we are today.
Note that <http://www.imc.org/ietf-mailsig/mail-archive/msg02252.html> refers
to unsigned messages and not signed messages that do not match the From field.
d/
--
lert... everyone else.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
few postings on the list, can you blame them?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Michael Thomas wrote:
Dave Crocker wrote:
Do envision a reasonable scenario where a receiver has adopted SSP and
conforms to it, but does not have the stated sender enforcement ...
Yes, trivially. Look at the way Spamassassin works...
SSP_STRICT_FAIL = 4
SSP_ALL_FAIL = 2
SSP_UNKNOWN = 0
include the particular that you say
this exchange involves? Is there some reason you didn't seek to find that out?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
k
we have sufficiently demonstrated that this exchange cannot be productive.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
now available at:
<http://dkim.org/ietf-dkim.htm#documents>
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
unlikely?
This sort of heuristic approach to protocol specification and interpretation
usually has a poor outcome in Internet-scale services.
d/
ps. Another question that has solidly emerged is whether you can discuss this
topic without ad hominems.
--
Dave Crocker
Brandenburg I
Among the various discussions I've had today, one comment about SSP struck me
as worth wider consideration:
SSP is one organization's attempt to tell another
what it should do with mail that is from a third
organization.
c/
--
Dave Crocker
Brandenburg Inter
ed effect.
Equally, the references to choices made due to common user interface display
practices has not received analysis, other than the earlier discussions for
DKIM where we agreed not to factor human factors into the design, opting
instead for a focus on receive-side filter engine activi
s from some others that they want the same service -- I think we
have a solid basis for believing that there will be uptake among this market
niche.
What we also have is, at best, conflicting data about the broader market. It
makes no sense for us to decide to ignore this fact.
d/
--
Dave
d wish for someone to explain it to me.
The point of the perspective is not to disenfranchise the first organization,
but to make sure we are not blindly disenfranchising the third.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_
sibly legitimate mail senders.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
501 - 600 of 1523 matches
Mail list logo
