organization's attempt to tell another what it
should do with mail that is from a third organization that
claims to be from the first organization.
Of course, SSP also includes guidance on unsigned messages.
eric
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
, 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
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 InternetWorking
, 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
.
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/
--
Dave Crocker
Brandenburg InternetWorking
.
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
Brandenburg InternetWorking
bbiw.net
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 operates
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
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
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
.
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://mipassoc.org/dkim/ietf-list-rules.html
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 InternetWorking
bbiw.net
. 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
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
-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
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 InternetWorking
bbiw.net
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 RSET - meaning
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
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
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
Brandenburg InternetWorking
bbiw.net
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, what
) 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?
Thanks.
d/
--
Dave Crocker
Brandenburg
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 what I
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 InternetWorking
bbiw.net
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
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
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
Commission anti-spam workshop where we
heard a senior FTC staffer state that the only way he could familiarize
himself with DKIM was to read -base. This is such an unreasonable demand to
place on him that it's not his fault that he viewed DKIM as too complicated
and risky...
d/
--
Dave Crocker
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 according to
http://mipassoc.org/dkim/ietf-list
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/
--
Dave
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
http://mipassoc.org/dkim/ietf
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.
Thoughts?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
.
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": Un
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, then yes, it'd
bounces?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
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/
--
Dave Crocker
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
___
NOTE WELL
. 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
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 Crocker
Brandenburg
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
___
NOTE WELL: This list
, 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 InternetWorking
bbiw.net
--
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/dkim/ietf
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 InternetWorking
bbiw.net
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
that 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,
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
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
http://mipassoc.org/dkim
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
Brandenburg
be deprecated...
d/
--
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 LWSP-related
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 particular
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
bbiw.net
.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
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 Crocker
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/ietf-list
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 according
.
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 WELL: This list operates
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 operates according to
http
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
Brandenburg InternetWorking
bbiw.net
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 InternetWorking
bbiw.net
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 InternetWorking
bbiw.net
) character. Implementors and administrators are
cautioned to be careful to ensure that the TXT records produced conform to the
specification.
Yes, we might later choose to enhance the specification, to allow the case
that has appeared in the field, but then, we might not.
d/
--
Dave
Tony Hansen wrote:
The version coming out in the internet-drafts repository will say -04
instead of -03. Dave will update the copy on dkim.org at some point.
done.
http://dkim.org/specs/draft-ietf-dkim-overview-04.html now contains the
corrected version of the draft.
d/
--
Dave
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
://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
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
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
___
NOTE
of other.
Wietse
___
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
|
. | |
+-+--+ +-+
||
| Reputation |
||
++
5. Is the query made for:
a) All signed messages
b) All unsigned messages
c) Other (please describe the conditions)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
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 list
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
___
NOTE WELL: This list operates
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
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 InternetWorking
bbiw.net
, not the recipient's.
Hence, SSP should be used for receipt of unsigned messages. Statements
like I sign everything and I send no mail are examples.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according
for the North American mainland, right?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
will provide ad-hoc mechanisms if we fail to provide an official one.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
the previous, stable draft s
are upward compatible.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
is intended to be purely mechanism.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
and you lose the real stricture that
was the entire intent we chose.
Turn the MUST to a MAY has you reverse the agreement that was developed about
that concern.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list
that the working group politely decline to pursue this
scenario.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
changed since she
posted the existing comments, what with all of the conversations folks have been
having with her.
Guessing the current details might be fun, but there is no reason to believe it
would be productive...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
.
Working group specs are subject to semantic change up to the point of IESG
approval. Anyone deploying code based on a spec prior to that moment is taking a
well-advertised risk.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE
it is the best solution to the problem.
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:
Two lines of argument. You were invoking the 'installed base'
argument and I was noting that it is not valid to use that, at this
stage, for this type of issue.
No I was not.
ok. sorry I misread it to mean that.
d/
--
Dave Crocker
Brandenburg
A number of changes to http://dkim.org worth a quick review.
Please send comments, additions and corrections to me privately.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http
-- and we all ought to be particularly cautious
about expecting a focus on .sender as being import to the human side of phishing
or other abuse issues.
(Importance for automated filtering and other assessment software is an entirely
different matter.)
d/
--
Dave Crocker
Brandenburg
a failure as being equivalent to no signature,
that leaves a total of 2 states:
1. GoodSig
2. NoSig
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
challenges.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
exceptionally difficult and the sort of thing you
are attempting to pursue *should* be of benefit -- and therefore interest -- to
the larger email text-handling community.
That said, I'm not sure what venue to suggest, and I don't want to guess, lest
it confuse things further.
d/
--
Dave Crocker
this scenario mandatory, however.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
schemes.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
recipient operators will find them useful, we are chasing
our collective tail.
I suggest that discussion about technology -- that is, mechanisms -- should be
deferred until the receive-side benefits (and, for that matter, the receive-side
consuming component) are established.
d/
--
Dave
of the
delivering ADMD and not of the message as it is received from the open Internet.
In that context, how does your described threat survive?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according
effort than useful, I have switched
that mailing list field back to mipassoc.org.
So, dkim.org is what to use for the web page.
mipassoc.org is what to use for the mailing list.
Sorry for the (my) confusion.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
The IETF working group page, under dkim.org, has been updated with materials for
the latest working group meeting, including the 4 SSP proposals.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates
.
Maybe it will reach a critical mass of deployment. That would be excellent, of
course.
But there is no guarantee that it will happen.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
NOTE WELL: This list operates according to
http
to be.
On the other hand, explaining what types of extensions the existing system has
provided for (e.g., multiple query services) can be help readers understand the
design better. So my own preference is to have that section discuss something
like Extensibility.
d/
--
Dave Crocker
Brandenburg
801 - 900 of 1246 matches
Mail list logo
