[11:01:40] --- Harry has joined
[11:04:09] --- Harry has left
[12:23:38] --- wrs1864 has left: Disconnected
[12:26:46] --- andy has joined
[12:28:35] <andy> test
[12:55:33] --- wrs1864 has joined
[14:33:05] --- dcrocker has joined
[14:35:14] --- gordonf has joined
[14:35:56] <wrs1864> So, is there going to be a non-meeting here today?
[14:36:49] <gordonf> When are the meetings? Weren't they pushed back by an hour to compensate for daylight savings time or something?
[14:37:36] <wrs1864> yeah, that's what I remembered... 20:00 UTC instead of 21:00 UTC
[14:38:14] <gordonf> And still every two weeks? Is this this week or the next?
[14:38:42] <andy> this week
[14:38:55] * wrs1864 has lost a week somewhere
[14:39:00] <wrs1864> anyone seen it?
[14:39:14] <dcrocker> i don' t recall the agenda for today.
[14:40:38] <andy> there is one. I'll go into that when more people sign on.
[14:44:20] --- tonyhansen has joined
[14:46:20] --- SamSilberman has joined
[14:46:38] --- mrose has joined
[14:49:14] --- hardie has joined
[14:52:32] --- Harry has joined
[14:53:40] --- resnick has joined
[14:54:02] <andy> Let's go ahead and start.
[14:54:26] <andy> Unlike last time, we have an agenda.
[14:55:06] <andy> We have asked Dave Crocker to talk about HELO/EHLO checking.
[14:55:51] <andy> Second, we have asked Harry Katz to talk about 2822 header selection in Caller-ID.
[14:56:14] <andy> We'll go with the same moderation protocol as we did two weeks ago.
[14:56:35] <andy> Speakers with finish with <eot> to signal they are done.
[14:56:48] <andy> If you want to line up in the queue, <rts> - topic.
[14:56:55] <andy> Any questions?
[14:57:30] <andy> Ok. Dave, you have the floor.
[14:58:22] * hardie wonders whether dave's mic is on.
[14:58:24] <dcrocker> howdy. smtp helo validation is intended to have the hosting network certify that a host is authorized to act as an MTA.
[14:58:38] <dcrocker> (dave types slowly and was pondering how to start.)
[14:59:40] <dcrocker> The salient "philosophy" of Client SMTP validation is that channels should validate channel information and end-points should validate content. The major bit of channel information in an SMTP session is the HELO declaration.
[15:00:16] <dcrocker> The problem, today, is that a client may declare that it is any domain name. So the challenge is to authenticate it and then validate its function as a client smtp.
[15:01:06] <dcrocker> Authentication can occur through a number of mechanisms. The draft cites two, with a placeholder for a second. The first is the obvious reverse-IP, with its known limitations.
[15:01:46] --- jgmyers has joined
[15:02:25] <dcrocker> The second is through a registration of top-level domain names, such as paypal.com. The registration means that they are declaring participation in the validation scheme and are registering authorized hosts.
[15:02:50] <dcrocker> The forward-lookup scheme takes the domain name from the EHLO and queries DNS for
[15:03:18] <dcrocker> and SRV record under _client._smtp.<domain>. It's important to note that this type of use of
[15:03:43] <dcrocker> SRV is as an extension to the base domain name, rather than as a real mapping to one or more addresses.
[15:04:15] <dcrocker> It is equally important to distinguish between validating a name/address mapping, versus assessing its authorization to act as a client MTA.
[15:05:06] <dcrocker> All of this leads to the question of wondering how any of this important. So what if we know that the hosting network authorized the client MTA? My primary response is that that's true for all authentication schemes. How do we know to "trust" the entity doing the authenticating or the authorizing.
[15:05:54] <dcrocker> So the main answer is that Client MTA Validation provides a platform for being able to make administrative assessments of the accountable authority, namely the hosting net.
[15:06:34] <dcrocker> The other point to make is that this is an intentionally limited facility, designed to make statements only about the preceding hop, and that it is not tied to a particular chain or to any particular content. <eof>
[15:06:50] <gordonf> <rts>
[15:07:41] <andy> gordon, go
[15:07:48] <gordonf> "Hosting net": hosting _network?_ (infrastructure) Or hosting _domain?_ (organization)
[15:07:52] <gordonf> <eot>
[15:08:22] <dcrocker> good point. hosting domain.
[15:08:29] <dcrocker> <eot>
[15:09:02] <andy> any other questions for Dave?
[15:09:04] <jgmyers> <rts>
[15:09:09] <andy> jgmeyers, go
[15:09:46] <jgmyers> If an smtp client uses a HELO value for which there are no authorization records, what does a validator know or do? <eot>
[15:10:15] <dcrocker> The same as it knew without the validation mechanism. No more and no less.
[15:10:38] <dcrocker> this is not a preemptive mechanism.
[15:10:57] <dcrocker> It is intended to augement the running mail service, rather than to replace anything. this
[15:11:29] <dcrocker> requires treating anything other than an explicit presence of the mechanism to be the same as if there were no mechanism defined. And to
[15:12:12] <jgmyers> So while you may know that a client is "authorized", you're unlikely to know that it is "unauthorized"?
[15:12:28] <dcrocker> define active "failure" and active "success" only in terms of matching existing SRVs, etc, or fail to match existing SRVs, (that is, to find SRVs but not one with this domain name). /eot
[15:12:45] <dcrocker> i garbled my response. let me try again:
[15:13:24] <dcrocker> if there are no SRVs, then the client's domain is not declaring support for the facility. hence you can make no assessment of the validity of the particular client. if
[15:13:52] <dcrocker> there are srvs for the domain, then you can assess authorization for the domain. whether you
[15:14:06] <jgmyers> <rts>
[15:14:22] <dcrocker> can judge the whole domain or just a particular one
[15:14:45] <dcrocker> depends on the way the domain registers its coverage. if it regisers a *, then it covers the whole thing. <eot>
[15:15:05] <andy> jgmyers, <cts>
[15:15:43] <jgmyers> I was going to ask: if records exist for example.com but not foo.example.com, what can you tell for helo foo.example.com
[15:16:03] <jgmyers> So then, does it make sense to register records without using wildcards?
[15:16:13] <jgmyers> <eot>
[15:16:22] <dcrocker> right. the question is whether there is an etnry for *.example.com. <eot>
[15:16:37] <dcrocker> I think whether to
[15:16:57] <dcrocker> register *.example.com or whether to register individual ones depends on the policy of the hosting domain. for example,
[15:17:21] <dcrocker> A paypal.com is certain to want to register *.paypal.com. On the
[15:17:41] <dcrocker> other hand, a general-purpose ISP well might choose to register only the MTA's of its own, but make no
[15:18:01] <dcrocker> statement about MTA's of its customers. And now that I've said that
[15:18:17] <tonyhansen> <rts>
[15:18:21] <dcrocker> I've implied the obvious question of whether
[15:18:52] <dcrocker> an isp customer might have a valid client mta that operates under the Isp's domain or whether it iks required to have its own domain.
[15:19:17] <dcrocker> My preference is to leave such things up to the ISP, rather than ahve our spec dictate particular configurations. <eot>
[15:19:27] <andy> tony, <cts>
[15:19:51] <wrs1864> <rts>
[15:20:02] <tonyhansen> can one have an administrative domain that covers *.example.com, except for certain specific exceptions (foo.example.com, bar.example.com), and disallow any other *.example.com?
[15:20:31] <tonyhansen> the foo.example.com and bar.example.com would have their own definitions
[15:20:36] <tonyhansen> <eot>
[15:21:04] <dcrocker> i sure hope so. (I'm not positive the spec makes that clear, but it needs to.) seems certain to want to be able to say "only explicitly allowed clients are authorized, all others are prohibited". <eot>
[15:21:34] <andy> wrs, <cts>
[15:21:36] <wrs1864> Just out of curiosity, why overload SRV records instead of A records (a-la a DNSBL) or even a TXT record? SRV records are a fair amount larger, aren't they?<eot>
[15:22:00] <Harry> <rts>
[15:22:16] <dcrocker> srv records have the extra fields to specify values in. A records only specify addresses <eot>
[15:22:41] <andy> harry, <cts>
[15:23:09] <Harry> Dave, I'd like to go back to your first "Philosophy" statement about endpoints validating content.
[15:24:00] <Harry> It seems to me that today MTAs are doing a lot of things relative to content, so perhaps I'm not understanding your use of the term "endpoint"
[15:24:11] <Harry> Could you clarify? <eot>
[15:24:17] <dcrocker> sure.
[15:24:44] <dcrocker> a pure mta routes and relays mail. the only thing it does with content is to add a received header. we
[15:25:05] <dcrocker> have mtas that do all sorts of gateway functions, translating content, but that is beyond the core functions.
[15:25:13] <dcrocker> <eot>
[15:25:24] <dcrocker> oops.
[15:25:29] <dcrocker> not done. sorry.
[15:25:52] <dcrocker> endpoints are the MSA and MDA or the two MUAs. We can quibble between them, but the main
[15:26:30] <dcrocker> distinction is between those systems at the end, versus the arbitrtary number of relaying MTAs in the middle. <real eot>
[15:26:42] <Harry> OK. But it's not clear we can make these crisp distinctions any longer, at least for MDA and MSA.
[15:27:04] <Harry> MTAs do virus and spam filtering today, and content-based routing is becoming more common too.
[15:27:31] <Harry> Sometimes this happens durnig protocol handling, sometimes after acceptance of the message. It's all pretty blurry.
[15:27:38] <Harry> <eot>
[15:27:49] <SamSilberman> <rts>
[15:27:55] <dcrocker> i take your point, but
[15:28:27] <dcrocker> am inclined to suggest that that has more to do with special gateways at "interesting" boundaries than with basic mta functionality. <eot>
[15:29:13] <andy> sam, <cts>
[15:29:13] <resnick> <rts>
[15:29:51] <SamSilberman> While validating the most recent hop is useful, could this scheme be used to validate the "chain of hops" back to the originating MTA (or first non-participating MTA)? <eot>
[15:30:33] <dcrocker> I could imagine yes, but haven't tried to think of the way to do it.
[15:30:43] <dcrocker> interesting idea. <eot>
[15:31:01] <andy> resnick, <cts>
[15:31:11] <resnick> Is there any reason to do this first? That is: If other work we do is going to come up with a general DNS mechanism to specify "authorized to do X as an MTA", is there a reason to have a special mechanism for X == anything, or couldn't we just latch this on at a later date?<eot>
[15:32:03] <dcrocker> This is a simple, safe, easy mechanism. It provides a useful statement about the guy talking to you. Thati is far more than we have today. As
[15:32:36] <dcrocker> an incremental step, in a world of confusion and frustration, with alternatives that are complicated and have significant sid-effects, yeah, I think this is a good first step. <eot>
[15:32:58] <andy> ok. Thanks Dave.
[15:33:12] <dcrocker> back at yah.
[15:33:16] <andy> Let's now move to our second topic.
[15:33:34] --- Maex has joined
[15:33:34] <andy> Harry will be covering 2822 headers.
[15:33:43] <andy> Harry, you have the floor
[15:33:52] <Harry> Thanks, Andy.
[15:34:06] <Harry> We had a number of goals in mind when we designed Caller ID.
[15:34:29] <Harry> One of the most important was ease of adoption. We have tried to design CAller ID so that the fewest number of software changes are required, and so that we don't require upgrades at both ends of the conversation in order to gain some benefit.
[15:35:03] <Harry> This led us to examine various scenarios under which mail gets sent: Direct interpersoanl mail, mailing lists, web applications generating mail, outsourced email, and of course the thorny business of forwarding.
[15:36:05] <Harry> Looking at these together, and considering also the experience of end users who are the ones directly affected by spam and spoofing led us to look at the RFC2822 headers as a mechanism for identifying the purported responsible domain (PRD) of a message.
[15:37:11] <Harry> We did actually have the RFC2821 MAIL FROM at the top of our list in initial designs. However, as we got farther into looking at the scenarios and what we could actually do on the basis of a check of the MAIL FROM we found it was not helpful in several cases.
[15:37:15] <Harry> So we removed it.
[15:38:01] <Harry> Now in my post last night I've suggested a modification to our algorithm that adds MAIL FROM back in, mainly to help with mailing list servers that today do not insert a Sender header.
[15:38:47] <Harry> I guess that's it for a general intro. I'm open to questions. <eot>
[15:38:52] <gordonf> <rts>
[15:39:02] <andy> gordon, <cts>
[15:39:37] <Maex> <trs>
[15:39:44] <gordonf> Without checking any 2821 information, this doesn't save any bandwidth. How does this save time, money, etc?
[15:40:07] <gordonf> That's my only real issue with relyilg solely on 2822 info.<eot>
[15:40:16] * gordonf can't spel ether :-)
[15:40:24] <Harry> Understood. This comes up alot.
[15:41:05] <Harry> Our view is that ultimately we will not be able to reject much mail at all solely on the basis of a 2821 spoof check.
[15:41:27] <Harry> Spammers will register their own domains, or they will move to domains that don't publish outbound MTA info.
[15:41:52] <gordonf> <rts> $9/domain
[15:42:24] <Harry> In the end, in order to make an accurate determination, you'll have to take the message over the wire anyway. So the idea that you can save alot of bandwidth by rejecting at MAIL FROM is, I believe, false ... as much as I might wish it to be otherwise.
[15:43:23] <Harry> Also, just to be clear, I am not opposed to performing other checks of the MAIL FROM, for example allow.deny lists, etc. If you have reliable info that allows you to block mail at MAIL FROM, then hey go for it, block away!
[15:43:49] <Harry> My point is that I do not believe that you can do this reliably based on a spoof check of MAIL FROM.
[15:43:58] <jgmyers> <rts>
[15:44:53] <Harry> Now, related to the $9/domain point, you're right, they're cheap. But if they send you alot of spam, you'll quickly add them to your block list. That in fact is one of the benefits of any of these MTA validation schemes ... they give you additional info to build up those lists <eot>
[15:45:12] <andy> maex, <cts>
[15:45:13] <wrs1864> <rts>
[15:45:16] <Maex> 1) If we have a DNS based authorization scheme for domainnames that are part of email addresses, I don't see whether it should make such a big difference as to where to apply it to. At least why it is now a difference.
[15:46:11] <Maex> 2) A "From:" address is a accurate and as easy to fake as a RFC2821 address. So a check on the From is no benefit, IMHO. Maybe would if we use the full email address.
[15:46:23] <Maex> eot
[15:47:06] <Harry> 1. Because messages can for legitimate reasons travel different routes and arrive with 2822 headers different from the 2821 header (List servers are an example).
[15:47:46] <Harry> And because we're tying the check to the IP address over which the message is recieved, we have to match the two together.
[15:49:03] <Harry> 2. Yes, any of these headers can be spoofed. But the From address is the one the end user sees. And if we're to help restore confidence in email, I think we need to start there.
[15:49:50] <Maex> is a message with a 2821fake and 2822true more authorised than a 2821true and 2822fake ?
[15:49:56] <Harry> We have also put in the spec some ideas like directOnly which may not be perfect, but which give recipients some additional information upon which to base a filtering decision or to make additioinal checks
[15:50:58] <Harry> Probably not. But my point is that you can't reliably conclude that 2821 is fake until you actually look at the 2822 headers.
[15:51:11] <gordonf> <rts>
[15:51:23] <Harry> <eot>
[15:51:48] <andy> gordon, you were up next anyway. <cts>
[15:51:59] <gordonf> What of where to send bounced mail to? If the sender really wants to know if their mail bounced, wouldn't MAIl FROM at least point to a useful address? What if that bounce address is intentionally different?
[15:52:23] <gordonf> (and about bandwidth) What about stats gathered in DMP testing demonstrating significant bandwidth savings? <eot>
[15:53:11] <Harry> I addressed the bandwidth question above. I'm not familiar with the stats your referring to. If you want to send me a pointer off-line, I'll be happy to look at them.
[15:53:20] <Harry> On your first question ...
[15:54:13] <Harry> This is the joe job issue, right?
[15:54:32] <gordonf> More of a "bounces to" issue.
[15:54:34] <gordonf> <eot>
[15:54:54] * resnick makes a point of order: The time is now 2100 utc.
[15:55:32] <Harry> Well I'm not sure I'm understanding the gist of your question, but I think that which set of headers you check is independent of where the bounce goes.
[15:55:55] <andy> jgmyers, <cts>
[15:56:00] <jgmyers> You discount checking MAIL FROM for the reason that that you don't want to require changes on mail forwarders (to implement SRS). The proposal, however, requires forwards to add Resent-* headers. How is this consistent?
[15:56:06] <jgmyers> <eot>
[15:56:27] <Harry> Forwarders are going to have to do something.
[15:56:52] <Harry> Forwarded mail today is indistinguishable from forged mail.
[15:57:07] <jgmyers> Then why not SRS?
[15:57:35] <Harry> We believe that adding a resent- header is a simpler, less burdonsome change than adopting SRS and the subsequent burden of handling bounce messages.
[15:58:13] <Harry> Also, if as we believe, we're going to end up having to inform the user about which identity was validated, the SRS address is simply unintelligible.
[15:58:36] <Harry> <eot>
[15:58:48] <andy> wrs, <cts>
[15:58:53] <wrs1864> does RFC2822 allow an email forwarder to modify/add the Resent-* and Sender:headers
[15:59:09] <wrs1864> Also, you can just use the domain name part of the SRS address<eot>
[15:59:39] <Harry> Resent- headers are trace records, they get added to the top of the headers just as Received headers do.
[16:00:08] <Harry> I'm not sure about Sender headers. I think there's only supposed to be one per message, but I've seen examples that have > 1. <eot>
[16:00:10] <resnick> <rts> On what 2822 allows
[16:00:30] <mrose> pete, <cts>
[16:00:47] <resnick> What 2822 "allows" (more to the point, intends as meanings of the fields) is:
[16:01:15] <resnick> Resent-*: Trace fields added by the resender. Matches proposed use.
[16:02:01] <resnick> Sender: Added by the original sender if that differs from the author. But that would invalidate current list use, so it's questionable whether that matches reality.
[16:02:03] <resnick> <eot>
[16:02:05] <wrs1864> <rts> RFC2822 and email forwarder
[16:02:18] <mrose> wrs,<cts>
[16:02:35] <wrs1864> My reading of RFC2822 explicitly says that email forwarders are not supposed to use Resent-*
[16:02:37] <wrs1864> <eot>
[16:02:42] <resnick> <rts>
[16:03:44] <mrose> all - i'd like to wrap things up as we're coming to the end of the window...
[16:03:47] <mrose> resnick, cts
[16:04:37] <resnick> Shortening what I was going to say: It could be argued that .forward type forwarding is or is not reasonable to use Resent-*.
[16:04:41] <resnick> <eot>
[16:05:09] <mrose> anyone in the queue that i missed?
[16:05:58] <mrose> ok, thanks very much
[16:06:03] <wrs1864> thank you
[16:06:07] <mrose> next informal chat is in two weeks
[16:06:13] <andy> thanks everyone.
[16:06:21] <mrose> dave and harry can i ask each of you to write-up a summation of your part of the agenda and post to the list.
[16:06:34] <mrose> it can be brief, just indicate the issues that popped up
[16:06:51] <Harry> OK
[16:06:56] <mrose> harry - thanks
[16:06:57] <mrose> dave - ?
[16:07:02] <dcrocker> ok
[16:07:05] <mrose> thakns
[16:07:08] <mrose> adjourn...
[16:07:27] <gordonf> Anyone else wanted that stats link I sent Harry?
[16:07:34] <andy> yeah
[16:07:35] <Maex> yes, please
[16:07:42] <gordonf> http://www.pan-am.ca/dmp/dmp-logs.zip
[16:07:52] <gordonf> Sorry that it's an Access97 database - you use the tools you have.
[16:08:38] <andy> is there a possibility you can summarize it?
[16:08:49] <gordonf> I thought I did in chapter 8 in the DMP draft.
[16:08:56] <andy> thank you.
[16:09:21] <gordonf> The raw information could be useful for comparisons to other things.
[16:09:52] --- hardie has left
[16:09:53] <andy> ok. I wasn't clear on what you were handing out.
[16:10:42] <gordonf> Harry brought up that blocking based on MAIL FROM didn't produce any bandwidth savings. I thought I demonstrated otherwise.
[16:12:45] --- gordonf has left
[16:14:49] --- Harry has left
[16:16:48] --- mrose has left
[16:20:02] --- Maex has left
[16:25:51] --- andy has left
[16:25:58] --- jgmyers has left
[16:51:52] --- resnick has left
[17:39:16] --- SamSilberman has left: Disconnected
[17:43:44] --- dcrocker has left: Disconnected
[19:10:18] --- wrs1864 has left: Disconnected
[19:24:56] --- mitsubachi has joined
[20:11:51] --- mitsubachi has left
[22:58:12] --- tonyhansen has left