Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

On 02/11/2018 06:20 PM, Dave Crocker wrote: On 2/11/2018 5:54 PM, Michael Thomas wrote: You clearly have no idea what you are talking about. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html Mike

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

On 02/11/2018 05:46 PM, Dave Crocker wrote: On 2/10/2018 10:47 AM, Michael Thomas wrote: But I still think this entire conversation is silly in its theoreticality. Extra design complexity and consuming development resources -- programming, bench testing, interoperability testing

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

On 02/10/2018 10:22 AM, Dave Crocker wrote: On 2/10/2018 10:12 AM, Michael Thomas wrote: DKIM-Signature-v2: vs DKIM-Signature: v=2; Angels, meet the pinhead. equal semantics does not mean equal implementation. the processing for each of these takes place in very different parts

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

On 02/10/2018 10:04 AM, Dave Crocker wrote: On 2/10/2018 9:47 AM, John R Levine wrote: Well, OK, other than DKIM-Improved-Signature how would you do conditional signatures, where the signature has to fail if the semantics of the re-sign tag aren't satisified? Remember that the current rule

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

On 2/8/18 4:45 PM, Dave Crocker wrote: On 2/8/2018 4:42 PM, Michael Thomas wrote: Besides if you wanted to go from DKIM to EKIM, you'd be opening pandora's box imo. The pandora's box is creating an incompatible new version.  All the rest is just engineering and operations tradeoffs

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

On 2/8/18 12:32 PM, Mark Delany wrote: I think this is the biggest flaw with the whole v= rationale. There is never going to be a v=2 change that doesn't leave everyone continuing to generate/validate a v=1 header. Is a new header by stealth better engineering than formalizing a new header? I

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

On 11/15/16 11:57 AM, Murray S. Kucherawy wrote: On Wed, Nov 16, 2016 at 4:17 AM, Martijn Grooten > wrote: My understanding is an attack where the email is sent to an outside address owned by the sender, who then gets a

Re: [ietf-dkim] [dmarc-ietf] draft-kucherawy-dmarc-rcpts

