-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Jim Fenton
Sent: Tuesday, October 12, 2010 9:53 PM
To: IETF DKIM WG
Subject: [ietf-dkim] Last call comment: Changing the g= definition
Between June 1 and September 1,
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Murray S. Kucherawy
Sent: Tuesday, October 12, 2010 11:30 PM
To: IETF DKIM WG
Subject: [ietf-dkim] Collected data (oops)
Oops, sorry for the bogus Subject: change. Feel
--On 12 October 2010 13:02:41 -0400 Hector Santos hsan...@isdg.net wrote:
Your mail to 'ietf-dkim' with the subject
(no subject)
Is being held until the list moderator can review it for approval.
The reason it is being held:
Message has implicit destination
Either the
On Wed, Oct 13, 2010 at 12:50 AM, Jim Fenton fen...@cisco.com wrote:
6.3 paragraph 5 has changed signing identity to SDID. The signing
identity really corresponds to the AUID. As currently worded, the mail
system is advised to take pains to ensure that the SDID is displayed for
a message
- In order to make use of ADSP, Y needs to change which MTA it's
using. This is almost certainly an expensive effort.
- Y simply can't use ADSP.
- The DKIM reporting extensions should have a flag that says DSNs
should not cause generation of fraud reports.
I'll take
Subject: Buy fake watches at fakewatch.example.com!
Will some clients display the second subject line? I suspect some
will. Do we need to recommend that signers also add a protective second
subject: to their h= value? Or do we need to require that verifiers
make sure that any header fields
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of John Levine
Sent: Wednesday, October 13, 2010 9:29 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] FW: An issue with DKIM reporting extensions
- In order
On 10/13/10 3:29 PM, John Levine wrote:
- In order to make use of ADSP, Y needs to change which MTA it's
using. This is almost certainly an expensive effort.
- Y simply can't use ADSP.
- The DKIM reporting extensions should have a flag that says DSNs
should not
On Tue, 12 Oct 2010 14:36:42 +0100, Hector Santos hsan...@isdg.net wrote:
What it means for most systems that they need to change a model based
on this:
CHECK DKIM PASS -- ACCEPT
CHECK RFC5322 BAD -- REJECT
BREAK
RESIGN
DISTRIBUTE
To this:
On Oct 13, 2010, at 8:07 AM, Rolf E. Sonneveld wrote:
or
a special selector (e.g. s=notifications), to identify the different
nature of this mail stream?
No. Never do this.
Selectors are an operational convenience for key rotation and
ease of domain delegation. They have no semantics
If a v= value is not found at the beginning of the DKIM key record,
the key record MAY be interpreted as for DomainKeys [RFC4870]. The
definition given here is upwardly compatible with what is used for
DomainKeys, with the exception of the g= value. In a DomainKeys
key
On Mon, 11 Oct 2010 23:05:13 +0100, Wietse Venema wie...@porcupine.org
wrote:
Charles Lindsey:
When the bad guy sends mail with (multiple) forged headers, the
best they can get is that naive mail programs render their forged
header with an indication that THE BAD GUY'S DKIM SIGNATURE
What happens if you do the same thing, but put the To: header above the
From: headers? What about when it's between the two From: headers?
Actually, the chairs would rather take this off the DKIM mailing list,
as out of the group's scope. If some folks want to go do some testing
about what
On 10/13/10 8:04 AM, John Levine wrote:
Subject: Buy fake watches at fakewatch.example.com!
Will some clients display the second subject line? I suspect some
will. Do we need to recommend that signers also add a protective second
subject: to their h= value? Or do we need to require that
On Tue, 12 Oct 2010 07:46:42 +0100, Barry Leiba barryle...@computer.org
wrote:
There are only two significant changes between -01 and -02 ... most of
the changes are just updating the references. The substantive changes
are:
1. The addition of the paragraph that begins Similarly, a message
On Tue, 12 Oct 2010 14:00:19 +0100, Dave CROCKER d...@dcrocker.net wrote:
Oh boy. Very sorry folks.
The full text reads:
tSimilarly, a message not compliant with RFC5322, RFC2045
and
RFC2047, can be subject to attempts by intermediaries to
correct
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Jim Fenton
Sent: Wednesday, October 13, 2010 10:42 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Collected data
[sticking with Murray's subject line so as not to
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Jeff Macdonald
Sent: Wednesday, October 13, 2010 11:27 AM
To: DKIM
Subject: Re: [ietf-dkim] detecting header mutations after signing
rant
Count me as one of those who was
On 10/13/2010 2:27 PM, Jeff Macdonald wrote:
DKIM seems to make assurances to message integrity. But it
doesn't. I think the reason why many think it does is because of the
body hash. It is trying to do to much. It should just provide an
identifier that can be verified. Instead of using the
On 10/13/10 10:53 AM, Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Jim Fenton
Sent: Wednesday, October 13, 2010 10:42 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Collected data
On Wed, Oct 13, 2010 at 2:40 PM, Dave CROCKER d...@dcrocker.net wrote:
On 10/13/2010 2:27 PM, Jeff Macdonald wrote:
DKIM seems to make assurances to message integrity. But it
doesn't. I think the reason why many think it does is because of the
body hash. It is trying to do to much. It
On 10/13/2010 11:25 AM, Scott Kitterman wrote:
On Wednesday, October 13, 2010 11:55:25 am Steve Atkins wrote:
On Oct 13, 2010, at 8:07 AM, Rolf E. Sonneveld wrote:
or
a special selector (e.g. s=notifications), to identify the different
nature of this mail stream?
No. Never do this.
On Wed, Oct 13, 2010 at 2:47 PM, Scott Kitterman
ietf-d...@kitterman.com wrote:
On Wednesday, October 13, 2010 02:27:29 pm Jeff Macdonald wrote:
And even if there was a DKIM signature, it is the BAD GUY'S signature,
which should cause it to go into the SPAM folder, with a large
phishing
On 10/13/2010 12:47 PM, Jeff Macdonald wrote:
Then you send me a piece of signed mail, I change everything except the
Message-ID and Date, and send it to someone else. And the verifier will
green-light it, meaning you've taken responsibility for it. Are you OK with
that?
My way of
If a v= value is not found at the beginning of the DKIM key record,
the key record MAY be interpreted as for DomainKeys [RFC4870]. The
definition given here is upwardly compatible with what is used for
DomainKeys, with the exception of the g= value. In a DomainKeys
key
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Jeff Macdonald
Sent: Wednesday, October 13, 2010 3:59 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
On Wed, Oct 13,
On Wed, Oct 13, 2010 at 4:01 PM, Michael Thomas m...@mtcc.com wrote:
But like I said, I was ranting.
Jeff, an identifier that's not bound to something is useless. It's
like Mike just bouncing around the aether. Until it binds to
something, it's not providing anything useful and certainly not
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Jeff Macdonald
Sent: Wednesday, October 13, 2010 1:15 PM
To: DKIM WG
Subject: Re: [ietf-dkim] What DKIM provides, again
On Wed, Oct 13, 2010 at 4:01 PM, Michael Thomas
-Original Message-
From: John Levine [mailto:jo...@iecc.com]
Sent: Wednesday, October 13, 2010 2:47 PM
To: ietf-dkim@mipassoc.org
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] detecting header mutations after signing
DKIM simply highlights an issue that's been there for a very
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Mark Delany
Sent: Wednesday, October 13, 2010 1:59 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] detecting header mutations after signing
I understand the issues
On Oct 13, 2010, at 1:59 PM, Mark Delany wrote:
It strikes me that a DKIM verifier is already well into the business
of 2822 semantics as it knows about headers, header labels,
continuation syntax, header/body boundaries and so on.
In that light, taking an additional step wrt duplicate
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Barry Leiba
Sent: Wednesday, October 13, 2010 3:46 PM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] Last call comment: Changing the g= definition
Everyone, please weigh in on
+1.
Barry, as the original issue submitter and I only provided suggested
text to jump start WG input with better text, I am very happy with Jim
Fenton's text. It doesn't lay blame and straight to the key points.
Folks, this is really a simple solution and in my opinion, DKIM can
gain from
At 13:03 13-10-10, Barry Leiba wrote:
To avoid second-guessing in a security context, and because
DomainKeys is an obsolete protocol, DKIM verifiers MUST
interpret this situation in DKIM terms, matching only
empty i= values.
Changing the g= definition takes advancement
-Original Message-
From: Jim Fenton [mailto:fen...@cisco.com]
Sent: Wednesday, October 13, 2010 3:22 PM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] ISSUE: 4871bis-02 - Section 8.14 comments
Here's some text I propose for section 8.14, in place of
Jim Fenton wrote:
It also adds more complexity to the specification and to
implementations. Besides, DK compatibility should become less of an
issue with time since it is a legacy protocol.
+1
IMO, DKIM is already a complex technology to properly implement and
integrate into a system,
Folks,
I know section 3.6.2.1 has this informative note:
INFORMATIVE OPERATIONAL NOTE: Wildcard DNS records (e.g.,
*.bar._domainkey.example.com) do not make sense in this context
and should not be used. Note also that wildcards within domains
(e.g.,
In that light, taking an additional step wrt duplicate headers (or
malformed 2822 in general) is still in the same layer as the verifier.
My objection isn't so much layering within the software, because I know that
gets mushy real quick, but layering among the protocol specifications.
+1, well said Mark.
Its a real potential situation that is on par, IMTO, with what the
DKIM technology was suppose to help with. It was unfortunate it fell
through the cracks during the Threats Analysis RFC 5016 production. If
it was realized back then, I don't think anyone would be debating
Anyone recognize 550 5.7.0 bad DKIM signature data?
A couple of folks just got bounced off a mailing list due to their MTAs doing
that in response to some mail I sent, so I'm interested in what software might
do that.
Cheers,
Steve
___
NOTE WELL:
On Wednesday, October 13, 2010 03:59:27 pm Jeff Macdonald wrote:
On Wed, Oct 13, 2010 at 2:47 PM, Scott Kitterman
ietf-d...@kitterman.com wrote:
On Wednesday, October 13, 2010 02:27:29 pm Jeff Macdonald wrote:
And even if there was a DKIM signature, it is the BAD GUY'S signature,
which
On 10/13/2010 3:17 PM, John R. Levine wrote:
We put a bunch of stuff in DKIM to allow benign modifications of messages,
notably relaxed canoncalization. (We can argue about whether l= is
useful, but it's easy enough to ignore if one thinks it isn't.) I think
it's also reasonable to put
On 10/13/2010 4:59 PM, Mark Delany wrote:
I know we're not in the MUA business, but if DKIM makes no difference
to what an end-user finally sees, then it serves a very limited
purpose indeed.
Well, yes. But that's a /good/ thing, as a core capability.
More importantly, we are not in the
On 10/13/2010 8:56 PM, Mark Delany wrote:
If DKIM has any value it's that it ultimately affects the user mail
experience for the better. Consequently, to remain silent on matters
that we know will adversely affect that experience seems
contradictory. Similarly to not offer guidance to
On 10/13/10 4:32 PM, Murray S. Kucherawy wrote:
It seems to me you're saying the same thing bis-02 is saying, but with
perhaps less terse language. In particular, bis-02 says SHOULD NOT
validate something that's malformed, while you're saying SHOULD validate
format before processing.
Hi Steve,
At 18:56 13-10-10, Steve Atkins wrote:
Anyone recognize 550 5.7.0 bad DKIM signature data?
dkim-filter and OpenDKIM can send such a response.
A couple of folks just got bounced off a mailing list due to their
MTAs doing that in response to some mail I sent, so I'm interested
in what
At 17:31 13-10-10, Hector Santos wrote:
I know section 3.6.2.1 has this informative note:
[snip]
This is just to jump start suggested text. Others can add/change
whether they think helps:
The DKIM public key TXT record MUST not be mixed or merged
with other TXT records, i.e. SPF.
On 10/13/2010 6:36 PM, SM wrote:
At 13:03 13-10-10, Barry Leiba wrote:
To avoid second-guessing in a security context, and because
DomainKeys is an obsolete protocol, DKIM verifiers MUST
interpret this situation in DKIM terms, matching only
empty i= values.
What you are calling for would be good to have. It should be done.
Just not in the signing spec.
Correct me if I'm wrong, but I hear you saying that if one creates or
verifies the DKIM signature on a message, one should also do the double
header check somewhere in the mail processing path,
49 matches
Mail list logo
