[10:18:57] --- yakovsh has joined
[10:18:57] --- resnick has left: Lost connection
[10:23:01] --- yakovsh has left
[11:46:54] --- yakovsh has joined
[11:47:08] --- yakovsh has left
[14:02:02] --- anewton has joined
[14:02:18] <jlcjohn> Hi, andy
[14:02:18] --- tonyhansen has left: Lost connection
[14:02:18] --- wrs1864 has left: Lost connection
[14:03:00] --- mrose has joined
[14:03:42] <mrose> meeting starts in a few minutes (coordinating getting people into the meeting)
[14:04:08] <jlcjohn> ...to be expected...
[14:16:36] <mrose> meeting starts at 12:30 us/pacific
[14:17:07] <jlcjohn> thx
[14:24:01] <mrose> interim meeting begins
[14:25:21] --- hardie has joined
[14:26:01] <mrose> agenda: agenda bashing, notes from chair, semantics, bounce address tag validation, 30% solution, dns record type, syntax
[14:26:06] <mrose> bashing begins
[14:26:08] <mrose> round of introductions
[14:27:29] <mrose> about 20 people in the room
[14:28:16] <mrose> expectation is that the dns stuff will take place tomorrow
[14:28:58] <jlcjohn> :^)
[14:29:27] <mrose> dcrocker: re the 40% solution introduces some issues on reputation, let's be sure to discuss those issues
[14:29:34] <mrose> pete: i have a slide on that too
[14:30:19] <mrose> dcrocker: how much consistency exists between peoples' understandings as to what each mechanism solves? it is probably low.
[14:31:52] --- mengwong has joined
[14:32:25] <mengwong> <rts>moo.</eot>
[14:32:43] <mrose> dhc> a question we need to answer for each proposal: what problem is it solving, specifically.
[14:33:35] <mrose> dhc> we need to distinguish the mechanisms in the proposals in terms of what they're solving.
[14:34:54] <mrose> andy>let's talk about it after the dns stuff, since both are ratholes.
[14:35:05] <mrose> andy>any other agenda bashing?
[14:36:16] <mrose> andy>so, we're talking about semantics today; other stuff tomorrow.
[14:36:22] <mrose> andy>bashing over.
[14:36:50] --- resnick has joined
[14:36:59] <mrose> andy> chair notes: please be courteous to others, remember that we are here to work towards concensus.
[14:37:41] <mrose> [amusing note to people not in the room: everytime someone types something to this chatroom, andy's mac chimes...]
[14:38:20] <mrose> andy>chair notes over
[14:38:42] <mrose> andy>dcrocker to discuss btag ideas
[14:39:01] <mrose> dhc> answers the question "is a bounce address valid"
[14:39:08] <mrose> dhc> valid = authorized by addrss owner
[14:39:43] <mrose> dhc> address owner = domain owner of the address, by "owner", we mean administrator
[14:41:03] <mrose> ted> by bounce address, you're referring is 821.mail-from
[14:41:05] <mrose> dhc> correct
[14:41:51] --- RBarclay has joined
[14:42:13] <mrose> dhc> approach is to sign the bounce address, e.g., hash(address+timestamp+secret)
[14:43:02] <mrose> dhc> as = <local-part> "/" <sig-type> "/" <sig-value> (sig-type is a keyword)
[14:43:41] <mrose> dhc> recall that <local-part> is opaque to the internet, it is meaningful only within the domain specified by <domain-part>
[14:45:06] <mrose> ted> it must be preserved, but need not be understood globally
[14:45:32] <mrose> unk> what is the difference between this and SRS?
[14:45:41] <mrose> dhc> i can't speak to that right now
[14:46:33] <mrose> dhc> getting back to exposition...
[14:46:56] <mrose> dhc> when a bounce comes back, the mta asks is this a valid local-part (a valid use local-part)?
[14:47:45] <mrose> dhc> somewhat helpful that the data we're talking about is in the 821 mail-from, and is less visible than 822 stuff
[14:48:53] <mrose> unk>so this about avoiding joe jobs
[14:49:28] <mrose> phb> is this really a standards activity, since it's all local?
[14:51:14] <mrose> dhc> excellent point...
[14:51:25] <mrose> dhc> i will answer it in a bit
[14:51:45] <mrose> unk>don't you need certificates and such?
[14:52:05] <mrose> dhc> not in this mode, because the originating domain is the only one who needs to know the secret, etc...
[14:53:16] <mrose> unk> seems similar to syn-cookies (e.g., three way handshakes)
[14:53:20] <mrose> dhc> maybe.
[14:54:01] <mrose> phb> it's the same thing as the proof of consent protocol suggested earlier for mailing subscriptions
[14:55:03] <mrose> dhc> that was the private use approach (at a high-level)
[14:56:19] <mrose> dhc> i think this needs to be standardized because within a single domain, there may be multiple pieces of software doing this stuff
[14:56:46] <mrose> dhc> part deux: can the generating of a bounce determine if the address will be a valid bounce address
[14:57:06] <mrose> dhc> need cert stuff, etc., for that, e.g., domainkeys
[14:57:36] <mrose> dhc> could be problematic, but that risky part can fail, and we still have something useful
[14:59:13] <mrose> unk> in a 3rd-party MTA environment, how do you manage the shared secret?
[15:01:31] <mrose> phb>if doing things at the 821 level and PKC, you need to be able to do things immediately, either you restrict the scope of what you doing (and having no advantage over other approaches) or you end up with full-blown s/mime or pgp stuff
[15:01:52] <mrose> phb>it doesn't matter where the signature goes, that trade-off pops up
[15:02:37] <mrose> rbs> protecting against replay attacks is the hard thing, because you're not tying anything to the message...
[15:03:08] <mrose> dhc> it's an issue, the timestamp may not deal with it
[15:03:53] <mrose> dhc>the private approach stops joe jobs at the destination, the public approach stops joe jobs at the source
[15:04:31] --- resnick has left: Disconnected
[15:04:55] --- resnick has joined
[15:04:57] <mrose> jim> i also wanted to talk about some unilateral actions you an take in this regard!
[15:06:20] <mrose> does anyone who's not here in campbell have any questions on this?
[15:06:50] <jlcjohn> was anything advertised in DNS?
[15:07:19] <mrose> nope. basically, it's a local mechanism that software within a domain can implement.
[15:07:25] <jlcjohn> thx
[15:09:00] <mrose> phb> if the public scheme is all about avoiding the bounce, it's hard to imagine someone doing the PKC rigamaroo to just avoid sending a dead bounce...
[15:10:11] <mrose> wayne>this looks like last year's SRS or anti-bounce proposals.
[15:11:05] <mrose> wayne> there's a 64 octet limit on the local part enforced on some systems; some mtas reject the slashes in the local part, etc.
[15:12:00] <resnick> (Side note: The editor of RFC 2822 would love to hear about which servers have such limits.)
[15:12:10] <jlcjohn> :^)
[15:13:24] <mrose> andy> is this within the scope of merit? not really, but it may shape the discussions.
[15:13:34] <mrose> jim>
[15:13:47] --- resnick has left: Replaced by new connection
[15:13:47] --- resnick has joined
[15:15:41] <mrose> jim> here's some ideas on the same problem (joe job variations)
[15:16:38] <mrose> jim> there things that can be done unilaterally do to deal with these issues
[15:19:26] <mrose> jim> here's another scheme: outgoing mta adds a header (e.g., "NDR-Verifier") whose value is a hash of the concatenation of a secret, mail-from, date, msg.
[15:19:52] <mrose> jim> NDNs tend to include headers of the email being bounced, and MTA receiving the NDN can do the comparison
[15:20:50] <mrose> jim> there are a lot of possibilities for unilateral behavior, not really suitable at this time for standardization, more experimentation needed
[15:21:23] <jlcjohn> But it'd be nice for receiving MTA to know about it.
[15:21:53] <mrose> do you have a question for jim?
[15:22:20] <mrose> unk> perhaps this is an ietf bcp docment.
[15:22:33] <jlcjohn> use your judgment: "How does receiving MTA know this is happening?
[15:23:35] <mrose> we're moving onto a new speaker, rather than disrupt the flow, why not email him - jimlyon@microsoft.com
[15:23:42] <jlcjohn> OK
[15:23:58] <mrose> now onto pete resnick and the 30% solution
[15:24:50] <mengwong> one last note re the envelope signing, for the record, the SPF community has spent some time considering this kind of approach, which we call Signed Envelope Sender or SES, and we are generally in favour of this sort of scheme for validating bounces and helping to limit the damage of joe-job floods. We haven't considered the public-key version of it, but we have considered the unilateral private-secret version, and it is a good complement to other approaches.
[15:25:06] <mrose> pete> 2 minute review - we're talking purely semantics (any use of syntax is just for exposition).
[15:26:17] <mrose> pete> receiving server gets "claimed" domain name, receiving server looks up "claimed" domain to get 1 or more MARID records, from those records you compose a list of legitimate and illegitimate domain nams or addresses, receivinger server checks IP address of sending server
[15:27:01] <mrose> MARID records must contain domain names that resolve to IP addresses or IP address ranges
[15:27:32] <mrose> for example, could be resolved to A, AAAA, a new "range" record, or a CNAME record
[15:28:17] <mrose> MARID records might contain IP addresses or IP address ranges
[15:29:10] <mrose> MARID records must contain some flags to indicate (il)legitimate, source field (e.g., mail-from, ehlo, etc.), resolution type (e.g., domain name, mx resolution)
[15:30:07] <mrose> procedure: check for the client MTA address in a particular set legitimate or illegitimate (but not both)
[15:32:12] <mrose> unk>does this imply that the set of IP addresses is for only SMTP?
[15:32:36] <mrose> pete> my view is that it's only for SMTP
[15:38:16] <mrose> [sorry, i'm trying to find the thread that folks are arguable...]
[15:39:31] <jlcjohn> Why not do all Pete's 30% work at the DNS server? Wouldn't it be better for a buggy implementation to affect the sender directly?
[15:40:05] <mrose> jim> you're partitioning ip addresses into three sets: good, not good, and everybody else
[15:42:36] <hardie> Pete: discussion is leading to discussion of whether an explicit "known bad" is valuable
[15:43:07] <anewton> phil: discussing legit mail originating from each address.
[15:43:51] <anewton> phil: probabability of the sets, arguing known-bad is actually likely to be leget.
[15:43:54] <hardie> known bad set might be less bad
[15:45:34] <anewton> hardie: zone admin will be able to make assertions about where mail will come from.
[15:46:40] <anewton> hardie: if the assertions are wrong, that is not a MARID issue
[15:47:48] <anewton> phil: there will be another mechanism for reporting bad nets or bad net actions
[15:48:07] <mrose> pete> can we table the question as to whether there is a illegitimate set for right now?
[15:48:26] <mrose> can we "put it aside"?
[15:49:06] <mrose> unk>if you have more than one set, you may still need negation
[15:50:30] --- gordonf has joined
[15:50:39] --- eric_allman has joined
[15:51:13] <hardie> eric_allman: you were on our "attending" list; will you be here in person tomorrow?
[15:52:20] <eric_allman> that's my plan. i always knew i couldn't make it today....
[15:53:26] <hardie> okay
[15:53:31] <hardie> eric_allman: okay
[15:56:07] <mrose> jim> so, to summarize: 1. the domain owner expresses which IP addresses are expected to send mail containing that domain; 2. this is done by splitting the world into 3 states; 3. the only inputs are the domain name (and perhaps the local-part) too.
[15:56:20] <mrose> jim> so this is either spf or caller-id after you take out the details
[15:58:17] <mrose> pete> part one: we want domain owners to be able to express that certain ip addresses are allowed to use, somewhere in the mail transaction, that domain/subdomain (e.g., to include localpart using an soa-like hack)
[15:59:41] <mrose> pete>let's defer part two for a minute (anything beyond legitimate use)
[15:59:47] <mrose> apparently not, more talk
[16:04:05] <mrose> pete> three possibilities: 1. express legitimate, 2. express everything else illegimate, and controverially, 3. only certain things are illegitimate
[16:05:16] <mrose> unk> illegimate can be specified only using set subtraction from legimate.
[16:10:33] <jlcjohn> Are we arguing _whether_ everything not mandatory must be forbidden?
[16:11:05] <mrose> it is unclear to me what people are arguing about...
[16:11:14] <jlcjohn> ;^)
[16:11:22] * gordonf is glad to be out of striking distance
[16:12:09] <mrose> ed> it's hard for me to understand how someone manages the explicitly bad addresses
[16:13:39] <mrose> ed> having admins keep track of all the places they don't want things to come from will be a management problem because they'll forget to remove entries
[16:13:48] <hardie> I am concerned that people are confusing "the set created by some assertion that a block of addresses is known not to be valid" with "the set which would be created by a complete set of asserts about blocks of addresses which are not valid"
[16:14:02] <hardie> The first may be useful, even if the second is not possible.
[16:14:15] <gordonf> "they'll forget to remove entries" - couldn't this be solved with dynamic DNS and a "smart" MARID implementation?
[16:15:00] <jlcjohn> Dunno about "solved"; but certainly "eased".
[16:15:08] <gordonf> ok, "eased" is probably better
[16:15:08] <mrose> pete> people should use illegitimate sets only for things that are owned by them
[16:17:17] <mrose> dan>there are three policies: good, bad, and i don't know; so, do we specify each of these three things?
[16:19:18] <mrose> dan> if you don't have "this is bad" listed, you'll get repeated queries.
[16:20:29] <gordonf> Dan: WOuldn't you get repeated queries anyway? From multiple sites? What if "bad" becomes "i don't know" or "good" and you want that change tor each folks?
[16:22:01] <mrose> greg> inputs: ip address, domain-name, maybe local-part; output: good/bad or good/bad/unknown - that's the question.
[16:23:35] <mrose> pete> the question is: do we need to be able to express all three independently at the same time? (the alterative is that one of good/bad/unknown must be empty)
[16:23:56] <mrose> independently hums a little louder
[16:24:02] <mrose> phil> i don't like humming
[16:24:35] <mrose> ed> not spoken here is what folks do with that
[16:26:04] --- gordonf has left
[16:30:19] <jlcjohn> Did the hum (seem to) settle _anything_?
[16:30:27] <mrose> no, of course note.
[16:30:34] <mrose> no, of course not.
[16:30:48] <jlcjohn> sigh...
[16:31:25] <mrose> jim> onto part three, the inputs.
[16:31:36] <hardie> I thought I heard a hum for the idea that each of "known good" "known bad" and "not known" must be idependently expressable in a MARID RR (that is, you can make an assertion directly about each case, rather than some of them being inferred)
[16:31:40] <hardie> Did I get that wrong?
[16:32:57] <mrose> hardie - to my ear, i didn't get much of a sense either way. one was louder than the other, but it's closer to florida in '00 than reagan in '80
[16:33:14] <jlcjohn> I'm not there, of course, but my impression was different: whether it was _permissible_ to express three sets by any ruse.
[16:33:45] <mrose> hardie - i don't disagree with your characterization, just that it didn't seem that substantive
[16:34:09] <mrose> phil> need to flag use of the SOA-hack, right?
[16:34:58] <mrose> ed> if you are expecting to use the SOA-hack, then i you sign your zone, do you really want to expose all your email addresses?
[16:35:43] <mrose> meeting resumes at 1500 us/pacific
[16:35:51] <jlcjohn> thx
[16:36:14] <eric_allman> sorry for being stupid, but what's the SOA hack?
[16:36:53] <jlcjohn> <user>@<domain> as <user><dot><domain>
[16:37:01] <eric_allman> ah, thx
[16:37:15] <jlcjohn> from the way contact is expressed in SOA RR
[16:37:57] <eric_allman> right. i've never understood how you translate first.last@dom.ain reversably. probably escape the first dot
[16:38:41] <jlcjohn> hopefully, DNS is maintained by people clueful enough to know better...
[16:38:57] <eric_allman> yeah, hopefully..... hah!
[16:57:27] --- gconnor has joined
[16:57:54] <mrose> meeting resumes, now talking about the 40% solution
[16:58:22] <mrose> pete> receiving server gets "claimed" domain name, looks up "claimed" domain (with prepended type indicator?)
[16:58:42] <mrose> pete> get back list of "egit" and "maybe lebit", along with a flag saying "all known" (and reputation service)
[16:58:50] <mrose> pete> if found, prepend textual ip address and source field indicator
[16:58:57] <mrose> pete> lookup separate record
[16:59:15] <mrose> pete> get back specific "legit", "maybe legit", "maybe illegit", or unknown
[16:59:24] <mrose> pete> lookup reputation service
[17:02:24] <jlcjohn> (Are we back to how many sets can dance on the head of a pin?)
[17:06:19] <anewton> We are on 40% solution.
[17:07:02] <jlcjohn> Is Pete talking -- or taking questions?
[17:07:39] <anewton> he is talking
[17:08:02] <jlcjohn> OK -- I'd like to comment on any questions...
[17:08:17] <anewton> ok, just let us know.
[17:08:39] <jlcjohn> (Alas, I need to hear about them first...)
[17:10:07] --- dcrocker has joined
[17:10:21] <jlcjohn> hi Dave
[17:10:53] <dcrocker> upper/lowercase ssid. sheesh. finally got wireless working.
[17:11:03] <jlcjohn> :^)
[17:11:18] <anewton> question asked, it start out in SPF mode and then goes into DMP mode.
[17:11:20] <anewton> ?
[17:11:32] <jlcjohn> Can Dave take that one?
[17:12:02] <jlcjohn> It really never is anywhere close to SPF mode.
[17:12:38] <jlcjohn> And, if I heard correctly, Pete suggested the reverse-lookup happened regardless of the first SRV lookup -- not so.
[17:13:31] <jlcjohn> The intent is that the first SRV typically returns enough to say yes or no on the HELO.
[17:14:05] <jlcjohn> Then we proceed to the reputation lookup -- mostly out of scope...
[17:14:06] <gconnor> slide now visible: "40% solution, My Read" ** Receiving server gets claimed domain name **Looks up claimed domain name (optionally with prepended "type" indicator) ** Get back list of "legit", "maybe legit" along with a flag saying "all known" (and "reputation service"?)
[17:15:00] <anewton> Concern was raised about DNS load for the multiple lookups.
[17:15:31] <gconnor> slide contd: **If not found, prepend textual ip address and source field indicator **Look up separate record **Get back specific Legit, known bad, or unknown
[17:15:41] <anewton> It was mentioned that one benefit is that it hides the good and bad records which is not the case for other proposals.
[17:15:48] <jlcjohn> Typical load is one SRV lookup before reputation; maximum load is about four.
[17:16:38] <gconnor> Question was: does "not found" mean "the IP was not in the list" or "there was no record at the first lookup"
[17:17:03] <anewton> Also a concern about DNS referral chains causing latency.
[17:17:18] <jlcjohn> "Not found" on slide means IP was not on list and list was not complete.
[17:18:11] <jlcjohn> Not certain about latency -- can't see how it would be worse than MX, offhand.
[17:21:38] <anewton> The comment on this concern was that multiple serial lookups are the issue.
[17:22:25] <jlcjohn> IMHO, multiple serial lookups are rare.
[17:23:23] <gconnor> jlc- Good... there was some concern that if a second lookup is always required, that would be bad
[17:26:48] <anewton> The confusion is about the first lookup, vs the lookup on the IP address. They want to know why even do the first.
[17:27:18] <jlcjohn> Reasonable question...
[17:28:38] <jlcjohn> One answer is that I believe there's a need for the "MARID level" showing what portion of our specification that domain supports.
[17:29:20] <jlcjohn> Also, whether there are extensions and reputation services listed.
[17:30:08] <jlcjohn> But, I'm not averse to coding such information in a reverse-lookup.
[17:30:12] <gconnor> Getting some pushback on the second lookup being expected/required.
[17:31:36] <gconnor> microsoft person whose name I don't know says: I don't like the idea of automatically doing the second, ip query... I would rather have some code in the first record that tells me if the second lookup is required.
[17:31:50] <anewton> Jim Lyons
[17:31:54] <jlcjohn> ... which is certainly the intent!!!
[17:32:00] <gconnor> good!
[17:35:42] <gconnor> Dan> Any "second" or "dependent" lookup is bad, for performance
[17:36:11] <jlcjohn> ... if frequent...
[17:37:31] <gconnor> ...talking about reputation servers and whether the hint should even be followed
[17:38:27] <gconnor> PHB shouting at dave now
[17:38:30] <jlcjohn> Good discussion. I'd let it run.
[17:39:21] <jlcjohn> IMHO, it's _important_ that the reputation hint be there; but not terribly important whether each receiving MTA asks for it.
[17:41:19] <gconnor> Dave says, I think, that reputation services are a bit of a rathole and not really core to lmap... and that we don't have enough ammunition to "guess" right now at how people are going to use them. So, let's define some useful mechanisms and let people use them as they see fit
[17:41:40] <jlcjohn> I agree.
[17:42:53] <jlcjohn> The important point is that if the receiving MTA trusts the reputation service, that can translate into trust of what the sending MTA has done.
[17:43:17] <gconnor> phil's objection was, we DO have 10 years experience with the reputation services.
[17:43:47] <jlcjohn> Hmm...
[17:44:19] <jlcjohn> Clearly, reputation services have to make _someone_ unhappy.
[17:44:26] <eric_allman> which reputation services? rbls?
[17:44:31] <gconnor> Pete> Do we think that the reputation hint would be needed? Phil> Yes, adamantly. (omitting phb's threat to derail the process if this is not given)
[17:44:40] <jlcjohn> But if they make one party happy, we're ahead.
[17:45:23] <jlcjohn> I think the reputation hint is essential, once we get past about a dozen services.
[17:45:49] <jlcjohn> And I think we're going to have to deal with hundreds.
[17:46:12] <gconnor> Dave's previous point> we shoudl probably start using the word "accredication" when we mean "good", not reputation
[17:46:47] <jlcjohn> I refuse to argue which word is better...
[17:47:03] <eric_allman> accreditation != positive rep
[17:47:48] <jlcjohn> I _would_ hope, under whatever name, the service reports some good and some bad.
[17:47:57] <eric_allman> agreed
[17:49:26] <gconnor> Well... in the case where you decide to put hints in your marid record, you would probably not want to point out who has *bad* info about you ;)
[17:49:48] <jlcjohn> ;^)
[17:50:12] <eric_allman> natch. the spammers are of course going to create their own reputation service, and guess what it's going to say?
[17:50:37] <jlcjohn> spammer == excellent
[17:50:55] <eric_allman> give that man a prize
[17:51:03] <jlcjohn> (but the recipient's service may not agree)
[17:51:52] <eric_allman> yeah, which is why the recipient has to pick the reputation service, not the sender. hints are OK, but they can't be trusted by themselves. reputation services may have reputations.
[17:52:47] <gconnor> Right, so my point was, if the (purported) sending domain has a pointer to "some" service that would probably be an "accreditation"
[17:53:55] <eric_allman> well, i guess that depends on how you define accreditation. people seem to be using the word differently. habeus and bonded sender strike me as being the most traditional form of accreditation.
[17:55:53] <gconnor> Dave> reputation is good, but should be considered separately from "is it forged or not"...
[17:56:35] <jlcjohn> I agree -- except that reputation is often adequate.
[17:57:06] <jlcjohn> For example, we probably can deal with a domain letting one forgery through per million good emails.
[17:57:34] <eric_allman> personally i prefer reputation over accreditation. it may be that accreditation is a way to "buy" an initial reputation, but that the reputation then runs freely from there.
[17:57:35] <gconnor> (I think the reputation hint is a rathole. I would like to suggest that we handwave that and say "Reputation would be an extension that some people would find useful. Extensibility is something we already know we want.")
[17:58:00] <hardie> We need to be very careful about handwaving to extensibility.
[17:58:34] <jlcjohn> Careful, yes... but neither do we need to get it exactly right the first pass.
[17:58:41] <dcrocker> jlc - rep is entirely separate from forgery. let's say that ebay.com has a wonderful rep. that does nothing to deal with lots of people forging use of the name. (in fact, the good rep _attracts_ forgers./
[17:58:46] <gconnor> I meant, handwave for now, since it's not 100% core to "is this IP allowed to use this Domain".
[17:58:58] <hardie> There are definitely ways in which this could be structured that either 1) extensibility would be very, very hard or 2) extensibiltiy would undermine the basic mechanism to the extent that an unknown extension means you don't know anything from the base records
[17:59:13] <jlcjohn> Dave: sorry, didn't realize we were talking RFC2822.
[17:59:16] <hardie> So handwaving to extensibility has to be bounded.
[17:59:46] <dcrocker> jlc - i wasn't thinking only 2822.
[18:00:15] <eric_allman> hardie: yep.
[18:00:18] <jlcjohn> Dave: IMHO 2821 MAILFROM need only verify enough to bounce reasonably.
[18:00:23] <dcrocker> ted - we need to be clear what the 'extensible mechanism' does and what benefit there is.
[18:00:45] <dcrocker> jlc - the problem with mailfrom TODAY is forging, not reputation.
[18:02:30] <jlcjohn> Dave: yes, MAILFROM is forged: but the problem at envelope time is simply whether the bounce address is useful.
[18:03:43] <gconnor> Dan is explaining why "chained" or "dependent" or "followup" queries are bad for performance,
[18:03:51] <jlcjohn> Greg: I'm convinced the reputation hints are essential; but that doesn't mean we need to say they even SHOULD be used.
[18:06:10] <gconnor> Dan objected based on, when the hint comes back, then a second query is required. Ideally we want to fire off all dns queries at once and wait for them to come back, then a second query happens *after*
[18:07:31] <jlcjohn> I already consider the query for the hint to be optional.
[18:08:00] <jlcjohn> Personally, I'd probably query and log.
[18:16:42] <dcrocker> accreditation record: take a look at <http://brandenburg.com/specifications/draft-crocker-marid-srvvouch-00.html> for definition of an independent pointer.
[18:18:50] <mengwong> i'm a little puzzled that people are debating whether accreditation services are useful, when microsoft today is checking ironport's bondedsender, who has active customers.
[18:19:11] <jlcjohn> Welcome to America!
[18:19:16] <mengwong> the point of adding an accreditation extension is to save receivers the trouble of querying accreditation services for domains that don't have accreditation.
[18:19:32] <gconnor> Agreed.
[18:19:52] <mengwong> if domains that are accredited by bondedsender can give receivers that hint, then there's no need for those receivers to query bondedsender for all incoming mail. that is all.
[18:20:17] <jlcjohn> That's not the _only_ point, but it's a good one.
[18:20:42] <gconnor> I would very very much like to stop talking about reputation now.
[18:21:11] <jlcjohn> In fact, I expect receiving MTAs with enough traffic to justify all this worry to query downloaded databases.
[18:21:16] <mengwong> i don't think we've gained any new insight since the last time i posted http://www.imc.org/ietf-mxcomp/mail-archive/msg01098.html
[18:21:44] <hardie> what is an accreditation backwash?
[18:22:45] <gconnor> Can I ask the chair to clarify what question we are trying to answer :)
[18:23:09] <mrose> i want to know if we can just call this a future extension and move on.
[18:23:21] <gconnor> I agree.
[18:24:10] <jlcjohn> The only thing I want is to define a way to publish hints. I don't care one whit what people do with them.
[18:24:45] <gconnor> In the rathole-prevention department, it's useful to remind people what the question currently is. People will respond to each other endlessly if we go with free-association method.
[18:25:46] <mrose> dan> we can leave this reputation as something for additional extensions, etc.
[18:26:05] <mrose> dan>marid doesn't need to be delayed because of this.
[18:26:15] <gconnor> Right. Saying "we want extensibility" should be sufficient for the current context
[18:26:22] <hardie> If you say you will include a URI for the reputation service, please limit the number of schemes you plan to support; a generic "any scheme" inclusion tends to run into problems (is mailto: okay? being the classic question).
[18:27:03] <jlcjohn> I'm happy with any way to publish. In any case, I agree the meeting should move on.
[18:27:48] <gconnor> s/future/optional/
[18:28:10] <jlcjohn> I'm even happier!
[18:28:46] <mrose> phil> all we need to agree is to include a domain name and that it's associated with an accreditation for omar's camel?
[18:29:00] <mrose> larry> could you flowchart what the hint does for me?
[18:29:26] <jlcjohn> On the mailing-list, I'd be happy to.
[18:29:58] <jlcjohn> And, re the domain-name, that's plenty to publish.
[18:32:33] <gconnor> jlc: larry was asking phil actually
[18:33:05] <jlcjohn> Asking Phil to do it now???
[18:33:43] <gconnor> Phil drew something on the board but it isn't really a flowchart
[18:41:12] <mrose> "the ability to specify a hint which gives a domain that gives further information with respect to accreditation (and could be in a separate record)"
[18:41:55] <mrose> a co-chair declares that there is a sense in the room that this is an acceptable requirement and no one finds it absolutely untolerable.
[18:43:32] <mrose> 10 minute break, resume at 1700 us/pacific, to see how various proposals address various issues, hard stop at 1800 us/pacific
[18:43:43] --- hardie has left
[18:43:44] <jlcjohn> thz
[18:44:10] <jlcjohn> (That's Thanks, I was falling asleep... ;^)
[18:54:27] <mrose> resume.
[18:54:33] <mrose> now time to compare semantics between proposals
[18:57:24] <gconnor> Doug> discussing doug/dave joint proposal using SRV records
[19:01:51] --- hardie has joined
[19:06:53] <gconnor> I was going to summarize but I don't understand what doug is saying
[19:12:39] <mrose> summary: input=ehlo, output=ip address, pen/closed, bridge to use if ehlo doesn't match mail-from
[19:16:24] <gconnor> Switching to Dave Crocker
[19:17:04] <gconnor> Assertion: there are "channel-based" and "content-based"... things (proposals? identities?)
[19:17:39] <gconnor> dave> helo is "channel based" because it has to do with the immediate transaction.
[19:18:32] <gconnor> dave> MAIL FROM is "content-based" because it is related to the Sender: (Mail From is set by the person listed in Sender;)
[19:20:11] <gconnor> Ted> is Mail From not a channel-based identity? It's part of the "return channel"...?
[19:21:27] <gconnor> Dave> No, MAIL FROM is not *directly* related to the *current* transaction [hopefully I am summarizing correctly :/ ]
[19:23:20] <gconnor> Dave> There are problems with misbehaving MTAs. We would like to know if the MTA is "authorized to act as an smtp client"
[19:27:11] <gconnor> Dave> Service Vouching - the host at this domain name (mail1.example.com) is authorized to use this service (e.g. smtp)
[19:27:49] <gconnor> We will come back to this later
[19:27:58] <gconnor> Switching to Sam S.
[19:32:36] --- RBarclay has left
[19:33:42] <gconnor> Sam> MAIL FROM: <user/TAG@domain.com> The idea is that there is some kind of signature in the mail from itself (a la SRS/SES)
[19:34:41] <gconnor> Discussion re: signed sender addresses are vulnerable to replay attacks.
[19:39:27] <gconnor> phb> The "forwarding agents" should be agents with a known relationship to the receiver. The receiver should have explicitly opted in to that forwarding relationship
[19:48:16] <mengwong> here's my stab at a requirements document. http://archives.listbox.com/spf-discuss@v2.listbox.com/200405/0139.html
[19:49:07] <mrose> wrapping up: meeting tomorrow resumes at 08:30 us/pacific
[19:49:47] <mrose> people may show up as early as 08:00 us/pacific
[19:50:22] <mrose> ted> the charter does not allow the wg to "break" core email functionality.
[19:50:54] <mrose> ted> any solution that this group comes up with has to be bounded with an applicability domain.
[19:52:55] <mrose> mike> in other words, we don't have to solve all problems, but we shouldn't break things
[19:53:23] <mrose> adjourn.
[19:53:35] --- anewton has left
[19:53:38] --- gconnor has left
[19:53:51] <eric_allman> bye all, see you tomorrow (live!)
[19:53:54] --- eric_allman has left
[19:54:07] --- mrose has left
[19:59:10] --- hardie has left
[19:59:22] --- resnick has left: Disconnected
[20:00:21] --- jeff has joined
[20:11:50] --- mengwong has left: Disconnected
[20:13:22] --- dcrocker has left: Disconnected
[21:21:40] --- jeff has left
[22:45:26] --- resnick has joined
[23:09:49] --- resnick has left: Replaced by new connection
[23:36:18] --- resnick has joined
[00:00:16] --- resnick has left: Disconnected