[ietf-dkim] Now supporting rsa-sha256

[Sorry if this is a duplicate, but it seems like my other post vanished...] Our open source implementation now supports rsa-sha256 hashes and signatures, and tests in both directions against AT&T's and Alt-N's implementations. The source code is available at: http://sourceforge.net/p

[ietf-dkim] Signature identifier proposal

While considering the idea of multiple signatures on a message, I realized that it may be desirable or even necessary to be able to indicate to the MUA or some other agent which signatures succeeded verification and which did not. However it's also conceivable that two signatures on the message

[ietf-dkim] Jamming stuff in the selector record

I'm a little concerned about the trend of sticking more and more stuff in the selector (key) record. Today at the IETF we talked about both "r=" and the "we sign with these hashes" stuff in selector records. The argument in favour of this is that the "r=" in there shields a spam target via ob

Re: [ietf-dkim] Jamming stuff in the selector record

On Mon, 20 Mar 2006, Jim Fenton wrote: I agree with you regarding the obscurity of the "r=" value. Typically there will be a lot of messages floating around from which selector names can be harvested (from certain mailing list archives, for example); depending on confidentiality of selector na

Re: [ietf-dkim] Signature identifier proposal

On Mon, 20 Mar 2006, Jim Fenton wrote: I don't understand the value of knowing which signature(s) succeeded beyond knowing what the signing identity/ies (i= or equivalent) is associated with the successful signature(s). One of the primary reasons for i= is to clarify the role of the signer whe

Re: [ietf-dkim] Signature identifier proposal

On Tue, 21 Mar 2006, Michael Thomas wrote: If you're looking for a fingerprint, is there something wrong with b=? Actually yeah, using the first several bytes of the signature might work just fine. Then we don't need to change -base at all, and Authentication-Results: can just cite a piece o

[ietf-dkim] Proposed fingerprint tag description

Following up on prior discussion, I'd like to start working on some formal wording for a fingerprint tag. This will be used to describe the results of verifying a message with multiple signatures present, so that the receiver can match up each result to its respective signature even if there's

Re: [ietf-dkim] Proposed fingerprint tag description

william(at)elan.net wrote: Since fingerprints have specific meaning in cryptography, can you change the name to something like "Unique Signature ID" (i.e. "u" although personally I like "u"s for URLs). Fine by me. How about "sid" for Signature ID? How you planning to make reference to specif

Re: [ietf-dkim] Proposed fingerprint tag description

Douglas Otis wrote: Verification results based upon an added header might be spoofed when an MTAs is not configured to remove them. In addition, these headers will not be reliably present until universally adopted, perhaps many years from now. While the header might be removed normally,

Re: [ietf-dkim] Proposed fingerprint tag description

Michael Thomas wrote: It sounds like what you really want to do is to cause b= to be unique. That could be accomplished by just adding some hash-collision resistant number of random bytes. Or you could use those random bytes directly, I suppose. It may in fact be completely sufficient for the s

[ietf-dkim] Clarifications on draft-ietf-dkim-base-01

There are a few spots in the newer draft which are ambiguous. I chatted with Eric yesterday and he concurs; it's stuff he meant to change but they fell through the cracks prior to submission. They'll be fixed in the next one. My implementation follows the intended algorithm as we discussed it

[ietf-dkim] Re: [dkim-dev] Clarifications on draft-ietf-dkim-base-01

Tony Hansen wrote: This paragraph should be ignored completely. It should have been removed. Should the CRLF be there or not between the canonicalized headers and the DKIM-Signature? I expect it to be there, but this paragraph is the only place that says it should be there. No, it should not

[ietf-dkim] Re: authentication result headers are an unsafe alternative