On 11/15/2016 11:17 AM, Martijn Grooten wrote: On Tue, Nov 15, 2016 at 11:56:11AM -0600, Scott Kitterman wrote: Not at all. As I understand the scenario, the provider knows it's bad, doesn't send the mail on to the outside world, but still gives a signed copy back to the originator (which is

Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (3758)

On 10/20/2013 06:35 AM, Barry Leiba wrote: This one's right, of course: no one uses v=DKIM1; it's always v=1. Authors, was this just left in from the transition from DK days? Hmm, my implementation (the first) has it as DKIM1. That says that it's been that way for a long time. Iirc, DK didn't

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

On 9/12/13 12:10 PM, Murray S. Kucherawy wrote: On Thu, Sep 12, 2013 at 7:57 AM, Michael Thomas m...@mtcc.com mailto:m...@mtcc.com wrote: The list of things DMARC does that ADSP doesn't in its appendix, is a trip down memory lane of constraints that were placed

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

On 9/11/13 6:15 PM, Murray S. Kucherawy wrote: I also agree with this proposal. I don't have much to add over the text in the formal request; it lays out the case based on my experience implementing DKIM and ADSP in open source. I can also say that I have never encountered an operation

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

On 9/11/13 9:32 PM, Dave Crocker wrote: On 9/11/2013 6:41 PM, Michael Thomas wrote: It doesn't help that ADSP's author actively wanted to subvert it. As far as I can tell, DMARC is warmed over ADSP with a different set of participants to claim credit for their original ideas. I don't

Re: [ietf-dkim] Weird i= in client mail

On 06/18/2013 07:18 AM, Tony Hansen wrote: On 6/18/2013 12:43 AM, Dave Crocker wrote: On 6/17/2013 9:20 PM, Franck Martin wrote: On Jun 17, 2013, at 8:58 PM, John Levinejo...@taugh.com wrote: At one stage i= was thought to represent different mail streams with different reputation, however

Re: [ietf-dkim] The good ol' t= tag in key records

On 07/23/2012 06:47 AM, Murray S. Kucherawy wrote: On Mon, Jul 23, 2012 at 6:42 AM, Michael Thomas m...@mtcc.com mailto:m...@mtcc.com wrote: There seems like there are many things wrong with this sort of helpfulness. If a given selector is dodgy, the reputation system should

Re: [ietf-dkim] The good ol' t= tag in key records

On 07/23/2012 06:13 AM, Barry Leiba wrote: That customer brought up an interesting point. t=y could also be useful for messages whose signatures do verify. Specifically, it could be used by a signer to say It's possible this message shouldn't have been signed by us. Please don't give it

Re: [ietf-dkim] No signatures, bad signatures, cousin domains

On 05/25/2011 01:05 AM, Murray S. Kucherawy wrote: Interesting. I ran some queries on our data for ebay.com, paypal.com, chase.com and bankofamerica.com. In all cases, messages with failed signatures were never tagged by Spamassassin, and at most 7% (usually less) of unsigned mail where

Re: [ietf-dkim] Certifying the DKIM public key?

On 05/23/2011 11:17 AM, Dave CROCKER wrote: As an impressive example of even deeper misunderstanding: More of CROCKER's famed civility. On 5/22/2011 10:49 AM, Michael Thomas wrote: But this is exactly what DKIM is. You prove yourself fsvo prove to the registrar who certifies you

Re: [ietf-dkim] Certifying the DKIM public key?

On 05/22/2011 10:27 AM, John R. Levine wrote: It occurs to me that since mail certification is likely to make assertions about behavior as well as identity, the SSL model in which certs last for a year won't work, since behavior can change rapidly. Either the certifier has to issue a stream

Re: [ietf-dkim] 8bit downgrades

On 05/19/2011 10:50 AM, Murray S. Kucherawy wrote: Can anyone remember why there’s a SHOULD for the downgrade to 7-bit in RFC4871 Section 5.3, rather than a MUST? The likelihood of breakage is so high when sending 8-bit data that DKIM almost becomes pointless without the upgrade. Not

Re: [ietf-dkim] 8bit downgrades

On 05/19/2011 02:53 PM, Pete Resnick wrote: In this case, the spec says that you MUST downgrade prior to signing *unless you know that the end-to-end path is 8-bit clean and will not downgrade later*. That's what SHOULD downgrade means. If there is an implementation that doesn't downgrade

Re: [ietf-dkim] 8bit downgrades

On 05/19/2011 07:11 PM, Pete Resnick wrote: On 5/19/11 6:09 PM, Michael Thomas wrote: We send things that get forwarded through all kinds of manglers, 8bit manglers just being one variety. In the abstract, you can never know as a signer that a path is clean... it can always be forwarded. So

Re: [ietf-dkim] 8bit downgrades

On 05/19/2011 07:20 PM, John Levine wrote: Can anyone remember why there's a SHOULD for the downgrade to 7-bit in RFC4871 Section 5.3, rather than a MUST? The likelihood of breakage is so high when sending 8-bit data that DKIM almost becomes pointless without the upgrade. I think

Re: [ietf-dkim] New canonicalizations

On 05/16/2011 07:40 AM, Mark Delany wrote: On 16May11, Alessandro Vesely allegedly wrote: OTOH, comparing the count fields of those two lines, 86% relaxed vs 14% simple, says that such kind of benefit is really really wanted. But that's a perceived benefit, not an actual one. Folk

Re: [ietf-dkim] New canonicalizations

On 05/16/2011 09:39 AM, Dave CROCKER wrote: Sorry, but I believe the above also does /not/ help us to understand actual survivability differences. To assess that difference, the experiment needs to send the same set of message twice, one with each type of canonicalization, and then see what

Re: [ietf-dkim] Issue: Consider deprecating l=

On 05/09/2011 02:39 PM, Murray S. Kucherawy wrote: - the PS-DS promotion rules say we should cut stuff that's not actually in use, but this is; - we therefore don't have any data to conclude that there isn't anyone out there that finds it exceptionally useful despite the dangers Yes

Re: [ietf-dkim] Issue: Consider deprecating l=

On 05/09/2011 02:28 PM, Barry Leiba wrote: Semantics first: we don't vote here. OK, that taken care of, it's a fair request, because there's been a lot of discussion about it. We certainly have a good base of support for deprecating l=. So I'll ask it this way, starting a new thread for

Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output

On 05/06/2011 08:12 AM, Rolf E. Sonneveld wrote: John, the opendkim project gathers information from various sources, they're not necessarily the users of Murray and they're not necessarily subscribed to mailing lists. The statistics also doesn't tell which inbound mail is from legitimate

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/05/2011 03:35 AM, Rolf E. Sonneveld wrote: Excuse me for my poor English, I shouldn't have used the word 'certify' here. I'm not talking about validity of content. Were I used the word 'certify' I mean: if a DKIM signature verifies successfully, the consumer can be sure that the body

Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote: Technical: The AUID is an unvetted value. The local-part and the subdomain could be garbage. It's inappropriate for a security protocol to return a possibly false value in the context of saying something was cryptographically validated.

[ietf-dkim] Output considered harmful

On 05/04/2011 05:04 AM, John R. Levine wrote: For a scenario where a caller is calling a DKIM milter which in turn calls an API, this is all true. But DKIM will be/is deployed in many more scenarios. Indeed, but you're misunderstanding the point of a standard. The DKIM spec tells

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 07:08 AM, Dave CROCKER wrote: The claim that rfc4871bis has the goal you claim is yours. So you need to do the work of subtantiating it. So far, as you acknowledge, your only reference is quite old, merely informative, and not a specification. In contrast, rfc4871bis declares

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 08:16 AM, Dave CROCKER wrote: Michael, On 5/4/2011 7:58 AM, Michael Thomas wrote: This is a good example of why this effort has come off the rails. Going from 4871 to DS should have been a fairly straightforward effort considering the high degree of interoperability we

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 08:51 AM, Murray S. Kucherawy wrote: Both documents refer to rfc4686, albeit only in the Informative References section. rfc4871 refers to rfc4686 only in section 8, rfc4871bis in section 8 as well as in section 1.1. There are two main fallacies that appear to be behind

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 09:15 AM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 9:03 AM To: Murray S. Kucherawy Cc: Rolf E. Sonneveld; dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 09:14 AM, Dave CROCKER wrote: I've uploaded Murray's helpful effort to the DKIM site: http://dkim.org/specs/rfc4871-to-bis02-diff.htm I had assumed that the complete diff would be unreadable, which is why I originally put up the incremental diffs. However in looking

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 10:13 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Wednesday, May 04, 2011 10:11 AM To: dcroc...@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 10:25 AM, Murray S. Kucherawy wrote: I count at least two new normative changes -- in informational notes of all places -- by scanning *half* the document, both of which are wrong. What were the two normative changes in informational notes that were wrong in the

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 10:43 AM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 10:29 AM To: Murray S. Kucherawy Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 11:03 AM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 10:54 AM To: Murray S. Kucherawy Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary - proposing ODID

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 11:53 AM, Dave CROCKER wrote: Considerations Section 8. To avoid this attack, signers should be extremely wary of using this tag, and verifiers might wish to ignore the tag. To avoid this attack, signers need to be extremely wary of using

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 12:08 PM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Wednesday, May 04, 2011 12:08 PM To: dcroc...@bbiw.net Cc: Dave CROCKER; Murray S. Kucherawy; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Output summary

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 11:26 AM, Dave CROCKER wrote: It's because I didn't want to imply that those were the only two. This is quite a remarkable premise for refusing to provide concrete substance. I'm trying to imagine how a working group could ever make progress, were this premise prevalent.

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 01:57 PM, Murray S. Kucherawy wrote: And who gets to define appropriate? It's already been pointed out that we could list every current tag's value and a pile of other stuff to pass on to the next layer, which may or may not find it useful, but that would make for an extremely

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 02:11 PM, Michael Thomas wrote: On 05/04/2011 01:57 PM, Murray S. Kucherawy wrote: And who gets to define appropriate? It's already been pointed out that we could list every current tag's value and a pile of other stuff to pass on to the next layer, which may or may

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 02:32 PM, Dave CROCKER wrote: On 5/4/2011 2:29 PM, Michael Thomas wrote: I should also expand that this entire situation started with Crocker insisting that we must choose between between i= and d= as The Output. It was a false dilemma then, and it remains a false dilemma

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 02:53 PM, Dave CROCKER wrote: On 5/4/2011 2:47 PM, Michael Thomas wrote: On 05/04/2011 02:32 PM, Dave CROCKER wrote: On 5/4/2011 2:29 PM, Michael Thomas wrote: I should also expand that this entire situation started with Crocker ... Right. It was all me. Another ad hominem

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 03:55 PM, Rolf E. Sonneveld wrote: Well, I think you both are right in reading what my concern/objection against 4871bis is. And maybe you're also right in that RFC4871 wasn't that much different of RFC4871bis. I think in the early days of DKIM most people assumed DKIM would

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

On 05/04/2011 04:40 PM, Dave CROCKER wrote: [] I'll do Barry the favor of stopping this inane conversation, much as it amuses me. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Output summary - proposing ODID Originating Domain Identity

Dave CROCKER wrote: On 4/30/2011 9:10 PM, Hector Santos wrote: So perhaps to help shut down this ambiguity we should add a DKIM terminology to clearly separate it from AUID. 3.x Originating Domain Identity (ODID) The ODID is the domain part of the From: address. This identity

Re: [ietf-dkim] despair

On 04/27/2011 09:53 AM, Dave CROCKER wrote: With that sort of documented history, the responsibility to claim otherwise falls on the critic. Otherwise the wg is essentially being asked to prove a negative and almost serves as a DOS attack... Denial of service on what/whom? As far as I

Re: [ietf-dkim] despair

On 04/27/2011 09:45 AM, Murray S. Kucherawy wrote: -Original Message- From: Michael Thomas [mailto:m...@mtcc.com] Sent: Tuesday, April 26, 2011 4:31 PM To: Murray S. Kucherawy Cc: DKIM IETF WG Subject: Re: [ietf-dkim] despair When you commit a 20 page diff without the benefit

Re: [ietf-dkim] despair

On 04/27/2011 12:19 PM, Barry Leiba wrote: chair Complaining is easy. Indeed so. And so let's cut the meta-discussion and not go back to throwing darts around. To the points: Mike's concern is valid. Murray's and Dave's notes have addressed it. I don't see how getting

[ietf-dkim] despair

There sure seems to be an awful lot of changes going on for a supposed draft standard document. I for one can't keep up with the rate of change, and I doubt anybody else can either. I really don't care if each individual piece can -- microscopically -- be justified within the process of draft

Re: [ietf-dkim] despair

On 04/26/2011 04:03 PM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Tuesday, April 26, 2011 2:43 PM Cc: DKIM IETF WG Subject: [ietf-dkim] despair There sure seems

Re: [ietf-dkim] Issue: Section 4.3 Hash method Note

On 04/25/2011 01:57 PM, Barry Leiba wrote: Dave further tweaks: INFORMATIVE NOTE: Although use of rsa-sha256 is strongly encouraged, some senders might prefer to use rsa-sha1 when balancing security strength against performance, complexity, or other needs. However,

Re: [ietf-dkim] ADSP stats

On 04/20/2011 01:29 PM, Murray S. Kucherawy wrote: There has been no uptake at all in OpenDKIM for ATPS, and almost none is apparent with ADSP, although in the latter case our data can only give a range for adoption because we don't query when an author signature passes. That isn't a

Re: [ietf-dkim] ADSP stats

On 04/20/2011 04:13 PM, Murray S. Kucherawy wrote: That isn't a helpful metric. The 99% most likely domains to have a ADSP record are ones where you see DKIM signatures and they pass. So if you're only checking domains without DKIM signatures (broken or otherwise), you're going to get a self

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

On 04/06/2011 08:48 AM, Steve Atkins wrote: That sounds like a fragile way to extend things - leave a little used feature around and hope someone who wants something new hijacks that field in a non-conflicting way instead. (Which may not be what you're suggesting, but it's an implication I've

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

On 04/06/2011 09:29 AM, Steve Atkins wrote: On Apr 6, 2011, at 9:07 AM, Michael Thomas wrote: There is something to be said about using tags in the signature rather than signed headers. Signers don't have to have any reason -- and none should be inferred -- for signing any given header

Re: [ietf-dkim] Extensions (was RE: Proposal: Removal of AUID (i= tag/value))

On 04/06/2011 10:25 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Wednesday, April 06, 2011 9:43 AM To: Steve Atkins Cc: DKIM WG Subject: Re: [ietf-dkim] Proposal

Re: [ietf-dkim] Extensions (was RE: Proposal: Removal of AUID (i= tag/value))

On 04/06/2011 12:34 PM, Steve Atkins wrote: On Apr 6, 2011, at 11:05 AM, Michael Thomas wrote: \ The alternative would be very squirrelly when you think of the general case of multiple signers in the path. The approach I suggest has no problems with multiple signers even

Re: [ietf-dkim] Extensions (was RE: Proposal: Removal of AUID (i= tag/value))

On 04/06/2011 01:18 PM, Steve Atkins wrote: Yes it does. In your example, a second signer who isn't privy to whether it knows the birth date could either sign it because it wants to keep transport integrity, or not sign it because it doesn't actually know the veracity of the X-Birthdate:

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

John R. Levine wrote: Flip that around: I want to give positive warm fuzzies to mail from the users that are authenticated by bigisp.com and are on my positive list. I believe that's what we call human shields. Um, no. This whole model of bigisp sending a mixture of legit and forged mail,

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

Dave CROCKER wrote: The distinction that needs to be made is between formally-specified output vs. implementation-specific access to DKIM internals. i= was never intended to be DKIM internals. That's why the entire gambit to make d= the only show in town sucked. Mike

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

On 03/31/2011 02:33 PM, Jim Fenton wrote: The direction of the DKIM specifications since RFC 4871 have been to rely less and less on the AUID (agent or user identifier, the i= value on the signature) to the point that it provides no security benefit. The working group was bamboozled into

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

Murray S. Kucherawy wrote: The working group was bamboozled into the false dilemma that DKIM had to produce a singular output. It has all gone down hill from there. Things that use heuristics like spam filters thrive with more information, and suffer with less. So we've destroyed information

Re: [ietf-dkim] DKIM using old RSA padding?

Hanno Böck wrote: Am Mon, 28 Feb 2011 09:44:25 -0500 schrieb Dave CROCKER d...@dcrocker.net: Just for archive completeness (and to comfort folks like me who lack crypto clue) could you offer a very brief summary of the difference between what DKIM currently uses and what is being

Re: [ietf-dkim] Re-thinking the organization of the DKIM spec

Snatching defeat from the jaws of victory: -1 Mike Barry Leiba wrote: The chairs are happy with how this discussion has been going so far, except that we remind people that discussion of any details of iSchedule or any other protocol that might cite DKIM is entirely out of scope -- we need

Re: [ietf-dkim] Re-thinking the organization of the DKIM spec

J.D. Falk wrote: On Jan 11, 2011, at 4:12 AM, Eliot Lear wrote: 2. The mechanisms in DOSETA were designed for DKIM. If we are generalizing along the lines that Dave has mentioned, I would prefer that DOSETA in particular not advance to draft status, as it ought to be tested in at least

Re: [ietf-dkim] Re-thinking the organization of the DKIM spec

Oh, good. I'm not the only party pooper. To what Jim wrote, I'll add: 1) As a developer, multiple documents generally suck. IKE, ISAKMP, and their friends. Need I say more? 2) Frameworks almost invariably fail, and that's what I sense here. We gave some passing thought to making this

