DKIM working group meeting, 25 March 2009 This is the content of the WebEx chat, which was used when there were problems with the jabber room. 03/25/2009 10:09:25 AM from Jim Fenton: Note that I have remotely muted some people -- you may need to unmute yourself to speak 03/25/2009 10:09:34 AM from Dennis Dayman: thx 03/25/2009 10:10:54 AM from Dennis Dayman: is that someone in teh audience speaking? 03/25/2009 10:10:58 AM from Jim Fenton: ok then nudge me here or on Jabber 03/25/2009 10:10:59 AM from Jon Callas: could the speakerget closer to the mic? 03/25/2009 10:11:08 AM from Jon Callas: what's the jabber room? 03/25/2009 10:11:37 AM from Jim Fenton: jabber room is dkim@jabber.ietf.org 03/25/2009 10:12:25 AM from J.D. Falk: is there a better audio stream, or is webex it? 03/25/2009 10:12:56 AM from Jon Callas: Yes, can we get a mic to the speaker? 03/25/2009 10:13:49 AM from Dave Crocker: there is a conference audio stream from the ietf: 03/25/2009 10:14:54 AM from J.D. Falk: webex audio is working now (though it's kinda amusing to listen to both at once) 03/25/2009 10:23:15 AM from J.D. Falk: can barely hear Dave 03/25/2009 10:24:21 AM from Dennis Dayman: audio is great using the stream from IETF website 03/25/2009 10:24:48 AM from J.D. Falk: thanks, I'll switch over -- though I noticed it's a few seconds delayed 03/25/2009 10:30:46 AM from Dave Crocker: "can barely hear Dave " - wow. I don't get that very often. 03/25/2009 10:31:42 AM from J.D. Falk: Dennis was right: this 64k mp3 stream sounds way better than the overcompressed audio from webex 03/25/2009 10:32:21 AM from Hector Santos: The IETF audo stream is great! 03/25/2009 10:32:33 AM from Jon Callas: where is it? 03/25/2009 10:32:50 AM from J.D. Falk: http://feed.verilan.com:8000/imperial_a 03/25/2009 10:33:14 AM from Hector Santos: Jon, http://feed.verilan.com:8000/imperial_a.m3u 03/25/2009 10:33:53 AM from Michael Adkins: I'm guessing that we'll still need to stay on the phone if we want to talk, right? 03/25/2009 10:34:11 AM from Jim Fenton: right, or we can channel you if you type here or on the jabber room 03/25/2009 10:35:33 AM from Hector Santos: Love to know who is currently speaking. 03/25/2009 10:35:50 AM from Jim Fenton: this is barry 03/25/2009 10:37:00 AM from Michael Hammer: I think Hector means who is speaking voice 03/25/2009 10:38:02 AM from Michael Hammer: +1 to what Ellen is saying 03/25/2009 10:39:21 AM from Michael Adkins: d= is the required one 03/25/2009 10:40:40 AM from Hector Santos: I agree too. 03/25/2009 10:41:30 AM from Michael Hammer: How does one identify a spoofed message from DKIM base? 03/25/2009 10:42:05 AM from Hector Santos: I agree. 03/25/2009 10:42:43 AM from Hector Santos: who is speaking? 03/25/2009 10:43:07 AM from Michael Adkins: Murray K 03/25/2009 10:44:26 AM from J.D. Falk: some good side conversation on the jabber, BTW 03/25/2009 10:44:43 AM from Michael Adkins: dkim@jabber.ietf.org? 03/25/2009 10:44:44 AM from Michael Hammer: My pidgin client keeps on blowing up when I try to join the room 03/25/2009 10:44:56 AM from J.D. Falk: madkins: yep 03/25/2009 10:45:18 AM from J.D. Falk: works fine in iChat... *shu rg* 03/25/2009 10:51:16 AM from Hector Santos: Is that not determine by the DOMAIN signer? 03/25/2009 10:51:51 AM from Hector Santos: The signer should have the alternate say what a verifier should do. 03/25/2009 10:52:09 AM from Hector Santos: as far was what is bad. 03/25/2009 10:52:52 AM from Hector Santos: I agree. 03/25/2009 10:56:51 AM from Hector Santos: Nodding head. 03/25/2009 11:00:01 AM from Hector Santos: Man, its amazing that Dave feels this way. He doesn't reflect these views in the WG. 03/25/2009 11:05:19 AM from Florian Sager: I agree, there is some need for a collection of demands from practical work 03/25/2009 11:05:48 AM from Florian Sager: I guess the amount of output values will turn out to be rather small. 03/25/2009 11:06:55 AM from Dennis Dayman: he's coming out of the closet? ;) 03/25/2009 11:17:41 AM from Florian Sager: don't forget there may be data (e.g. user-based-identifiers) the signer should be able to provide somehow and that can be used by an accessor if the accessor trusts the signing domain. This is abstract from DKIM itself but it seems to me it's technically reasonable to transfer this data. as part of the signature. 03/25/2009 11:18:36 AM from J.D. Falk: yep, that's the part that's best left vague for now (IMO) 03/25/2009 11:18:55 AM from Dennis Dayman: +1 03/25/2009 11:24:09 AM from Michael Hammer: The signature is only that the signing domain is taking some responsibility for that particular mail 03/25/2009 11:25:39 AM from Dennis Dayman: who is that? 03/25/2009 11:25:48 AM from Hector Santos: But there is a BASE ACCESSOR - the 1st domain signing domain. 03/25/2009 11:26:11 AM from Michael Hammer: does it matter unles we are talking about ADSP? 03/25/2009 11:34:15 AM from Ellen Siegel: what happened to the jabber room? 03/25/2009 11:34:19 AM from Hector Santos: Did the jabber room crash? 03/25/2009 11:34:33 AM from Michael Adkins: I don't think so 03/25/2009 11:34:34 AM from Eliot Lear: seems to have for me. 03/25/2009 11:34:40 AM from Hector Santos: me too. 03/25/2009 11:34:59 AM from Eliot Lear: nice to have a backup ;-) 03/25/2009 11:35:08 AM from Michael Adkins: ah, nm. it has 03/25/2009 11:35:46 AM from J.D. Falk: hm yes, perhaps it has. wacky. 03/25/2009 11:36:05 AM from Hector Santos: I just created: dkim@conference.jabber.isdg.net 03/25/2009 11:38:12 AM from Eliot Lear: MIC: are these architectural components or functions of the same component? 03/25/2009 11:38:30 AM from Eliot Lear: do we have verification and assessement or verifier and assessor? 03/25/2009 11:39:08 AM from Michael Adkins: architectural components 03/25/2009 11:39:49 AM from Dave Crocker: Barry's summary of tasks: 1) fix/replace use of 'opaque'; 2) fix definition of 'assessor'; and 3) clarify must/may statement on output to assessor 03/25/2009 11:40:00 AM from Michael Hammer: I think I agree with Mike Adkins.... architectural components gives us more flexibility down the road 03/25/2009 11:41:01 AM from Eliot Lear: the distinction is that you don't have to worry about API issues if you have functions as opposed to componentry 03/25/2009 11:41:03 AM from Hector Santos: is the jabber room open? 03/25/2009 11:41:27 AM from J.D. Falk: I'm unable to connect to either the official jabber, or your alternate 03/25/2009 11:41:30 AM from Eliot Lear: you don't have to get into MUST/ MAYs 03/25/2009 11:41:34 AM from Eliot Lear: which was jim's point 03/25/2009 11:41:42 AM from Michael Hammer: Do you feel that API issues would be that significant? 03/25/2009 11:41:49 AM from Michael Adkins: I agree with your distinction, but I believe they are implemented as architectural components in existing systems 03/25/2009 11:42:07 AM from Eliot Lear: not in all such systems 03/25/2009 11:42:10 AM from Michael Adkins: true 03/25/2009 11:42:11 AM from Jim Fenton: Yeah, it looks like there are problems with the jabber room 03/25/2009 11:42:30 AM from Michael Adkins: if you want to do both in the some component, you may 03/25/2009 11:42:36 AM from Michael Adkins: *same 03/25/2009 11:43:17 AM from Michael Adkins: but the strength of a standard identifier is that the assessment component can be maintained by another organization 03/25/2009 11:43:18 AM from J.D. Falk: Eliot, Michael: might that be the core of the confusion? 03/25/2009 11:44:00 AM from Michael Adkins: I'm not sure what the confusion is about.... I'm not sure any of the confused people are verifiers or assessors 03/25/2009 11:44:29 AM from Eliot Lear: michael, your concern is the sender. right? 03/25/2009 11:45:03 AM from Michael Hammer: which Michael? 03/25/2009 11:45:06 AM from Eliot Lear: adkins 03/25/2009 11:45:08 AM from Michael Adkins: my concern is the small verifiers that cannot perform their own assessments 03/25/2009 11:45:25 AM from Eliot Lear: why would they perform their own verification? 03/25/2009 11:45:27 AM from Michael Adkins: senders will follow suit with the major isps 03/25/2009 11:45:46 AM from Michael Adkins: verification requires access to the mail stream 03/25/2009 11:46:30 AM from Eliot Lear: so then what gets sent to the assessor? ONLY the SDID? 03/25/2009 11:46:55 AM from Michael Adkins: By default, the SDID 03/25/2009 11:47:24 AM from Michael Hammer: There might be additional information as was discussed earleir but it would be tied to SDID 03/25/2009 11:47:44 AM from Michael Adkins: if the assessor might support other input, they would have to communicate that to the verifiers 03/25/2009 11:48:02 AM from Eliot Lear: ok. so we're talking about whitelist/blacklists 03/25/2009 11:48:07 AM from Eliot Lear: as an example 03/25/2009 11:48:10 AM from Michael Hammer: or it might be an extension to DKIM 03/25/2009 11:48:24 AM from Michael Adkins: correct, that is an example 03/25/2009 11:48:50 AM from Eliot Lear: ok. i see your point. 03/25/2009 11:48:57 AM from J.D. Falk: MIC: there's a constituency who keep saying "DKIM is useless" because they don't understand it. they're confused. a long update process would add to their confusion. 03/25/2009 11:49:16 AM from Michael Hammer: or it might be something along the lines of Daves afilias proposal 03/25/2009 11:49:20 AM from J.D. Falk: (there are also a few who say it's useless because they DO understand it, and disagree, but that's different) 03/25/2009 11:49:30 AM from Michael Adkins: we're planning on using SDID for internal assessment by default 03/25/2009 11:49:44 AM from Michael Adkins: and then considering additional information for certain types of domains 03/25/2009 11:49:51 AM from DKIM Chairs: OK, JD... after Tony. 03/25/2009 11:50:03 AM from J.D. Falk: thanks, chairs 03/25/2009 11:50:44 AM from Eliot Lear: in that case, isn't it up to the verifier to decide what it wants verified? 03/25/2009 11:51:38 AM from Eliot Lear: if it wants to verify the From: line domain in the context of a particular SDID, ... 03/25/2009 11:51:43 AM from J.D. Falk: +1 to moving quickly, regardless of precise process used 03/25/2009 11:51:43 AM from Michael Adkins: I don't think so. The verifier is the actor that knows the least. 03/25/2009 11:52:08 AM from Michael Adkins: the signer potentially knows useful things about it's mail 03/25/2009 11:52:14 AM from Michael Hammer: Do you mean verify Eliot or do you mean assess? 03/25/2009 11:52:28 AM from Eliot Lear: verifier 03/25/2009 11:52:58 AM from Michael Adkins: the assessor knows the results of its assessments 03/25/2009 11:53:20 AM from Michael Adkins: but the verifier really only knows the result of verification, pass or fail 03/25/2009 11:53:22 AM from Michael Hammer: I'll bite.... so how does the verifier verify the From address? 03/25/2009 11:53:43 AM from J.D. Falk: now I'm tempted to submit the peanut butter errata 03/25/2009 11:54:14 AM from Michael Adkins: if the verifier wants the assessor to provide data about a From: address, they will have to find or create an assessor that does so 03/25/2009 11:54:26 AM from Michael Adkins: and then modify their verification process to send that data as well 03/25/2009 11:54:28 AM from J.D. Falk: the verifier can't verify that the from address is true, but can verify that it was signed -- and if it was signed by someone trusted, then they can (if they wish) assume that the from is true 03/25/2009 11:54:34 AM from Eliot Lear: if the From: address is signed, (which it is), then it might want to know something more granular. 03/25/2009 11:54:41 AM from Eliot Lear: as an example 03/25/2009 11:54:51 AM from Jon Callas: (switching to phone as I have to get into the car.) 03/25/2009 11:55:12 AM from Eliot Lear: the verifier might trust the assessor on both counts. 03/25/2009 11:55:22 AM from Michael Adkins: I agree 03/25/2009 11:55:33 AM from J.D. Falk: thanks for squeezing my comment in there 03/25/2009 11:55:37 AM from Michael Adkins: in which case it could send both the SDID and From to the assessor 03/25/2009 11:55:42 AM from DKIM Chairs: We try. 03/25/2009 11:55:48 AM from Michael Adkins: I don't think the errata forbids that 03/25/2009 11:55:58 AM from Michael Hammer: I don't think it does either 03/25/2009 11:55:59 AM from Michael Adkins: it just makes it an extension from the default 03/25/2009 11:56:16 AM from Michael Hammer: But I'm not sure I would consider that verifying.... I would call it assessing 03/25/2009 11:56:27 AM from Michael Hammer: as in, "What do these signed things mean" 03/25/2009 11:56:33 AM from Eliot Lear: all i'm getting to is jim's point about what is passed between the two. 03/25/2009 11:57:04 AM from Michael Adkins: sure 03/25/2009 11:57:04 AM from Eliot Lear: maybe in my example, the one guy is both verifier and assessor 03/25/2009 11:57:10 AM from Michael Adkins: possibly 03/25/2009 11:57:15 AM from Michael Adkins: internally here, I'm both 03/25/2009 11:57:21 AM from Eliot Lear: right 03/25/2009 11:57:22 AM from Michael Adkins: so I tend to see things in that light as well 03/25/2009 11:58:33 AM from Michael Hammer: I'm just thinking out loud, but on the inbound side I might rely on postini to validate but do additional assessment once it gets to our systems 03/25/2009 11:58:49 AM from Michael Adkins: and I would actually say that the verifier is not the part that would want more info, the handling filter is 03/25/2009 11:58:59 AM from Michael Hammer: correct 03/25/2009 11:59:02 AM from Michael Adkins: but that's more architectural discussion 03/25/2009 11:59:35 AM from J.D. Falk: one of the cool things about DKIM (vs. IPs) is that it becomes easier to have multiple layers of assessment with access to the same identifier 03/25/2009 11:59:37 AM from Murray Kucherawy: wow. 03/25/2009 11:59:45 AM from Hector Santos: wow is right. 03/25/2009 11:59:45 AM from Michael Hammer: I think architecture is important because it helps us test the theory 03/25/2009 12:00:57 PM from Michael Hammer: louder Ellen 03/25/2009 12:02:03 PM from J.D. Falk: I find myself caring less and less about the process the longer this goes on. 03/25/2009 12:02:11 PM from Michael Adkins: +1 03/25/2009 12:02:12 PM from Eliot Lear: here's a q- what if your input to the assessor needs to be IP address and domain? what does the interface look like? 03/25/2009 12:02:37 PM from Hector Santos: I could never survive this. :-) 03/25/2009 12:02:38 PM from Michael Adkins: to a single assessor? or one for each? 03/25/2009 12:02:48 PM from Eliot Lear: to a single assessor? 03/25/2009 12:03:30 PM from Eliot Lear: and we know that happens. 03/25/2009 12:03:54 PM from Michael Adkins: how do we vote via chat? 03/25/2009 12:04:00 PM from Murray Kucherawy: will relay 03/25/2009 12:04:01 PM from Eliot Lear: just say it in the chat 03/25/2009 12:04:08 PM from Murray Kucherawy: what's your vote? 03/25/2009 12:04:10 PM from Hector Santos: I vote for to follow procedure. 03/25/2009 12:04:18 PM from Murray Kucherawy: hector: what's procedure? 03/25/2009 12:04:50 PM from sm: I'm for procedure 03/25/2009 12:04:58 PM from Murray Kucherawy: what's procedure? 03/25/2009 12:05:02 PM from Murray Kucherawy: there are two procedures at least 03/25/2009 12:05:04 PM from Murray Kucherawy: pick one 03/25/2009 12:05:07 PM from sm: IETF process ;-) 03/25/2009 12:05:19 PM from Murray Kucherawy: which one? 03/25/2009 12:05:25 PM from Michael Adkins: I'm for whatever is quickest 03/25/2009 12:05:34 PM from sm: It's the IETF Standards Process, Murray 03/25/2009 12:05:38 PM from J.D. Falk: I'm with madkins 03/25/2009 12:05:49 PM from Murray Kucherawy: ok so SM votes for I-D method 03/25/2009 12:05:53 PM from Murray Kucherawy: anyone else? 03/25/2009 12:05:58 PM from Michael Hammer: If we have a consensus on the 3 points raised earlier 03/25/2009 12:06:07 PM from Ellen Siegel: me too... more delay means additional time for confusion over the ambiguities 03/25/2009 12:06:22 PM from sm: Well, Pasi can speed it up 03/25/2009 12:06:31 PM from Murray Kucherawy: who's being harmed by that though? i think that's a legitimate question 03/25/2009 12:06:34 PM from Michael Adkins: is the jabber room back up? I can't seem to connect still. 03/25/2009 12:06:35 PM from Murray Kucherawy: is there a clear and present danger? 03/25/2009 12:06:40 PM from Murray Kucherawy: madkins: me either 03/25/2009 12:06:44 PM from Eliot Lear: me either 03/25/2009 12:06:53 PM from J.D. Falk: no jabber lovin' here 03/25/2009 12:06:56 PM from Eliot Lear: murray, that's been my question all along. 03/25/2009 12:06:59 PM from Ellen Siegel: it seems to be back up, but there's no content yet 03/25/2009 12:07:00 PM from Michael Hammer: can we publish something informational as interim but letting people know where the I-D is going 03/25/2009 12:07:02 PM from sm: Jabber is down 03/25/2009 12:07:19 PM from Michael Hammer: I prefer speed as well 03/25/2009 12:07:22 PM from Murray Kucherawy: i still can't join jabber 03/25/2009 12:07:25 PM from Hector Santos: I have someone working on a backup room. Seems t only work with local accounts. 03/25/2009 12:07:26 PM from Murray Kucherawy: mhammer: why? 03/25/2009 12:07:33 PM from Hector Santos: I'm getting it opened up now. 03/25/2009 12:07:49 PM from Michael Hammer: I prefer speed which would indicate errata approach 03/25/2009 12:07:50 PM from Hector Santos: Me too! 03/25/2009 12:08:06 PM from J.D. Falk: hammer: I think we should keep publishing clarification & discussion on circleid & such, since the current process discussions are so unwelcoming to anyone who just wants to find out WTF is going on with DKIM 03/25/2009 12:08:08 PM from Michael Hammer: On the other hand I want to find a way to get consensus 03/25/2009 12:08:08 PM from Murray Kucherawy: so you just want it done, plain and simple? 03/25/2009 12:08:25 PM from J.D. Falk: in other words, non-IETF-process clarifications while the IETF process churns on 03/25/2009 12:08:32 PM from Hector Santos: who speaking agin? 03/25/2009 12:08:37 PM from Michael Hammer: that is risky J.D. 03/25/2009 12:08:38 PM from sm: Jim 03/25/2009 12:08:39 PM from Eliot Lear: jim fenton 03/25/2009 12:08:43 PM from Ellen Siegel: was Jim, now Pasi 03/25/2009 12:08:54 PM from J.D. Falk: hammer: agreed 03/25/2009 12:09:26 PM from Michael Hammer: Murray: It's not simply that I want it done. It's that ongoing confusion is detrimental to broader implementation 03/25/2009 12:09:44 PM from Michael Hammer: I want it done "right" 03/25/2009 12:09:54 PM from Murray Kucherawy: in that sense i think getting ADSP out is more important than this; our biggest complaint in industry is that that piece keeps changing 03/25/2009 12:10:07 PM from Michael Hammer: I agree Murray 03/25/2009 12:10:37 PM from sm: i= would be better if we want to keep g= 03/25/2009 12:10:41 PM from Michael Hammer: But "this" can knock ADSP implementation off it's feet 03/25/2009 12:10:41 PM from Murray Kucherawy: but regarding the SDID/AUID stuff, i agree it hasn't been explained what the big present threat is which requires immediate processing 03/25/2009 12:11:14 PM from Murray Kucherawy: the alleged ambiguities in 4871 haven't caused any obvious harm so far, especially given the interop success 03/25/2009 12:11:54 PM from Michael Hammer: Murray: I think there is a significant difference between interop success and implementation in the wild 03/25/2009 12:12:00 PM from Murray Kucherawy: i like the approach the errata effort is taking but i haven't seen anything that makes me want to get behind "do it NOW" 03/25/2009 12:12:09 PM from Michael Adkins: eliot, an interface that has to handle multiple identifiers on a single message will have to start with answering the question of whether the assessor gets to decide which identifier gets precidence, and therefore only that result is returned, or whether 03/25/2009 12:12:18 PM from Murray Kucherawy: there may be, but have we heard any complaints to which we are responding? 03/25/2009 12:12:28 PM from Michael Adkins: whoops, I think I got truncated 03/25/2009 12:12:54 PM from sm: Question: can someone explain what g= is for? 03/25/2009 12:13:02 PM from Michael Hammer: Did you look at my post to CircleID on the message-id ehader or Marks post about validation failrue cases? 03/25/2009 12:13:12 PM from Michael Hammer: ehader = header 03/25/2009 12:13:29 PM from Michael Hammer: I need to type more carefully 03/25/2009 12:13:37 PM from DKIM Chairs: The jabber room appears to be back, so please move discussion there (it's archived). 03/25/2009 12:13:40 PM from J.D. Falk: MIC: I'm fairly certain that ADSP i= doesn't prevent other uses of i= 03/25/2009 12:13:42 PM from Murray Kucherawy: what's circleid? 03/25/2009 12:13:51 PM from sm: some website 03/25/2009 12:14:29 PM from sm: I'll send you the link, Murray 03/25/2009 12:14:35 PM from J.D. Falk: circleid.com, a multi-author blog type site focused on network stuff 03/25/2009 12:15:09 PM from sm: BTW jabber is still down 03/25/2009 12:15:14 PM from J.D. Falk: yeah, still no jabber 03/25/2009 12:15:46 PM from Paul Russell: just successfully logged in to jabber & joined conference room 03/25/2009 12:15:47 PM from Michael Hammer: It initially applies to a small number of domains 03/25/2009 12:15:49 PM from Hector Santos: Its open again from here JD 03/25/2009 12:16:05 PM from Michael Hammer: I think over time more domains will move in that direction 03/25/2009 12:16:05 PM from Eliot Lear: steve, you can say that we have to worry about precedence, but that is what some people do with very valid reasons 03/25/2009 12:16:12 PM from J.D. Falk: dkim@jabber.ietf.org, right? 03/25/2009 12:16:19 PM from sm: Yes 03/25/2009 12:16:25 PM from sm: Still not working for me 03/25/2009 12:16:50 PM from sm: Can someone ask my question about what g= is for? 03/25/2009 12:16:52 PM from Murray Kucherawy: still not working for me either 03/25/2009 12:18:43 PM from Michael Hammer: There is another value to using i=, which is that a single signing key can be used for multiple subdomains (that are used in i=) 03/25/2009 12:18:50 PM from Jim Fenton: g= (which was in DomainKeys as well) is intended to allow a domain owner to delegate a key to a party they don't fully trust 03/25/2009 12:19:18 PM from sm: Jim, what's the user if we are going for domains only? 03/25/2009 12:19:26 PM from sm: I mean what's the use 03/25/2009 12:19:43 PM from Michael Hammer: If you trust em some but not enough then delegate a subdomain and let them gen their own signing key 03/25/2009 12:20:02 PM from Michael Hammer: but if you really only trust them some, why give them a key at all? 03/25/2009 12:20:05 PM from sm: Mike, it's not subdomain. There are also constraints on the local-part 03/25/2009 12:20:17 PM from sm: I mean Michael 03/25/2009 12:20:19 PM from John Levine: Re Jim's point, this is the issue of asking recipients to do your user management 03/25/2009 12:20:54 PM from Michael Hammer: We delegate our newsletter mailings to ExactTarget... we give them a seperate subdomain 03/25/2009 12:21:11 PM from Michael Hammer: So let them send from whatever user at that subdomaint hey want 03/25/2009 12:21:23 PM to Dave Crocker: I think we'll see a nearly infinite number of different experiments for dealing with delegation 03/25/2009 12:21:26 PM from Michael Hammer: If we have a problem we change DNS 03/25/2009 12:21:49 PM from J.D. Falk: I think we'll see a nearly infinite number of different experiments for dealing with delegation 03/25/2009 12:22:01 PM from Michael Hammer: +1 03/25/2009 12:24:01 PM from Michael Hammer: If I might digress a second.... for ADSP, what would be people think of a tag along the lines of ADSP=Y if someone is publishing ADSP records? 03/25/2009 12:24:14 PM from Murray Kucherawy: interesting 03/25/2009 12:24:24 PM from Michael Hammer: That would save a lot of DNS lookups 03/25/2009 12:24:29 PM from Michael Adkins: how? 03/25/2009 12:24:33 PM from DKIM Chairs: But you only look for ADSP records if you don't have an author-domain sig. 03/25/2009 12:24:41 PM from DKIM Chairs: So how would such a tag work? 03/25/2009 12:24:43 PM from Jim Fenton: The tag doesn't help if there's no signature at all 03/25/2009 12:24:51 PM from Michael Hammer: Sure it does in a round about way 03/25/2009 12:25:13 PM from Michael Hammer: If I'm sending you messages every day all day long that have ADSP=Y 03/25/2009 12:25:29 PM from Paul Russell: if there is no sig, there cannot possibly be a tag that would be a component of the sig 03/25/2009 12:25:33 PM from Michael Hammer: I'm assuming you are going to pay attention to that 03/25/2009 12:25:48 PM from Michael Hammer: that is, you will be building a list of domains that sign 03/25/2009 12:25:58 PM from Michael Hammer: "all" or "discardable" 03/25/2009 12:26:13 PM from Michael Adkins: I can do that with or without an ADSP tag 03/25/2009 12:26:44 PM from Michael Hammer: Jsut trying to address the complaint that initially there will be a low number of domains publishing ADSP 03/25/2009 12:26:53 PM from J.D. Falk: can the slides be on webex? 03/25/2009 12:27:08 PM from Michael Hammer: and thinking along the lines of hints 03/25/2009 12:28:20 PM from Ellen Siegel: mike (adkins): what's your take on r=? 03/25/2009 12:28:22 PM from DKIM Chairs: Slides are on Webex now. 03/25/2009 12:28:59 PM from J.D. Falk: thanks, chairs 03/25/2009 12:29:14 PM from Michael Adkins: my take is that I would use it the way I currently intend to use i= 03/25/2009 12:29:49 PM from Michael Adkins: I'll only care for certain domains 03/25/2009 12:29:59 PM from J.D. Falk: I'd agree (wearing my assessor hat) 03/25/2009 12:30:57 PM from Michael Adkins: I don't really see why it's needed though 03/25/2009 12:31:04 PM from J.D. Falk: primary concern would be that adding this tag before everyone in the industry understands that the d= / i= debate is settled will just make the debate louder 03/25/2009 12:31:14 PM from Michael Adkins: +1