[14:55:51] --- LOGGING STARTED
[15:17:20] --- doug.otis@gmail.com has joined
[15:17:39] --- doug.otis@gmail.com has left
[15:17:48] --- doug.otis@gmail.com has joined
[15:17:59] --- doug.otis@gmail.com has left
[16:50:04] --- mike@mtcc.com has joined
[17:37:29] --- frank has joined
[18:13:20] --- jlcjohn has joined
[18:15:24] --- barryleiba@gmail.com has joined
[18:15:37] --- eric has joined
[18:16:30] --- fenton@jabber.org has joined
[18:17:13] --- fenton@jabber.org has left
[18:17:28] --- fenton has joined
[18:19:52] --- guenther has joined
[18:20:14] * guenther starts scribing
[18:20:26] <guenther> note well...
[18:20:41] <guenther> is the audio working?
[18:20:46] <eric> yes, i'm here, and it works
[18:21:03] --- dcrocker has joined
[18:21:23] <guenther> meeting goal: get SSP to WGLC, now or soon
[18:21:55] --- resnick has joined
[18:22:03] <guenther> hopefully the last call will start in December and run through mid January
[18:22:21] <guenther> slides are already posted
[18:22:36] <guenther> - agenda bashing
[18:22:38] <guenther> - document status
[18:22:42] <guenther> - dkim interop event
[18:22:44] <guenther> - SSP
[18:22:49] <guenther> - overview
[18:22:54] <guenther> - dkim deployment
[18:23:02] <guenther> - draft-otis-dkim-tpa-ssp
[18:23:07] <guenther> - authentication results
[18:23:15] <guenther> - reporting
[18:23:16] --- ryu has joined
[18:23:21] <guenther> - another other business
[18:23:23] --- ddayman has joined
[18:23:28] <guenther> s/another/any
[18:24:58] <resnick> So now that I've made this comment about Sender: on the list, is there a particular document to which this is apropos?
[18:25:28] <resnick> (Read: When do I have to start paying attention?)
[18:25:35] <guenther> next: interop
[18:25:46] <guenther> 20 companies
[18:25:57] <barryleiba@gmail.com> Pete: SSP, isn't it?
[18:26:12] <eric> can someone ask tony to get closer to the mike?
[18:26:27] <guenther> that better?
[18:26:36] <eric> yep, much better!
[18:26:44] <barryleiba@gmail.com> (Tony clips mic to beard... room laughs)
[18:26:53] <resnick> Barry, ack. Will wake up then.
[18:27:19] --- raj has joined
[18:27:35] <guenther> some minor issues, including some disagreement between the text and ABNF
[18:27:45] <guenther> <chart here>
[18:27:48] <mike@mtcc.com> much better tony :)
[18:28:01] <guenther> signature issues:
[18:28:13] <guenther> - what to do with empty bodies
[18:28:57] <guenther> "simple" has explicit text, "relaxed" doesn't; steps for "relaxed" give empty input
[18:29:34] <guenther> consensus: add clarification on expected values for empty bodies
[18:29:41] <guenther> <slide of expected hashes>
[18:29:56] <guenther> what if body is non-empty, but does not end in CRLF
[18:30:05] <guenther> - only possible with BDAT or non-SMTP transport
[18:30:16] <guenther> (or BURL, I suppose...)
[18:30:38] <guenther> "simple" says to add a CRLF, "relaxed" says nothing
[18:30:56] --- andrewsullivan has joined
[18:31:06] <guenther> consensus: is the add one if not empty and some other condition that flashed by before I could read it
[18:31:48] <guenther> use of signature when querying "reputations": is the domain in "i=" or "d=" when generating a domain reputation query
[18:31:59] <guenther> is this in scope for the WG? if not, where?
[18:32:22] <guenther> barry: (not as chair) does not belong in base-spec
[18:32:39] --- mike@mtcc.com has left: Replaced by new connection
[18:32:46] <guenther> doug otis: in most cases would only be worrying about the d= domain
[18:32:56] --- fujiwara has joined
[18:33:00] <guenther> doug: seeing lots of spam coming through the larger domains
[18:33:12] <guenther> doug: can't block entire domain, too important
[18:33:15] --- mike@mtcc.com has joined
[18:33:24] <guenther> doug: dkim is going to create new workflow for handling these cases
[18:33:46] <guenther> doug: might even want to drill down further than just hte domain
[18:34:16] <guenther> stephen: don't need to settle this here
[18:34:27] <guenther> dave crocker: "you guys are wrong"
[18:34:48] <guenther> dave: dkim has the job of delivering an identity
[18:35:27] <guenther> dave: it lets a signer take responsibility
[18:36:02] <guenther> jim fenton: the opinion is i=, but the reputation can use whatever it wants to provide a useful service
[18:36:24] <guenther> dave: yes, they can even use the outside temp, but that's out of scope
[18:37:05] <guenther> dave: resolving the ambiguity is critical
[18:37:10] <guenther> doug: agree with Dave
[18:37:14] <guenther> <shock noises>
[18:37:20] --- semery@jis.mit.edu has joined
[18:37:52] <guenther> doug: would like to see something that clarifies what you can anticipate this stuff(?) meaning
[18:38:46] <guenther> JD: given the conflicting use cases, document them and go from there
[18:38:56] <guenther> barry: action item to JD to start that thread
[18:39:11] <guenther> is "a=" required or optional?
[18:39:12] <mike@mtcc.com> yes
[18:39:27] <guenther> which
[18:39:44] <guenther> next: FWS in z= tag
[18:40:11] <guenther> FWS is allowed before the "|", but not after
[18:40:18] <guenther> ...but, and example has it the other way
[18:40:23] <guenther> s/and/an/
[18:40:54] <guenther> the FWS before the "|" in the ABNF is actually redundant, as it is implied in the previous token
[18:41:12] <guenther> was this a typo for the other way around?
[18:41:28] --- Randy has joined
[18:41:31] <guenther> no FWS allowed between header name a following colon
[18:41:48] <eric> how about changing sig-z-tag-copy to have [FWS] on both sides
[18:41:53] <guenther> stephen: what did people actually do in the code?
[18:42:03] <eric> remove it in all but the first case in sig-z-tag
[18:42:06] <mike@mtcc.com> i do what tony suggests
[18:42:31] --- doug.otis@gmail.com has joined
[18:43:11] <guenther> will be taken to the list (apparently)
[18:43:18] <guenther> when does x= take effect?
[18:43:41] <guenther> a receiving impl has three options:
[18:43:46] --- raj has left
[18:44:02] <guenther> <choices>
[18:44:08] <guenther> invalid q=, etc values
[18:44:13] <guenther> nothing in text about unknown values
[18:44:22] <eric> hold on, qp-hdr-value allows FWS anywhere.
[18:44:37] <guenther> consensus: ignore unknown values
[18:44:57] <guenther> plus an errata to ignore unknown values in particular things
[18:45:27] <guenther> multiple TXT records
[18:45:38] <guenther> spec says "undefined"
[18:45:57] <guenther> is this an issue? MUST NOT?
[18:46:07] <guenther> t=y semantics:
[18:46:33] <guenther> different usage by implementors: some ignore, some change 'hard fail' to 'neutral'
[18:47:04] <eric> just lost the audio
[18:47:17] <mike@mtcc.com> i haven't lost it yet
[18:47:29] <guenther> ?: there are lots of double TXT records for SPF
[18:47:36] --- ogud has joined
[18:47:42] --- dcrocker has left
[18:47:57] <guenther> ?: lots of testers break or say 'this is broken'
[18:48:02] <ogud> stop using TXT
[18:48:33] <eric> I was switched to KWAX and now I've got nothing.
[18:48:43] <guenther> doug: re: SPF: they didn't have a way to break out the records
[18:48:51] <fenton> Olafur: we would need to deal with multiple records even if using a different RR type.
[18:48:52] <mike@mtcc.com> yeah, i'm dead now too
[18:49:11] <guenther> ('?' == neil)
[18:49:15] <ogud> fenton: True
[18:49:34] <ogud> but then all of the records are relevant
[18:49:45] <guenther> next: g=foo*bar
[18:49:53] <guenther> is '*' allowed in the middle?
[18:49:58] <guenther> consensus: yes
[18:50:01] <barryleiba@gmail.com> Mike, Eric, are you still without audio?
[18:50:06] <mike@mtcc.com> yes
[18:50:08] <eric> no audio
[18:50:11] <guenther> errata: give additional examples with wildcard in middle
[18:50:18] <barryleiba@gmail.com> Dennis, are you remote also? Do you also have no audio?
[18:50:30] <guenther> h= (key) vs a= (signature)
[18:50:41] <guenther> requirement to correlate should be clarified?
[18:50:51] <guenther> are 'forgiving' parsers allowed?
[18:50:59] <guenther> (they're following Tony's slides pretty closely)
[18:51:15] <guenther> someone sent x=123; ;
[18:51:26] <guenther> empty tag= value invalid per ABNF
[18:52:08] <guenther> where's the harm vs lowest common denominator
[18:52:27] <guenther> no consensus; maybe weak preference for strict
[18:52:30] <mike@mtcc.com> are you still dead eric?
[18:52:36] <guenther> validate test plane?
[18:52:40] <mike@mtcc.com> audio that is? :)
[18:52:40] <guenther> validation, even
[18:52:43] <eric> yep, still dead
[18:52:49] <guenther> <eric> braaaaaains
[18:53:38] <guenther> RFC editor keeps official pages
[18:53:41] <guenther> for errata
[18:53:57] <guenther> process is changing some
[18:54:26] <guenther> Tim (AD): if it's just errata, that okay
[18:54:33] --- xiaodong has joined
[18:54:41] <guenther> tim: if something really is broken, then we need to do a bis draft
[18:55:12] <guenther> tony: nothing is _really_ broken: you see all those check marks in the table of interop?
[18:55:18] <guenther> <applause>
[18:55:34] <guenther> (a runner has been sent to see about fixing the audio)
[18:55:36] <barryleiba@gmail.com> Someone is telling someone (ahem) that the audio stream is dead.
[18:55:45] <guenther> next up: Jim Fenton: DKIM SSP
[18:56:06] <guenther> changes since last IETF
[18:56:25] <guenther> what's new:
[18:56:34] <guenther> - "handling" tag added
[18:56:54] <guenther> expresses preference about handling of suspicious messages
[18:57:30] <guenther> it's a request for how the verifier should behave
[18:57:35] <eric> grrrr..... this is frustrating.
[18:57:47] <mike@mtcc.com> yes...
[18:57:49] <guenther> was based on requests from large financials
[18:58:04] <guenther> - removed discussion on "third party sigs and mailing lists"
[18:58:09] <guenther> - clarfied record syntax
[18:58:13] <guenther> - wording tweaks
[18:58:22] <guenther> "handling":
[18:58:42] <barryleiba@gmail.com> Sorry guys... they have been told. We'll see if they can fix it soon.
[18:58:46] <guenther> does the domain value deliverability or security
[18:59:04] <jlcjohn> I have audio
[18:59:10] <mike@mtcc.com> it's buffering :)
[18:59:11] <barryleiba@gmail.com> Yay!
[18:59:14] <guenther> <insert quote from Erik Johnson at Bank of America>
[18:59:18] --- healthyao has joined
[18:59:22] <eric> YES!!!
[19:00:09] <guenther> these are the people that are the 'target' of DKIM
[19:00:09] --- tonyhansen has joined
[19:00:17] <eric> Erik Johnson: “DKIM has allowed the largest targets of online fraud and phishing, the financial services industry, to begin positively asserting e-mail that is legitimately from them. Conversely, we are looking toward SSP as a way to apply strong policy regarding e-mail that falsely purports to be from one of our domains. In other words, this policy framework needs to provide a clear intent related to the assertion of the sending institution, including a strong capacity for dealing with unsigned mail or malformed signatures, including the intent for this type of message to not be delivered to the customer mailbox.”
[19:00:36] <eric> Jeff Carnahan, US Bank: “Delivering an email that has failed a DKIM check as “Suspicious” may fit most use cases but not all. Domains that are targeted for Phishing need a mechanism of informing recipient domains that they have “no confidence” in unsigned or improperly signed email. These emails should be treated as potential threats and NOT delivered to the Intended recipients. A SSP “Deny” option would provide the ability for domains that fit this use case to recommend rejecting or quarantining email that has failed DKIM verification.”
[19:00:55] <guenther> Dave Crocker: we have similar quotes from large receivers
[19:01:10] <guenther> dave: do we have any from large anti-spam groups?
[19:01:39] <guenther> dave: where is the understanding of "phishing"?
[19:01:45] <guenther> (regarding the second quote)
[19:01:55] <guenther> dave: we're setting expectation and they're wrong
[19:02:08] <guenther> dave: SSP will not meet Jeff's expectations
[19:02:16] <eric> Yahoo is doing side agreements right now that are basically SSP. they would like a standard way to do that.
[19:02:53] <guenther> jim: Jeff is not saying that ssp is a solution
[19:03:08] <guenther> dave: so, any pushback will be side-stepped
[19:03:38] <eric> Dave seems to be assuming that we are wrong, and won't listen to any argument to the contrary.
[19:03:39] <guenther> dave: that is the pattern of feedback on features of SSP
[19:04:10] <guenther> barry: what are you asking for?
[19:04:45] <guenther> dave: doing a thorough review made clear (to him) how far SSP had changed
[19:04:56] <mike@mtcc.com> mic: at this point specific changes in the document would be a whole lot more valuable than sweeping generatizations
[19:06:21] <guenther> phil HB: kind of agree with Dave
[19:06:35] <eric> mic: the changes in SSP are largely because of specific requirements presented to us by senders, who have essentially said that DKIM is not useful to them without it. It isn't because we thought we would see how much we could sneak in.
[19:06:37] <guenther> phil: would like to narrow the target that SSP is to address
[19:06:42] <eric> And I've lost the audio again.
[19:06:56] <guenther> phil: e.g., won't apply to VOIP spam
[19:07:00] <guenther> s/spam/phishing/
[19:07:02] <barryleiba@gmail.com> Eric, your last comment is in the queue. Three others at the mic first.
[19:07:11] <eric> Audio back
[19:07:20] --- amarine has joined
[19:07:33] <guenther> phil: extended validation wasn't defined to stop phishing but rather to address specific modes of phishing
[19:08:00] <guenther> doug: agreed with a fair amount of Dave's review
[19:08:11] --- healthyao has left: Replaced by new connection
[19:08:14] <guenther> doug: overstepped what we had initially intended
[19:08:55] <guenther> doug: cannot effectively sign other headers without throwing out the i= param
[19:09:24] <guenther> doug: strict policy breaks normal usages (resending, etc)
[19:09:38] --- tim.polk has joined
[19:09:41] <guenther> doug: will see proliferation of subdomains in order to split policies
[19:10:27] <guenther> barry: you're worried that proliferation of domains gives opening to phishers?
[19:10:29] <guenther> doug: yes
[19:11:04] <guenther> elliot lear: "IETF is at its worst when it makes sweeping generalizations"
[19:11:17] <guenther> elliot: 35 points, 15 nits, 4 or 5 issues
[19:11:34] <guenther> (dave's review contains that)
[19:11:50] <guenther> elliot: please tease out the issues and get them in the tracker
[19:12:09] <guenther> elliot: several relate to issue 1399
[19:14:10] --- eliot.lear has joined
[19:14:16] --- healthyao has joined
[19:14:25] <guenther> neil schwarzman: big senders use SPF because we tell them to; they will use DKIM if we tell them to
[19:15:09] <guenther> neil: finds statement that "we won't use DKIM because it doesn't do anything for us" to be very strange
[19:15:55] --- marka has joined
[19:16:00] <guenther> neil: if there are senders that are afraid to about SSP, then we need to have them bang on DKIM before moving SSP forward
[19:16:25] --- ogud has left: Replaced by new connection
[19:16:37] <guenther> ?: as a receiver: I will probably use this as part of a scoring mechanisms when it is out
[19:16:42] <eliot.lear> wes hardiger
[19:17:20] <guenther> thanks
[19:17:45] <guenther> wes: having two competting methods for specifying policy will be a problem
[19:17:48] <guenther> (SPF vs SSP)
[19:18:29] <guenther> barry: suggest talking to tony, et al regarding the deployment doc
[19:19:08] <guenther> phil: does not think SSP's status is a stumbling block
[19:19:24] <frank> Integrate the 25 bytes SSP into SPF (the RR type) and be done with it
[19:19:34] <guenther> phil: DKIM is to hidden; need more quotes from receivers
[19:19:52] <guenther> stephen: this was an action item for you from Chicago, no?
[19:19:58] <guenther> phil: whoops...
[19:20:14] <guenther> open issues:
[19:20:22] <guenther> 1382: new RR type?
[19:20:34] <guenther> suggest closing
[19:20:45] <guenther> 1399: clarify i= vs SSP
[19:21:23] <guenther> "...need to provide the exact semantics in SSP of how a receiver determines whether a DKIM sig satistfies the SSP criteria or not"
[19:21:28] --- ogud has joined
[19:21:33] <guenther> think it's clear now (in the draft)
[19:21:55] <guenther> doug: agree it's clear, but people were expecting to use i= differently
[19:22:52] <ddayman> ust lost audio again
[19:22:55] <guenther> doug: not tying things only has a corner case for restricted keys
[19:23:07] <eric> Audio seems to be gone again.....
[19:23:12] <barryleiba@gmail.com> Sigh....
[19:23:24] <mike@mtcc.com> she's dead jim
[19:23:44] <barryleiba@gmail.com> I'll try sending the trouble desk a message again.
[19:23:46] <guenther> jim: yes, the restricted case is the important one
[19:23:58] <guenther> jim: restricted keys are in base, we should not water them down
[19:25:28] <guenther> doug: no way to prevent signing of sender header by restricted key
[19:25:49] <guenther> elliot: this also clarifies how you handle mailing lists
[19:26:03] <guenther> elliot: the ML will break the signature, it's going to resign
[19:26:14] <guenther> elliot: this is how you handle it by marking it all and not strict
[19:26:29] <guenther> dave: repeat comment about concern for delegated signers?
[19:26:47] <mike@mtcc.com> it's coming back up now
[19:26:51] <barryleiba@gmail.com> ok
[19:27:02] <guenther> jim: suppose that example.com has a marketting sender and they want to delegate the address marketting@example.com
[19:27:24] <guenther> jim: so they have a private key that is only authorized for marketting@example.com
[19:28:13] <guenther> jim: the reason for checking the local address is because if someone signs with an address of marketting@example.com but from: ceo@example.com, then it should not match
[19:28:27] <guenther> dave: I thought this was dealt with by g= in the DKIM DNS record
[19:29:11] <guenther> jim: no, this leverages off that
[19:30:20] <guenther> dave: so, we're asking the rest of the world (receivers) to enforce our contract with outsourced sneders?
[19:30:29] <guenther> jim: <missed>
[19:30:37] <guenther> (sorry)
[19:30:42] <mike@mtcc.com> when g= doesn't match, it is not a valid first party signature
[19:30:50] <mike@mtcc.com> and hence the need to consult ssp
[19:32:29] <guenther> doug: think this creates problem that are not needed
[19:32:47] <guenther> moving on
[19:32:54] <guenther> (mike, did you want that repeated?)
[19:33:03] <guenther> 1402: applicability of SSP to subdomains
[19:33:13] <mike@mtcc.com> probably not...
[19:33:32] <guenther> peter cook: is this just about a flag in the SSP or the searching
[19:33:33] <guenther> ?
[19:33:37] <guenther> jim: both
[19:33:40] <eliot.lear> peter koch
[19:34:05] * guenther switches to writing names in IPA
[19:34:48] --- dcrocker has joined
[19:34:59] <guenther> peter: IIRC, suggests to query for the SSP record for the domain, then go do parent except for TLD, or certain other second level domains
[19:35:22] <mike@mtcc.com> MIC: my biggest concern is whether this search algorithm works in reality, ie the way DNS is actually deployed. how do we do that sanity check?
[19:35:33] <guenther> peter: this is not a good idea
[19:36:05] <guenther> stephen: has this been posted to the list?
[19:36:14] <guenther> peter: probably not for this draft
[19:36:36] <doug.otis@gmail.com> Require MX records?
[19:37:09] <guenther> jim: good question
[19:37:34] <guenther> jim: murray, do you have an implementation of this?
[19:37:50] <guenther> msk: of the -01 draft, yes
[19:37:58] <guenther> stephen: experience with it?
[19:38:13] <guenther> msk: no complaints, but not really any feedback
[19:38:42] <guenther> phil: not exactly happy about this
[19:39:15] <guenther> phil: but, given what it would take to do it right, as long as we only have one level of searching, it's probably okay
[19:39:46] <guenther> phil: require caching?
[19:41:31] <guenther> dave: we don't really have community view on this use/misuse of DNS
[19:41:38] <frank> Again, why not integrate the 25 bytes SSP as record in the SPF RR type?
[19:41:44] <guenther> dave: not clear why we have to have this in the spec
[19:42:06] <resnick> Are you guys back on the air audio-wise?
[19:42:19] <resnick> Joel claims to have fixed it.
[19:42:29] <guenther> peter: would like name of I-D, so as to recommend author to the nomcom
[19:42:31] <mike@mtcc.com> it's working now, but i have a long buffer
[19:42:44] <guenther> peter: even one step up may be the wrong one
[19:43:28] <guenther> wes: any time the default is non-zero, you're making a large number of assumptions about what is being published
[19:43:32] --- ddayman has left
[19:43:41] <eric> audio gone again....
[19:43:42] <guenther> wes: people forget this stuff
[19:43:54] <guenther> jim: so the default should be s=0?
[19:43:57] <guenther> wes: yes
[19:44:06] <guenther> stephen: please make suggestion to the list
[19:44:39] <guenther> phil: if you're not going to sign your DNS you can kludge up the SSP records on the fly
[19:44:47] <guenther> (synthetic records)
[19:45:38] <guenther> phil: would be nice to include various things in TLD records
[19:45:44] <guenther> jim: completely out of scope
[19:46:00] <guenther> barry: ...and said by someone working for the company that handles the root
[19:46:08] <guenther> <laughter>
[19:46:17] <guenther> moving closed
[19:46:20] <guenther> moving one
[19:46:24] <eric> negative
[19:46:26] <guenther> (issue closed)
[19:46:27] <guenther> for now
[19:46:37] <guenther> issue 1512:
[19:46:44] <guenther> SSP should not like "all" and third parties
[19:46:49] <guenther> s/like/link/
[19:46:56] <eliot.lear> phil - 1402 is NOT closed.
[19:46:58] <eric> channels 1, 3, 7 are all out
[19:47:01] <guenther> draft is worded ackwardly
[19:47:22] <guenther> elliot: right, I meant "closed for discussion right now"
[19:47:26] <eliot.lear> ack
[19:47:30] <guenther> bad phrasing
[19:47:43] <guenther> if you want stuff, propose to list
[19:47:49] <guenther> 1513: the new handling tag
[19:48:13] <guenther> is there a need for combinations? or should deny/process be side-effects of strict/all
[19:48:16] <mike@mtcc.com> what happened with 1512?
[19:48:20] <guenther> need more discussion
[19:48:22] --- tonyhansen has left: Replaced by new connection
[19:48:30] <guenther> send opinions to the list
[19:48:40] <guenther> we're moving fast due to time constriants
[19:48:56] <guenther> (jim is supposed to be talking at 3 ekrs)
[19:49:13] <guenther> new issue: responsiblity vs validity
[19:49:51] <guenther> dkim base does not make any assertion of correctness of from: field, but SSP checks for a binding
[19:50:19] <guenther> proposal: publishers of SSP MUST ensure that when the signing and from match, that the from is 'valid' authorized
[19:50:33] <guenther> doug: what you're saying is that the i= has been authenticated
[19:50:39] <guenther> jim: only if the from matches the i=
[19:51:02] <guenther> doug: what about a partially restricted key?
[19:51:05] <mike@mtcc.com> this sounds like a deep rathole.... what does valid mean
[19:51:09] <guenther> jim: take it to the list
[19:51:23] <guenther> new issue: granularity of comparison
[19:51:32] <guenther> should it consider the localpart?
[19:51:38] <mike@mtcc.com> audio starting up again
[19:51:44] <guenther> next steps:
[19:51:58] <guenther> issue -02 with feedback in a week or so
[19:52:14] <guenther> would like WGLC mid-dec
[19:53:00] <frank> mid-dec 2007?
[19:53:02] <guenther> #1399 is considered to be still open
[19:53:19] <guenther> frank: uh huh
[19:53:28] <guenther> need to wrap up #1399
[19:53:41] <eliot.lear> taking over for phil
[19:54:01] <eliot.lear> SSP preso by Doug Otis
[19:54:10] <eliot.lear> please refer to the slides
[19:54:21] <eric> audio is back
[19:54:25] <eliot.lear> trying to simplify issues between all and strict
[19:54:36] <eliot.lear> this will cause a lot of normal uses to not work
[19:54:58] <eliot.lear> i= parameter disqualifies signatures generated by g=
[19:55:04] <eliot.lear> so strict would be less strict
[19:55:06] --- Randy has left
[19:55:10] <eliot.lear> TPA-SSP policy extensions
[19:55:17] <eliot.lear> this can be added as an extension
[19:55:25] <eliot.lear> minimize administrative complexity
[19:55:40] <eliot.lear> allow autonomous authorizations
[19:56:03] <eliot.lear> minimize the overhead of TPA
[19:56:30] <eliot.lear> you can use scope parameter to lock down portions of a domain
[19:56:36] --- amarine has left
[19:56:56] <eliot.lear> TPA comes into play whenever SSP has caused a message to be disqualified
[19:57:33] <eliot.lear> this 3rd party signature is authorized by our domain
[19:57:59] <eliot.lear> can vary assertions depending on who's signing
[19:58:06] --- xiaodong has left
[19:58:09] <eliot.lear> any subdomain is a 3rd party signature
[19:58:22] <eric> have we skipped forward to "Transparent and Flexible Policy Compliance"?
[19:58:34] <eliot.lear> now you can partition up your users
[19:58:52] <eliot.lear> (this is TPA-SSP)
[19:58:57] <eliot.lear> w/ Doug Otis
[19:59:08] <fenton> Current slide: "Granularity..."
[19:59:31] <mike@mtcc.com> could we skip back to "Relevance"?
[19:59:34] <mike@mtcc.com> :)
[20:00:21] <eliot.lear> we can't stop spam on large domains where a lot of it is coming from. the larger domains have a conflict of interest. want to minimize the bottom line while at the same time minimizing spam from their users
[20:00:31] <eliot.lear> we have solutions that are free
[20:00:32] <eliot.lear> ""
[20:00:53] <eliot.lear> if this mechanism was available to larger domains, my nhope would be to use it
[20:02:55] <eliot.lear> jim fenton:
[20:03:13] <eliot.lear> all and strict are intended for transactional domains
[20:03:59] <eliot.lear> doug: doesn't quite believe it
[20:04:31] <eliot.lear> murray now being embarrassed...
[20:04:41] <eliot.lear> a warm welcome to murray's parents
[20:04:51] <eliot.lear> auth-results draft
[20:05:05] <eliot.lear> draft status
[20:05:11] <mike@mtcc.com> audio c'est mort
[20:05:19] <barryleiba@gmail.com> Pth.
[20:05:20] <eliot.lear> -09 defines the headers
[20:05:24] <barryleiba@gmail.com> Not enough time to report it again.
[20:05:25] <eliot.lear> header that is
[20:05:33] <barryleiba@gmail.com> Let's just hope it comes back.
[20:05:45] <eliot.lear> added iprev
[20:06:07] --- andrewsullivan has left
[20:06:14] --- healthyao has left
[20:06:18] <eliot.lear> deliberately vague so that iprev has local administrative meaning not global
[20:06:46] <mike@mtcc.com> is this part about authres?
[20:06:54] <fenton> y
[20:07:15] <eliot.lear> murray moving at break neck pace now
[20:07:24] <eliot.lear> esmtp-00 new
[20:07:48] <eric> oh frabjous day, the audio is gone again.
[20:07:54] <mike@mtcc.com> yep
[20:08:19] <eliot.lear> sorry- murray explaining esmtp extension
[20:08:25] <eliot.lear> dave doesn't get it
[20:08:30] <mike@mtcc.com> my feeling is that authres needs a wg home and wider review... it's in a sort of purgatory now
[20:08:31] <eliot.lear> dave to read the draft ;-)
[20:08:45] <eliot.lear> authres has now a shepherd
[20:08:59] <eliot.lear> dave at mic:
[20:09:16] <eliot.lear> from everything i've been able to tell, auth-results is a home run.
[20:09:23] <eliot.lear> "has total mindshare"
[20:09:31] --- xiaodong has joined
[20:09:33] <eliot.lear> but you can lose it.
[20:11:03] <mike@mtcc.com> it might have mindshare, but i doubt we all share the same mind, especially as it hits a wider audience
[20:11:19] <frank> I hope auth-res can get "official" SPF support (needs one more ballot)
[20:11:22] --- xiaodong has left: Replaced by new connection
[20:11:42] <eliot.lear> eliot: doesn't have my mind share
[20:11:45] --- xiaodong has joined
[20:11:47] <eliot.lear> dave: your mind doesn't count
[20:11:49] <eliot.lear> ;-)
[20:12:25] <eliot.lear> eliot: basic issue: default is for border MTAs to trust header and that's not safe. 2821 extension is by default safe
[20:12:36] <eliot.lear> Tony Hansen now presenting overview
[20:12:39] <eliot.lear> at break neck speed
[20:12:39] <mike@mtcc.com> MIC: I think we shouldn't confuse mindshare of geeks doing interops and downstream consumers like mua vendors
[20:12:44] <mike@mtcc.com> oh well
[20:13:09] <eliot.lear> can we ship the overview?
[20:13:23] <eliot.lear> stephen: draft needs more reading
[20:13:28] <eliot.lear> jim fenton: quick comments
[20:13:30] <barryleiba@gmail.com> Sorry Mike... no time to channel you.
[20:13:32] <eliot.lear> needs editorial work
[20:13:47] <eliot.lear> i have trouble with the document where section 4 describes the goals
[20:13:57] <eliot.lear> but then 2 sections later you state here are the goals for dkim
[20:14:04] <eliot.lear> and i can tell who wrote what.
[20:14:19] <eliot.lear> dkim development, deployment, and operations
[20:14:30] <eliot.lear> provides guidance
[20:14:33] <eliot.lear> bcp-like
[20:14:48] <eliot.lear> we don't know yet what the best practices are
[20:15:01] --- xiaodong has left
[20:15:02] <eliot.lear> exactly one comment right now
[20:15:08] <eliot.lear> what to do?
[20:15:34] <eric> audio channel 1 is back, but 7 (dkim) is still dead
[20:15:48] <eliot.lear> now polling who has actually used dkim
[20:15:59] <mike@mtcc.com> i think there is some fear about rehashing very old arguments on overview
[20:16:01] <eliot.lear> and now charging those who raised their hands to read the document
[20:16:08] <mike@mtcc.com> and that's why nobody's chiming in
[20:16:10] <eliot.lear> q&qa
[20:16:17] <eliot.lear> that's it
[20:16:23] <mike@mtcc.com> buffering again
[20:16:30] <eliot.lear> murray back at the mike
[20:16:35] <eliot.lear> DKIM Reporting
[20:16:38] --- resnick has left
[20:16:48] <eliot.lear> senders will want to know when their brands are being violated
[20:17:01] <eliot.lear> they want to know that their brand is under attack
[20:17:17] <eliot.lear> they want to know if what they're doing simply doesn't work
[20:17:29] <eliot.lear> implementors want forensic data
[20:17:35] <eliot.lear> where did the body get screwed up?
[20:17:45] <eliot.lear> Issues
[20:17:52] --- doug.otis@gmail.com has left
[20:18:02] <eliot.lear> you can get clobbered with volume
[20:18:06] <eliot.lear> requirements
[20:18:20] <eliot.lear> based on ietf-dkim consensus, senders need to be able to indicate that they want these reports
[20:18:32] <eliot.lear> need to specify where the reports should go, and what format they should be in
[20:18:59] <eliot.lear> add r= tag to DKIM and SSP
[20:19:01] <mike@mtcc.com> MIC: i'd be really concerned about security of this: reflection, amplification, data leakage, etc.
[20:19:18] --- dcrocker has left
[20:19:54] --- semery@jis.mit.edu has left: Disconnected
[20:20:54] --- ryu has left: Computer went to sleep
[20:21:04] --- eliot.lear has left
[20:21:05] --- tim.polk has left
[20:21:08] --- fenton has left
[20:21:23] --- barryleiba@gmail.com has left
[20:27:41] --- mike@mtcc.com has left
[20:28:02] --- marka has left
[20:30:48] --- eric has left
[20:33:03] --- jlcjohn has left
[20:36:44] --- ogud has left: Replaced by new connection
[21:04:36] --- guenther has left
[21:40:22] --- andrew.daviel has joined
[21:43:39] --- andrew.daviel has left
[21:58:26] --- fujiwara has left
[23:17:47] --- frank has left
[23:33:16] --- xiaodong has joined
[23:34:36] --- xiaodong has left
[23:35:46] --- healthyao has joined
[23:43:25] --- healthyao has left