Re: [ietf-dkim] Statistics about DKIM and MIME

On 10/25/2010 10:01 AM, Murray S. Kucherawy wrote: In the particular case of multipart/signed there were 106 messages where the RSA verification failed, but 122 where it passed but the body hash at the verifier didn't match the one in the signature. So more failures occur from body changes

Re: [ietf-dkim] double header reality check

On 10/20/2010 01:31 PM, Rolf E. Sonneveld wrote: On 10/20/10 9:30 PM, MH Michael Hammer (5304) wrote: Seeing as the M in DKIM stands for Mail, we don't have to put a but only when used in the email context clause. If a DKIM like approach is used for other protocols then we might reasonably

Re: [ietf-dkim] double header reality check

On 10/20/2010 04:36 PM, Steve Atkins wrote: On Oct 20, 2010, at 3:19 PM, Murray S. Kucherawy wrote: Validating mail syntax belongs in the specification for the mail components and DKIM work belongs in the DKIM components. That's why, layer violation or no, I think it's important to

Re: [ietf-dkim] detecting header mutations after signing

On 10/19/2010 06:18 AM, Wietse Venema wrote: valid signature + good signer + no suspicious unsigned content - good message Has nobody learned that good signers from good authors can still be evil? I mean come on, people, bot'd machines? This is horrible advice. s/unsigned/; and this

