[14:30:12] --- DOtis has joined
[14:38:22] --- mrose has joined
[14:40:34] <DOtis> Hello Marshall. Why are the open-ended XML records still included within the core document?
[14:41:20] <mrose> because a new version of that document is being published this week, without them.
[14:41:56] <DOtis> Thanks.
[14:44:34] --- tonyhansen has joined
[14:44:49] --- mengwong has joined
[14:45:31] * mengwong reading http://www.itu.int/osg/spu/spam/presentations/LEVINE_Session%203.pdf
[14:49:05] --- andy has joined
[14:50:01] <andy> we probably ought to give people five minutes.
[14:50:08] <mrose> agreed
[14:53:24] <DOtis> Did anyone understand the network instability issue regarding the abbreviated DNS lookup timeouts and the use of RFC2822 identities to reject messages?
[14:53:29] --- Harry has joined
[14:54:34] <andy> I think that is your answer.
[14:54:58] <mrose> let's get started.
[14:55:11] <mrose> hands-free mic at this point (i.e., no protocol).
[14:55:18] <mrose> andy - could you introduce the first topic?
[14:55:44] <andy> yes. We'd first like to talk about a non-technical working group issue.
[14:56:18] <andy> It has been brought to our attention that their is a company that has or is trademarking the name "SenderID" for use in an anti-spam product.
[14:56:38] <andy> They have registered it in the UK apparently.
[14:57:17] <andy> We are currently seeking legal advice from the IETF lawyers, however the decision to go forward with "SenderID" is a decision this working group must make.
[14:57:19] --- wrs1864 has joined
[14:57:37] <andy> So, are there any thoughts on this?
[14:57:54] --- justthisguy has joined
[14:57:59] <DOtis> Back to SPF?
[14:58:36] <Harry> Microsoft attorneys did conduct a trademark search and found none registered.
[14:58:58] <mengwong> http://www.senderid.org/ is the site that i found.
[14:59:15] <Harry> I have asked our legal department to confirm this. I suggest we wait for both the IETF and MSFT legal folks to confirm.
[14:59:32] <andy> http://webdb4.patent.gov.uk/tm/number?detailsrequested=C&trademark=2367652
[14:59:36] <tonyhansen> too much baggage for the SPF name (consider someone asking, were you talking about the old SPF or the new SPF?)
[15:00:02] <DOtis> SPFv2
[15:00:15] <andy> We are talking about the drafts this working group will produce.
[15:00:25] <andy> (not the CSV drafts obviously).
[15:00:51] <andy> what is currently marid-core, and a new draft describing the record syntax.
[15:01:15] <andy> Does anyone object with Harry's plan to wait and see?
[15:01:37] <DOtis> Sender-Domain-Verification SDV
[15:02:49] <andy> Given the past history of this group, I would have thought there would be more opinions.
[15:02:55] <mengwong> if the DNS record contains v=spf1, i think we should keep calling it the SPF record.
[15:03:05] <DOtis> The domain is expected to verify the ID. That they do not for the most part should limit the claim of ID anyway.
[15:03:15] <wrs1864> re: SenderID I thought everyone knew about MailKey's use of the name. They had started using it before the interim meeting... IANAL, but I also thought that all you need to trademark things was to use the mark in trade. (registering gives more legal rights though)
[15:03:40] <mengwong> the Sender ID name should be used for the overall architecture involving the PRA and so on.
[15:04:14] <mengwong> so maybe people will end up saying "you run a Sender ID test based on the SPF record".
[15:05:03] <DOtis> Again, that seems a bit miss leading. The check only goes to the domain. The domain _may_ check the ID.
[15:05:07] <andy> I'm not sure that is the way we want to present things, otherwise it might also be "you run a CSV test based on the SPF record."
[15:05:43] <mengwong> who knows, maybe people will run a CSV test based on the SPF record :)
[15:06:07] <andy> Well, that certainly is not the intent of the working group.
[15:06:36] <DOtis> Perhaps simply change ID for domain.
[15:06:45] <DOtis> That seems more accurate.
[15:07:17] * wrs1864 can't get worked up over a name
[15:07:21] * wrs1864 isn't in marketing
[15:08:33] <DOtis> Sender-Domain or Sender-D.
[15:08:59] <wrs1864> SPF-ID
[15:09:12] <mrose> ok, time to move on. for now, we'll wait to hear what the ietf's lawyers say. hopefully we'll have an answer before the next set of drafts are produced in san diego. we don't have to decide now.
[15:09:26] <andy> I agree.
[15:10:04] <andy> Topic two: the design team meeting.
[15:10:46] <andy> Just to let everyone know, the small design team which met last week did a very good job and made a lot of progress.
[15:11:35] <andy> The record describing the SPF syntax was submitted and the submitter and marid-core drafts will be updated and submitted before the deadline next week.
[15:11:42] --- mtnviewmark has joined
[15:12:46] <andy> And so, for the rest of this jabberchat, we thought the appropriate subject would be "CSV"
[15:13:13] <DOtis> There are only a few changes with the Intro document that Dave is working on.
[15:13:25] <wrs1864> What will be in the marid-core draft?
[15:13:25] <DOtis> There are a few changes with the DNA.
[15:13:34] <wrs1864> (nevermind)
[15:13:37] --- jlcjohn has joined
[15:13:48] <DOtis> Great.
[15:14:18] <andy> Doug, is that end of the summary of changes?
[15:15:05] <DOtis> Well, I think John may continue on the DNA.
[15:15:34] <andy> Well, why don't we see if anybody has any open issues with CSV.
[15:15:38] <jlcjohn> umm... I just got out of a tax-department hearing -- dunno what has gone before.
[15:16:08] <DOtis> We had started talking about CSV. Do you want to review changes you have in mind for DNA?
[15:16:34] <jlcjohn> very few... actually I'm not sure we'll update it before the 18th.
[15:16:57] <wrs1864> DOtis: try as I might, I still have not figured out what CSV does that is so much different from SPF checking on the HELO domain.
[15:17:18] <DOtis> Well, there is a big difference.
[15:18:06] <DOtis> The accreditation is for the administration of the polices of the client SMTP.
[15:18:25] <DOtis> With SPF, there can be no negative accreditation.
[15:18:43] <DOtis> With SPF, there is no single responsible domain.
[15:19:16] <DOtis> In other words, with SPF, there is only the ability to filter messages and not accurately assign credit for messages good or bad.
[15:19:46] <DOtis> CSV only looks to assign credit to the domain running the server and ensuring the security and polices of the server.
[15:20:06] <DOtis> SPF can not assess the level of security as it can not track bad messages.
[15:20:07] <mtnviewmark> <rts> accrediation
[15:20:15] <DOtis> eot
[15:20:35] <andy> mark, we are in free-form mode so no need to rts.
[15:20:47] <mtnviewmark> Doug: Do you see this distinction as arising because CSV explicitly only looks at HELO
[15:21:00] <mtnviewmark> whereas SPF is so far a bit muddy on what it is being used for?
[15:21:29] <mtnviewmark> In otherwords, it is a matter of how clear the langauge is in the spec?
[15:21:32] <DOtis> It only looks to identify the domain of the SMTP server. SPF attempts to filter messages into grades.
[15:21:43] <DOtis> No.
[15:22:01] <DOtis> It is a matter of what what the dataset involves.
[15:22:13] <DOtis> SPF is a different dataset from that of CSV.
[15:22:30] <mtnviewmark> Ah, so it arrises because SPF says you are checking for each message if it could have come from that server, whereas CSV is checking HELO for the session
[15:22:32] <mengwong> doug, just so we have some common ground, can you tell me which version of the SPF spec you're using as a basis for your discussion? there have been a number of evolutions recently.
[15:23:10] <DOtis> Meng, tell me the one I should read.
[15:24:00] <mtnviewmark> Surely the published info is simliar in both cases: The domain publishes a record that partitions all IPs in permitted and not permitted sets in both cases
[15:24:13] <mtnviewmark> (admittedly, SPF does allow a few other buckets)
[15:24:46] <DOtis> The datasets are not the same. They are not functionally the same. They do not do the same thing.
[15:24:47] <mtnviewmark> (and SPF does allow, via the macro facility, the partition to take into account the localpart of the mail address)
[15:25:03] <mtnviewmark> Okay, then let me see if I've got CSV right
[15:25:30] <mtnviewmark> The domain publishes a SRV record to indicate which set of IP addresses are allowed to use that domain name in HELO, and which IP address are not
[15:25:33] <mtnviewmark> yes?
[15:25:55] <jlcjohn> no
[15:26:23] <jlcjohn> The SRV fundamentally says a domain-name is authorized.
[15:26:43] <jlcjohn> the IP addresses come along for the ride, just like an Address query.
[15:27:00] <jlcjohn> ,eor.
[15:27:06] <jlcjohn> eot, that was
[15:27:09] <mtnviewmark> Ah, is says it is authorized at all - the whole domain name, yes or no?
[15:27:34] <DOtis> The helo/ehlo host name.
[15:27:37] <jlcjohn> The domain-name as given in the EHLO, no more, no less.
[15:27:38] <mtnviewmark> And then it has the option of indicating a set of IPs that are authorized?
[15:28:05] <jlcjohn> As I said, the IP addresses are whatever the Address query would return.
[15:28:16] <mtnviewmark> so what is the semantic of the IP addresses?
[15:28:28] <jlcjohn> They're Address RRs
[15:28:40] <jlcjohn> possibly OT: We're starting a FAQ at http://www.jlc.net/MARID/CSV/FAQ.txt
[15:28:44] --- gconnor has joined
[15:29:22] <mtnviewmark> Is there nothing that ties or restricts which IPs can use the HELO?
[15:29:22] <wrs1864> what do you do with the Address RR? or are they just "wasted" bandwidth?
[15:29:59] <jlcjohn> Typically, the Address RR's are check to see if the EHLO string matches the remote IP address.
[15:30:12] <jlcjohn> If so, that counts as "authentication" of the EHLO string.
[15:30:26] <mtnviewmark> what if they don't?
[15:30:58] <jlcjohn> Then authentication has failed. The EHLO string must be considered unauthenticated, and thus suspect.
[15:31:03] <mtnviewmark> Ah - so
[15:31:45] <mtnviewmark> The CSV SRV record says whether or not a domain name is authorized to be used in HELO -- and if any IP address come along too, then it only counts if the client server has one of them
[15:32:25] <jlcjohn> Mostly yes.
[15:33:04] <jlcjohn> <eot>
[15:33:25] <DOtis> The goal is to establish what domain is accountable for the mail stream. Not for any single message. Accreditation must be able to assign both good and bad messages.
[15:33:31] <mtnviewmark> okay - this seems exactly isomorphic to the SPF record (when applied to HELO) saying "this domain name is allowed to be used for HELO if it is in this set of IPs" whre the set is constructed from the SPF mechanisms
[15:33:38] <mengwong> the "unified" set of drafts were written as an academic exercise. they attempt only to sketch out some theory. they go beyond the current SenderID effort in MARID, but I believe they are worth reviewing because they show a possible direction for future evolution. doug: a recent set of documents can be found at http://spf.pobox.com/unified/ . if i were you, i would read 1, 3, and 5 first. together, they represent protocol+SPF/HELO which we see as a credible alternative implementation of CSV. example: mta2.example.com TXT "v=spf1 a -all", and the nameserver returns the set of mta2.example.com's A records in "additional data".
[15:34:53] <wrs1864> DOtis: I think it was Chris Lewis on SPAM-L that posted some interesting stats a while back. the vast majority of SMTP sessions only send one email and sending more than a half dozen emails in one session is a very strong spam indicator.
[15:35:11] <mtnviewmark> As far as the mechanics of the record, I think CSV, and an SPF record applied to HELO represent the same abilities -- though I recognize that we might find differences in the strength of the claims in the text of the proposals
[15:35:45] <mengwong> the CSV approach is admittedly simpler and more efficient, not requiring parsing of the SPF record.
[15:35:53] <DOtis> They are not the same dataset and as such can not offer the same results.
[15:35:57] <mtnviewmark> I am all in favor of the CSV clear and strict concepts of authorization and authentication -
[15:36:21] <mengwong> they are the same dataset if we deem them to be the same dataset.
[15:36:27] <mtnviewmark> I just think we should re-use the format and use the SPF format for both (though some macros wouldn't be valid for HELO authorization)
[15:36:43] <DOtis> They are not the same dataset if the goals are different.
[15:36:46] <gconnor> dotis... what if the record was "v=sfp1-helo xxxx" would that solve the objection that they are not the same dataset and therefore should not be used in the same way?
[15:37:06] <DOtis> What is the point?
[15:37:14] <mtnviewmark> Ah, so is the issue that you are concerned that example.com's SPF record can't be used for BOTH a mail message check and a HELO check?
[15:37:14] <wrs1864> code reuse
[15:37:27] <jlcjohn> How can we make it clear that the "general-purpose" SPF record is inappropriate for EHLO verification.
[15:37:29] <gconnor> By that I mean, you can publish any text record you like, the spec and the agreement between admins is what "defines" what it "means"
[15:37:31] <DOtis> You have a greater risk of the wrong record used just to spoof.
[15:37:36] <mtnviewmark> why not locate SPF format records that are to be used for CSV HELO checks at _csv.example.com?
[15:37:52] <DOtis> You have a greater risk of the IT manager not getting the sets straight.
[15:37:59] <mtnviewmark> Ah -
[15:38:02] <gconnor> ok lets explore that a bit
[15:38:03] <DOtis> You will need two records anyway.
[15:38:14] <gconnor> let me ask another question for doug or john
[15:38:17] <mtnviewmark> Yet that poor IT guy now has to learn two systems of encoding...
[15:38:45] <DOtis> I would hope there is already some knowledge regarding SRV records.
[15:38:55] <gconnor> What if they were a way to specify in the record two different sets: the set of machines I Actually Own, and the set of machines I Don't Own But Are Permitted To Use the name
[15:39:04] <jlcjohn> (We give an example of the SRV in the FAQ)
[15:39:06] <gconnor> Would that help clarify "responsible" domain?
[15:39:09] <wrs1864> I suspect that most people don't use SRV records...
[15:39:09] <mtnviewmark> Actually, the IT guys get it right now for SPF
[15:39:27] <DOtis> SPF would be wrong for CSV.
[15:39:29] <mtnviewmark> With currently deployed SPF you need one record for your HELO domain names and one for your mail domains
[15:39:36] <DOtis> SPF dataset is not the same.
[15:39:44] <gconnor> That's what I'm trying to explore, Doug. Can you answer my question?
[15:39:55] <mtnviewmark> people deploy two records, with different meanings, with the same syntax, and get it right all the time
[15:40:19] <DOtis> Why take the chance of allowing a spoof method?
[15:40:30] <DOtis> Why take the chance of needing more queries.
[15:40:34] <gconnor> No, the question was What if they were a way to specify in the record two different sets: the set of machines I Actually Own, and the set of machines I Don't Own But Are Permitted To Use the name
[15:40:53] <jlcjohn> (is that two sets in the _same_ record?
[15:40:59] <mtnviewmark> Er, whre those "why take a chance..." really concerns with the SPF format?
[15:41:06] <gconnor> I'm trying to get at WHY you insist the sets are so different. Is it because the spec says they should be used for a different purpose?
[15:41:23] <gconnor> jlc: Yes, assume two sets in the same record
[15:41:29] <DOtis> They are used for different purposes.
[15:41:37] <mtnviewmark> No - people with SPF deploy two records, with different sets, right now: they need to
[15:41:56] <gconnor> If they are used for different purposes, does that mean they will normally be different?
[15:42:05] <mtnviewmark> my record for mx.glyphic.com is "v=spf1 +a -all" and the record for glyphic.com is "v=spf1 +mx -all"
[15:42:18] <wrs1864> right
[15:42:31] <DOtis> You have no control what someone uses in their HELO domain.
[15:42:42] <DOtis> You can not control which record is used for what.
[15:42:50] <DOtis> You have only made a mess.
[15:42:54] <jlcjohn> gconnor: I see only authorization so far; how do we authenticate?
[15:43:00] <mtnviewmark> Now, it turns out, I couldn't get anyone to give me a reasonable example where these records needed to be different: "v=spf1 +mx -all" works for both, though it is a bit liberal for mx.glyphic.com
[15:43:06] <gconnor> Doug. Here is the question again because I can't tell if you answered it: What if they were a way to specify in the record two different sets: the set of machines I Actually Own, and the set of machines I Don't Own But Are Permitted To Use the name?
[15:43:15] <mtnviewmark> What?
[15:43:17] <gconnor> jlc- you may answer that as well
[15:43:23] <mtnviewmark> Of course you control what is used for what:
[15:43:34] <mtnviewmark> "v=spf1 +a -all" is published under mx.glyphic.com
[15:43:46] <mtnviewmark> "v=spf1 +mx -all" is published under glyphic.com
[15:43:53] <DOtis> You can not control what someone puts in their HELO domain.
[15:43:59] <mtnviewmark> these records never both come back for the same query.
[15:44:02] <mengwong> Yeah, but ... they can.
[15:44:03] <DOtis> You can not be sure which record is used.
[15:44:11] <mtnviewmark> Ah, for which purpose?
[15:44:18] <gconnor> No, I mean two sets defined by the same record...
[15:44:19] <mtnviewmark> Is that the crux of the problem?
[15:44:40] <DOtis> There are two conversations that seem to overlap.
[15:45:03] <andy> yes there are.
[15:45:13] <gconnor> ok. Doug. Ignore mark for a second. Answer my question.
[15:45:14] <andy> Let's limit it to Mark's line of questions.
[15:45:20] <mtnviewmark> :-)
[15:45:23] <gconnor> Or that.. I can wait.
[15:45:30] <andy> thanks, greg.
[15:45:36] <gconnor> go mark
[15:46:15] <jlcjohn> (I don't understand what QNAME we use to get the EHLO SPF record.)
[15:46:16] <mtnviewmark> Okay, so, the concern seems to hinge on the issue that the same format is used to publish statements about two different things - the HELO set and the MAIL-FROM (or PRA) set ...
[15:46:31] <mtnviewmark> jlcjohn: you use the EHLO name
[15:46:51] <jlcjohn> And is that returning the +a -all?
[15:46:58] <mtnviewmark> yes
[15:47:17] <mtnviewmark> AND so, yes, if someone sends mail with "bob@mx.glyphic.com", that record gets mis-used for the other purpose
[15:47:32] <mtnviewmark> If this is the crux of the problem, then I have two possible fixes for it
[15:47:32] <jlcjohn> Is the idea that we do a separate Address query to authenticate?
[15:47:50] <gconnor> let's verify if that is the crux of the problem first
[15:48:10] <gconnor> jlc, what do you mean by separate address query?
[15:48:21] <jlcjohn> Dunno if it's the "crux" but it worries me.
[15:48:31] <mtnviewmark> (and vice-versa, publishing "v=spf1 +mx -all" for glyphic.com will get used if someone uses glyphic.com in HELO, and it will be mis-applied as a HELO check)
[15:48:49] <mtnviewmark> OKAY, well, then, assuming it is a big worry
[15:49:19] <jlcjohn> gordon: Authentication of the EHLO string is necessary, IMHO.
[15:49:37] <mtnviewmark> 1) we could fix this with a bit of syntax where the record is marked for what scope it is valid for. (This forwards my goal of having one syntax)
[15:49:44] * gconnor is greg btw
[15:50:38] <mtnviewmark> 2) we could fix this by using domain name prefixes: _helo.mx.glyhpic.com and _from.glyphic.com -- so that when _from.mx.glyphic.com is queried there is no record, similarly for _helo.glyphc.com)
[15:51:02] <DOtis> There are several problems with SPF. As I reviewed with the number of possible queries. But beyond that, these are two separate functions and there is little to no benefit trying to use a text record to do what a SRV record already does. The utilities to handle this record already exist within hundreds of programming languages. There would be no danger of these records becoming mixed. The scope of the SPF is too large to be safe for use with CSV in my opinion as well.
[15:51:25] <mtnviewmark> 3) I've tried to find a case where mis-interpreting the record leads to a real security issue - no one has been able to come up with one
[15:51:35] <gconnor> Doug- We are trying to focus on one specific aspect, can you save that line of comment for later?
[15:52:08] <DOtis> One record is open +all and the one intended is closed. The one for the HELO domain wanted to use closed, but the attacker pointed to the open list.
[15:52:10] <mtnviewmark> I recognize that option 3 is going to be a hard sell - but I truly believe it
[15:52:28] <mtnviewmark> neither ends in +all...
[15:52:39] <jlcjohn> (I'm having a great deal of difficulty figuring what we do with a EHLO SPF record that says anything other than +a -all...)
[15:53:17] <DOtis> And of course, there must be more DNS queries where you are left in the boat that does not work already.
[15:53:20] <gconnor> I can answer that jlc, but I'm waiting for my question to come back around :)
[15:53:36] <mtnviewmark> jlcjohn- that record says: the only host authorized to use this domain name in HELO/EHLO is the one whos IP is listed in the A (or AAAA) records for this domain name
[15:53:59] <mtnviewmark> oh
[15:54:04] <mtnviewmark> oops, other than...
[15:54:27] <mtnviewmark> there is the record "v=spf1 -all"
[15:54:38] <mtnviewmark> for things that shouldn't do HELO
[15:54:52] <mtnviewmark> but yes, you are right, "v=spf1 +a -all" is the 99% case
[15:55:03] <andy> Just to interject, I think that is John's point.
[15:55:11] <mtnviewmark> taken -
[15:55:12] <DOtis> We have that case now, but it has a flaw.
[15:55:18] <jlcjohn> How would you publish, "this domain shouldn't send mail?
[15:55:31] <mtnviewmark> "v=spf1 -all"
[15:55:52] <jlcjohn> Is there any other useful case?
[15:56:02] <gconnor> case of what?
[15:56:33] <jlcjohn> ... than those two...
[15:56:42] <mtnviewmark> There are domains that don't use the host name in HELO - but I realize you'd call them errant
[15:57:04] <jlcjohn> For those, how would we do the lookup?
[15:57:39] <mtnviewmark> In the name given - so say example.com uses mail.example.com in the HELO, but the machines are really mx1.example.com etc...
[15:57:45] <andy> I think both Mark and John have come eyeball-to-eyeball with their respective concepts and will probably need to circle back to see where that leaves each.
[15:57:58] <mengwong> whoa, eyeballs.
[15:58:08] <andy> Because of time, Greg do you still feel your question must be answered?
[15:58:22] <mtnviewmark> under mail.example.com publish "v=spf1 +a:mx1.example.com +a:mx2.example.com -all"
[15:58:33] <gconnor> Well. yes but we can take it to the list.
[15:58:47] <mtnviewmark> okay - thanks andy - onward to greg...
[15:59:19] <gconnor> If we can keep talking for another 15 min I think we can at least figure out where the disagreement is?
[15:59:26] --- justthisguy has left: Disconnected
[15:59:32] <andy> Well, I am not sure any minds have been changed, but I do think the two camps are seeing each others positions more easily.
[15:59:41] <wrs1864> agreed
[15:59:51] <wrs1864> I'm still confused by what the difference is supposed to be.
[15:59:55] <gconnor> I don't understand doug's position very well actually
[15:59:55] <andy> While that may not seem like progress, its much better than just talking past each other which is where we usually end up.
[16:00:17] <mtnviewmark> I think doug has pointed out that SPF syntax is probably overkill in the 95% case -
[16:00:28] <mtnviewmark> or rather John has
[16:00:36] <DOtis> 99.9%
[16:00:57] <jlcjohn> Actually, I'm more worried than just "overkill" -- we need to define what we do with the other cases.
[16:01:12] <DOtis> The spf example does not go past the present state of affairs that the SRV record is trying to fix.
[16:01:18] <gconnor> What I am not understanding here is WHY are they different? Because we said so in the spec? Because one is TXT and the other is SRV?
[16:01:19] <andy> Mark & John, can you two chat offline to see if you can take this further.
[16:01:20] <andy> ?
[16:01:50] <gconnor> I am available to stay for a bit longer if people want to
[16:01:58] <andy> To be clear, that was a question not a command.
[16:02:05] <jlcjohn> andy: I'm willing...
[16:02:29] <wrs1864> I'm willing to take over for Mark if he has to leave
[16:02:38] <mtnviewmark> mark has to leave, alas...
[16:02:57] <andy> I didn't mean now... but sometime in the future.
[16:03:20] <andy> There has been a lot of talking past each other from all sides, and I think you two had the biggest break throughs today.
[16:03:25] <jlcjohn> (we've exchanged email addresses.)
[16:03:29] <andy> cool.
[16:03:48] <andy> Thanks everybody for attending. Naturally, you are free to hang out and chat.
[16:04:02] <gconnor> ok thanks andy!
[16:04:08] --- andy has left
[16:05:35] <wrs1864> Ok, I can understand for the purposes of HELO checking only, the SRV record is more efficient.
[16:05:46] <jlcjohn> I believe so
[16:06:00] <wrs1864> I still don't see the semantic differences though
[16:06:26] <gconnor> Here is a hypothesis.
[16:06:33] <jlcjohn> I'm not sure I can help you: I've tried to be very clear about the SRV semantics; but I'm not clear about SPF semantics.
[16:07:06] * wrs1864 passes the ball to gconnor
[16:07:39] <wrs1864> (John, I know you have tried to be clear. I *think* I understand both, and I don't see the difference.)
[16:07:49] <gconnor> What Doug and Jlc describe as "the difference between spf and csv records" I would instead describe as "the difference between + and ?" - it boils down to "do you trust this IP completely and are you willing to take responsibility for its actions" vs. "just allowing someone else to use the name"
[16:08:16] <gconnor> is that right, jlc?
[16:08:21] <jlcjohn> Yes. (I don't see how to read "+" to mean that, though.)
[16:08:26] <DOtis> No. Is this the domain that is accountable for the mail stream is a different question to answer.
[16:08:42] <DOtis> It has nothing to do with trusting a message that verifies.
[16:08:46] <gconnor> Doug, explain?
[16:09:02] <gconnor> Why is it a different question to answer?
[16:09:12] <DOtis> You find a positive match only with SPF. In that the message is a member of a set.
[16:09:31] <DOtis> CSV only checks for a single party being accountable.
[16:09:55] <DOtis> It ensures both the authorization and Authentication of that accountable entity.
[16:10:14] <DOtis> SPF missing that goal while looking for a message being a member of a set.
[16:10:31] <gconnor> ok. You said "it is a different question to answer". What are the two questions, if different from what I said?
[16:10:54] <DOtis> One is asking, is this message a member of a set?
[16:10:55] <gconnor> is it because it is per message and not per mta-persistent-name?
[16:11:16] <DOtis> The other is asking is this MTA authenticated and authorized?
[16:11:28] <gconnor> ok let me see if I understand what you are saying
[16:11:31] <DOtis> No. The set of information is different.
[16:12:04] <DOtis> You create a full set to answer questions regarding a message that are wholly different from the channel.
[16:12:07] <gconnor> CSV attempts to answer "is this MTA authorized and authenticated, based on HELO name and IP" correct?
[16:12:18] <DOtis> The channel is independent of the question regarding the message.
[16:12:39] <gconnor> ok I think I am getting it. If so can you answer Yes?
[16:13:09] <DOtis> I am not sure what you are getting?
[16:13:25] <gconnor> ok. CSV attempts to answer "is this MTA authorized and authenticated, based on HELO name and IP" correct?
[16:13:57] <DOtis> Yes, but this was tried before and failed. This is an attempt to repair a simple problem.
[16:14:09] <DOtis> A problem not repaired with your spf example.
[16:14:13] <gconnor> wait a second.. are you trying to answer my question or trying to make another point?
[16:14:33] <DOtis> Sorry for getting ahead I guess.
[16:15:23] <jlcjohn> (It's not _only_ a matter of EHLO and IP: we need a statement of authorization.)
[16:15:35] <DOtis> As I said, CSV attempts to do two things in a simple but effective fashion. Authorize and Authenticate the MTA. Just the MTA, totally unrelated to the messages.
[16:15:53] <gconnor> ok. My question was, since you said there are two different questions being asked, what are those questions? Is it: "do you trust this IP completely and are you willing to take responsibility for its actions" vs. "just allowing someone else to use the name for a message"?
[16:16:47] <DOtis> No. Is this the domain accountable for the MTA with all messages good or bad. This is done through a process of authorization and authentication.
[16:17:14] <gconnor> OK. Since you answered NO...
[16:17:15] <DOtis> Trust would be a process of accreditation.
[16:17:34] <gconnor> I will ask you to state "The two different questions are __ and __"
[16:17:50] <wrs1864> Doug: The SPF checking of the HELO domain does, in effect, authenticate the MTA rather than the message
[16:18:11] <gconnor> wayne, you're getting ahead of things here, don't distract him
[16:18:35] <DOtis> SPF does not authenticate the MTA directly enough to allow accreditation and in fact this breaks down if the messages are questionable.
[16:19:06] <gconnor> ok. That doesn't answer the question but I am prepared to ask another. Were you done, trying to answer my first question?
[16:19:22] <DOtis> SPF asks the question is this message within a set of domains authorized to carry a message.
[16:19:54] <jlcjohn> (In general SPF syntax, that _is_ inevitable.)
[16:19:55] <DOtis> CSV asks the question is this MTA authorized and authenticated by the domain that manages policy to send outbound mail.
[16:20:06] <gconnor> ok... parsing
[16:21:41] <gconnor> Now.. If I understand you right, there is a different context, a different reason for the question, and a different set for the answer. But... are both of these questions of the form: authorized ( NAME, IP ) = YES, NO, UNKNOWN?
[16:22:26] <DOtis> We have been over this before. The verbs and answers overlooks the dataset.
[16:22:35] <gconnor> yes or no?
[16:23:00] <gconnor> am I getting the inputs and outputs right, for both?
[16:23:05] <jlcjohn> If I may answer, no.
[16:23:16] <gconnor> jlc - OK, explain
[16:23:28] <jlcjohn> That is, SPF is a function call; CSV isn't.
[16:23:50] <jlcjohn> Our intractable problem is that if we call the SPF function, a lot of baggage comes along for the ride.
[16:24:02] <jlcjohn> CSV is short and simple. <eot>
[16:24:31] <gconnor> ok set aside that for a second.. are the inputs and outputs the same?
[16:24:41] <DOtis> Authorized to carry a message over a set domains for SPF. Authorized by the domain to send outbound mail. Different datasets, different answers.
[16:25:14] <gconnor> Doug- that doesn't answer my question. Are the inputs and outputs the same?
[16:25:22] <DOtis> No.
[16:25:26] <gconnor> Explain.
[16:25:29] <DOtis> The verbs are not the same.
[16:25:40] <gconnor> ok. Are the inputs and outputs the same?
[16:25:47] <DOtis> The full definition of authorized is different.
[16:25:53] <gconnor> right.
[16:26:14] <gconnor> setting aside the context, are the inputs and outputs the same?
[16:26:34] <DOtis> The outputs can not be the same if working with a different dataset.
[16:26:41] <gconnor> Explain?
[16:26:57] <DOtis> The output does not mean the same thing and the verb does not mean the same thing.
[16:27:01] <gconnor> Are the outputs other than YES, NO, UNKNOWN?
[16:27:14] <wrs1864> or, give an example of when they will be different
[16:27:25] <DOtis> The answers are to different questions.
[16:27:35] <DOtis> Therefore they do not have the same meaning.
[16:27:35] <gconnor> ok. are you not understanding the question?
[16:27:55] <jlcjohn> CSV does not "return" "YES" or "NO" or "unknown
[16:27:57] <DOtis> I understand these questions to be different as are the datasets.
[16:28:24] <gconnor> OK. What is the question CSV attempts to answer?
[16:28:42] <gconnor> you said "CSV asks the question is this MTA authorized and authenticated by the domain that manages policy to send outbound mail." is that right?
[16:29:30] <DOtis> Is this MTA authorized by the domain that handles policy and Authenticated to send outbound mail to allow full accreditation of all messages good or bad.
[16:29:55] <gconnor> ok. Now. Can you tell me the inputs to that question?
[16:30:14] <gconnor> Are they (name, ip)?
[16:30:23] <DOtis> HELO/EHLO domain and the SRV record.
[16:30:36] <gconnor> No, srv record is a mechanism, not an input
[16:30:51] <gconnor> The inputs are (name, ip) correct?
[16:30:58] <jlcjohn> SRV is a critical information source.
[16:31:01] <DOtis> You are trapped into thinking of simplified verbs and responses. This overlooks the differences entirely.
[16:31:24] <jlcjohn> (Please think of this as an accreditor must consider it...)
[16:31:35] <gconnor> Look, this will take a lot longer if you don't use Yes or No answers
[16:31:56] <DOtis> You must stop thinking in these terms to make progress.
[16:32:07] <DOtis> This is not a function call.
[16:32:42] <gconnor> You can refuse to answer, or say I don't know. If you are going to try and answer me, it will be helpful if you say yes or no, so I can see what parts I am understanding correctly and what I am getting wrong
[16:33:35] <DOtis> It would be helpful if you stopped trying to reduce everything to this simplified model that overlooks the scope.
[16:34:41] <gconnor> What I am trying to do is to see if the "scope" is dependent on 1. the csv spec 2. the definition of what a SRV record means 3. how senders and receivers decide to use it, or 4. other...
[16:34:52] <DOtis> There are basic differences even if you attempt to say they all use the same verbs and answers. They use different definitions for those verbs and answers.
[16:35:03] <gconnor> You were not able to answer that question directly so I am trying to break it down.
[16:35:29] <gconnor> "They are different definitions". Explain? Why are they different?
[16:35:31] <jlcjohn> Please do break down that last question, I don't understand it.
[16:35:49] <jlcjohn> (the three-choice one)
[16:36:01] <jlcjohn> (sorry, four)
[16:36:34] <gconnor> The assertion is that SPF-mechanism is unsuitable for expressing what CSV expresses. That is what I am trying to understand. How and where is CSV defined, and by whom?
[16:36:54] <jlcjohn> draft-ietf-marid-csv...
[16:37:50] <gconnor> Ok. In the context that people might want to use CSV, would the basic elements of the transaction be the same whether it was a SRV record that says 1 or a TXT record that says YES
[16:38:29] <jlcjohn> Um... if we knew both records were answering the same question, they'd be equivalent.
[16:39:16] <DOtis> Almost, but there is more with SRV that just a single 1.
[16:39:19] <gconnor> Right. Now. I think I understand CSV well enough to say what question it is answering. What doug said is consistent with what I have learned up to now.
[16:39:57] <gconnor> What I am trying to understand is, is it the SEMANTICS of spf that are unacceptable for CSV, or the MECHANICS, or both?
[16:40:21] <jlcjohn> I don't understand the semantics well enough to say.
[16:40:28] <gconnor> In this context, Semantics means "what does it really mean" and Mechanics means "Now how do I find the answer"
[16:40:47] <DOtis> The datasets are different as the basic issue.
[16:40:55] <gconnor> ok. I understand that.
[16:41:00] <jlcjohn> As for mechanics, I find the possibly-overlaid "+" difficult.
[16:41:04] <gconnor> Here is a hypothetical case
[16:43:13] <mengwong> i think you guys are talking about different things. I think Doug and JLC are talking about SPF Classic, and Greg is talking about SPF/HELO.
[16:43:34] <mengwong> If we all read the unified drafts at http://spf.pobox.com/unified/ we might have a common terminology.
[16:43:44] <DOtis> Sorry, Meng. I have not had time to understand these new documents.
[16:43:46] <gconnor> What if SPF is already deployed for the purpose that classic and/or senderID describe. What if people want to do CSV also. Would it be theoretically possible to define a _csv.* TXT record that does what CSV wants, using SPF language?
[16:43:55] <jlcjohn> Meng: is that document #5 you mentioned?
[16:44:09] <mengwong> under the unified framework, SPF Classic is now just SPF/Mail-From, and operates at the same semantic level as SPF/HELO.
[16:44:17] <gconnor> sorry about the delay there, some sales guy calling if I want anti-spam tools :)
[16:44:42] <jlcjohn> :^)
[16:45:02] <gconnor> John or Doug, would you like to take a stab at my hypothetical case?
[16:45:34] <jlcjohn> I'd really like Meng to answer which document he's referring to.
[16:45:57] <mengwong> yes, document 5 describes SPF/HELO.
[16:46:01] <jlcjohn> thx
[16:46:05] <mengwong> SPF/HELO is intended to offer the same semantics as CSV.
[16:46:10] <jlcjohn> (I'm parsing it...)
[16:46:57] <DOtis> How is that any different that doing an A record forward query?
[16:47:23] <DOtis> What results would you expect?
[16:48:08] <jlcjohn> (A quick perusal doesn't find the "call the SPF function", but I can't find any other way to get the "result"s.)
[16:48:57] <mengwong> calling the function is described in docs 1 and 2, but yes, one calls the function to get the results.
[16:49:48] <jlcjohn> How do we know what the function may return in cases other than "+a -all" and "-all"?
[16:49:49] <DOtis> How does this Unified SPF ensure the record is only for HELO domains?
[16:50:31] <gconnor> Basically, it doesn't... It is up to the publisher to use a scope mechanism *if* the results would have been different
[16:50:33] <mengwong> it doesn't, it expects domains to publish records for all the HELO hostnames used by its MTAs.
[16:51:15] <DOtis> This prevents accreditation of bad or questionable messages later deemed abusive.
[16:51:23] <mengwong> if a domain name is used for more than one identity, the SPF record should be constructed as a superset of all the PASSing hosts.
[16:51:33] <gconnor> doug- how so?
[16:52:44] <DOtis> You have an abusive message. Which domain was responsible for a lack of exercise of policy that allow the message to enter the mail stream?
[16:53:10] <mengwong> all the domains which returned a PASS for any of its identities.
[16:53:33] <DOtis> And if they returned unknown?
[16:53:57] <DOtis> Or if from an open list?
[16:53:57] <gconnor> If they return unknown, they are not responsible.
[16:54:21] <DOtis> That means there is no way to accredit this class of mail.
[16:54:26] <gconnor> If the list is open it is still possible to get a Pass result from the ips on the list
[16:54:41] <DOtis> With CSV, this mail still can be accurately accredited.
[16:54:44] <gconnor> Yes. Agreed. Unknown means "do not use this identity to accredit"
[16:55:09] <gconnor> Well... CSV also has an unknown state, correct?
[16:55:10] <mengwong> if a domain doesn't publish a CSV/SRV record, how do you accredit the mail?
[16:55:32] --- Harry has left
[16:55:42] <gconnor> (Bye Harry :)
[16:56:03] <jlcjohn> CSV doesn't answer that question, Meng.
[16:57:01] <mengwong> but i thought doug said, "With CSV, this mail still can be accurately accredited."
[16:57:42] <DOtis> If CSV is employed. If SPF is employed, there is a question still left with this class of messages.
[16:58:15] <gconnor> that question being?
[16:58:21] <mengwong> when you say "employed", does that mean "the sender publishes and the receiver checks", or "the sender doesn't publish and the receiver checks"?
[16:59:04] <DOtis> The domain for the message is using an open list.
[16:59:26] <jlcjohn> (I believe CSV employed means sender publishes.)
[17:00:28] <DOtis> Sorry, open list in the case of SPF.
[17:00:36] <jlcjohn> (CSV has no "unknown" case if sender publishes; just an "authorized but not authenticated".)
[17:01:23] <mengwong> ok, if the sender doesn't publish, then can CSV be used in accreditation of the mail?
[17:01:36] <mengwong> btw, re terminology, i think we mean different things by "accredit".
[17:02:18] <DOtis> IF there is no CSV record, then CSV can not be used.
[17:02:37] <DOtis> If there is an open list for SPF, there is limited use for SPF.
[17:02:43] <jlcjohn> (The absence of sender publishing can be recorded.)
[17:02:48] <DOtis> It still allows abuse to enter unaccredited.
[17:02:55] <mengwong> agreed.
[17:03:27] <jlcjohn> In the absence of sender publishing, blacklists may apply.
[17:03:33] <mengwong> abuse can enter unaccredited if SPF returns an "unknown" due to client MTA's presence in an open list.
[17:03:44] <DOtis> Yes.
[17:03:52] <mengwong> abuse can also enter unaccredited if CSV records are not present, because the domain owner did not publish them.
[17:04:29] <DOtis> Yes. But the hope would be for this to be seen as a simple fix for an exception made for SMTP.
[17:04:44] <gconnor> When you say "open list" do you mean +all or ?all
[17:04:53] <DOtis> Yes.
[17:05:05] <gconnor> both?
[17:05:09] <DOtis> Or too broadly applied addresses.
[17:05:53] <DOtis> Yes and other doors left open.
[17:06:03] <gconnor> ok.. I want to understand what you mean... if I publish as my list, does that mean I *can* be accredited, or I cannot?
[17:06:39] <mengwong> i'd reckon you can ... if you accept responsibility for it, you can be accredited, according to Doug's use of "accredit"
[17:06:40] <DOtis> It means that the record is worthless for accreditation.
[17:07:41] <jlcjohn> If you think as an accreditor, publishing such a record pretty much disqualifies the domain.
[17:08:19] <DOtis> At what limit do you draw the line? Leaving the record open does the same thing.
[17:09:16] <jlcjohn> I really need to prepare for an evening meeting: can we take this to private email?
[17:09:20] <mengwong> ok, so, is your point that an accreditation agency would decline to accredit any domain that did not have a restrictive SPF record, ie. one that permits a small number of hosts, maybe one, and that ends in a -all?
[17:09:36] <gconnor> OK. I am agreeing with you... if the IP is not listed and the record ends in +all, then the publisher is saying "I take responsibility for absolutely everything from any IP"... This is kind of a useless statement, but I can still enter him into my system and he will get a bad reputation right away.
[17:10:30] <DOtis> What does that mean? That no one should use an open record. Why not require all records to be closed then?
[17:11:49] <mengwong> indeed, no one should use an open record for HELO names.
[17:12:07] <jlcjohn> How do you enforce that?
[17:12:08] <gconnor> Well... what I was trying to understand is whether you were objecting to +all, ?all, or both, and if so why?
[17:12:15] <DOtis> You can not be sure with the records being the same for either use.
[17:12:18] <mengwong> 20040712-18:23:05 mengwong@dumbo:~% dnstxt icicle.pobox.com v=spf1 a mx:fallback-relay.pobox.com -all
[17:12:24] <mengwong> we do use closed records for our MXes.
[17:13:09] <gconnor> jlc- I think what Meng means is "there is no advantage to using a ?all for helo" - you must have a + result to hang any accreditation on
[17:13:13] <DOtis> The goal is to stop abuse. These records only shift the problem to the submitter being spoofed.
[17:13:31] <gconnor> I didn't understand that, could you clarify?
[17:13:36] <DOtis> The open nature of these records allows the Trojans to continue unabated.
[17:13:44] <gconnor> shift from whom to whom?
[17:14:04] <DOtis> What ID will be spoofed.
[17:14:25] <jlcjohn> I'm signing off. If Meng and/or Greg really want to resolve this, think in terms of a modifier, and let us check just the modifier (no recursion, etc.).
[17:15:11] <mengwong> i think Doug's argument is that if everybody adopts CSV, then all MTA HELO domain names will return PASS or FAIL for all IPs; if everybody adopts SPF/HELO, there is a possibility that some IPs will fall into an "unknown" or "neutral" list.
[17:15:22] <mengwong> furthermore, it is easier to construct a "+all" with SPF than with CSV.
[17:15:40] <DOtis> Yes indeed.
[17:15:52] <DOtis> And easier to attack.
[17:16:28] <gconnor> I think I agree with that, though I think it's a less important consideration
[17:16:40] --- mrose has left
[17:17:47] <DOtis> DNS is not perfect and has many problems. If you try very hard, you might get the right answer. But this is not easy even if the answer is relatively simple.
[17:28:19] <gconnor> ok all... thanks for your time. I think we have made some progress
[17:28:29] <DOtis> Bye then.
[17:29:19] <gconnor> Later!
[17:29:23] --- gconnor has left
[17:32:02] --- mengwong has left
[17:40:20] --- DOtis has left
[19:51:37] --- mtnviewmark has left: Disconnected
[20:26:30] --- wrs1864 has left
[21:24:55] --- tonyhansen has left