-Original Message-
From: McDowell, Brett [mailto:bmcdow...@paypal.com]
Sent: Tuesday, May 11, 2010 9:51 AM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Lists BCP draft available
I'm an IETF newbie, so correct me if I'm wrong. But it seems you
I've posted an individual submission draft that attempts to capture some of the
consensus and some appropriate guidance around the use of DKIM in the context
of mailing lists. I don't propose that it's final at all, but merely an anchor
point for further discussion.
for forwarding fall under the aliasing-style MLMs
as the mechanism is identical. Perhaps we could say so here.
From: Franck Martin [mailto:fra...@genius.com]
Sent: Monday, May 10, 2010 1:43 PM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Lists BCP draft available
This looks
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of J.D. Falk
Sent: Monday, May 10, 2010 2:28 PM
To: IETF-DKIM WG
Subject: Re: [ietf-dkim] Lists BCP draft available
That brings up the strange question of what supporting
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Michael Ströder
Sent: Thursday, May 06, 2010 4:51 AM
To: ietf-dkim@mipassoc.org
Subject: [ietf-dkim] Clarification needed for Computing the Message
Hashes
HI!
I
-Original Message-
From: Michael Thomas [mailto:m...@mtcc.com]
Sent: Thursday, May 06, 2010 9:48 AM
To: Murray S. Kucherawy
Cc: Michael Ströder; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Clarification needed for Computing the
Message Hashes
You're computing two hashes
I don't see how this would work with mailing lists. A domain owner
would have to know all the lists his users may want to be on. His
users would need to know to notify him when they joined a new list.
+1. Doesn't seem scalable to me.
___
NOTE WELL:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Douglas Otis
Sent: Wednesday, May 05, 2010 8:59 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] forward to friend, was besides mailing
lists...
+1. Doesn't seem
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Dave CROCKER
Sent: Monday, May 03, 2010 4:20 PM
To: Al Iverson
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] besides mailing lists...
The reply-to is a good point.
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Alessandro Vesely
Sent: Thursday, April 29, 2010 10:55 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Broken signatures, was Why mailing lists
should strip them
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Jeff Macdonald
Sent: Friday, April 30, 2010 8:32 AM
To: dcroc...@bbiw.net
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of John R. Levine
Sent: Wednesday, April 28, 2010 6:03 AM
To: Ian Eiloart
Cc: DKIM List
Subject: Re: [ietf-dkim] list vs contributor signatures, was Wrong
Discussion
Oh,
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of John Levine
Sent: Tuesday, April 27, 2010 9:24 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] mailing list doc, was Wrong Discussion - was
Why mailing lists should
-Original Message-
From: Jeff Macdonald [mailto:macfisher...@gmail.com]
Sent: Tuesday, April 27, 2010 10:05 AM
To: McDowell, Brett
Cc: Murray S. Kucherawy; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists
should strip DKIM signatures
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Douglas Otis
Sent: Tuesday, April 27, 2010 12:18 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists
should strip DKIM signatures
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of McDowell, Brett
Sent: Tuesday, April 27, 2010 12:29 PM
To: dcroc...@bbiw.net
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists
-Original Message-
From: McDowell, Brett [mailto:bmcdow...@paypal.com]
Sent: Monday, April 26, 2010 10:37 AM
To: Murray S. Kucherawy
Cc: John Levine; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Wrong Discussion - was Why mailing lists
should strip DKIM signatures
Murray
Someone on the opendkim-users list has pointed out that DKIM signatures are
being invalidated when re-mailed through one particular MLM that rewrites
Content-Type: so that its value is all lowercase. Obviously this is a problem
for DKIM since even relaxed requires nothing other than spacing
-Original Message-
From: John Levine [mailto:jo...@iecc.com]
Sent: Saturday, April 24, 2010 9:55 PM
To: ietf-dkim@mipassoc.org
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] DKIM vs. MIME
Although I see the point in this particular case, it seems to me that
it would
-Original Message-
From: Murray S. Kucherawy
Sent: Friday, April 23, 2010 12:13 PM
To: 'MH Michael Hammer (5304)'; Al Iverson; ietf-dkim@mipassoc.org
Subject: RE: [ietf-dkim] Why mailing lists should strip DKIM signatures
Even without thinking of the FBL issues, I would want
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of MH Michael Hammer (5304)
Sent: Friday, April 23, 2010 11:22 AM
To: Al Iverson; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Why mailing lists should strip DKIM signatures
-Original Message-
From: John Levine [mailto:jo...@iecc.com]
Sent: Friday, April 23, 2010 2:34 PM
To: ietf-dkim@mipassoc.org
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] Why mailing lists should strip DKIM signatures
If I'm running a mailing list and I get a piece of signed
-Original Message-
From: John R. Levine [mailto:jo...@iecc.com]
Sent: Friday, April 23, 2010 4:04 PM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: RE: [ietf-dkim] Why mailing lists should strip DKIM signatures
I am about 99% certain that the FBL reports that started
I've got as a task for the next major OpenDKIM release a reworking of our
statistics collection component. This is something that's off by default; one
must specifically enable it both at compile time and at run time.
What I'm considering is a change to the code so that it collects a larger
Maybe, or at least partly. It depends on your reputation scheme’s secret sauce.
But reputation in particular is out of scope for this working group.
From: Franck Martin [mailto:fra...@genius.com]
Sent: Thursday, March 25, 2010 3:42 PM
To: Murray S. Kucherawy
Cc: IETF-DKIM
Subject: Re: [ietf
---BeginMessage---
On Monday in the APPAREA meeting, I mentioned some upcoming work regarding the
Authentication-Results: header field. I've split the two changes I'm seeking
to make into separate drafts because one is fairly trivial and only requires an
IANA registration action to complete
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Barry Leiba
Sent: Friday, March 12, 2010 9:40 AM
To: Eliot Lear
Cc: Patrik Fältström; IETF-DKIM
Subject: Re: [ietf-dkim] Proposed new charter
So, as Eliot asks: Do we
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Michael Thomas
Sent: Wednesday, February 24, 2010 9:47 AM
To: Mark Delany
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] Broken signature analysis
But I guess this all rather
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Mark Delany
Sent: Wednesday, February 24, 2010 11:00 AM
To: Michael Thomas
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] Broken signature analysis
I wasn't thinking of wide
-Original Message-
From: Dave CROCKER [mailto:d...@dcrocker.net]
Sent: Wednesday, February 24, 2010 11:53 AM
To: Murray S. Kucherawy
Cc: Mark Delany; IETF DKIM WG
Subject: Re: [ietf-dkim] Broken signature analysis
The previous interop event targeted basic, direct signing
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Barry Leiba
Sent: Friday, February 19, 2010 11:32 AM
To: IETF DKIM WG
Subject: [ietf-dkim] Proposed new charter
Here is a charter proposal for us to bash. It covers the
OK, dates:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Barry Leiba
Sent: Friday, February 19, 2010 11:32 AM
To: IETF DKIM WG
Subject: [ietf-dkim] Proposed new charter
[...]
+++ New Work +++
The working group
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Barry Leiba
Sent: Thursday, January 21, 2010 2:02 PM
To: IETF DKIM WG
Subject: [ietf-dkim] Collecting re-chartering questions
1. Advance DKIM base to Draft Standard
Yea.
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of hector
Sent: Sunday, November 01, 2009 7:44 PM
To: John Levine
Cc: barryle...@computer.org; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Interesting Dupe Signatures
-Original Message-
From: John R. Levine [mailto:jo...@iecc.com]
Sent: Monday, November 02, 2009 10:15 AM
To: Murray S. Kucherawy
Cc: ietf-dkim@mipassoc.org
Subject: RE: [ietf-dkim] Interesting Dupe Signatures
I don't see much benefit for saving the header hash, since it depends
-Original Message-
From: HLS [mailto:sant9...@gmail.com] On Behalf Of hector
Sent: Monday, November 02, 2009 11:00 AM
To: Murray S. Kucherawy
Cc: barryle...@computer.org; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Interesting Dupe Signatures
Comparing public APIs, it appears
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Barry Leiba
Sent: Wednesday, September 30, 2009 9:01 AM
To: IETF DKIM WG
Subject: [ietf-dkim] DKIM charter update proposal
Pasted below is my proposal for an updated DKIM
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of John Levine
Sent: Sunday, October 18, 2009 1:31 PM
To: ietf-dkim@mipassoc.org
Cc: barryle...@computer.org
Subject: Re: [ietf-dkim] How about that DKIM charter update
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Daniel Black
Sent: Sunday, October 18, 2009 6:00 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] DKIM charter update proposal
I think supporting data collection by
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Michael Thomas
Sent: Monday, October 19, 2009 9:53 AM
To: Daniel Black
Cc: barryle...@computer.org; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Issue: Deployment Guide
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Steve Atkins
Sent: Monday, October 19, 2009 10:42 AM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] DKIM charter update proposal
I'd be fine with doing that through this WG,
-Original Message-
From: i...@sussex.ac.uk [mailto:i...@sussex.ac.uk]
Sent: Wednesday, October 14, 2009 4:53 AM
To: Murray S. Kucherawy; John R. Levine; Daniel Black
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Is anyone using ADSP? - bit more data from the
receiving side
-Original Message-
From: HLS [mailto:sant9...@gmail.com] On Behalf Of hector
Sent: Wednesday, October 14, 2009 7:06 AM
To: Ian Eiloart
Cc: Murray S. Kucherawy; Daniel Black; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Is anyone using ADSP? - bit more data from the
receiving side
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of hector
Sent: Wednesday, October 14, 2009 7:20 AM
To: dcroc...@bbiw.net
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] brand protection, was Is anyone using ADSP?
A
-Original Message-
From: HLS [mailto:sant9...@gmail.com] On Behalf Of hector
Sent: Wednesday, October 14, 2009 10:30 AM
To: Murray S. Kucherawy
Cc: i...@sussex.ac.uk; Daniel Black; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Is anyone using ADSP? - bit more data from
-Original Message-
From: HLS [mailto:sant9...@gmail.com] On Behalf Of hector
Sent: Wednesday, October 14, 2009 11:53 AM
To: Murray S. Kucherawy
Cc: Michael Thomas; ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Is anyone using ADSP? - bit more data from the
receiving side
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of John R. Levine
Sent: Monday, October 12, 2009 7:24 PM
To: Daniel Black
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Is anyone using ADSP? - bit more data from the
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Barry Leiba
Sent: Monday, October 05, 2009 6:56 AM
To: Franck Martin
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] DKIM charter update proposal
DKIM might or might not get to
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of MH Michael Hammer (5304)
Sent: Monday, October 05, 2009 8:19 AM
To: dcroc...@bbiw.net
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] Third-party authorization
Perhaps the
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Franck Martin
Sent: Thursday, October 01, 2009 12:56 PM
To: J.D. Falk
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] DKIM charter update proposal
Is the goal of a spec, the
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Douglas Otis
Sent: Thursday, August 06, 2009 8:26 AM
To: hector
Cc: ietf-dkim@mipassoc.org; MH Michael Hammer (5304)
Subject: Re: [ietf-dkim] DKIM adoption
Since few
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Steve Atkins
Sent: Sunday, August 02, 2009 6:34 PM
To: DKIM WG
Subject: Re: [ietf-dkim] Escaping things in key/ADSP records
[...]
Nice work! However:
If anyone has
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Steve Atkins
Sent: Monday, August 03, 2009 9:59 AM
To: DKIM WG
Subject: Re: [ietf-dkim] Escaping things in key/ADSP records
For typical DKIM users though, commenting on an
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Scott Kitterman
Sent: Friday, July 31, 2009 12:09 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Escaping things in key/ADSP records
On Fri, 31 Jul 2009 10:19:43
Are you trying to say?
DKIM_RESULT = DKIM_VERIFY(ENVELOPE, PAYLOAD)
FINAL_RESULT = DKIM_ASSESSOR(DKIM_RESULT, DKIM_TAG_QUERY(D) )
-- minimum requirement?
I don't fully understand your notation, but I think what I'm saying is that a
minimal DKIM implementation provides what's in
BTW, What is the definition of an Application Programming Interface
and what portion of DKIM is like an API definition.
I'm quite comfortable with drawing an implicit you must be this tall line and
assuming someone reading this, i.e. an implementer (e.g. YOU), will know what
an API is.
Or
So, here's a suggested merging of the two:
tThis currently leaves signers and assessors with the potential for
making different interpretations between the two identifiers and may
lead to interoperability problems. A signer could intend one to be
used for
If you going to this level, you need to be more specific with software
engineering terminologies and how it applies to SMTP. Murray's API is
not going to be same as MY API or that guys API and it may not be just
in C or C++, but in multiple of languages, and the API be COM
interface, a .NET
Any reputation assessment system should not:
1) limit what is to be assessed.
The proposed text does not put any limits on what gets assessed. If an
assessor wants more information, it is free to use a verifier that provides
more information.
2) allow inclusion of un-assessed information
DKIM's purpose has been lost with the continued out of scope undefined
reputation modeling. A concern raised over and over again, Assessment |
Reputation - wink wink, same thing when it come to coding it. Word
smithing does not solve implementation issues.
I don't agree at all with these
tThis update resolves that confusion. It defines
additional, semantic
labels for the two values, clarifies their nature and
specifies their
relationship. More specifically, it clarifies that the
identifier
intended for delivery to the assessor --
OK, so now I guess I'm confused. My understanding is that if i= isn't
specified it takes the value of d=, so I'm not clear how it can be
undefined?
Maybe the wording of the errata draft could be improved (I'll propose new text
shortly if I can), but here's my understanding:
I believe
There’s a draft proposal out to add a new tag to keys for doing this. See
draft-kucherawy-dkim-reporting.
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On
Behalf Of Franck Martin
Sent: Thursday, June 11, 2009 6:04 AM
To: ietf-dkim@mipassoc.org
Subject: Re:
In addition, acceptance of indirect A-R records should be handled with
caution. Keep in mind that A-R headers themselves are not secure,
and that trust in authserv-id (that recipients may have been asked
to enter into their MUA to enable annotations) need to have originated
from their
I think I've come around to +1 on keeping h= in key records.
-MSK
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Here's what I remember from the original discussion of h= and k= in
the key record.
First, part of the idea was to have them both there, to make things
parallel: This key is used for this crypto suite.
[...]
I'm neutral on either keeping or removing this one. It seems to me an RSA key
is
Another way to look at it is that k= is useless, but it's not harmful,
so it'd be more productive to argue about the warts that are both
useless and harmful.
I don't know that it's completely useless, but I'll defer to Jon on this point:
Is the actual cost of parsing k=rsa from the key and
-Original Message-
From: Douglas Otis [mailto:do...@mail-abuse.org]
It seems suitable to either reject or annotate a stern warning, those
messages where the domain refutes the algorithm claimed in the DKIM
signature.
Doug,
I'm still not convinced, but you have me thinking about
By selecting specific A-R headers to remove, header content might be
processed post delivery, and then appear to match against some trusted
domain.
I believe the Security Considerations of RFC5451 covers this adequately.
For sure, individual recipients may wish to check signatures etc.
The use of the DKIM l=, z= and x= features provide a means for
recipients to separately evaluate DKIM signatures without reliance on
intermediary assessors. In addition, the A-R header does not capture
the IP address when assessing path registration protocols, which means
that safe
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Dave CROCKER
Sent: Wednesday, June 03, 2009 11:13 PM
To: ietf-dkim@mipassoc.org DKIM IETF WG
Subject: Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type
Eliot
The issue of A-R headers being trusted only when signed by DKIM runs
counter to their intended use.
That's not necessarily true.
You're making hard assertions about a fuzzy situation. DKIM signing might work
just fine in certain installations. That's why RFC5451 suggests doing this
without
TXT RR tags
h: Acceptable hash algorithms
The spec needs to define the supported set of hash algorithms. There
may be some value in a signer being able to state that they're using
an algorithm that isn't supported, perhaps.
But unless there is a viable attack such that an
Disagree. This feature is about better informing recipients as to the
status of the signature.
For the sake of enumerating implementations, the current libdkim implementation
does make a distinction between a signature that failed to verify and one that
couldn't be verified because the key's
WTF is the point of inserting an A-R header if you are not willing to
take responsibility for what you have done by signing it?
And why should anyone else believe your A-R if you have omitted that
elementary step?
Because, if you've followed the RFC defining it, the border MTA has removed
Quoth Jon Callas:
I don't think it's worth expending breath on removing SHA1. [...]
+1
-MSK
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Well, sure, but the question is whether that information is useful. We
could include the phase of the moon and the software author's middle
name, too.
Sure, if you want to be silly about it. But I was being serious.
I'm all in favor of standards communicating useful information, but if
Key Records:
1) 4871bis-compliant code [MUST|SHOULD|MAY] be able to use
4871-compliant key records
SHOULD, in the classic you should have a good reason not to sense.
2) 4871-compliant code [MUST|SHOULD|MAY] be able to use
4871bis-compliant key records
MAY
Signatures:
3)
The question remains: given a message with such a signature, which is
entirely valid in the current DKIM, what will a recipient system do
with it? What will users see? Ask ten people, get ten answers, which
is about as far from interoperable as you can get.
I think the use of
I thought you just said that you know people who reject signatures if
the l= covers less than some percentage of the message.
I know of at least one implementation that offers that possibility, but it is
clearly divided into an assessor portion and a verifier portion. They happen
to be
Why does the current specification allow the signer to specify an
arbitrary
value for l=, rather than requiring the value of l= to be the actual
length
of the message body at the time the message is signed?
How could a verifier tell any different, thus making non-compliance detectable?
The
I don't have a legalistic definition of interoperability; I want
implementations to, you know, interoperate. When I sign and send a
message, it'd be nice if I could expect recipients to interpret the
signature consistently. If assessors are likely to do inconsistent
things with parts of the
I agree. As a receiver, I laugh in the face of the very notion that am
obligated to do anything with a message other than as I will.
Which means you're also given the option to know what the signer's notion of
the signature's validity time is. And you're free to ignore it too.
If the signer
Then we're screwed, since it'll be impossible to do anything at all
that makes it more likely to get your mail delivered.
That's still blurring the line between a verifier and an assessor. We can only
make educated guesses about the latter, but we have substantial influence on
the former.
DKIM is not limited to just email. Even ADSP failed to limit its
assertions to just email. As such, what should unspecified message
formats contain?
One would think the unspecified message formats would have defining documents
someplace that identify header fields that are supposed to be
Without this feature, people may soon find their inbox flooded by
bogus messages indicating the use of new algorithm, that could have
been mitigated extensively by having the key feature.
As opposed to what? What would you expect a verifier or assessor to do if the
hash used to sign was not
On Thu, 28 May 2009, Barry Leiba wrote:
3. A few Yes, adding this is groovy, messages would be good and all.
Yes, adding this is way groovy.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On Wed, 20 May 2009, Steve Atkins wrote:
Another use case is to use l= to sign a text part of an email, but not
to sign an attachment. In that case I can obviously replace the
attachment with my own content, but depending on the details of the
email structure I may well be able to replace
On Sat, 9 May 2009, Steve Atkins wrote:
q: List of query methods
I don't think q= is going to be controversial either, but I'm
mentioning it separately as it currently only has one value, the
default, it's unlikely to be extended, and if it were it would require
a whole new RFC to do
On Sun, 10 May 2009, Dave CROCKER wrote:
For example, saying MAY on l= could mean that a signer might choose to
implementer and a validator might not. Hence, no interoperability.
In the case of z=, for example, a verifier electing not to implement
would simply ignore the tag.
If the use of
On Sat, 9 May 2009, Dave CROCKER wrote:
The simpler a spec is, the easier it is to develop, test and
operate, and the easier it is to explain to others.
Deprecating what is non-essential facilitates adoption. You can't
facilitate that adoption if you wait until there is more
On Thu, 9 Apr 2009, J.D. Falk wrote:
I agree with Doug's point here. The problem is that the more I think
about it, the more I think it's a mistake for us to put MUA advice
into the standards-track documents, and I'm inclined, rather, to want
to remove what's there rather than to change it.
I understand the desire to constrain the SDID to be a registered name or
under one, but is there a need to make this normative? DKIM verification
simply won't work if the SDID doesn't meet that criterion, and perhaps
that's good enough.
___
NOTE
On Thu, 26 Mar 2009, Hector Santos wrote:
With specific reference to DKIM, what I most want to discourage is
awful IP/domain hybrid hacks like only validating a signature if
the Sender-ID or SPF passes. So our interop advice is when you're
thinking about DKIM, don't think about IP
On Wed, 25 Mar 2009, Eliot Lear wrote:
8. RFC4871 Section 2.11 Identity Assessor
Old:
The name of the module that consumes DKIM's primary payload, the
responsible Signing Domain Identifier (SDID). It can optionally
consume the Agent or User Identifier (AUID)
On Wed, 25 Mar 2009, John Levine wrote:
New:
A single domain name that identifies the agent or user on behalf
of whom the SDID has taken responsibility. For DKIM
processing, the name has only basic domain name semantics; any
possible owner-specific semantics is
On Mon, 9 Mar 2009, John Levine wrote:
I sign all my mail, but there's no way I can say that with ADSP. In its
current form, ADSP is broken and useless.
I thought that's what dkim=all says:
allAll mail from the domain is signed with an Author
Signature.
Do you not sign
On Mon, 9 Mar 2009, John R. Levine wrote:
I sign all my mail, but there's no way I can say that with ADSP. In its
current form, ADSP is broken and useless.
I replied:
I thought that's what dkim=all says:
allAll mail from the domain is signed with an Author
Signature.
On Mon, 9 Mar 2009, John R. Levine wrote:
Even though I do in fact sign all my mail with valid DKIM signatures, I
can't say that with ADSP. Perhaps there are people who consider that
makes ADSP highly functional, but it seems an odd interpretation.
I also think it seems odd to label
On Tue, 10 Mar 2009, deiva shanmugam wrote:
Can anyone please let me know, if control characters like vertical
tab, Form feed, page eject etc are available in the header, what has to
be done, when relaxed canonicalization for the headers is followed?
Example:
501 - 600 of 656 matches
Mail list logo