Re: [ietf-dkim] sophistry is bad, was Data integrity claims

Far be it for me to defend Dave, but I think you two are in violent agreement. I think you misread some of Dave's comment because they were posed as rhetorical. Mike On 10/16/2010 11:56 AM, Scott Kitterman wrote: On Saturday, October 16, 2010 10:50:25 am Dave CROCKER wrote: On 10/16/2010 10:26

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

On 10/15/2010 06:51 AM, Charles Lindsey wrote: On Thu, 14 Oct 2010 18:23:21 +0100, Michael Thomasm...@mtcc.com wrote: I would hope so because this would be a really stupid thing to do. Without the next line of defense -- virus, malware, spam, phishing -- you'd be setting your users up for

Re: [ietf-dkim] Last call comment: Changing the g= definition

On 10/15/2010 08:28 AM, Dave CROCKER wrote: On 10/15/2010 10:28 AM, Jeff Macdonald wrote: On Thu, Oct 14, 2010 at 6:33 PM, Dave CROCKERd...@dcrocker.net wrote: Although some folk have done a +1 for one (or another) removal, I'd like to get a round of explicit reactions to the specific

Re: [ietf-dkim] Last call comment: Changing the g= definition

On 10/15/2010 10:32 AM, Barry Leiba wrote: I'd like to ask a procedural question of the chairs: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds for authors who kill file

