[07:51:20] --- wrs1864 has joined
[12:07:05] --- ghewgill has joined
[13:34:27] --- willix has joined
[13:56:02] --- molson has joined
[13:56:25] --- jlcjohn has joined
[14:27:26] --- anewton has joined
[14:42:13] --- anewton has left
[14:42:28] --- andy has joined
[14:43:29] <wrs1864> How are you gentlemen?
[14:43:49] <andy> today... tired.
[14:44:13] --- AndyBakun has joined
[14:44:37] <andy> How are you?
[14:45:23] --- AndyBakun has left
[14:45:35] --- mengwong has joined
[14:45:45] * wrs1864 notices that Cats isn't here yet.
[14:45:53] <wrs1864> I'm doing well
[14:46:46] --- thwarted has joined
[14:47:21] --- gconnor has joined
[14:48:24] <gconnor> hello all
[14:48:30] <mengwong> moo.
[14:48:33] <thwarted> ping
[14:48:56] <gconnor> pong
[14:49:18] --- mrose has joined
[14:49:28] <gconnor> Hi marshall
[14:49:51] <mrose> hola everyone.
[14:51:21] <mrose> ok, let's get started.
[14:51:53] <mrose> what andy i and would like to hear from folks today is this: do we think that XML documents are too large for DNS; and, if so, should the DNS contain a pointer to the document instead.
[14:52:05] --- SamSilberman has joined
[14:52:13] <gconnor> Is "whether xml is appropriate" open for discussion
[14:52:28] <mrose> since we have only 8 folks on at the moment, i'm going to start in unmoderated mode. if we get more folks, or if it becomes a jumble, we'll go to the moderation mode
[14:52:49] <mrose> sure, we can discuss that too.
[14:52:50] <mrose> begin.
[14:52:51] --- markl has joined
[14:53:14] <thwarted> what kind of "pointer" are we talking about?
[14:53:35] <gconnor> I would guess an http url
[14:53:54] <mrose> i don't think it particularly matters, could be a URL, probably
[14:54:25] <thwarted> is there a restriction on protocol, or all all protocols fair game?
[14:54:35] <thwarted> er, are all
[14:54:45] <mrose> i think that level of detail isn't particularly useful at this point.
[14:54:48] <willix> We want to make sure the pointer is to protocol whose data allows for cashing
[14:55:06] <mengwong> word.
[14:55:12] <molson> perhaps we should list requirements
[14:55:14] <gconnor> I think a key point is whether it's in DNS or not in DNS... if it's not in DNS, I don't have a strong preference as to protocol
[14:55:19] <markl> if you allow all protocols, then you have to be really clear on what should happen if the client doesn't happen to understand the given protocol
[14:55:25] <thwarted> exactly
[14:55:28] <gconnor> But, I think getting everything in DNS is a good goal
[14:56:05] <wrs1864> molson: it should be able to leap large packets in a single bound
[14:56:11] <gconnor> :)
[14:56:23] <wrs1864> and faster than a speeding bullet
[14:56:34] <markl> and then, reality set in....
[14:56:53] <willix> can we talk about xml in dns.... and how bad this is ...
[14:56:56] <gconnor> would anyone like to state requirements that we think are obvious but may not be obvious to everyone?
[14:57:04] --- Harry has joined
[14:57:10] <wrs1864> really, it could be just a normal UDP packet, similar to DNS, but without the 512 byte limit. (the UDP limit is something like 64k)
[14:57:29] <wrs1864> Ah! now Cats, erh, Katz, is here.
[14:57:34] <gconnor> Well... packets over 1000 are going to fail to pass some gateways
[14:57:40] <gconnor> not sure what happens then
[14:57:42] <molson> gconnor: can you state your requirements?
[14:58:12] <gconnor> I think "lightweight" is either a requirement or a primary goal
[14:58:30] <gconnor> To me "lightweight" is more important than "extensible"
[14:58:41] <gconnor> Did everyone see my reply to Jim about extensibility?
[14:58:53] * wrs1864 nods
[14:59:20] <gconnor> I think "extensible" is important, but not more important than "lightweight"... just my opinion
[14:59:25] <gconnor> eot
[14:59:47] <molson> I would put extensible above lightweight
[14:59:58] <wrs1864> well, I think we should back up: do we want XML in DNS?
[15:00:07] <thwarted> the message with the subject "RE: Comments on draft-ietf-marid-core-01 xml use" yes, I've seen it
[15:00:10] <wrs1864> if the answer is "yes", then another protocol is irrelevant
[15:00:12] <gconnor> Do you mean feature-extensible or syntax-extensible molson?
[15:00:45] <markl> or, to put it another way, "Is it a requirement that the info be available only from DNS?" -- or "Is it a requirement that client software not have to use HTTP?"
[15:00:45] <molson> both; how do you get feature extensible w/o syntax extensible
[15:01:13] <gconnor> The reason I ask is that XML provides only syntax extensibility... adding new features is still problematic
[15:01:44] <gconnor> On the other hand, a simpler language like SPF can provide feature extensibility as well, if we define a couple keywords ahead of time
[15:02:03] <molson> but how do we know what keywords to create?
[15:02:21] <molson> Particularly in a highly volatile space, and I think this is a highly volatile space
[15:02:36] <gconnor> More details in that post of mine, but it's basically "planning ahead for how to proceed without the feature"
[15:03:02] <markl> Plenty of custom syntaxes have been defined to allow future extensibility - I'm sure the SPF syntax can be made to handle what ever we define is acceptable future syntax extensibility
[15:03:07] <gconnor> something like "if this feature is unusable, skip" or "error" or "return unknown"
[15:03:10] <thwarted> I like the 'alt=' suggestion, greg, but at flush blush, it seems too simple -- only applying to the next feature/mechanism
[15:04:01] <willix> xml allows to extend and define additional attributes any particular data set. Extensibility in is primarily that of adding new command or new dataset
[15:04:06] <gconnor> Right. My guess is that there are 90% of cases where the default is acceptable, and probably 99% of cases where the ability to override one term is acceptable
[15:04:10] <markl> When Meng and I designed the SPF syntax, I spent sometime exploring a more robust, but more complicated extention mechanism (both syntatic and semantic)
[15:04:29] <gconnor> More than that we would need nesting, like include/continue/break or something
[15:04:36] <thwarted> bah, my typing is bad today -- first blush.
[15:05:12] --- Harry has left
[15:05:16] <markl> While XML does have well defined syntatic extensibility built in, and doesn't relieve you of the burden of designing semantic extensibility - it does offer a number of semantic idioms that are in common use, and so easy to pick if they work for you
[15:05:17] <gconnor> I don't actually know if the MS-proposed XML has any multi-level nesting to it...
[15:05:59] <willix> it should, just not for small dns records!
[15:06:05] --- Harry has joined
[15:06:16] <gconnor> I guess my point is that any language could be feature-extensible if determined ahead of time.
[15:06:29] <gconnor> am I off base?
[15:07:02] <markl> While it is a good thing to worry about future exentisbility, and to ensure that we don't shoot ourselves in the foot, let's not lose sight of the problem domain: It isn't that big, and I'm not sure it merits things like multi-level nesting or full logical expressions....
[15:07:18] * wrs1864 agrees
[15:07:32] <gconnor> Or, let me throw out a different question... does anyone here have a requirement that XML satisfies, and other formats might not?
[15:07:41] --- resnick has joined
[15:07:46] <gconnor> hi pete
[15:07:46] <thwarted> from re-reading that message, it seems that alt=fail and alt=error and alt=unknown could have different parsers/evaluators return different results -- SPF record creators would have to be careful to not place "important" features/mechanisms AFTER they specified an alt={unknown,fail,error}
[15:07:53] <markl> Using XML simply makes part of the work easier - the syntactic extensibility is already done for you - and there is software to robustly parse it. - that is all XMl is going to buy us - but that is something
[15:08:01] <molson> XML parsers are widely available, and lots of engineers understand it.
[15:08:19] <mengwong> if we take a step back and look at general internet architectural requirements: whether for MARID applications or for something else, domains in the DNS are probably going to need to provide fairly large amounts of machine-readable data (eg various kinds of public keys). i think HTTP is a reasonably good way to serve that kind of data. BEEP protocols are another possibility. we can solve the "but what if a domain doesn't have a web server" problem by creating a free or for-pay service that lets domain owners make (somewhat constrained) XML available over HTTP (a la geocities).
[15:08:23] <gconnor> thwarted- Order is important, but I think that is true of both CID and SPF already
[15:08:24] <wrs1864> yes, but the policy language is also trivially small
[15:08:29] <mengwong> just wanted to get that off my chest. :)
[15:08:41] <gconnor> I think it's possible to make the spec so that all parsers would execute them the same way
[15:08:59] <markl> On the other hand, if the problem is small enough, and the technical situation (say in DNS) requires it, than a custom syntax may be the way to go...
[15:09:22] <thwarted> requiring an HTTP client (or perhaps an HTTPS client) might be as much code as an xml parser
[15:09:50] <markl> Actually, and HTTP client for this sort of thing is almost embarrassingly small.
[15:10:04] <wrs1864> have we decided that XML should *not* be put into DNS?
[15:10:14] * wrs1864 still thinks we should answer that question first
[15:10:22] <markl> * markl agrees
[15:10:26] <gconnor> I think we are still on "Is XML a requirement at all"
[15:10:32] <willix> I agree with Meng and wrote about it on ASRG just recently that possiblity exists for using xml with beep and with soap and sending it through udp, but it'll need to be comprehensive effort to define new protocol for such policy information serivce and in the mean time we have to do something for mard
[15:10:40] <thwarted> I agree - no XML in DNS, but only because I don't think it is a requirement at all.
[15:10:43] <markl> (markl's client is impoverished)
[15:11:23] <gconnor> I see Harry on the list but haven't heard from him
[15:11:24] <wrs1864> ok, I agree with thwarted
[15:11:26] <markl> I guess I disagree with multiplying our options here: BEEP and SOAP are poor choices -
[15:11:47] --- fenton has joined
[15:11:55] <markl> Everyone in this space originally choose DNS to store the info because a) it had the right caching semantics) and b) it was small and quick
[15:11:58] <gconnor> I am going to assume that MS has their reasons for wanting XML. I would like to understand a bit better what those are. Has that been covered on the list and I missed it?
[15:12:05] <Harry> [Jim Lyon speaking, my myJabber is screwed up.] About a week ago, I posted 10 scenarios for possible future extensions. It's clear we could get to any or all of them with XML. It's not clear that we can get to all of them with something SPF-like.
[15:12:07] <molson> I'm still lost on what requirement we don't meet if XML is in DNS
[15:12:09] <willix> markl: beep and soap are different layers. Beep is like http, soap is like cgi
[15:12:15] <wrs1864> (another protocol option: call backs via SMTP and use a new comand "policy")
[15:12:24] <gconnor> Hey Jim
[15:12:36] <markl> If the data no longer fits in DNS (still to be determined here), then HTTP is the obvious choice - it has the right caching semantics, everyone has it, everyone can implement it
[15:12:54] <thwarted> markl - sure, HTTP clients can be small, but then your MTA needs to speak an additional protocol -- someone wrote a XML parser for MS's CID record in something like 2k or 20k or something -- but that seemed limited -- if you're going to allow external references via http, much of the http protocol is goign to need to be supported. If I'm going to serve a policy file via http, it would be great if it was https so people can be sure it is mine
[15:13:02] <gconnor> Jim, I will go try to find the message. Can you remember one or two of the situations where XML was needed?
[15:13:13] <Harry> I think that the assumption that the data no longer fits in DNS is unfounded.
[15:13:39] <willix> FYI: We have 15 people in the chat now....
[15:13:55] <molson> I agree with Jim
[15:13:57] <Harry> Some future extensions: 1. Feedback on how each individual SPFish mechanism is doing. 2. Advice on where to complain about spam.
[15:13:59] <markl> thwarted - yes, I understand - I was just saying that if it's going to be another protocol, it shouldn't be BEEP, SOAP or yet some other custom one we design here.
[15:14:02] <wrs1864> harry: do you have stats?
[15:14:14] <Harry> 3. List of accrediting agencies.
[15:14:28] <thwarted> markl - okay, that makes sense. smtp POLICY command makes a lot of sense
[15:14:43] <wrs1864> 1. report= 2. abuse.net 3. accred=
[15:14:46] <Harry> 4. Statements of whether all mail is S/MIME signed.
[15:14:54] <wrs1864> 4. smime=
[15:15:00] <markl> willix - yes, I know 'bout BEEP and SOAP and their layers - I'm just using them as proxies for "other protocols and encodings"...
[15:15:16] --- Aredridel has joined
[15:15:18] <mrose> ok, time to start manual moderation.
[15:15:23] <gconnor> SMTP command makes some sense, about as much as http... remember that you have to open a second connection, you can't just ask the currently connected client (who might lie)
[15:15:29] <mrose> folks wishing the mic, now need to request it
[15:15:46] <Harry> Suppose we have v=spf1 +mx -exist:%{i}.blacklist.com ~all. No we want reports of what matched ~all. Possibly other reports on what matches -exists...
[15:16:03] <Harry> The point is that just the SPF modifier syntax isn't enough.
[15:16:16] <wrs1864> <rts: spf modifiers>
[15:16:27] <mrose> wrts1864 - go
[15:17:03] <wrs1864> I think SPF modifires *are* enough. The report= extension is probably a better system than the XML suggested system
[15:17:08] <wrs1864> limit one report per day.
[15:17:11] <wrs1864> <eot>
[15:17:33] <Harry> <rts: answer>
[15:17:39] <mrose> harry - go
[15:17:40] <thwarted> <rts: report extension>
[15:18:23] <willix> rts: spf + xml
[15:18:25] --- richr has joined
[15:18:26] <Harry> But how to tell the diffrerence between wanting reportss on PASS amil, SOFTFAIL mail, FAIL mail, and different causes of each.
[15:19:03] <gconnor> rts
[15:19:05] <molson> <rts xml vs spf>
[15:19:05] <Harry> XML helps give appropriate scoping.
[15:19:09] <Harry> <eot>
[15:19:29] <mrose> willix
[15:19:59] <willix> Why are we not considering mixing spf and xml in the way that xml syntax serves as extension for spf but spf remains primary record
[15:20:21] <Harry> <rts: answer>
[15:20:23] --- JimLyon has joined
[15:20:29] <mrose> harry
[15:20:33] <markl> <rts: answer mix spf + xml>
[15:20:55] <Harry> Because (a) we don't know how, and (b) it would probably be the worst of both worlds.
[15:20:58] <Harry> <eot>
[15:21:18] <mrose> thwarted - i haven't forgotten about you, i want to finish this thread first
[15:21:22] <mrose> molson - go
[15:21:30] <willix> <rts: answer>
[15:21:52] <molson> It sounds like we are discussing the relative merits of xml and spf.
[15:21:58] <mengwong> <rts: response to willix>
[15:22:16] <molson> To my way of thinking, xml as a widely available standard wins by default, unless there is a flaw
[15:22:21] <molson> which I haven't heard
[15:22:22] <molson> <eot>
[15:22:33] <mrose> willix - go
[15:22:49] <willix> I'll let meng speak first
[15:22:56] <resnick> <rts - extensibility necessary?>
[15:22:58] <mrose> ok, meng - go
[15:23:09] <mengwong> if a client understands both XML and SPF,and if a publisher has both XML and SPF formats available, the XML format should be primary over the SPF representation. </eot>
[15:23:14] <mrose> willix - go
[15:23:20] <thwarted> <rts : widely available standard>
[15:23:54] <willix> Which is were I disagree with meng. XML format is too large when it has to be used for every part of the record, but its great for extensibility of just one particular part of it
[15:24:26] <willix> Mix up is possible, I sent some examples to marid list, btw
[15:24:42] <willix> <eot>
[15:24:44] <JimLyon> <rts: answer [I'm me now, and Harry is Harry]>
[15:25:22] <mrose> markl - go
[15:25:26] <markl> Meng said most of it for me - but to focus: It would be hard but doable to define "Mixing" SPF and XML - I'm not sure the problem is big enough to warrant such a complicated system. <eot>
[15:25:38] <mrose> thwarted - go
[15:25:42] <thwarted> I assert that the SPF syntax parsing is similar to enough to RFC822 header parsing that it's already a "widely available standard" that all MxAs implement
[15:25:42] <wrs1864> <rts: channeling Julian: dangers w XML>
[15:26:01] <thwarted> and is more mature -- xml is much newer than SMTP and 822
[15:26:04] <thwarted> <eot>
[15:26:09] <wrs1864> Could someone bring this as an example for why XML is dangerous overkill for the task at hand? <?xml version="1.0"?><!ENTITY foo SYSTEM "http://foo.com/cgi-bin/generate-mass-garbage"><bar>&foo;</bar> And: if one prohibits this, is it really still XML(TM)?
[15:26:15] * wrs1864 fucks up
[15:26:32] <mrose> resnick - go
[15:26:34] <molson> <rts answer thwarted>
[15:26:37] <markl> <rts: answer wrs>
[15:26:50] <resnick> I'm perfectly willing to be quiet if I'm alone in this, but is there anyone else who thinks that this extensibility is really unnecessary? I'm of the opinion that whatever MARID is, it's a short term solution to a short term problem and letting wildly extensible stuff loose in the DNS is probably not the best deployment plan. I'd like folks speak up if they agree. (Chair's discretion on how to ask for those voices.) <eot>
[15:27:14] <mrose> any rts on this?
[15:27:17] <JimLyon> <rts: answer resnick>
[15:27:21] <thwarted> <rts: answer resnick>
[15:27:23] <mrose> jimlyon - go
[15:28:00] * wrs1864 agrees with Resnick
[15:28:21] <JimLyon> Spoofed email is a short-term problem only because MARID will solve it. -- If we quit solving it, spoofing will come back. However, MARID alone doesn't solve spam, which is the larger goal. For that, we'll need various extensions.
[15:28:22] <JimLyon> <eot>
[15:28:40] <Aredridel> <rts: answer resnick>
[15:28:46] <markl> <rts: answer resnick>
[15:29:08] <willix> <rts: answer resnick (quick)>
[15:29:11] <gconnor> <rts answer(pete) also>
[15:29:29] <mrose> thwarted - go
[15:29:33] <thwarted> I think extensibilty as "unnecessary" is the wrong way to think of it -- it's not so much unnecessary as difficult to deploy extensions that will be meaningful to a signficant population after policies have already been deployed. consider extensions to HTML that not all browser support...
[15:30:07] <thwarted> everyone and their dog coming up with extensions and then a tower of babble of ...
[15:30:24] <thwarted> "if only your MTA supported my SPF extension, you won't be rejecting my mail"
[15:30:46] <thwarted> if there are extensions that we want to add now..
[15:31:15] <thwarted> before becoming a full standard, let's do it, or define some simple nesting or overrides
[15:31:16] <thwarted> eot
[15:31:34] <JimLyon> <rts: answer>
[15:31:41] <mrose> aredridel - go
[15:32:13] <Aredridel> I think that thinking in syntactic extensibility is similar to extensions to HTML -- difficult to manage.
[15:32:57] <Aredridel> Instead, a layered approach might solve it more cleanly -- define policy in well-defined steps: IP-based, then another record for crytographic MIME, another for other schemes. Let them be independent as much as possible.
[15:32:58] <Aredridel> <eot>
[15:33:32] <mrose> markl - go
[15:33:47] <markl> Re: XML and entities: Yes, you don't have to follow external system entities, and it is still XML. The publisher runs the risk that the document may not be usable, if they do such things - so in this context no one would ever do it - since no client is likely to read them.
[15:33:55] <markl> Re: Extensibilty: I agree with the philosophy of let's get the problem we understand under control. And I think we need to be congnizant that there will be future things we need to do. The original SPF tried to strike this balance: Hit the mark for now, some room for future, but we expect something bigger down the line...
[15:33:58] <markl> <eot>
[15:34:07] <mrose> willix - go
[15:34:09] <willix> If "short term" is next 10 years, then we need extensibility and be prepared for MARID 2.0 :) with backward compability with 1.0 in better way then spf interpretation rules under xml marid drafts.<eot>
[15:34:09] <JimLyon> <rts: answer Aredridel>
[15:34:17] <mrose> gconnor - go
[15:34:21] <gconnor> I disagree that marid should be considered "short term" but I think the overall point is a good one, if we allow extensibility it should be controlled, and well known ahead of time what you are able to add and what you aren't. Any "extension" would probably not cover 100% of deployed implementations. I would vote for "rigidly defined areas of doubt and uncertainty" :) <eot>
[15:34:26] <mrose> jimlyon - go
[15:35:43] <JimLyon> We *know* we're not done with MARID. If we push extensibility off to additional records, everyone will just have to do multiple lookups. People worry about record sizes, but they're not a problem unless someone has something to say about *many* extensions. Typical record will use few.
[15:35:54] <JimLyon> <eot>
[15:36:26] <mrose> wrs1864 - go
[15:36:33] <mrose> also, 15 minute warning
[15:36:39] <wrs1864> <eot I hit enter early>
[15:36:54] <mrose> molson - go
[15:37:19] <molson> MARID requires tools and information exchange; publishing is not nearly so easy as "publish your records". It's more complicated than it's generally given credit for. The tools are critical to adoption, and so using technology that tool writers know is a big win. It's not just MTA authors we need to be concerned with when thinking about the syntax.
[15:37:59] <molson> eot>
[15:38:03] <gconnor> rts question for jim
[15:38:09] <thwarted> <rts: question for molsen>
[15:38:35] <mrose> gconner - go
[15:38:41] <gconnor> I am interested to find out if XML has anything to do with possible patent claims by MS. I understand MS has sought a patent on the XML format for Office documents. If you guys are able to answer, does use of XML or not determine whether we are in an area covered by an MS patent app? eot
[15:38:55] <mrose> jim - go
[15:39:20] <JimLyon> No, to the best of my knowledge. <eot>
[15:39:30] <mrose> thwarted - go
[15:39:36] <willix> <rts: followup question to JimLyon>
[15:39:39] <thwarted> which tools are we talking about here? do tool writers know more about XML? Isn't this solved with some kind of "xml to SPF" library? ...
[15:40:10] <molson> I'm speaking from my experience, but yes tool writers do know more about XML.
[15:40:13] <thwarted> the spf help page that asks you questions and gives you a record doesn't require the publishers to know anything other than their network layout and local policies
[15:40:14] <thwarted> eot
[15:40:23] <mrose> molsen - go
[15:40:29] <Harry> <rts - MS patents>
[15:40:30] <gconnor> rts consensus question
[15:40:32] <molson> For many domains one person won't have all the ifnormation
[15:40:40] <thwarted> XML isn't gonig to help that
[15:41:15] <molson> well, I can much more easily imagine how to write a multi-company record building tool in a short period of time with xml
[15:41:21] <thwarted> I can't come up with any techonology that helps that :)
[15:41:24] <molson> xml to spf does help, but why?
[15:41:58] <molson> <eot>
[15:42:09] <thwarted> uh, I have nothing more :) eot
[15:42:13] <thwarted> I can't answer that
[15:42:18] <mrose> harry - go
[15:42:22] <wrs1864> <rts xml requires SPF parsing>
[15:42:47] <Harry> The patent claims the MS has filed with respect to XML in Office are completely unrelated to Caller ID. And the Caller ID patents are licenced royalty free. Any more detailed questions on this, please let me by email and I'll fwd to our attorneys for clarificationl.
[15:43:12] <Harry> <eot>
[15:43:49] <mrose> gconnor - wait. wrs1864 - go.
[15:43:59] <mengwong> =)
[15:44:15] <wrs1864> The current SPF-ID spec calls for XML structures that are really just SPF syntax with a lot of junk added to it. e.g. <a>%{ir}.%{s3-}.%{d}</a> . any system that can create such an XML spec can just as easily create an SPF record.
[15:44:32] <willix> <rts - MS Patents follow up question>
[15:44:33] <wrs1864> the SPF syntax is just basically XML with all the tag crap converted to a single space <eot>
[15:44:53] <mrose> willix - go
[15:45:11] <molson> <rts answer willix>
[15:45:26] <molson> <rts sorry, answer wrs1864>
[15:45:26] <willix> If <ep> is not specifically covered by MS Patents does it extend in general to use of xml in dns records and if no does it extend to use of <ep> in dns records?
[15:45:51] <willix> <eot until answered by Jim or Harry>
[15:46:19] <mrose> gconnor - we're not going to get to your consensus issue on this chat, though i will talk about it in 2 mins
[15:46:24] <wrs1864> <request for extended session>
[15:46:35] <mrose> molson - go, you have 1 min
[15:46:38] <thwarted> <request for extened session at another time>
[15:46:41] <Harry> I'll have to look into the specific details of the patent and reply later. I do want to emphasize that we are licensing these royalty free.
[15:46:42] <willix> P.S. Basicly I'm just asking if Microsoft has patented any use of XML in DNS or just use for <ep> records
[15:46:42] <molson> if you can deterministically convert SPF to XML and back I'm happy - it statisfies my requirement.
[15:46:44] <molson> <eot>
[15:47:03] <JimLyon> <rts resp molsen>
[15:47:12] <wrs1864> <rts: molson answer>
[15:47:14] <mrose> willix - harry and jim and look into the patent thing and post something to the list.
[15:47:20] <mrose> jimlyon - go
[15:47:37] <Harry> Will do.
[15:48:09] <JimLyon> XML as defined is a strict superset of SPF.
[15:48:38] <JimLyon> Semaintics of things not in SPF are not defined yet. <eot>
[15:49:09] <andy> I'm taking over for Marshall. gconnor - go
[15:49:21] <mrose> actually, i'm taking the token for a second.
[15:49:23] <mrose> gconnor - wait.
[15:49:32] <gconnor> ok
[15:49:57] --- fenton has left
[15:50:19] <mrose> all - i have another meeting to go to, but i'm going to make an observation. unless andy, ted, and i start seeing some actual agreement and compromise on some stuff, i think it likely that the iesg is going to dump this wg.
[15:51:17] <mrose> although, i wasn't entirely happy with what was going on at the interim meeting, it appears to be a "reasonable compromise" in the sense that while no one was really happy with it, it would more or less work and wasn't technically embarassing. in an open forum, that's about par for the course.
[15:51:30] --- DouglasOtis has joined
[15:51:37] <mrose> however, over the last couple of weeks, people have harded their positions back to the point, where we aren't going to get agreement on stuff.
[15:52:38] <mrose> here's a hint: if the iesg were to take a look at the last two weeks of email archive, they could reasonably conclude that the wg doesn't have concensus on a damn thing, and they could easily use that as the basis for tossing anything the wg sends to them. back in the day when i was on the iesg, i would do stuff like that if i wasn't happy with a wg's performance.
[15:53:13] <mrose> so, while it's fine to have disagreements on stuff, at some point, people have to move closer towards a concensus position and actually arrive at one. it doesn't have to be perfect, it just has to work, etc., etc.
[15:53:44] <mrose> i have specifically kept this diatribe vague and general so as not to "out" anyone, but you know who you are, and more importantly, ted, and andy and i damn well know who you are as well.
[15:54:14] <mrose> so, decide whether you want this group to produce something. if not, then start moving towards a compromise. otherwise, this has been a fine use of bits, but nothing else.
[15:54:32] <mrose> and now, i have to go yell at some engineers in another of my roles, so andy is taking over to address gconnor's issue...
[15:54:34] --- mrose has left
[15:54:57] <andy> gconnor - go
[15:55:06] <andy> if it is still appropriate.
[15:55:08] <gconnor> I think we have established some cases where xml is not strictly necessary for Marid but might be useful for a larger framework which Marid is a part. Do we need to talk about, if XML is desired, whether it should be in DNS or not? Do we need to talk about, if XML is desired, if all receivers need to be able to parse it? (Directed to the chair on how to respond I guess) <eot>
[15:55:39] <andy> wrs - go
[15:56:03] <thwarted> (sorry for being out of turn) I have to go --- but back to extensibility before I do re: extensibility. I'm going to have to take Stuart D. Gathman's position ("exists is the only thing you need") on a report extension -- if you want reports, then set your SPF record to v=spf1 <some exists string> ~all and generate reports based on your DNS logs <eot>
[15:56:33] <wrs1864> It was trivial to convert SPF to XML, I coded it up during the interim meeting. I don't know enough XML parsing stuff to do the reverse, but I wouldn't think it would be too hard. (as long as you don't use arbitrary extenstions) <eot>
[15:56:38] <wrs1864> (sorry)
[15:56:51] <andy> quite all right.
[15:56:55] <andy> Any other rts?
[15:57:13] <willix> <rts: q to Andy on Marshall's last comments>
[15:57:21] <DouglasOtis> XML could work if limited to being a standalone document where the header is virtual and represented by a token.
[15:57:22] <JimLyon> <rts> answer thwarted>
[15:57:23] <andy> willix -go
[15:58:05] <Aredridel> <agreement with DouglasOtis>
[15:58:05] <willix> Is there really a chance that IESG will stop this WG, because it seems more likely they'd let it continue at least until next one or two IETF meetings
[15:58:41] <willix> We're getting too quick with decisions and that is what we'll likel get punished for and that is also why we don't have consensus
[15:59:13] <andy> It has happened in the past. And if Ted, our AD, where to ask the co-chairs, "Is the working group making progress?" our answer would not be very positive at the moment.
[15:59:37] <gconnor> rts
[16:00:05] <andy> The IESG gave this WG a very short set of deadlines because they sensed the players in this area were very close to consensus and willing to find compromise.
[16:00:31] <andy> However, if you look at the mailing list, that is hard to see.
[16:00:36] <wrs1864> <rts harding positions>
[16:00:42] <andy> I'll dwell no further on this as it is not productive.
[16:00:53] <andy> gconnor -go
[16:01:14] <gconnor> if we're not making very good progress, is it appropriate to ask for the chairs to take a more active role in guiding the discussion? Should we be policing ourselves? (OK to not answer right now if you want to take it off line)
[16:01:17] <gconnor> eot
[16:01:48] <andy> I'll confer with Marshall and we will get back to the wg on that.
[16:02:00] <gconnor> ok thx
[16:02:03] <andy> wrs - go
[16:02:21] <wrs1864> My position on several things has, indeed, hardened again in the last couple of weeks, but that is in a large part due to the sense I have of the SPF community. I will not claim that all the objections to XML by mail admins are rational, but there is a *very* strong current against it. I think XML is a deal killer for too many people.<eot>
[16:02:55] <JimLyon> <rts resp wrs>
[16:02:58] <wrs1864> (e.g. I'm "representing" the SPF community as much as my own) (real eot)
[16:03:03] <andy> jim - go
[16:04:03] <JimLyon> I agree that many mail admins don't like XML. That's why they get to continue using SPF syntax. For now, nobody sees the XML except people who *choose* to publish it, and software implementers. <eot>
[16:04:27] <wrs1864> <rts: ans Jim>
[16:04:46] <andy> wrs - go
[16:05:33] <wrs1864> but software implementers are often not too hot on the subject of XML either, and mail admins just don't want libxml on their servers. The don't know the security implemications and they want to keep it simple. requiring XML parsing forces mail admins to run things the don't want to run<eot>
[16:06:35] <gconnor> rts
[16:06:50] <andy> I would like to ask the following question: Has anybody ever known of an exploit that targeted a vulnerability in the XML spec?
[16:06:54] <Harry> rts, answer wrs
[16:07:47] <andy> Any takers to the question?
[16:07:49] <willix> <rts: back to dns>
[16:08:03] <JimLyon> Andy, you should take that as a resounding no.
[16:08:10] <DouglasOtis> Any time there is specialized code to parse text, there is potential for bugs.
[16:08:13] <wrs1864> <ans andy: I'm not an XML expert, so I don't know of any. for what it is worth, I have said I would put XML into libspf-alt, if wanted)
[16:08:26] <andy> gconnor - go
[16:08:59] <gconnor> I think the XML issue is a very small part of the important work we are doing within MARID. It's an implementation detail. We have made a lot of progress in terms of coming together on identities and features. let's not forget that. I know the XML issue pushes a lot of people's hot buttons. I don't want this issue, which I consider "not really central to the problem we are trying to solve" to tear the group apart
[16:09:29] <Aredridel> <agreement>
[16:09:31] <mengwong> me too!
[16:09:36] <wrs1864> yes
[16:09:41] <markl> here here!
[16:09:43] <SamSilberman> yes
[16:09:46] <molson> yes
[16:09:47] <Aredridel> I want to solve my customer's problems. With something that works.
[16:09:51] <mengwong> i just think consensus is sometimes harder to detect because people have been conditioned against saying "me too!".
[16:09:52] <willix> yes as well
[16:09:59] <Aredridel> Agreed.
[16:10:04] <gconnor> I just want a solution that won't be laughed at in 5 years. If MS can make a relatively convincing case that there is a need for "email policy document" over and above what MARID needs, then we can probably allow for that expandability...
[16:10:06] <JimLyon> It's more nearly central than gconner says, but I don't want it to tear us apart either.
[16:10:28] <andy> let's get back to moderation
[16:10:34] <gconnor> almost done
[16:11:09] <gconnor> anyway... I don't want something that's far too simple for expansion, but let's be awayre that there is not really *that* much room for exansion in DNS.
[16:11:20] <gconnor> eot
[16:11:24] <andy> willix - go
[16:12:05] <willix> gconner just said it actually. We need to think about possibility of overloading dns with to large a records
[16:12:29] <JimLyon> rts - record sizes>
[16:12:34] <andy> harry - go
[16:12:40] <willix> fyi - not done yet
[16:12:49] <andy> sorry. finish.
[16:13:28] <willix> We need to consider publishing draft that tries to explain to network administrators these issues and how they should try to minize mard records and in which situation they should move to using different type of record redirection (i.e. http probably)
[16:14:19] <willix> This would be BCP type of info for dns administrators on publishing marid and if we do go with XML I think this BCP should say that if its possible to express something in simpler terms (SPF) they should do it
[16:14:22] <willix> <eot>
[16:14:28] <andy> harry - go
[16:14:33] <Harry> I'll defer to Jim.
[16:14:37] <andy> jim - go
[16:14:39] <JimLyon> The XML overhead isn't large. Typical small record: "v=spf1 +mx -all": 15 chars. XML: "<ep><m><mx/></m></ep>" only 21 chars. Larger record: "v=spf1 +a123.123.123.240/28 +a123.123.123.240/28 -all": 55 chars As XML: <ep><m><r></r><r></r></m></ep>: 66 chars. Not a huge difference.
[16:14:40] <DouglasOtis> <rts: rsp willix>
[16:15:10] <JimLyon> The tag overhead is small when there's data. When there isn't data, the record is small. <eot>
[16:15:20] <andy> doug - go
[16:15:33] <willix> <rts - xml overhead>
[16:15:53] <DouglasOtis> The use of TCP will be a serious hit to performance. The size of XML is not problem if it is defined as standalone.
[16:15:57] <DouglasOtis> eot
[16:16:03] <andy> willix - go
[16:16:06] <wrs1864> <rts: record sizes>
[16:16:28] <willix> XML has large overhead with its header urn defition and with required ending, etc. Just part inside <out> is small
[16:16:41] <JimLyon> <rts ans willix>
[16:16:42] <willix> Most records would be very small and should not have extra overhead like that
[16:17:08] <willix> for those using spf is better. For large records additional startup xml overhead is not a big issue, but then record itself maybe too large
[16:17:11] <willix> <eot>
[16:17:22] <andy> wrs - go
[16:17:28] <wrs1864> Jim: do you have stats on how large the typical XML doc will be? (I have many times posted the stats on SPF.)
[16:17:55] <wrs1864> I also disagree with the amount of expansion that XML creates. (I'll dig up a pointer to a post on SPF-discuss in just a sec)
[16:18:01] <JimLyon> No stats, but translations seem to add about 20% to SPF. <eot>
[16:18:16] <andy> you done, wrs?
[16:18:22] <JimLyon> (That's by looking at test cases, not published rec's.) <real eot>
[16:18:23] <wrs1864> and also, it is critical to remember we don't have full 512 bytes
[16:18:38] <gconnor> rts on sizes
[16:18:53] <wrs1864> we have to take into accoutn UDP and DNS overhead so even a small increase can be very important<oet>
[16:19:04] <andy> gconnor - go
[16:19:35] <DouglasOtis> <rts: ques- JimLyon>
[16:19:52] <gconnor> With regard to 512 bytes, it is possible to do DNS over TCP... people have been treating that as a no-no since some people have broken firewalls, but I would think we should consider it, as an option, at least as an alternative to setting up an http server and cache :)
[16:19:55] <gconnor> eot
[16:20:19] <wrs1864> <rts: spf post>
[16:20:54] <JimLyon> <rts ans gconnor>
[16:20:55] <andy> Ok. Now I get to ask another question: Would the XML proponents be willing to look at some of the suggestions (mentioned on the list) for cutting down the size of XML?
[16:21:26] <JimLyon> Yes, if I can understand them. :-)
[16:21:45] <andy> Anyone else on that question?
[16:21:53] <DouglasOtis> yes
[16:21:58] <willix> <rts>
[16:22:04] <andy> doug - go
[16:22:42] <DouglasOtis> The ability to extend XML outside the standard process is a high risk. Specing a standalone document would help in that respect.?
[16:22:46] <DouglasOtis> eot
[16:22:55] <andy> willix - go
[16:22:57] <Aredridel> <rts regarding broken firewalls>
[16:23:07] <willix> defer for about 2 minutes, looking through my email...
[16:23:14] <JimLyon> <rts ans Doug>
[16:23:20] <andy> jim - go
[16:24:32] <JimLyon> Doug, I'm not sure what the old <?xml standalong=yes?> means in the face of XML namespaces and schemas. Extension isn't high risk, if the rules clearly state that the extensions are merely providing more information, not changing the meaning of standardized info.
[16:24:57] <DouglasOtis> <rts: ans- Jim>
[16:25:04] <willix> <rts - specific xml suggestions>
[16:25:21] <andy> Doug, Jim - take this issue to the list. It is complex. I know.
[16:25:24] <andy> wrs - go
[16:25:26] <JimLyon> Examples I posted above are real. You just specify <ep><m><mx/></m></ep>. Nothing else. Namespaces are implied by the wrapper in the doc.
[16:25:27] <wrs1864> In http://archives.listbox.com/spf-discuss@v2.listbox.com/200406/0561.html I discuss some of the XML growth. <eot>
[16:25:28] <JimLyon> <eot>
[16:25:45] * JimLyon opens http://archives.listbox.com/spf-discuss@v2.listbox.com/200406/0561.html
[16:25:45] <andy> Aredridel - go
[16:26:46] <andy> Aredridel?
[16:27:18] <Aredridel> Drop.
[16:27:19] <Aredridel> Sorry.
[16:27:23] <Aredridel> Skip me.
[16:27:35] <andy> ok. willix - go
[16:28:02] <willix> Specific suggestions I made on June 2nd included dropping <?xml version="1.0" charset="us-ascii"?> <root xmlns="urn:ietf:params:xml:schema:marid-1">
[16:28:18] <willix> And instead using very simple <?xml?><ep v=marid=1>
[16:28:31] <willix> and including ability to incorporate spf syntax as part of xml
[16:29:01] <willix> <spf +a=test.example.com -all> instead of using set of <m> elements
[16:29:26] <willix> There have been suggestions by others as well, it all comes down to making sure xml that is in dns is easy to read and small
[16:29:59] <willix> Also 20% increase size of xml is I'm not mistaken is only for the conversion of spf into <out> ...</out> porition
[16:31:03] <willix> P.S> If there is automated conversion tool available for SPF->MARID XML, I'd be willing to run a script and have this compute statistics for ALL currently published spf records. They we'd have real answer
[16:31:06] <willix> <eot>
[16:31:27] <JimLyon> <rts ans willix>
[16:31:38] <molson> <rts SPF -> MARID>
[16:31:52] <andy> let's start to finish up... Jim & Margaret and then we'll end.
[16:31:54] <andy> jim - go
[16:32:16] <JimLyon> 1. Published DNS rec's *never* have <?xml...> <root...>.
[16:32:45] <JimLyon> 2. We currently have a script for SPF->CallerId XML. We should soon have one for SPF->MARID XML.
[16:33:31] <JimLyon> 3. I need to think, but I think we could do something on the lines of <spf>+a:test.example.com -all</spf>. Does this sound good. <eot>
[16:34:03] <molson> I caution the group about reading too much into currently published SPF->MARID conversions; the SPF v1 and MARID data are different for many (most?) domains
[16:34:05] <andy> Anybody want to say yes, no, or maybe to Jim's question
[16:34:07] <Aredridel> I like #3! <eot>
[16:34:30] <markl> i dislike #3
[16:34:47] <wrs1864> molson: please explain!
[16:34:59] <willix> Make sure Jim's #3 can be mixed as part of normal xml <m> elements, and I'm on board as long as #1 is also true and xml header is not required
[16:36:10] --- resnick has left: Disconnected
[16:36:22] <andy> Ok. Let's let Margaret finish her statement. Then we can end. And people are welcome to stay around afterward and chat as long as they want.
[16:36:30] <andy> margaret - go
[16:36:34] <molson> SPF v1 is the return path; SenderID/SPF-ID/Marid is the PRD (submitter).
[16:37:09] --- markl has left: Disconnected
[16:37:29] <molson> For many domains, both very large and very small, the PRD is a richer & more complicated (and also much more interesting to check) list
[16:37:37] <molson> <eot>
[16:37:40] <gconnor> Team- If anyone would like to hang around after the session, I would be interested in chatting about "layers, identities, and building a chain of trust"
[16:37:57] <andy> Ok. Thanks for coming.
[16:38:07] <wrs1864> thanks Andy (and Marshall)
[16:38:16] <molson> gconnor: I am interested but need to leave soon
[16:38:30] <JimLyon> I need to leave soon, too.
[16:38:34] <andy> If you want to stick around and chat with Greg, please feel free to do so. Also, this chat room is open all the time. You don't just have to show up for MARID Mondays.
[16:38:45] <willix> good session today
[16:38:47] <wrs1864> molson: I would be very interested to read more about what you are talking about
[16:39:04] <molson> I'll post something later tonight or tomorrow
[16:39:07] <wrs1864> ok
[16:39:08] <JimLyon> gconnor, do you have something written about layers, ...
[16:39:37] <wrs1864> I have long suspected that you are right, but I've had a hard time creating situations that SPFv1 records couldn't work for both
[16:39:57] <molson> I can show you some situations :-)
[16:40:07] <wrs1864> thanks
[16:40:34] <gconnor> Jim- I posted something to marid, let me get the info...
[16:40:37] <willix> I agree with Margarett that PRD records would be different and maybe slightly larger. But for statistical computation of different between SPF and MARID, using standard script to do it would be good enough
[16:41:11] <willix> s/different/"difference in size of records"/
[16:42:10] * mengwong moos.
[16:43:09] <gconnor> Anyone else have last-minute comments on XML, before we close the official portion?
[16:43:25] <DouglasOtis> I'll do my comments on the list...
[16:43:57] <DouglasOtis> <eot>
[16:44:20] --- JimLyon has left
[16:44:23] --- Harry has left
[16:46:08] <gconnor> OK.. for those who are sticking around, has anyone read my message from Saturday "A layered approach to identities, possibilities for a chain of trust"
[16:46:50] <wrs1864> greg: I'm sure I have, but I don't remember exactly which post you are refering (PHB) to.
[16:47:16] <willix> Yes and I think the trust generated is not good enough. We need some crypto confirmation. I trust PGP chain of trust, I would not trust MARID chain of trust
[16:48:08] <willix> What you say is that I have to believe that what you said about what they other guy said is true. But that is herecy, the most I trust is what you said yourself
[16:48:56] <gconnor> The main idea is that the identities that bind strongly to IP, are not normally "long lasting" and the ones that are long-lasting don't bind well to IP
[16:49:19] <Aredridel> Absolurely.
[16:49:32] <willix> That is true but that is not MARID any more...
[16:49:49] <DouglasOtis> My expectations are finding a means of handling layer zero first. The next layer would be admistratively defined as this requires rewriting the Mail From parameter.
[16:50:09] <gconnor> IF the mail is sent directly to you, without a forwarder, then you can validate them by IP. I'm interested in seeing if that validation can be "stretched" to a validation of the previous hop, and so on
[16:50:12] <DouglasOtis> administratively...
[16:51:03] <gconnor> I actually defined Layer 0 as the HELO name - I was thinking that Doug and Dave C would probably like to see that included.
[16:51:08] <willix> I'm interested too and in fact I'm writing document just on that, but that is based on crypto s/mime like approach and not marid at all
[16:51:13] --- andy has left
[16:51:49] <willix> The doc should be ready by end of the month, I have 10 pages written already and some early perl script as proof of concept. This will go to ASRG
[16:52:12] <DouglasOtis> The mail using the modified header scheme defines the last administrator that handled the mail. It seems to be misleading to suggest this tracks fully those responsible for the mail.
[16:53:03] <jlcjohn> I've read gconnor's email several times, and I don't catch how he builds layer 1 validation from layer 0.
[16:53:34] <DouglasOtis> There must be a way to know when the chain of trust has been left open.
[16:53:56] <DouglasOtis> I have seen similar documents using crypto coming from Cisco.
[16:54:13] <DouglasOtis> There is a major problem getting keys.
[16:54:16] <DouglasOtis> .
[16:55:21] <gconnor> Actually layer1 is not built on layer0 :)
[16:55:44] <gconnor> layer0 is a way to catch people who are clearly lying about their HELO names, but it's not crucial to layer 1
[16:55:54] <jlcjohn> hmm.. How, then, do you trust any headers?
[16:56:40] <gconnor> My opinion is that if I trust a forwarding service with my mail, I should be able to trust the received lines added by their server. If the message is delivered to me from their IP...
[16:56:56] <DouglasOtis> http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-00.txt
[16:56:57] <willix> No you should not
[16:57:04] <jlcjohn> What about the received lines _before_ them?
[16:57:28] <gconnor> I would not want to trust lines added by an untrusted server
[16:58:09] <jlcjohn> What means "untrusted"?
[16:58:12] <gconnor> But, the received info added by (e.g.) pobox.com might be enough to tell me that the From: address was real, because the IP talking to pobox was authorized for that From: address
[16:58:13] <DouglasOtis> Although most spammers forge headers, the MTA is more readily detected.
[16:58:40] <mengwong> okay, i'll attempt to list all the crypto solutions i know of. PGP, GPG, S/MIME (both user-level and domain-level), Vanquish, Yahoo! DomainKeys, MS Postmarks, and Cisco's Identified Internet Mail.
[16:58:52] <mengwong> are there any others.
[16:59:24] * wrs1864 hadn't heard of the cisco one
[17:00:06] <gconnor> willix- do you have a reason to believe that IP info + trusted forwarder list is not enough to get validation of the previous hop details?
[17:00:37] <willix> cisco published it recently its rather strang adaptation of parts of s/mime into domainkeys like headers with public keys being passed along the message and requirements to run independent and yet undefined verification server that will use fingerprints to verify the public key is correct
[17:01:03] <DouglasOtis> And http to serve the keys...
[17:01:08] <gconnor> I mean, it's possible a crypto solution would do the end-to-end thing better, but is there something basically wrong with trusting the previous hop, once you establish the current hop is real?
[17:01:42] <willix> Can I pretend to be a spammer for a moment and tell you what I'd do :)
[17:01:49] <gconnor> ok
[17:02:44] <willix> I set up SPF record and pretent to be a forwarder. I setup domain with invalid whois. I forge email to have come from somebody else and forge all the received lines to have valid spf signatures as if I actually got the email and validated it
[17:03:02] <gconnor> ok good point
[17:03:22] --- molson has left: Disconnected
[17:03:34] <gconnor> would asking each user to select a list of "forwarders I trust" address that angle?
[17:04:01] <willix> Yes, that is called whitelist of forwarders. This is reputation service
[17:04:10] <gconnor> No I mean, each user
[17:04:14] <DouglasOtis> Without trusting the MTA nothing can be trusted with respect to prior information collected in the headers...
[17:04:46] --- thwarted has left
[17:06:01] <gconnor> When I set up a forwarding address, I will probably get a lot of mail in which my own address (gconnor@pobox.com) is the PRD. For those users, MARID will always return "OK everything checks out there chief, this message really is, uh, from you"
[17:06:23] <gconnor> I am interested in taking that to the next level... if possible
[17:07:01] <willix> You can trust the last hop right before what is picked up by your POP3 or IMAP (i.e. your ISP). I would not go any futher then that.
[17:07:31] <DouglasOtis> In the real world not everyone has VPN to their outbound SMTP machine. They will use the valiable server and in some cases be forced to do so...
[17:08:13] <DouglasOtis> There will be thousands of these machines.
[17:08:34] <gconnor> ok.. that is what I am trying to understand... why would you not want to trust what the forwarding service recorded, if they are acting on your behalf?
[17:09:43] <willix> It is acceptable mechanism on per-user basis as long as you can reasonably verify that email really came through that forwarder and was not forged by somebody else on the way directly to your ISP
[17:10:20] <willix> Acceptable would be for forwarder to add crypto header that is actually signed by your public key
[17:10:34] <jlcjohn> gconnor: I miss the connection: why _would_ you want to trust them, except simply to forward?
[17:10:37] <willix> Then I trust that it reall came through that forwarder which acted on my behelf
[17:11:25] <gconnor> jlc- In the case where I have a forwarding address, and all my mail goes to gconnor@pobox.com and then forwards... Marid doesn't really do anything for me, does it?
[17:11:54] <gconnor> As compared to, if I get mail directly to gconnor@nekodojo.org, most of the time I can check the sender's IP myself
[17:12:07] <gconnor> that is the issue I am trying to address if possible
[17:12:11] <jlcjohn> <sidestepping that flamewar> You want to trust them to forward; but you're probably unaware of their internal policies.
[17:12:47] --- fenton has joined
[17:12:58] <gconnor> Right, but they wouldn't add fake received lines woudl they? :)
[17:13:05] <jlcjohn> (IOW, the end user doesn't _know_ whether they record headers well.)
[17:13:49] <jlcjohn> There's a wide variety of header-checking -- it doesn't have to be forgery to be useless for us.
[17:15:07] <gconnor> OK. I'm sensing some "not quite comfortable with this idea". anyone else agree with willix (that you should only trust the IP info you see currently connected) or jlc (that the info will probably be unreliable)
[17:15:16] <Aredridel> gconnor, you'd like to see a sort of record (in DNS?) that let a domain say what checks it performs, and a way to put that in the message headers?
[17:16:15] <gconnor> Possibly. For example SPF defines a header Received-SPF:.. But I would actually settle for a normal-looking received line, as long as it's on a server owned by the forwarding agent
[17:16:29] <DouglasOtis> Yes of course. Without encryption the only trust that can be established is with information that is not easily spoofed.
[17:16:56] <gconnor> The caveat would be, it's a forwarder I personally trust, because I set up the account, and I know the message is coming through them, because their IP checks out with standard MARID
[17:16:56] <Aredridel> Yes.
[17:17:03] * Aredridel nods.
[17:18:10] <DouglasOtis> That concept of setting up before hand all possible sources for someone's mail is not very practical. A DNS record may takes days to be renewed.
[17:19:08] <gconnor> Here are my reasons for wanting to pursue this. 1. Marid validates the PRA by IP. If we stop at that, anyone who uses forwarding will not get the benefit of MARID to validate the From: or Sender:. The forwarding agent still can do the check at their edge, but my MUA will not mark the From: or Sender: as trusted... ever. Is this an acceptable outcome for Marid?
[17:19:51] <Aredridel> Not particularly, but it does cover a lot of people.
[17:20:28] <Aredridel> What about a shared-key crypto between forwarder and client? Something very simple, a simple validator and header-field selector.
[17:20:32] <fenton> Has anyone considered the possibility that the attacker may hijack address space, or guess TCP sequence numbers, to spoof the source IP address?
[17:20:38] <Aredridel> If it were standardized, it could be very useful.
[17:20:49] <mengwong> several times, yea
[17:20:54] <Aredridel> fenton, yes -- but not in the general sense.
[17:20:59] <willix> gconnor: what you want REQUIRES recepient mta to also support marid and do validation of the forwarder's ip. That is great and in that case the end-user will see that its MARID validated already
[17:21:26] <gconnor> 2. I'm not talking about "all possible senders"... I'm talking about very specific forwarding relationships that the receiver has set up. If the sender does some funny business on their side, I would expect that to be covered by their Marid record. My main theory is that you are either an agent for the sender, or an agent for the receiver. If you are neither, you have no business handling the mail. That is something a bit narrower than "mail could come from anywhere and I don't want to have to list all those places ahead of time"
[17:21:29] <Aredridel> willix: only if there's a way to communicate that ~securrely to the MUA
[17:22:14] <Aredridel> gconnor, agreed. That's a reasonable scheme, I think. I can't think of a good thing that works otherwise.
[17:22:23] <willix> yes. Note to future of the group: how to securily communicate to MUA about MARID
[17:23:06] <gconnor> willix- Yes. From a marketing angle, I would like users to start seeing little green checkmarks in their email saying "This address was verified". I think this is a more positive focus than just "stop forgery" and I think it will sell well... but we are leaving forwarding out, and to an extent leaving mailing lists out too
[17:23:07] <fenton> willix: What sort of security do you need after MARID check?
[17:23:17] <Aredridel> Would a header-authenticator be something to spec out? Perhaps under another WG? (has something like that been proposed to the ASRG?)
[17:24:20] <willix> not exactly proposed I've messed around with idea of putting signatures at the end of extended received headers
[17:24:27] <Aredridel> Hm.
[17:24:32] <gconnor> Given that marketing angle, I think forwarders would be willing to put headers in, if we give them a format to use. If they are already doing the Marid check at their edge, that's a good feature, and their users will want to see that and benefit from it
[17:24:36] <Aredridel> (Something like Header-Validator: by mta.example.com Received=deadbeef From=deadbeef ?
[17:25:03] <Aredridel> AAargh.
[17:25:11] <Aredridel> Oops. Wrong window. Apollogies.
[17:25:19] <fenton> Wouldn't the path from the MARID check to the recipient have to be trusted? Why not just add an unauthenticated header?
[17:25:55] <gconnor> Fenton- Right... The forwarder has to be trusted AND their IP must check out
[17:26:33] <fenton> But the recipient is trusting the path between the MARID checker and itself...otherwise the spammer can insert messages there
[17:26:54] <gconnor> I dont' understand what you mean?
[17:27:24] <gconnor> Say for example my forwarding address is gconnor@pobox.com and my real mail is gconnor@gconnor.com
[17:27:31] <Aredridel> True -- in the case of a malicious forwarder [so hold them responsible], or an agent of the sender [so hold them responsible...]
[17:27:33] <gconnor> where would the spammer inject bad data?
[17:27:37] <fenton> I'm wondering why you can't just add a header that says the MARID check was OK, no authentication, and leave it at that...as long as the MARID checker removed any such headers it received.
[17:27:41] <willix> Basicly what you want is to have capability to have list of specially trusted marid mtas, the first one by default is your ISP if it supports it. If that checked our record ok, you go down the list of received headers and see if the one down the list is also in your list of trusted mtas. That is kind of additional whitelisting capabilities for MUAs
[17:27:52] <Aredridel> gconnor, I agree. It's not crypto, but it's deployable.
[17:28:03] <willix> for MTAs
[17:28:23] <Aredridel> fenton, not a bad idea. Lightweight.
[17:28:49] <gconnor> willix- Right. I would only trust the Received: (and related) data recorded by someone I trust, and only then if their path to me is all trusted
[17:29:08] <mengwong> the whole trust path thing can get ooky quickly.
[17:29:34] <fenton> Got a good ooky example?
[17:30:06] <gconnor> fenton- I agree with the reason behind removing the previous Marid header. I guess I'm saying, if it was added by a trusted party, I could use their info, but that would have to be a tight list of who I decide to trust
[17:30:21] <mengwong> hard to distinguish a -> b -> c -> d from spammer-pretending-to-be-a -> c -> d
[17:30:44] <gconnor> Meng- don't shoot me down here, these are your customers we're trying to sell this to :)
[17:30:53] <fenton> gconnor: Yes, it needs to be a short list, but it should just be the incoming MTAs for your domain, right?
[17:30:56] <mengwong> sorry, i'm not all caught up on scrollback
[17:31:29] <gconnor> Fenton- Right, though if all my mail comes from a forwarding service, that would be a next logical step.
[17:31:50] <fenton> gconnor: Still sounds like a short list
[17:32:02] <gconnor> Right, it has to be.
[17:32:08] <willix> I think it has limited scope for few end-users, I'm not sure this requires standartization and can be considered MUA feature
[17:32:49] <gconnor> Most forwarders already add something like X-Delivered-To or X-Forwarded-by or something like that, right? wasn't that the point of defining the PRA with all those headers?
[17:33:00] <fenton> willix: I think it's good to allow end-users to implement their own policy about what do with messages that don't MARID-verify
[17:33:08] <mengwong> i'll catch up later, time for dinner
[17:33:13] <gconnor> ok meng later
[17:34:12] --- mengwong has left: Disconnected
[17:34:13] <gconnor> Anyway, maybe it really is just an extension of whitelisting other mail servers that might handle my mail.
[17:34:42] <gconnor> I just want forwarding users to enjoy the benefits of marid too :)
[17:35:22] <Aredridel> Hm. Yeah.
[17:35:29] <fenton> The problem is, if I'm an individual user on some big domain, how do I tell my domain MARID checker to trust my forwarder?
[17:35:52] <Aredridel> Right. That's the real catch.
[17:37:22] <gconnor> good point. Perhaps Marid would just record the current (layer 1) info and it's up to the MUA to grovel through and see what is trusted?
[17:37:35] <Aredridel> Ah, drat. My server calls. Someone has decided to use very poor SQL and it's killing the server.
[17:37:36] <Aredridel> Tata.
[17:37:40] --- Aredridel has left
[17:37:47] --- DouglasOtis has left
[17:38:23] <gconnor> OK that was all I had... let's wrap
[17:38:30] <gconnor> I will summarize for the list
[17:38:33] --- dcrocker has joined
[17:39:32] <willix> gconner: right, focus on MUA. Have them add in additional to SPF green check additional green check (double check, tripple check) if it came through known good list of forwaras specified in that MUA and all confirmed by MARID
[17:39:54] <gconnor> cool
[17:39:59] <gconnor> Hi dave!
[17:39:59] <willix> sorry for bad spelling, but you got the idea...
[17:40:28] <willix> I'll leave as well. Time to get back to the DC work
[17:41:21] <dcrocker> sorry for missing things. i'm in an interim multi6 meeting with almost no internet access.
[17:43:18] <gconnor> no problem :)
[17:43:26] <gconnor> what is multi6?
[17:44:15] <willix> dcrocker: Ah, you mean they implemented different ip6 only non-bgp multi-path and roaming capabilities just to test how the group is doing?
[17:44:33] <willix> :)
[17:44:56] <willix> Sorry, now I'm really leaving.
[17:46:33] --- willix has left
[17:52:12] --- fenton has left: Disconnected
[18:07:01] --- willix has joined
[18:07:29] --- willix has left
[18:12:15] --- gconnor has left
[18:16:58] --- SamSilberman has left: Disconnected
[18:36:58] --- ghewgill has left
[18:55:16] --- SamSilberman has joined
[19:04:08] --- dcrocker has left: Disconnected
[20:13:47] --- SamSilberman has left: Disconnected
[20:58:54] --- wrs1864 has left