[10:49:57] --- jlcjohn has joined
[11:01:17] --- CSVjohn has joined
[13:46:41] --- DOtis has joined
[13:57:42] --- CSVjohn has left
[14:45:02] --- mengwong has joined
[14:49:32] --- jfenton has joined
[14:50:24] --- andy has joined
[14:51:10] <andy> hello all
[14:51:10] --- SamSilberman has left: Lost connection
[14:53:38] --- andy has left
[14:53:53] --- andy has joined
[14:54:26] <DOtis> I see the last minute updates still include XML syntax and leaves out many details found in the original SPF draft. When will there be something a bit more complete?
[14:56:04] <andy> good question. Marshall and I need to discuss this.
[14:56:44] --- mrose has joined
[14:57:12] <mrose> sorry, i'm late
[14:57:40] <andy> I guess we should go ahead and start.
[14:58:08] <andy> Since there aren't a lot of people on today, I think we can dispense with the moderation unless the cross traffic gets brutal.
[14:58:34] --- resnick has joined
[14:59:29] <andy> So, we can start with Dave's presumption at the interim, "CSV is orthogonal". How do people feel about?
[14:59:31] <mrose> agreed.
[14:59:34] * resnick is only marginally paying attention. Shout if you need him.
[14:59:42] <jlcjohn> agreed
[14:59:44] <DOtis> I agree
[15:00:21] <mengwong> could someone please explain a bit more detail how it's orthogonal, or what it's being orthogonal to?
[15:00:46] <DOtis> It uses a different premise.
[15:00:54] <jlcjohn> CSV considers EHLO, and authorization to act as MTA
[15:01:06] <jlcjohn> SPF considers forgery
[15:02:08] <mengwong> If Hector Santos were here, he might say "SPF has been very successful at preventing forgery of EHLO"
[15:02:16] <andy> Would complimentary be a better term?
[15:02:36] --- Harry has joined
[15:02:46] <andy> sorry... "complementary"
[15:02:48] <jlcjohn> not sure if we can reach consensus on that...
[15:03:20] <mengwong> if Carl Hutzler were here, he might say "we're interested in SPF as a whitelisting device to start with, and we would be happy to apply it to EHLO names"
[15:03:50] <jlcjohn> the CSV authors consider EHLO authentication a first step "orthoganal" to forgery.
[15:04:17] <jlcjohn> as to application of SPF to EHLO, we see a difficulty getting the semantics right.
[15:04:29] <mengwong> personally, I would say that just as it's possible to use an SPF query to detect forgery of either the return-path or the Purported Responsible Address from the headers, it's possible to use SPF to determine authorization status for an MTA based on the EHLO name.
[15:05:03] <DOtis> SPF looks for domains to carry mail for other domains. CSV only asks the identity of the domain to assert accountability.
[15:05:05] <andy> John, can you explain that last statement?
[15:05:21] <mengwong> so i see some degree of overlap between CSV and the Unified SPF concept I mentioned on the list recently.
[15:05:29] <jlcjohn> (other than the misspelling?)
[15:05:34] <DOtis> The SPF list can never be concise enough to allow MTA identity assertions.
[15:06:01] --- gconnor has joined
[15:06:03] --- wrs1864 has joined
[15:06:20] <jlcjohn> ('twould be easier to respond to questions...)
[15:06:45] <andy> yeah. I guess we are gonna have to go to moderation mode now that more people are on.
[15:06:58] --- ghewgill has joined
[15:07:00] <andy> John, do you want to take questions.
[15:07:01] <mrose> yes.
[15:07:10] <jlcjohn> yes, please.
[15:07:35] <andy> ok. remember: <rts> to get in the queue. you'll be given a <cts> when it is your turn.
[15:07:52] <andy> and <eot> when you are done asking the question.
[15:08:32] <andy> any questions?
[15:09:04] <gconnor> rts
[15:09:12] <andy> cts
[15:09:35] <gconnor> john can you explain what you mean by difficulty getting the semantics right
[15:09:46] <gconnor> xfer cts to john
[15:09:52] <jlcjohn> Happy to.
[15:10:07] --- lbruno has joined
[15:10:24] <jlcjohn> SPF considers whether an IP address is expected to send email for a domain found in some header.
[15:10:50] <jlcjohn> CSV considers whether a domain accepts responsibility for whatever a sending MTA client may do.
[15:11:20] <jlcjohn> without some addition to SPF, I don't see how we can extract the information about responsibility.
[15:11:23] <jlcjohn> <eot>
[15:11:31] <gconnor> ok. follow up...
[15:11:44] <andy> greg, cts
[15:12:08] <mengwong> <rts>
[15:12:09] <gconnor> spf has a clause for checking HELO when mail from = <> - some have suggested to just turn that on all the time (i.e. Hector)
[15:12:58] <DOtis> rts
[15:12:58] <gconnor> so the thing we are checking for is really "Is MTA at IP w.x.y.z allowed to use the name mail1.example.com". Would that be sufficient for our purposes?
[15:13:22] <gconnor> eot
[15:13:33] <jlcjohn> No. Without semantics about responsibility, there's no audit trail.
[15:14:03] <jlcjohn> Use of the name is one piece of CSV, and is not sufficient without a statement of responsibility.
[15:14:06] <jlcjohn> <eot>
[15:14:19] <andy> meng, cts
[15:14:38] <mengwong> jlc suggested an addition to SPF. is the extension shown at http://spf.pobox.com/slides/unified%20spf/0250.html sufficient to constitute such an addition, or do we need to add language as well that explicitly establishes responsibility?
[15:15:07] <gconnor> rts
[15:15:09] <mengwong> specifically, running SPF against the HELO has some overlap with CSV.
[15:15:31] <mengwong> can the overlap be broadened to fully encompass the value that CSV brings to the table?
[15:15:33] <mengwong> <eot>
[15:16:16] <jlcjohn> The problem lies in the semantics of what SPF encodes.
[15:16:33] <jlcjohn> There might be a way to encode sufficient semantics, but it's not there right now.
[15:16:35] <jlcjohn> <eot>
[15:16:51] <mengwong> i think doug and greg are up next
[15:16:58] <andy> doug, cts
[15:17:18] <DOtis> There is the concise response made available using SRV and the label used with EHLO is likely different anyway. This should suggest there is no reason to overload the already heavily overloaded SPF syntax.
[15:18:08] <DOtis> I suggest to prevent the DDoS, CSV as is offers greater protections and avoids the problem of their being different definitions for the meaning of the address lists. <EOT>
[15:18:24] <jlcjohn> didn't see a question <eot>
[15:18:30] <andy> greg, cts
[15:19:17] <gconnor> I usually think of the "permission to use the name" as a pretty transparent operation. I.e. if there is an A record leading from a name to an IP, then the machine at that IP is "allowed to use the name". In this case PTR and HELO could both be "hints" to what the name is, but they are not authorizations in/of themselves. If we adopt a "unified spf" approach I think it would be implied that SPF PASS means not only "allowed to use the name" but "allowed to use the name *FOR EMAIL*" which would encompass both of those you said (identity and authorization).
[15:19:55] <gconnor> If we tell people that's what it really means and how it should be used would *that* be sufficient? (open to john first, but anyone else can anser
[15:19:57] <gconnor> eot
[15:19:58] * mengwong <rts>
[15:20:05] <DOtis> rts
[15:20:15] <jlcjohn> I don't see how that solves the problem.
[15:20:54] <jlcjohn> for forgery purposes, a domain advertising SPF needs to be liberal and include possible senders over which it has no control.
[15:21:15] <jlcjohn> for responsibility purposes, we need at least a statement of ability to change providers.
[15:21:21] <jlcjohn> <eot>
[15:21:30] <andy> meng, cts
[15:21:40] <gconnor> rts
[15:22:35] <mengwong> We're not overloading the SPF syntax, we're overloading the SPF semantics. But wait, the SPF semantics already allow HELO checking to indicate a responsibility relationship. So we're not even overloading SPF's semantics. We're really highlighting CSV semantics in what's already present in SPF, even SPF Classic. From what I've seen, "overloading the semantics" doesn't cause trouble, and is certainly less work than defining a new CSV syntax/protocol to go with the CSV semantics. Using the SPF syntax/protocol to go with the CSV semantics is simply code/protocol reuse.
[15:23:09] <mengwong> i would like to ask jlc to run us through a scenario in which the forgery vs responsibility purposes cause a real problem.
[15:23:10] <mengwong> </eot>
[15:23:40] <jlcjohn> Meng's slide, as I understand it, proposed running the same function on the EHLO string as is used for responsible-sender headers.
[15:23:51] <jlcjohn> I don't see how that can encode a statement of responsibility for "whatever" a MTA may send.
[15:24:18] <jlcjohn> As for scenario, I can try to work up something during another question -- or should the session wait?
[15:24:23] <jlcjohn> <eot?>
[15:24:44] <andy> let's not wait. that sounds like something for the list.
[15:24:49] <andy> doug, cts
[15:24:52] <DOtis> Overloading SPF, this leaves the problem of accountability in that there is no clear definition what IP is administered by which domain.
[15:24:57] <DOtis> eot
[15:25:16] <andy> greg, cts
[15:25:18] <gconnor> I understand the distinction between "control" and "allow", but I think the difference is not really a useful one... If you authorize some other agent to represent you, and they use some servers you don't control, you are still "in control" of the relationship, meaning that you can go to them to ask for problems to be resolved, or you can remove their authorization to act as your agent. Even though you don't "control" the server you are still "responsible".
[15:25:49] * mengwong <rts>
[15:25:56] <gconnor> If there are two names (helo and mail from) and they both "pass" their spf checks, then both entities are "responsible" for the output, I believe.
[15:25:59] <gconnor> eot
[15:26:12] <jlcjohn> Responsible, to me, means "able to respond".
[15:26:31] <gconnor> not "willing to take responsibility?"
[15:26:46] <jlcjohn> SPF records (currently at least) need to specify the full range of MTAs which may be used for email from a domain.
[15:27:13] <wrs1864> <rts: %{scope} macro variable>
[15:27:33] <jlcjohn> Some of these may be responsive quickly; others will no doubt be cable providers who consider 30-days "responsive".
[15:27:40] <gconnor> rts follow up?
[15:27:47] <andy> greg, cts
[15:27:53] <jlcjohn> I don't think that's useful for fixing problems.
[15:27:55] <jlcjohn> <eot>
[15:28:56] <gconnor> ok. so as I said, I understand the distinction. You are saying you believe it is a useful one. I don't really agree with that. I think it will confuse people if they have to publish two lists
[15:28:56] <DOtis> rts
[15:28:59] <gconnor> eot
[15:29:19] <jlcjohn> Let us remember that whatever we do, reputation services will have to rate the behavior of domains.
[15:29:52] <jlcjohn> Is it better to have to post two DNS records, or better to have to suffer a terrible reputation?
[15:29:55] <jlcjohn> <eot>
[15:30:04] <andy> meng cts
[15:30:05] <mengwong> Under the SPF model, if a domain authorizes an MTA to use its name in the HELO string, that is an implicit statement of responsibility. I think if Jim Lyon were here he might say something like "I submit that any statement of a relationship between a domain and an entity in which the domain does not accept responsibility for its name being used by that entity, is not a useful statement." It sounds to me like we're talking at cross purposes; when we use the word "responsible" do we have the same meanings in mind? I have in mind a kind of relationship where if the message is spam the domain's reputation can justifiably suffer.
[15:30:12] <mengwong> <eot>
[15:31:18] <jlcjohn> I don't think I understand _how_ a domain authorizes an MTA "to use its name in the HELO string" separately from authorizing it to send email listing the domain as PRD.
[15:31:22] <jlcjohn> <eot?>
[15:31:45] <gconnor> i can answer, or meng can
[15:31:55] <mengwong> short answer: generally, it doesn't.
[15:31:55] <andy> greg, cts
[15:32:00] <mengwong> long answer, go greg :)
[15:33:13] <gconnor> A helo check is just a check of auth(helo,IP). It is based only on the helo name. therefore it doesn't authorize the use of any particlaur PRD, that is what the PRD check is for. (This is similar to CSV, the HELO name is checked only against the HELO domain, and you don't infer any relationship between domains)
[15:33:25] <gconnor> eot
[15:33:54] <andy> wayne, cts
[15:33:57] <wrs1864> The "unified SPF" proposal that Meng recently mentioned needs to add a macro variable that defines the scope. For the vast majority of situations, this is not needed, but in those cases where the MAIL FROM is much broader than the HELO, you can define the SPF record to allow this.<eot>
[15:34:40] <jlcjohn> Frankly, I don't think that the "vast majority" aren't in need of the distinction.
[15:34:54] <jlcjohn> Earlier, Meng stated "I have in mind a kind of relationship where if the message is spam the domain's reputation can justifiably suffer".
[15:35:03] <gconnor> rts answer?
[15:35:32] <andy> john, are you done?
[15:35:43] <jlcjohn> It will generally be difficult to fix a reputation: I think the substantial majority of domains cannot afford the risk of letting their reputation depend upon a cable provider.
[15:35:46] <jlcjohn> <eot>
[15:35:50] <andy> greg, cts
[15:36:17] <gconnor> I think the "vast majority" will define the mailers that are used to send mail (or the IP ranges in which they reside) and to them it's both a statement of intent to send and a statement of responsibility. I.e. for most domain owners, "not forged" means "I am responsible".
[15:37:10] <gconnor> If there really is a difference between the helo set and the prd set, mostly that is solved by merging the sets. Otoh, most MTA's don't HELO with example.com, they use mail1.example.com or whatever, so usually your MTA will have a very short simple SPF record
[15:37:31] <DOtis> The SRV RR for CSV is not really yet another list. It may be seen as a subset perhaps, but the concise nature of this establishes accountability. HELO should be removed from the SPF list of ID to check (last at the moment) if to consider the mail content alone. Define CSV as a prior check and that covers the HELO domain properly. It would be done first where it is needed most.
[15:38:13] <gconnor> the special case macro is really only useful if you want to restrict helo further for some weird reason AND your MTA's all use "HELO mydomain.com" instead of their hostname (or if your domain spf record ends in ?all and you want a more restrictive default for HELO
[15:38:21] <gconnor> eot
[15:38:54] <jlcjohn> If I understand, Greg thinks that the SPF record for the EHLO domain will generally be separate.
[15:39:09] <jlcjohn> For tiny domains, that's rather a change from current practice.
[15:39:29] <gconnor> Depend on if your MTA normally says "helo mydomain.com" or "helo servername.mydomain.com"
[15:39:39] <jlcjohn> Regardless, how is a receiving SMTP server supposed to know the difference?
[15:39:42] <jlcjohn> <eot>
[15:39:52] <gconnor> difference between what again?
[15:40:22] <jlcjohn> difference between the "main" SPF for PRD and the EHLO SPF for MTA responsibility
[15:40:23] <jlcjohn> <eot>
[15:40:33] <andy> doug, cts
[15:41:24] <mengwong> (if jlc gets a spare moment, i'd like to ask for some detail on the use case where there's an actual problem between using an SPF record for the PRD and using an SPF record for EHLO, please)
[15:41:36] <gconnor> rts
[15:41:47] <DOtis> The Administrative control of the MTA is where accountability is to be assigned. The concise ONE query nature of the CSV allows the needed protections. HELO done last does not offer this protection or accountability.
[15:41:50] <DOtis> eot
[15:42:11] <andy> meng, cts
[15:42:40] <mengwong> uh, so, jlc or doug, can you set up a problem scenario?
[15:42:44] <mengwong> <eot>
[15:43:04] <DOtis> I think that needs to go to the list.
[15:43:23] <mengwong> just thought maybe you guys had one in mind.
[15:43:30] <jlcjohn> Quick answer on case with problem: workers at home using their cable system to send email for their work domain.
[15:43:32] <jlcjohn> <eot>
[15:43:55] <andy> Meng, can you work with that?
[15:44:14] <mengwong> lemme see what the EHLO and the MAIL FROM look like real quick.
[15:44:38] <mengwong> (taking the MAIL FROM to be close enough to the PRA that SPF Classic and SenderID look the same in this case)
[15:45:15] <mengwong> EHLO cable-12-23-34-56.cty.cableco.net ?
[15:45:20] <mengwong> <eot>
[15:45:51] <andy> john?
[15:45:54] <jlcjohn> Actually, it might be that, or the cable provider might force use of their server.
[15:45:58] <jlcjohn> <eot>
[15:46:07] <mengwong> ok, so we have two subcases ...
[15:46:22] <mengwong> if the cable provider forces use of their server, we have EHLO mta4.cableco.net
[15:46:28] <mengwong> MAIL FROM:<worker@work.com>
[15:46:29] <mengwong> ?
[15:46:33] <mengwong> <eot>
[15:46:42] <jlcjohn> OK <eot>
[15:46:58] <mengwong> so mta4.cableco.net has an SPF record, and work.com has an SPF record ... and ... ?
[15:47:17] <mengwong> and the mta4.cableco.net SPF record is checked at EHLO time, and the work.com record is checked at MAIL FROM time ...
[15:47:31] <jfenton> <rts>
[15:47:56] <wrs1864> <req for extended session??>
[15:48:01] <mengwong> <eot>
[15:48:10] <jlcjohn> What happens when mta4.cableco.net gets a bad reputation?
[15:48:13] <jlcjohn> <eot>
[15:48:17] <mrose> i'd rather keep these to an hour
[15:48:28] <mengwong> then work.com has to set up port 587 with SMTP AUTH
[15:49:01] <mengwong> if the mta4.cableco.net identity has a bad reputation, then it sucks for the mail sender whether the checks are being done with CSV or SPF, right?
[15:50:17] <DOtis> rts
[15:50:21] <andy> these are two good use cases. perhaps flushing them out on the list is good.
[15:50:24] <andy> greg, cts
[15:50:26] <gconnor> the answer i gave before to jlc's question was: there is usually NO difference in the list of authorized IPs.. If there is a difference, merge them or use a macro. That only applies if 1. you use the Same Exact name in HELO as in PRD, and 2. you want two different treatments when checking for authorization during HELO and during PRD. Also for Doug's question, I don't understand what you mean regarding HELO done last? Under unified SPF it would be done as soon as HELO is known. Under current SPF it is only done when MAIL FROM: <> but can optionally be done all the time. For the mobile-user case, mycompany.com could say +ptr:cableco.com, but they would be strongly advised not to... usually they would put ?ptr:cableco.com
[15:50:45] <gconnor> eot
[15:51:07] <jlcjohn> It may be possible to define such a macro: I haven't seen it yet.
[15:51:22] <gconnor> (see wayne's earlier comment...)
[15:51:35] <jlcjohn> 2. SPF checks can be done at MDA time, which won't have the EHLO to work with.
[15:51:44] <jlcjohn> <eot>
[15:51:54] <gconnor> (right, HELO is checked at HELO time :)
[15:52:02] --- lbruno has left: Disconnected
[15:52:09] <andy> jfenton, cts
[15:52:12] <jfenton> Also need to consider another subcase: whether work.com wishes to allow home users to send mail directly. Some need to audit their outgoing mail. Work.com needs to be in control of that.
[15:52:15] <wrs1864> <rts: HELO at MDA/MUA time>
[15:52:15] <jfenton> <eot>
[15:52:39] <jlcjohn> We can't tell work.com how to run its business.
[15:52:41] <jlcjohn> <eot>
[15:52:44] --- lbruno has joined
[15:52:46] <andy> doug, cts
[15:52:59] <andy> and wayne is last.
[15:53:01] <wrs1864> you can grab the HELO domain from the mail headers, which is the same place you will need to grab the IP address.<eot>
[15:53:09] <wrs1864> (oops)
[15:53:47] <jlcjohn> I don't recall a defined syntax for that. <eot>
[15:54:11] <DOtis> The cost of using a separate SRV record to do this function as an independent check seems a valuable method of keeping the issues with that of SPF from slowing definitions needed to establish this level of authorization and authentication. This method can be applied to other protocols as well.
[15:54:45] <DOtis> To load this into SPF clouds the issue of who is administratively responsible for the relayed or originated traffic.
[15:54:48] <DOtis> eot
[15:55:25] <andy> wayne, cts
[15:55:33] <wrs1864> <eot>
[15:55:43] <andy> ok.
[15:56:01] --- mrose has left
[15:56:14] <andy> We were given 3 use cases today. It would be good if meng could take his 2 to the list, and jfenton his to the list.
[15:56:50] <andy> Then let's let the CSV proponents explain two things for each, 1) how CSV handles them, and 2) how SPF does not.
[15:57:01] <andy> does that sound good?
[15:57:08] <DOtis> Okay to me.
[15:57:08] * wrs1864 nods
[15:57:15] <jlcjohn> OK
[15:57:29] <jfenton> yup
[15:57:31] <gconnor> thanks all!
[15:57:35] --- resnick has left
[15:57:36] <jlcjohn> (Can't speak for Dave, who can't get access right now...)
[15:57:45] <andy> Also, I'd like to see a list of current MTA behaviors that would have to be modified for CSV.
[15:57:57] <andy> if any
[15:58:29] <andy> does that make sense?
[15:58:43] <jlcjohn> happy to oblige.
[15:58:49] <andy> cool. thanks.
[15:59:37] <andy> thanks everybody.
[16:00:42] --- gconnor has left
[16:00:58] --- Harry has left
[16:02:20] --- ghewgill has left
[16:02:52] --- wrs1864 has left
[16:02:58] --- lbruno has left
[16:04:51] * mengwong has right.
[16:13:16] --- andy has left
[16:43:21] --- lbruno has joined
[16:46:11] --- lbruno has left
[17:13:50] --- jfenton has left
[17:43:33] --- DOtis has left
[22:34:52] --- mengwong has left: Disconnected
[22:36:57] --- mengwong has joined
[22:37:22] --- mengwong has left: Disconnected