Re: [ietf-dkim] Last call comment: Changing the g= definition

On 10/15/2010 11:19 AM, Dave CROCKER wrote: On 10/15/2010 1:32 PM, Barry Leiba wrote: Dave killfile's many participants, therefore any consensus he sees will merely reflect the echo chamber of his own making. So I strongly object on procedural grounds ... Mike, you needn't object

Re: [ietf-dkim] Last call comment: Changing the g= definition

On 10/15/2010 10:45 AM, Stephen Farrell wrote: In this case, I don't recollect an objection, so thus far, it seems to me that Dave's correct on this one. I think its perfectly fine for an editor to try to close off things that seem to have a clear consensus like this. Stephen -- the issue

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

On 10/14/2010 07:58 AM, John R. Levine wrote: Perhaps surprisingly, having redundant header fields does not make DKIM break. We must have some vastly different definition of break. If allowing through modified messages that render very differently isn't broken, shouldn't we remove the

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

On 10/14/2010 07:56 AM, Mark Delany wrote: On Thu, Oct 14, 2010 at 07:38:13AM -0700, Mark Delany allegedly wrote: What is essential is that it perform the task of validating and delivering a signing domain that is associated with a collection of bits. Anything that defines how to do this is

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

On 10/14/2010 09:45 AM, John R. Levine wrote: Unless there's *really* something they can't figure out without protocol help, I'm not sure what the point of this is. This double added From thing is trivial to detect with the current spec. Well, yeah. That's why I don't understand why people

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