If indeed discussion of Authentication-Results: or similar mechanisms is outside of the scope of this working group (or even if it isn't), I'd like to remind everyone that there's a mailing list dedicated to that very discussion. It is: [EMAIL PROTECTED] Bastardizing the administrativ

[ietf-dkim] Authentication-Results: discussion

I took as an action item in Prague to remind this list where the discussion about the Authentication-Results: header is going on. This is me, self-censuring for not doing so sooner. Dave Crocker has donated a list which you can subscribe to and browse archives at: http://mipassoc.or

Re: [ietf-dkim] DKIM Interoperability Event notes

On Thu, 8 Nov 2007, Hector Santos wrote: In sticking to the Subject: of this thread, no, this was not discussed at the Interop event. SSP was determined early on to be out-of-scope for our tests. We were focusing only on RFC4871 itself. How unfortunate. I disagree. Nobody at the event sai

[ietf-dkim] Authentication-Results: header draft

I just sent this off to ietf-822 and MAAWG's "techincal" list. Once more mentioning it here as well. Hoping to hand it off to our IETF AD soon. -- Forwarded message -- Date: Thu, 8 Nov 2007 14:32:30 -0800 (PST) From: Murray S. Kucherawy <[EMAIL PROTECTED]>

Re: [ietf-dkim] DKIM Interoperability Event notes

On Thu, 8 Nov 2007, Hector Santos wrote: It is clearly a threat entry point allowing anyone to try to create a DKIM signature and all they have to do is add t=y with the hope the receiver will ignore all fail validations. There was no discussion on this point. How can an attacker add t=y to a

[ietf-dkim] Proposal to amend SSP draft with a reporting address (fwd)

This time with feeling! (and the attachment) -- Forwarded message -- Date: Thu, 8 Nov 2007 16:13:41 -0800 (PST) From: Murray S. Kucherawy <[EMAIL PROTECTED]> To: ietf-dkim@mipassoc.org Subject: Proposal to amend SSP draft with a reporting address At MAAWG someone point

[ietf-dkim] DKIM Interoperability Event notes

quot;i=" or the domain in "d=" should be used when generating a domain reputation query based on a DKIM signature verification. At the end of this discussion, participants were asked to think about this and try to generate language for inclusion in later specifica

Re: [ietf-dkim] Proposal to amend SSP draft with a reporting address (fwd)

On Thu, 8 Nov 2007, Michael Thomas wrote: Maybe rather than proposing a change, it might be more productive to talk through what the problem actually is? I'm not convinced that random reports from potentially untrustworthy outsiders is what's wanted here. I'm not sure I should defend someone e

Re: [ietf-dkim] DKIM Interoperability Event notes

On Thu, 8 Nov 2007, Hector Santos wrote: How can an attacker add t=y to a signature? That only exists in keys and policies. They can make themselves look like cisco.com or any other HV domain and with the obvious failure and t=y, how will verifiers react to this? What you originally said wa

Re: [ietf-dkim] DKIM Interoperability Event notes

On Thu, 8 Nov 2007, Hector Santos wrote: Attackers will be able to create a FAILED fascimile of a primary domain DKIM complete message and as long as the primary has a t=y policy, the attackers need not worry about HASH PERFECTION - it just randomly creates a signature with a junk hash because

[ietf-dkim] Proposal to amend SSP draft with a reporting address

welcome. -- Murray S. Kucherawy = [EMAIL PROTECTED] Principal Engineer Sendmail, Inc.Emeryville, CA, USA (510) 594-5400 http://www.sendmail.com ___ NOTE

[ietf-dkim] Re: t=y

On Thu, 8 Nov 2007, Hector Santos wrote: - A testing attribute should used for Migration ideas, by it its very natural definition, a testing attribute is limited in scope and time. We actually have to say that, i.e. define "testing", in an RFC? - Not having any guidelines on how VERIFIERS will

Re: [ietf-dkim] Proposal to amend SSP draft with a reportingaddress(fwd)

On Wed, 14 Nov 2007, [EMAIL PROTECTED] wrote: Date: Wed, 14 Nov 2007 16:03:00 + From: Stephen Farrell <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Scott Kitterman wrote: On Wed, 14 Nov 2007 07:23:45 -0800 "Hallam-Baker, Phil

[ietf-dkim] draft-kucherawy-dkim-reporting-01 posted

The secretariat appears to be catching up, and the DKIM reporting draft I discussed at the Vancouver WG meeting is now available for review and discussion. Having talked to the co-authors of the ARF draft, it's likely that I can just get that draft modified to add what is needed to make this a

Re: [ietf-dkim] Proposal to amend SSP draft with a reporting address (fwd)

On Thu, 28 Feb 2008, Florian Sager wrote: > I just reviewed [ietf-dkim] "Proposal to amend SSP draft with a > reporting address" --> the responses dealt with using ARF or an own > abuse report format but they didn't refer to the reporting address. What > was the result of this discussion? There

Re: [ietf-dkim] Proposal to amend SSP draft with a reporting address (fwd)

On Thu, 28 Feb 2008, Florian Sager wrote: > Thanks for this reminder, I forgot about this draft: maybe section 4.1 > can be extended by s.th. like "a Reports are requested for passed > signatures inside mails with suspicious content". The same intent may > already be included in 4.2 "s ... signe

Re: [ietf-dkim] Issue 1550 - the name of the document (remains open *briefly*); there's still disagreement on "Author"

I'm coming down on the side that the strong language against changing drafts is unjustified. Moreover, I prefer the name change because at the moment one could implement the -02 draft, looking for "_ssp" and applying that algorithm, *and* the -03 draft, looking for "_asp" and applying that algo

Re: [ietf-dkim] sender-auth-header

On Fri, 14 Mar 2008, Frank Ellermann wrote: > [...] > > Unrelated, I just reviewed sender-auth-header-13, could the > DKIM experts here please also check it, especially section > 2.4.1 ? AFAIK some wannabe-DKIM results in 2.4.1 are wrong: > > There is no "policy" result in DKIM, or if it makes s

Re: [ietf-dkim] Practices protocol naming poll (Closing issue 1550)

[ ] ADSP - Administrative Domain Signing Practices (**) [X] ADSP - Author Domain Signing Practices [ ] ASP - Author Signing Practices [ ] FroDo - From Domain Signing Practices [ ] SPAD - Signing Practices of Author Domains [ ] SSP - Sender Signing Practices _

[ietf-dkim] New issue: Examples in SSP-03

The appendix of draft-ietf-dkim-ssp-03 which contains "Usage Examples" discusses a number of use cases, but actually contains no examples of the contents of the TXT record that would be used in any of those. Either the use cases should also include the corresponding TXT record to be used (or re

[ietf-dkim] A funny thing happened at RSA...

One of our marketing people just sent this to me. It's a paper produced by PayPal about their success fighting phishing via their deal with Yahoo! to have them discard any mail from paypal.com that wasn't signed or whose signature doesn't verify. http://www.blackops.org/~msk/paypal-phi

Re: [ietf-dkim] A funny thing happened at RSA...

Sorry, I wasn't done yet. The main reason I wanted to share this with the working group is to point out that we got some confused people at RSA asking us why we're going with DKIM and not DomainKeys in light of the content of this paper. I wonder if it would be prudent to (somehow) make a state

Re: [ietf-dkim] ietf-dkim Digest, Vol 118, Issue 8

On Thu, 1 May 2008, [EMAIL PROTECTED] wrote: > Looking for _adsp._domainkey.nxdomain.example. is a waste of time when > nxdomain.example. does not exist. I'd favour to keep it in the spec., > it is needed for result nxdomain. If you nevertheless remove both (the > step and the result) make sur

Re: [ietf-dkim] subdomain strawpoll

> Date: Thu, 1 May 2008 20:23:30 -0400 (EDT) > From: [EMAIL PROTECTED] (Wietse Venema) > Subject: Re: [ietf-dkim] subdomain strawpoll > To: ietf-dkim@mipassoc.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII > > Delete. And bury six foot deep, so that it won't come

Re: [ietf-dkim] [dkim-dev] need an interpretation of the base spec

On Tue, 3 Jun 2008, Tony Hansen wrote: > Right now, I'm leaning towards thinking that #2 is correct. What say the > rest of you? Discarding FWS and tokenizing is probably a common implementation tactic, which favours #2. I'm inclined to say it's an errata issue (and would offer #2 as the prefer

[ietf-dkim] I-D.kucherawy-dkim-reporting

> Sometimes I wonder what the goal here is. Why not ask me? > Looking into http://tools.ietf.org/html/draft-kucherawy-dkim-reporting > it reinvents RFC 3834 without referencing it, How? RFC3834 is a series of recommendations for a set of related scenarios, not a specific application. It woul

Re: [ietf-dkim] I-D.kucherawy-dkim-reporting

On Thu, 12 Jun 2008, [EMAIL PROTECTED] wrote: > Adding to this, Murray Kucherawy's draft captures the i= (identity) > parameter and a worthless s= (selector) parameter. The s= parameter > offers little value since the d= (key domain) parameter is missing. Only > the d= parameter (upon which the

[ietf-dkim] Theory vs. practise

Admitting up-front I'm only somewhat current on the ADSP debates: I'm not clear yet on what impact this will have, but now I'm aware of at least two large-scale DKIM implementors who fully intend to make a DNS tree walk of at least one level to determine if a parent domain has a published polic

Re: [ietf-dkim] I-D.kucherawy-dkim-reporting

On Mon, 16 Jun 2008, Douglas Otis wrote: >> It's not worthless to an implementor or administrator interested in >> figuring out why his/her mail isn't verifying properly. > > And to resolve such issues, knowing which Key Domain is being used is > still important, but nonetheless ignored. If fact

Re: [ietf-dkim] I-D.kucherawy-dkim-reporting

Dave Crocker wrote: > One should not say "published" for a draft, but if one were to say it, > in fact an ADSP draft is indeed published. > > But it has not been declared a working group document. I'm missing the distinction between "published" and "posted" (the latter being the one you'd prob

Re: [ietf-dkim] I-D.kucherawy-dkim-reporting

> Admittedly I was generally frustrated, and abused your draft to whine. > OTOH if you somehow missed those months to come to the ADSP decision, > and also propose to discuss parent domain again, that's also not very > encouraging. Your logic is faulty. The fact that I chose to participate in

[ietf-dkim] Documenting *why* the horse is dead

>> I'm trying to make the working group aware of possibly influential >> dissent outside of the working group. >> > > And how is that supposed to work ? Some persons known only to you > allegedly prefer the ssp-03 algorithm and are possibly influential; > what next ? There were tons of argu

Re: [ietf-dkim] Not an issue: multiple From headers

On Wed, 18 Jun 2008, [EMAIL PROTECTED] wrote: > [ not about ADSP, about DKIM ] > > An acquaintance points out that one could prepend an extra From: or > Subject: header to a DKIM signed message, which wouldn't break the > signature, but would often be displayed by MUAs which show the new one > r

[ietf-dkim] Authentication-Results: header users

I could cite in my note to the IESG that this spec is in use today? -- Murray S. Kucherawy = [EMAIL PROTECTED] Principal Engineer Sendmail, Inc.Emeryville, CA, USA (510) 594-5400 htt

[ietf-dkim] Need a document shepherd for Authentication-Results:

I am seeking a document shepherd for the Authentication-Results: draft. The chap who volunteered at the Philadelphia IETF is unable to fulfill that obligation. If willing and able, please contact me off-list. ___ NOTE WELL: This list operates according

Re: [ietf-dkim] [Interop] Adding a 'consultants' page to dkim.org

On Mon, 29 Sep 2008, Dotzero wrote: > It would be nice to be able to refer them to a consultants list through > dkim.org. I'm leaning toward objecting to that idea. I'm concerned that listing consultants on dkim.org could be construed as some kind of endorsement of those listed. __

Re: [ietf-dkim] [Interop] Adding a 'consultants' page to dkim.org

On Mon, 29 Sep 2008, Dave CROCKER wrote: > Software and Services Deployment > [404] > So really -- to use one of my favorite cliche's -- we are just haggling > about price... Ah, true. The link off the main page is entitled "Organizations Providing Software, H

Re: [ietf-dkim] [Interop] Adding a 'consultants' page to dkim.org

[Is this really appropriate for ietf-dkim?] On Mon, 29 Sep 2008, Dotzero wrote: > I appreciate your concerns Murray because there is currently a limited > universe of folks I would personally consider (FWIW) consultant caliber. > On the other hand I'm somewhat a believer in Caveat Emptor. Given

Re: [ietf-dkim] RFC 4871 errata

To answer the question about what current implementations do, I can speak for ours: Regarding erratum 1383, we responded to the consensus and allow "*" anywhere, and more than once, in the "g=" value. Regarding erratum 1378, we always include the "a=" in our generated signatures and require th

Re: [ietf-dkim] [Interop] Adding a 'consultants' page to dkim.org

On Tue, 30 Sep 2008, Dave CROCKER wrote: > I'd like to clarify the role of a new 'users' list from the DKIM lists > that already exist. The existing ones are: > >Standardization I'm guessing that's ietf-dkim. Pretty self-explanatory; the list covers the standardization of DKIM and its adju

Re: [ietf-dkim] [Interop] Adding a 'consultants' page to dkim.org

On Tue, 30 Sep 2008, Dave CROCKER wrote: > These are independently managed lists. Merging is possible, of course, > but we should get some pretty strong consensus to do that, I think. They remain ambiguous if not. But anyway, there's my vote in the hopes of creating some consensus. :) >> I'

[ietf-dkim] [Fwd: I-D Action:draft-hoffman-dac-vbr-04.txt]

[EMAIL PROTECTED] wrote: > The draft doesn't specify a discussion venue. I believe the plan is to > request > Informational RFC status. > > With respect to the IETF, is there a better place for discussion than the > DKIM list? > mail-vet-discuss? I don't imagine A-R will be there a whole l

[ietf-dkim] Considerations for rechartering

I'd suggest we consider rechartering to cover this draft: https://datatracker.ietf.org/drafts/draft-kucherawy-dkim-reporting The draft depends on two other drafts which are more broadly-based (draft-shafranovich-feedback-report and draft-kucherawy-sender-auth-header) and thus may not be able to

Re: [ietf-dkim] [mail-vet-discuss] ADSP and From header authentication?

Douglas Otis wrote: > The sender-auth draft provides a mechanism for use when ADSP records > are discovered, the From header field can be captured within an > Authentication-Results header. The purpose of the Authentication- > Results header is to convey to MUAs the results of various message

[ietf-dkim] Escaping things in key/ADSP records

DNS TXT records can contain multiple strings which we just concatenate to form a complete key record. That part's easily managed. However some people have taken it upon themselves to escape semi-colons for some reason, presumably because some programs like "dig" do that in their output, which

[ietf-dkim] Re-send: Considerations for rechartering

Apparently this got missed. Re-sending... -- Forwarded message -- Date: Fri, 17 Oct 2008 11:31:39 -0700 (PDT) From: Murray S. Kucherawy <[EMAIL PROTECTED]> To: ietf-dkim@mipassoc.org Subject: Considerations for rechartering I'd suggest we consider rechartering to

Re: [ietf-dkim] Escaping things in key/ADSP records

On Wed, 29 Oct 2008, John Levine wrote: > I find it hard to see this as anything other than a bug in whatever > scripts they're using to create their DNS records. The DNS has counts > for all variable length fields, so there's never a need to escape > anything in the bits on the wire. People w

Re: [ietf-dkim] Escaping things in key/ADSP records

On Thu, 30 Oct 2008, John L wrote: > A reasonable concern, but it seems to me that the best response is to > educate people about how to create valid DKIM setups. Early in the life > of SPF there used to be a lot of broken SPF records, but eventually > people got the hang of setting them up. S

Re: [ietf-dkim] draft Errata on RFC 4871

Serves me right for having this thing on "digest" mode all this time, and missing all the fun. Apologies, therefore, if my reply/replies here break threaded viewers, and certainly covers a few points that have probably been resolved, but I'd like to put my opinion out there for-the-record even

Re: [ietf-dkim] alternate proposal to draft-ietf-dkim-rfc4871-errata

Eliot, Your proposal would satisfy me (as an implementor, anyway) in terms of the opacity of the local-part value in "i=". What it doesn't do is address the question about whether or not RFC4871 presents a single identity as its output, and if so, which one that is. Or, alternately, perhaps yo

Re: [ietf-dkim] alternate proposal to draft-ietf-dkim-rfc4871-errata

On Wed, 11 Feb 2009, Jeff Macdonald wrote: >> It would be equally valid for a signer to apply a different >> pseudo-subdomain on each message, perhaps for tracking purposes. > > I think that is actually a mis-use of DKIM. The message-id field covers > that nicely. But Message-ID:'s semantics are

Re: [ietf-dkim] alternate proposal to draft-ietf-dkim-rfc4871-errata

On Wed, 11 Feb 2009, Jeff Macdonald wrote: >>> My understanding of opaque allows identical opaque values to identify >>> the same "something". >> >> Then you're arguing for something stronger than what the draft >> proposes. The draft uses SHOULD, where to match your understanding, it >> would

Re: [ietf-dkim] Requesting working group Last Call on: draft-ietf-dkim-rfc4871-errata-02

On Thu, 12 Feb 2009, Douglas Otis wrote: > The WG should also discuss the merits of making a statement warning > against a domain overlapping their valid namespace with fictitious or > token i= values. While such overlap should be discouraged to avoid > confusing recipients as to what the i= val

Re: [ietf-dkim] alternate proposal to draft-ietf-dkim-rfc4871-errata

On Fri, 13 Feb 2009, Jeff Macdonald wrote: >> In other words, I think the intent is that messages using the same >> UAID MUST be intended to be evaluated as sharing the same sphere of >> responsibility (this is a mandate on the sender's usage, not on the >> receiver's interpretation); senders SHOUL

Re: [ietf-dkim] alternate proposal to draft-ietf-dkim-rfc4871-errata

On Fri, 13 Feb 2009, Ellen Siegel wrote: In other words, I think the intent is that messages using the same UAID MUST be intended to be evaluated as sharing the same sphere of responsibility (this is a mandate on the sender's usage, not on the receiver's interpretation); senders

Re: [ietf-dkim] a protocol needs a payload

On Tue, 17 Feb 2009, Jim Fenton wrote: > But -rfc4871-errata-02 defines this backwards. The erratum makes > everything else internals, which eliminates a lot of information that > might be useful to a downstream assessor. For example: > [...] Perhaps this is a terminology question. In a DNS r

[ietf-dkim] DKIM WG meeting on the agenda

I just had a look and we have a 9am slot on the 25th (Wednesday) now. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Consensus call on d=/i= clarification

My vote: > (a) The erratum I-D [1] is ready to go. Process it. If there is indeed a requirement to conform to the concept that a protocol must specify its payload, I believe this is the right way to go. At present, a new API implementor has no clear indication of what a minimal DKIM implement

Re: [ietf-dkim] NO DKIM "POLICY"

On Thu, 19 Feb 2009, Hector Santos wrote: > What is the current recommended method to establish or expose that a > DOMAIN should not be signed, is not expected to be signed and that any > DKIM supportive receiver seeing a message with a signature from a > purported domain should be rejected with

Re: [ietf-dkim] NO DKIM "POLICY"

On Fri, 20 Feb 2009, Franck Martin wrote: > Should we not query every time the DNS, to check that this domain will > sign every message as policy and that a non signed message is therefore > invalid? You would then only query for a non-signed message, not every message. > In the case of the eba

Re: [ietf-dkim] Consensus call on d=/i= clarification

On Sat, 21 Feb 2009, SM wrote: > Given the scope of Dave's proposal, I'm still not comfortable with it > as an erratum. I choose Eliot's proposal (d). (d) included a "with the following changes" provision. What changes are you suggesting (or supporting)?

Re: [ietf-dkim] Handling the errata after the consensus call

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 si

Re: [ietf-dkim] Nitpicking about ADSP

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 >>

Re: [ietf-dkim] Nitpicking about ADSP

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 somet

Re: [ietf-dkim] Regarding Relaxed Canonicalization

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: > > Content-Type:*^L*mult

Re: [ietf-dkim] errata revision: Assessor

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 Identifi

Re: [ietf-dkim] errata revision: opaque

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 semant

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

On Thu, 26 Mar 2009, Hector Santos wrote: > And as long as this mindset persist, you are going to get the funny > looks from many disciplines in this market - mainly SMTP vendors! I represent an SMTP vendor, and I'm not sending funny looks. I'm pleased with these developments, and I concur with

Re: [ietf-dkim] what is a standard, was errata revision: Assessor

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

Re: [ietf-dkim] (registered) domain name (Re: errata revision: opaque)

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 WELL:

Re: [ietf-dkim] Update of RFC4871 Appendix D. MUA Considerations (resent)

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

[ietf-dkim] Comments on draft-ietf-dkim-deployment-04

I've been pretty thorough here, with an eye toward having it ready for the RFC editors. Anything starting "-" is a nit about form or grammar (there are lots), and anything else is about substance (there are some). GENERAL COMMENTS There's normative language in here. Is that appropriate, prope

Re: [ietf-dkim] I-D Action:draft-ietf-dkim-rfc4871-errata-04.txt

On Tue, 21 Apr 2009, Al Iverson wrote: >> I continue to be amazed at how utterly useless this document is, and >> more so that people are being asked to break a sweat to issue it. The >> most serious error is that it is a solution in search of a problem. >> >> Is there *one* person/organization her

Re: [ietf-dkim] Features that could be reconsidered as part of the bis process

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 d

Re: [ietf-dkim] Whither 4871bis?

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 us

Re: [ietf-dkim] Whither 4871bis?

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 ad

Re: [ietf-dkim] Whither 4871bis?

On Sun, 10 May 2009, Dave CROCKER wrote: > For l=, a MAY for signers produces a MUST for verifiers. Why is that necessarily the case? > If a signer bases their signature on use of an l= value, then the > signature will fail if the verifier does not implement it. That was kind of my point. And

Re: [ietf-dkim] Features that could be reconsidered as part of the bis process

On Mon, 11 May 2009, John Levine wrote: > Any idea what they're doing with it? Having added some support for DKIM > to majordomo2, I am more convinced than ever that the motivation for l=, > list recipients will filter list mail using the contributor's signature > rather than the list signature

Re: [ietf-dkim] Features that could be reconsidered as part of the bis process

On Mon, 11 May 2009, J.D. Falk wrote: > +1 to dropping these, though I'm willing to be convinced otherwise if > there are verifiers actively using them to make policy decisions -- > particularly z=. I can't imagine using "z=" as an input to a policy decision. I've only found it useful when deb

Re: [ietf-dkim] Features that could be reconsidered as part of the bis process

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 replac

Re: [ietf-dkim] Urgent: draft-ietf-dkim-ssp-10 and RFC 5451

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

Re: [ietf-dkim] RFC4871bis - whether to drop -- SHA1 support

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

Re: [ietf-dkim] RFC4871bis - whether to drop -- x=

> 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

Re: [ietf-dkim] 4871bis/4871 interop

> 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: > >

Re: [ietf-dkim] RFC4871bis - whether to drop -- l= and x=

> 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 "interopera

Re: [ietf-dkim] RFC4871bis - whether to drop -- l= and x=

> 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 pack

Re: [ietf-dkim] RFC4871bis - whether to drop -- l= and x=

> 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?

Re: [ietf-dkim] RFC4871bis - whether to drop -- l= and x=

> 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

  1   2   3   4   5   6   7   8   >