[12:54:27] --- wrs1864 has joined
[14:40:34] --- MatthewElvey has joined
[14:42:59] --- resnick has joined
[14:48:31] --- anewton has joined
[14:49:53] --- tonyhansen has joined
[14:50:09] --- mengwong has joined
[14:50:58] --- mrose has joined
[14:52:35] <mrose> we start in three minutes...
[14:56:13] <mrose> meeting begins, any presiding
[14:56:47] <resnick> "any"? You mean "andy"?
[14:56:58] <mrose> sorry, new keyboard.
[14:57:07] <anewton> We would like to start off this jabber conference with the 30% solution that Pete has given us.
[14:57:20] * resnick dons his tomato-resistant suit
[14:57:58] <anewton> So, we would like to start with a simple question: given Pete's proposal, what are the MUST HAVE's that are not present.
[14:58:12] <anewton> We'll use the standard protocol we have been using in the past.
[14:58:48] <anewton> as a reminder: <rts> to signal you want to talk. You will be given a <cts> when you are to start talking. Use <eot> to signal you are done talking.
[14:59:22] <wrs1864> <rts>
[14:59:24] <mrose> rts
[14:59:33] <anewton> And we can give two people the floor simultaneously so that q&a can occur.
[14:59:41] <anewton> cts - wrs
[14:59:45] <wrs1864> I suspect that my opinion of "must haves" are very different from others...
[14:59:48] <wrs1864> <eot>
[15:00:07] <anewton> cts - mrose
[15:00:38] <mrose> just to get things on a baseline, could we ask pete to enumerate the semantics in his proposal? eot
[15:00:50] <anewton> good idea. Pete?
[15:01:06] <resnick> Is there anyone on the line who hasn't read it, or is there some specific question?
[15:01:09] <resnick> <eot>
[15:01:36] <mrose> i just want the enumerated list of objects
[15:01:47] <resnick> Check
[15:01:49] <resnick> Here goes:
[15:02:08] <resnick> - The client (sending) SMTP server's IP Address (C) - The domain portion of the MAIL FROM command (F) - The domain returned in a MARID record (D) - The set of addresses that are legitimate (L) - The set of addresses that are illegitimate (I)
[15:02:23] <resnick> You want the operations as well?
[15:02:46] * resnick displays his impressive use of cut and paste
[15:02:55] <anewton> yes
[15:03:18] <resnick> This I'll shorten up and not cut and paste:
[15:04:01] <resnick> Get F as a MARID record. Get one or more Ds.
[15:04:16] <resnick> Resolve D's into A, AAAA, or ranges thereof.
[15:04:19] --- jlcjohn has joined
[15:04:53] <resnick> See if C is in the set of legit or illegit A's, AAAA's, or ranges thereof.
[15:04:57] <resnick> <eot>
[15:05:11] --- willix has joined
[15:05:13] <anewton> Ok, are there any questions?
[15:05:26] <wrs1864> <rts>
[15:05:47] <anewton> cts - wrs
[15:05:51] <wrs1864> is this a real proposal, or a strawman proposal? What are we going to use this proposal for?<eot>
[15:06:04] <resnick> rts
[15:06:08] <anewton> cts - pete
[15:06:39] <resnick> I view it as mostly a straw man to flesh out what *semantics* we need, though I could argue for it being a real proposal if you like. :-)
[15:06:50] <resnick> eot
[15:07:42] <anewton> Given that, is there need for clarification? Does anybody need Pete to clarify anything?
[15:08:26] <resnick> rts
[15:08:36] <anewton> cts
[15:08:44] <resnick> Do we want to make it a real straw man, call it "a proposal" and knock it over?
[15:08:45] <resnick> eot
[15:09:07] <mrose> rts
[15:09:09] <anewton> Well, that was the question with the MUST HAVEs.
[15:09:11] <anewton> cts
[15:09:22] <wrs1864> <rts>
[15:10:27] --- gconnor has joined
[15:10:48] <anewton> cts - mrose
[15:10:56] <gconnor> hey guys, sorry I'm late
[15:11:01] --- SamSilberman has joined
[15:11:20] <mrose> what i would like a discussion on is what additional semantics MUST be a solution. eot
[15:12:22] <anewton> Yes. So, given Pete's solution, what additional semantics are needed?
[15:12:25] <anewton> cts - wrs
[15:12:30] <wrs1864> My list of *MUST HAVES* include things like being very easy for domain owners to set up and to be resistant to errors. That, to me, implies that we must have things like an mx mechanism. Updating the same information in two places is just too error-prone. I think that we MUST HAVE a way of debugging the MARID record. I think we MUST HAVE the ability to do per-user policies.<eot>
[15:13:03] <resnick> rts
[15:13:07] <anewton> cts - pete
[15:13:45] <resnick> I'm ambivalent about MX, but don't think it's a big deal. Folks have to keep all sorts of records in sync now.
[15:14:03] <resnick> Debugging I want to hear more about. I'm not sure what that means.
[15:14:16] <resnick> I don't think per-user is needed.<eot>
[15:14:47] <gconnor> rts
[15:14:52] <anewton> cts - greg
[15:15:15] <mengwong> in Seoul, Hharald Alvestrand approached me after the BOF and asked how a sending domain could find out which of its users were sending legitimate mail in a nonconformant fashion. I explained how it could use an "exists" directive in the way that altavista presently does. He nodded, said "that is very good" and walked away satisfied.
[15:15:20] <gconnor> If we say something is 'not needed' does that mean it's off the table for good :) .eot
[15:15:34] * resnick calls point of order on meng!
[15:15:35] <anewton> Meng: please wait your turn
[15:15:45] <mengwong> sorry, that was supposed to go into my cut buffer.
[15:16:22] <anewton> Anybody want to respond to Greg's question?
[15:16:52] <resnick> rts
[15:16:54] <mrose> rts
[15:16:57] <anewton> cts - pete
[15:17:04] <resnick> defer to marshall eot
[15:17:12] <anewton> cts - marshall
[15:18:05] <mrose> each bell-and-whistle has a cost, individually a small cost; however, as soon as you get more than a few, the cost in aggregate begins to expand.
[15:18:05] --- MatthewElvey has left: Disconnected
[15:18:14] <resnick> rts
[15:18:14] <mrose> further, you have to start worrying about "feature interference".
[15:18:39] <mrose> certainly a good solution is one that will allow for standardized extensibility
[15:19:05] <mrose> the trick is determining what is the smallest number of features that let's people do real work, and simultaneously doesn't have too large of a footprint. eot
[15:19:08] <gconnor> rts
[15:19:15] <anewton> cts - pete
[15:19:22] <resnick> to answer greg's question a bit:
[15:19:42] <resnick> I think if we all come to consensus that something is not needed, we should take it off the table.
[15:19:50] <resnick> We are a rough consensus group.
[15:20:14] <resnick> That said, if at the end of the day we say, "Crap! We're screwed if we don't put *that* in!"
[15:20:23] <resnick> I don't think there's anything stopping us from putting it back.
[15:20:25] <resnick> eot
[15:20:29] <anewton> cts - greg
[15:20:45] <gconnor> I would agree with marshall on the general sense that we want to keep features from creeping and bloating. "Needed", I guess we need to define what we mean. Do we mean, "would be useful and there is currently no clever way to do the things we want without it"?
[15:21:02] <gconnor> Or just plain "Marid will not work with out it?
[15:21:04] <gconnor> eot
[15:21:52] <resnick> rts
[15:22:08] <anewton> cts - pete
[15:22:11] <resnick> I would put it somewhere between those two, leaning towards "Marid will not work without it".
[15:22:13] <resnick> eot
[15:22:44] <mrose> rts
[15:22:50] <anewton> cts - marshall
[15:23:26] <mrose> so far, i've heard two additional requirements, which to paraphrase are: do not store the same data twice, and, per-user policies
[15:23:48] <mrose> can folks talk about the "essential" nature of per-user policies? eot
[15:24:10] <anewton> Agreed. Does anyone have anything to say in favor of per-user policy?
[15:24:13] <wrs1864> <rts per-user policies>
[15:24:17] <anewton> cts - wrs
[15:24:19] <gconnor> rts
[15:24:26] <wrs1864> I think there was a pretty good thread on the mailing list about per-user policies
[15:25:01] <willix> rts
[15:25:11] <wrs1864> it basically comes down to email stuff can be messy. The political realities is that different users in a company will need to have different polices.
[15:25:50] <wrs1864> the CEO may well want to send from anywhere, at least until spammers abuse his email address, but if that policy can't be implmeented, then marid won't be implemented for the company
[15:26:18] <wrs1864> same goes for people who work from home (open a little bit for them), or sales people (maybe open quite a bit)
[15:26:20] <wrs1864> <eot>
[15:26:31] <anewton> cts - greg
[15:26:39] <gconnor> per-user is something that will be useful to a small minority of admins, but those who have a need for it may have no real workaround for the things they want to do. Some of the things that become possible with per-user specs are also the kinds of things that may make marid easier to adopt, such as letting some users opt out for a while...
[15:27:18] <gconnor> Or, asking clients/checkers to do reformulated queries which can be logged for tracking...
[15:27:20] <gconnor> eot
[15:27:26] <anewton> cts - willix
[15:27:55] <willix> One of possible additional requirements depending on type of record you want is to have CNAMe like mechanism
[15:28:14] <willix> and to allow to redirect to different dns server and possibly to more then one additional record
[15:28:19] <resnick> rts per user
[15:28:35] <willix> getting to it
[15:29:18] <willix> Per user policies can be considered in that regard as redirection to dns record like user.domain.com
[15:30:07] <wrs1864> <rts: queue: new "must have">
[15:30:30] <willix> Redirection is must have
[15:30:59] <willix> The question if we want to allow redirection to more then one location and that would resolve end-user policy question, but things become to complex
[15:31:02] <willix> eot
[15:31:13] <anewton> cts - pete
[15:31:31] <resnick> Undoing some typing cause willix said some of it:
[15:32:19] <resnick> Without going into syntactic detail, if the domain name *included* the user name, that could be covered in the 30%.
[15:32:44] <resnick> (Syntactic issues of wildcards and the like are interesting topics, but out of scope for the moment)
[15:33:12] <resnick> I guess given that it's relatively easy to do using this method,
[15:33:28] <resnick> I'll move to "don't care" about per-user.
[15:33:31] <resnick> eot
[15:33:38] <jlcjohn> <rts per-user>
[15:33:56] <anewton> cts - john
[15:34:10] <jlcjohn> The desire is obvious; the set of pointy-hair-bosses who will demand this is non-empty. The first-blush implementation is to return a "please include username" response when per-user is needed.
[15:34:16] --- SamSilberman has left: Replaced by new connection
[15:34:17] --- SamSilberman has joined
[15:34:18] --- SamSilberman has left
[15:34:23] <jlcjohn> <eot>
[15:34:38] --- SamSilberman has joined
[15:34:46] <anewton> Anybody else on per-user before we move on?
[15:34:49] <resnick> rts
[15:34:53] <anewton> cts - pete
[15:35:02] <tonyhansen> rts on per-user
[15:36:04] <resnick> I don't think we need to get to the details of a "username needed" response. (I think it could be done more easily with wildcards and *always* including the user). Let's just decide if this is needed functionality. I vote "(*shrug*), but I won't fight it.
[15:36:14] <resnick> "
[15:36:15] <resnick> eot
[15:36:22] <anewton> cts - tony
[15:36:28] <tonyhansen> one minor comment -- we don't want to be able to easily provide a means for spammers to generate a list of who it's okay to send as <eot>
[15:36:44] <gconnor> rts
[15:36:47] <tonyhansen> (ugh on english)
[15:36:48] <resnick> rts
[15:36:50] <anewton> cts - greg
[15:37:53] <gconnor> Good point re dictionary attacks. SPF has this concern too. I would like to say we could get around it by introducing some rate-limiting but that would require a special dns server...
[15:38:55] <gconnor> For now we can just say "For those users who need per-user policies, they will assume the risk of dictionary crawlers or take it on themselves to do something about it". It's theoretically possible to do something about it, but this group doesn't have to provide the answer, just leave the door open IMO.
[15:38:57] <gconnor> eot
[15:39:09] <anewton> cts - pete
[15:39:10] <resnick> Given the ability to dictionary (or brute force) attack the list of open targets, I'm not sure it's even worth leaving the per-user feature available. But again, I won't scream and yell.<eot>
[15:39:29] <gconnor> rts
[15:39:33] <anewton> cts - greg
[15:40:44] <gconnor> Forgot to say, this feature is one of those "Would be useful to a minority of users, but for those who would use it, there is no real workaround". That's a step up from "needed for all users" but it may be enough for us to keep it on the table, at least until we can *really* talk costs and not just "It feels expensive to me so I don't like it"
[15:40:45] <gconnor> eot
[15:41:55] <anewton> Taking a poll, how many people know of a domain with a per-user requirement?
[15:42:30] <mengwong> acm.org, ieee.org, pobox.com, alumni.*.edu
[15:42:52] <resnick> rts
[15:42:55] <anewton> cts - pete
[15:43:07] <willix> rts
[15:43:17] <tonyhansen> rts
[15:43:33] <resnick> forwarders are a different issue. They don't have a per-user requirement; they have a requirement to be let in by the people they're redirecting to. It's a different kettle of fish. <eot>
[15:43:47] <anewton> cts - willix
[15:44:15] <resnick> rts per user requirement
[15:44:24] <willix> I want to point out that "usefull for some" may quickly become "must have" in order for domain to implement marid records. The larger the domain & ISP is
[15:44:30] <wrs1864> rts
[15:44:31] <willix> the more likely that they need such feature
[15:44:59] <willix> PS. This is William Leibzon - william@elan.net (since you would not guess from chat nick)
[15:45:03] <willix> eot
[15:45:09] <anewton> cts - tony
[15:45:19] <tonyhansen> vanity domains have the flip side - a potential desire to ONLY be able to send from a small set of users, and NO others <eot>
[15:45:22] <SamSilberman> rts large domains
[15:45:36] <anewton> cts - wrs
[15:45:42] <wrs1864> there are 64 domains in the SPF adoption roll that use either the local part or the whole sender. Not a very big percentage, but again, for those that need it, there isn't any workaround. <eot>
[15:45:56] <anewton> cts - sam
[15:47:08] <anewton> Sam?
[15:47:37] <resnick> (my rts was missed above)
[15:47:48] <anewton> fine, cts -pete
[15:47:51] <resnick> As a receiving server, I don't give a rat's rear end that you have a per-user "requirement." I know that you have a gaping hole for spammers, and so I will *never* ask a per-user question of you. So I don't even think talking about who has a per-user requirement makes sense here. <eot>
[15:48:05] <jlcjohn> <rts per-user>
[15:48:14] <anewton> cts - john
[15:48:25] <gconnor> rts
[15:48:26] <jlcjohn> Surely the range of error-like responses will be extensible anyway. Anyone who returns that error can be warned of the consequences. I'd like to leave the per-user question that way (as an error-like extension which probably won't be in the first release).
[15:48:29] <jlcjohn> <eot>
[15:48:55] <anewton> cts - greg
[15:49:03] <gconnor> Pete, not necessarily true, per user feature could be used to lock down certain accounts even tighter
[15:49:04] <gconnor> .
[15:49:06] <gconnor> eot
[15:49:31] * resnick nods
[15:49:57] <anewton> Anyboy else have a last comment on per-user?
[15:49:59] <willix> rts
[15:50:11] <anewton> cts - willix
[15:50:16] * resnick notes the time
[15:50:47] <willix> What I did not say last time about large domains are that its the ones we probably most want to have implemented marid
[15:50:49] * anewton notes that William will be the last.
[15:51:34] <willix> Also as kind of a side-note to dictinary attacks, this can be used against spammers to specifically set certain record in a way that tracks the ip
[15:52:12] <willix> and then when you see email that mentions it you can try to track down the abuser
[15:53:06] <willix> But that still makes these records dangerous which is what should be clearly said in any document, that if you sent open per-user policy you're making yourself a target and must be prepared for it
[15:53:39] <willix> So it might be usefull to have per-user policy as part of general worgroup document and have separate BCP on how to use them
[15:54:02] <willix> eot
[15:54:18] <willix> sorry last thing
[15:54:20] <anewton> Ok. Thanks everyone.
[15:54:48] <anewton> I think this is helpful and good conversation to further the discussion on the list and at the interim meeting.
[15:54:49] <wrs1864> thanks, see many of you on Wednesday!
[15:54:58] <mengwong> cul8r!
[15:55:21] <tonyhansen> have a good mtg!
[15:55:50] <anewton> bye!
[16:00:07] --- mengwong has left
[16:01:28] --- millenix has joined
[16:05:12] --- SamSilberman has left: Disconnected
[16:05:31] --- anewton has left
[16:06:48] --- willix has left
[16:25:12] --- gconnor has left
[17:44:04] --- mrose has left
[18:07:50] --- millenix has left
[18:23:32] --- MatthewElvey has joined
[18:24:19] <MatthewElvey> Arrgh. Anyone have a log of the chat, after "[05/17 13:12] <resnick> This I'll shorten up and not cut and paste:" ?
[18:24:52] --- MatthewElvey has left