On 10/14/2010 10:15 AM, John R. Levine wrote: If you really think this is such a great big problem, maybe you should be banging the drums at MAAWG or other venues where the correct set of ears is potentially listening. I would rather not have to run a session at MAAWG entitled How to fix the

Re: [ietf-dkim] layer violations, was detecting header mutations after signing

On 10/14/2010 10:47 AM, Murray S. Kucherawy wrote: -Original Message- From: John R. Levine [mailto:jo...@iecc.com] Sent: Thursday, October 14, 2010 10:45 AM To: Murray S. Kucherawy Cc: DKIM List Subject: Re: [ietf-dkim] layer violations, was detecting header mutations after signing

Re: [ietf-dkim] Last call comment: Changing the g= definition

On 10/14/2010 11:54 AM, Barry Leiba wrote: On Thu, Oct 14, 2010 at 9:05 AM, Tony Hansent...@att.com wrote: Even though I supported the addition of wording on how to improve the compatibility with DomainKeys records, I would support removing the new proposed section 3.6.1.1 for the reasons

Re: [ietf-dkim] FW: An issue with DKIM reporting extensions

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.

Re: [ietf-dkim] What DKIM provides, again

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

Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE

On 10/07/2010 03:40 AM, Charles Lindsey wrote: On Wed, 06 Oct 2010 13:00:25 +0100, Steve Atkinsst...@wordtothewise.com wrote: On Oct 6, 2010, at 1:47 AM, Mark Delany wrote: Right. We could attempt to enumerate the 1,000 edge-cases we know today and then re-bis 4871 for the additional 1,000

Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE

On 10/07/2010 11:01 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Thursday, October 07, 2010 9:09 AM To: Charles Lindsey Cc: DKIM Subject: Re: [ietf-dkim

Re: [ietf-dkim] detecting header mutations after signing

On 10/07/2010 05:01 PM, John R. Levine wrote: I'd say that it would be better to just say that if you sign a non-compliant 5322 message that its verification is undefined, and move on. That at least matches reality, and hasn't hurt anything that I'm aware of. Except that's not the situation

Re: [ietf-dkim] signing and verifying invalid messages

On 10/05/2010 01:36 PM, John Levine wrote: Still, though, it's a solution to deal with malformations to which MUAs are susceptible, and not strictly a DKIM problem. Would it be a good idea to recommend in 4871bis that DKIM implementations should not sign or verify invalid messages? I

Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report

On 10/04/2010 02:09 PM, Murray S. Kucherawy wrote: I wrote it, and it looks ready to go. Dear g*d, it's the mailing list equivalent of people pressing the like button on their own posts :) Mike From: ietf-dkim-boun...@mipassoc.org

Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01

Steve Atkins wrote: On Oct 1, 2010, at 8:11 AM, Jeff Macdonald wrote: On Fri, Oct 1, 2010 at 2:48 AM, Murray S. Kucherawy m...@cloudmark.com wrote: The results in Section 4.1.2 mention Author vs. Third-Party. That is more about ADSP than DKIM. True. It should probably come out. It

Re: [ietf-dkim] Comments on draft-ietf-dkim-implementation-report-01

MH Michael Hammer (5304) wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Murray S. Kucherawy Sent: Friday, October 01, 2010 2:48 AM To: SM; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Comments on

Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs

Ignorance is bliss, I guess, especially when it comes to pontificates. That's what every implementation of DKIM for MTA's, both open source and commercial that I'm aware of does, though some do and don't do the ADSP lookup. News at 11: email is still delivered, with little to no observable impact.

Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs

On 09/27/2010 10:38 AM, John R. Levine wrote: Ignorance is bliss, I guess, especially when it comes to pontificates. That's what every implementation of DKIM for MTA's, both open source and commercial that I'm aware of does, though some do and don't do the ADSP lookup. News at 11: email is

Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs

On 09/27/2010 10:58 AM, Michael Thomas wrote: On 09/27/2010 10:38 AM, John R. Levine wrote: Ignorance is bliss, I guess, especially when it comes to pontificates. That's what every implementation of DKIM for MTA's, both open source and commercial that I'm aware of does, though some do

Re: [ietf-dkim] Corner cases and loose ends, was , draft-vesely-dkim-joint-sigs

On 09/27/2010 11:17 AM, Al Iverson wrote: On Mon, Sep 27, 2010 at 1:05 PM, Michael Thomasm...@mtcc.com wrote: On 09/27/2010 10:58 AM, Michael Thomas wrote: On 09/27/2010 10:38 AM, John R. Levine wrote: Ignorance is bliss, I guess, especially when it comes to pontificates. That's what every

Re: [ietf-dkim] Who signs what

John R. Levine wrote: here was a (hard won) consensus that a signature by the owner/admin of a domain carries more weight than the signature of a 3rd party because the owner/admin of the domain controls the domain and the 3rd party doesn't. That's not my recollection, but whatever.

  1   2   3   4   5   6   7   8   >