[13:56:11] --- gordonf has joined
[14:50:53] --- tonyhansen has joined
[14:53:30] <jlcjohn> My watch sez it's time...
[15:12:05] <tonyhansen> guess no one else decided to join in this week -- looks like we're definitely going with the 2 week wait instead of switching to 1 week
[15:12:56] <jlcjohn> We certainly can discuss things -- e.g. Andrew Newton's ultimatum...
[15:14:57] <gordonf> What ultamatum?
[15:15:02] <gordonf> (sp, I know)
[15:15:41] <gordonf> The post he did about scope of work?
[15:16:13] <jlcjohn> The one this afternoon, demanding we focus on four "identities" and "consider and list five "ramifications".
[15:17:27] <gordonf> *sigh* I'm frustrated atthat, as Yakov, Alan and others asked these same questions back at asrg-smtp-verify and got answers. Now we're asking the same questions over.
[15:18:46] --- gconnor has joined
[15:19:20] <jlcjohn> I'm bothered by the tone, suggesting that the posts of the last week have exceeded our scope...
[15:19:22] <gconnor> Hey guys, i just wanted to check if this client is working
[15:19:57] <jlcjohn> (I thought most of the posts were very good, and within scope.)
[15:21:03] <gordonf> (I'mhaving trouble what to say here, go figure!)
[15:21:43] <gconnor> Does anyone know if there is an offical charter posted? I see "draft charter" in the archive with some changes by Ted after it
[15:21:46] <gordonf> We do have guys talking about accreditation, extended defenitions of words like "identity" etc
[15:21:49] <jlcjohn> In between lines here, I'm working on a response...
[15:22:30] <gordonf> Am I reading correctly that the IESG has not yet approved the creation of a working group, and the draft charter is the only charter we have so dar?
[15:22:38] <gordonf> s/dar/far
[15:22:43] <jlcjohn> So far as I know, yes.
[15:23:55] <gordonf> I think accreditation is out of scope, for example. But this comes from a strong belief that the recipient decides.
[15:25:43] <jlcjohn> The scope, of course (in the draft charter) is: It would be useful for those maintaining domains and networks to be able to specify that individual hosts or nodes are authorized to act as MTAs for messages sent from those domains or networks. This working group will develop a DNS-based mechanism for storing and distributing information associated with that authorization.
[15:25:56] <gconnor> I liked the idea of focusing on 2821 MAIL FROM at first, but with the expectation that we would come back and address 2822 From: Sender: as a second task
[15:26:14] <gordonf> That reduces the work load to bite-size pieces, and I like that too.
[15:27:05] <jlcjohn> Hopefully that will be accepted by the Chairs; but I'm concerned that we leave room for expansion to RFC2822.
[15:27:25] <gconnor> The real challenge there would be to make the mechanism somewhat extensible so that the 2822 work can be covered with similar tools. Not 100% crossover but some crossover would be cool.
[15:27:44] <gordonf> I don't think that paragraph excludes RFC2822 data - it didn't say so outright.
[15:27:56] <gconnor> If we can't come up with an "extensible" mechanism, we may as well treat 2821/2822 together
[15:27:58] <jlcjohn> (
[15:28:23] <jlcjohn> Andrew did rule out RFC2822-Reply-To, which IMHO is most unfortunate...
[15:28:46] <gordonf> Reply-to is used exclusively by the MUA, no?
[15:28:56] <gordonf> An MUA could ignore it
[15:29:34] <jlcjohn> MUA's _could_ do anything -- but it is common to use that to automatically generate the To field of a reply.
[15:29:34] <gordonf> Plus it lets a sender still send on behalf of another, while keeping themselves accountable.
[15:30:24] <gconnor> Reply-To can be abused by (e.g.) 419 scammers
[15:30:57] <gordonf> Reply-to doesn't show up automatically in the From: column of my mail program, or most others I've seen.
[15:31:17] <gconnor> Right
[15:31:39] <gordonf> Is it a matter of the user hitting "reply" not realizing where their replies are going?
[15:31:49] <jlcjohn> Yes.
[15:32:26] <gordonf> I'm not sure that's actually MARID's business to mess with. It looks to me like a MUA implementation issue.
[15:32:32] <jlcjohn> We can't protect against misleading domain names, but we could certainly "authorize" automatic-reply addresses.
[15:32:37] <tonyhansen> if someone sends on behalf of another, they should be using Sender:, not playing around with Reply-To
[15:33:04] <gordonf> As Dave would say, that would change twenty or so years of existing semantics.
[15:33:05] <gconnor> I'm torn two ways on that one... on one hand I would like to control *any* use of my domain, but on the other hand, reply-to leaves a possible workaround for mobile users who are locked out of their home mail resources
[15:33:57] <jlcjohn> Mostly my point is expandability -- there should be a way for domain owners to specify authorization for headers we haven't seen yet.
[15:34:27] <gordonf> Now that I DO remember from the MARID BOF - that sounds like a domain policy problem.
[15:34:41] <gordonf> And some implementations actually have such a control (Exchange for example)
[15:35:12] <jlcjohn> I'm hoping we'll strongly encourage SMTP-AUTH for initial submissions...
[15:35:14] <gconnor> If we try to control Reply-to then we could be on a slippery slope of all kinds of headers people want to control. If we can create some extensible mechanisms, that can be applied to any header (including ones we haven't heard of yet) I would like that better than adding to a long list of headers to build in to the proposal
[15:35:29] <gordonf> BTW: what's the accepted rule for referring to trademarked stuff?
[15:36:13] <jlcjohn> I don't believe IETF has one -- we usually disclaim any meaning related to intellectual property.
[15:37:03] <gordonf> Well, it's not exactly privileged knowledge that Exchange can control who can send on behalf of whom, and I'll bet there are similiar settings in other commercial MTAs.
[15:37:36] <jlcjohn> That _is_ a MUA-internal issue (out of scope).
[15:37:54] <gordonf> good. Thought so.
[15:38:50] <gordonf> AUTH is one good way to ensure accountability in inital submissions. There are others.
[15:39:34] <jlcjohn> Absolutely. Web forms are quite popular, e.g.
[15:40:11] <gordonf> Yeah some ISPs block port 25, some even block port 587 (right port number?) because they're greedy about their corporate image. They're not going to block web mail, or a different port, etc unless they're really control freaks (and then users will complain.)
[15:40:31] <gconnor> do any of you also read SPAM-L?
[15:40:33] <jlcjohn> How often have you seen 587 blocked?
[15:40:44] <gordonf> I was on it. Left screaming from the noise.
[15:41:06] <gordonf> I've not seen 587 blocked (and I hope I don't either). Just noise I've heard.
[15:41:10] <jlcjohn> SPAM-L: I read archives occasionally...
[15:41:42] <gordonf> Even with HTML index to keep the volume down, it was insane.
[15:42:06] <jlcjohn> Clearly, _somebody_ someday will block 587: but there's no pressing reason for most ISPs to block it (if they even know about it).
[15:42:26] <gconnor> Yeah... I know what you mean.. I usually sort by thread and take random samples :) Anyway one of the guys there (bruce gingery) had some comments about, there was an RFC a bit later than 2821 that says "If you can't verify that the client is authorized to use that return address, then you SHOULD reject the message".
[15:42:49] <gordonf> Could that be the second edition of "don't spew?"
[15:44:08] <gordonf> it's too bad RFC 2821 didn't allow for just asking for headers only.
[15:44:23] <gordonf> Like a "HEAD" instead of "DATA" command.
[15:44:51] <jlcjohn> POP allows that.
[15:45:00] <gordonf> We're not relaying messages with POP though.
[15:45:15] <gordonf> We could accept mail with it, but between MTAs?
[15:45:16] <gconnor> I have seen more and more solutions that reject after DATA - I wonder if that is still considered taboo by many? There was the fear that some MTA's would retry the message if you 554 after end of data...
[15:45:42] <gordonf> Rejecting after DATA isn't really bad (ie: "we found a virus"), but the bandwidth's still used.
[15:45:50] <gconnor> Right
[15:45:59] <jlcjohn> It certainly would reduce spam volume to check just a few headers before rejecting.
[15:46:13] <jlcjohn> (bandwidth, I meant)
[15:46:30] <gordonf> Would leaving that (inspecting headers after DATA) to the MTA implementation be enough to start?
[15:46:53] <gordonf> I think that's what the 2821 first, 2822 second, argument is about.
[15:46:54] <jlcjohn> Rejecting after DATA is specifically allowed, but there used to be many broken MTAs that ignored the error and dropped the message without bounce.
[15:47:07] <gconnor> I would think so, enough mailers already do it, postfix is a good example
[15:47:46] <jlcjohn> I believe that no widely-used MTA currently has that problem.
[15:48:00] <gordonf> Nothing that a MTA upgrade couldn't fix
[15:50:04] <gconnor> Some folks might object to changing stuff that works now (even though it breaks pre-existing RFC). I would say if a previous RFC says you shouldn't do something, we shouldn't be afraid of enforcing that.
[15:50:20] <jlcjohn> Agreed.
[15:50:23] <gordonf> Now that is what's getting some folks into a fit.
[15:50:27] <gconnor> Normal users don't read RFCs but MTA developers should :)
[15:50:37] <gordonf> Changing too much of what already works.
[15:51:37] <gconnor> Right. I don't want to break the internet, but I do want to "heal" it. If we declare something "deprecated" it will eventually go away, it doesn't have to be broken right out the gate.
[15:52:03] <gordonf> "Creating a glitch in The Matrix," any one?
[15:52:05] <gconnor> LIke non-fqdn for HELO
[15:52:10] <gconnor> screw that
[15:52:18] <gordonf> heh
[15:53:11] <gordonf> non-FQDN for HELO isn't going to go away. But it could be avoided in MTAs.
[15:53:37] <gconnor> <<< 454 your dumb-ass mailer's official name is not localhost.localdomain, please fix
[15:53:46] <gordonf> Yeah, I know :-)
[15:54:06] <gordonf> I'm thinking about MUAs that don't know their own domain name.
[15:54:09] <gconnor> that's what I mean, it's not going away when we wave our magic wand but we can sure declare it deprecated
[15:54:24] <tonyhansen> btw, it's not SMTP+AUTH we should be advocating, but SUBMIT+AUTH
[15:54:29] <gconnor> Right, MUAs should be talking to their own MSA, not my MTA
[15:55:02] <gordonf> gconnor: Now that's gotten a minority into a fit, too. Mostly other geeks, notably.
[15:55:28] <gconnor> Using the same program for msa and mta has really blurred the lines... I would like a strong statement about when you're supposed to use submit vs. relay-smtp
[15:56:19] <gconnor> Gordon- Right, I can't understand why that would get anyone's panties in a bunch, it's already non-rfc2821 isn't it?
[15:56:36] <gordonf> I'd like to know how easy it is to implement SUBMIT, first. I know on Exchange it can be hacked by creating another virtual SMTP Server and using port 587. But on others it it's as hard as copying the executable, hacking it and launching it as another process.
[15:56:46] <gconnor> We need a second RFC that says "What we said in rfc2821 we really mean it this time"
[15:57:47] <gordonf> gconnor: Indulge me for a moment: Where in RFC 2821 does it say I can't talk to a MTA directly? (I'm in Dave C mode right now, wondering)
[15:58:47] <jlcjohn> It doesn't, of course.
[15:59:16] <gconnor> Actually I was referring more to "helo should have your right name" - I don't think 2821 even had MSA as a concept
[15:59:35] <gordonf> OK, not so much as my own box but make sure my box has a correct HELO.
[16:00:09] <jlcjohn> HELO hasn't fully recovered from bang-paths yet... ;^)
[16:00:23] <gconnor> Right.
[16:00:40] <gordonf> And it's been, what, ten years at least? (re: bangpaths)
[16:01:37] <gconnor> It's been well abused for a long time (HELO i mean). I would like to "take back the helo" mostly because it's a great data point and most (popular) MTAs already use it
[16:02:05] <jlcjohn> HELO is certainly _easy_ to configure -- people are just lazy.
[16:02:51] <gconnor> But, that will take a long time to become standard... which is why I rated it #3. ( my list was 1. 2821 mail from 2. 2822 from/sender 3. HELO)
[16:03:06] <gordonf> As much as I'd like to enforce HELO properly, MUAs aren't going to rDNS themselves nor are they always going to have a domain name from a DHCP server.
[16:03:22] <jlcjohn> Umm... how to you plan to check authorization on bounce messages?
[16:03:24] <gordonf> MTAs, on the other hand, I think should be fair game.
[16:03:53] <gordonf> john: Do it to MTAs, and MUAs that AUTH/SUBMIT properly could be pardoned
[16:04:51] <jlcjohn> Not sure I understand -- you mean that initial submission shouldn't check HELO, but any relaying should?
[16:05:02] <gconnor> I sort of like spf approach of MAIL FROM: <> means check HELO. Treat mail from <> as if it were from postmaster@<helo name>
[16:05:12] <gordonf> Yes, actually, because inital submission could be subject to tighter controls. Much tighter controls.
[16:05:35] <gconnor> Right
[16:05:59] <gordonf> connor: yeah, I like that too. I wonder where Meng got it from *whistle* *whistle* (heh) actually he's good about giving credit where due.
[16:06:51] <gconnor> RIght. I like SPF but I'm not married to it. DMP, RMX, MS, all have the right idea in my book. It's that whole "stand on the shoulders of giants" thing
[16:07:10] <gconnor> I wonder what ever happened to andrew church anyway
[16:07:12] <gordonf> I remember the giants reference but forgot its context.
[16:08:14] <gconnor> (I think there were two, some scientist said "we can see far because we stand on the shoulders of giants". A computer-science twist on it was "we stand taller because we stand on each other's feet" or something
[16:09:02] <gordonf> "SPF is cool because it builds on good ideas," or such?
[16:09:23] <gconnor> Right. Credit where due is extremely important
[16:09:31] <gordonf> I like the "stand on each other's feet" better. Strangely appropriate. :-)
[16:09:45] <gconnor> So, pat yourself on the back too, when patting Meng's
[16:10:11] <gordonf> I just wish he thought more about our respective egos. He appreciates that now more than before Seoul, I think.
[16:10:18] <gconnor> Yeah... I think it was a reference to building huge tall infrastructures that will be 90% replaced inside of 5 years
[16:11:04] <gordonf> That I remember too - something about SMTP beign eventually replaced.
[16:11:08] <gconnor> Right, also being one-upped by MS gave him a taste of what that's like. THough I did notice that he lists you as "co-author" some time back...
[16:11:22] <jlcjohn> Umm... the hour's up -- anything we should take as action items?
[16:12:07] <gconnor> I recommend, uh, less arguing and more discussion, on list :)
[16:12:31] <gordonf> I would like to make clear what the MTA does vs a MUA, as that seems to be a sticky point.
[16:12:47] <gordonf> We eliminate stuff that is MUA's work
[16:12:53] <gconnor> Yes... we should dig up the RFC that defines MSA and discuss it
[16:13:08] <jlcjohn> Yes to RFC.
[16:13:16] <gordonf> What number was it?
[16:13:28] <gconnor> dunno but I can dig it up and write to the list
[16:13:31] <gordonf> Thanks
[16:15:18] <tonyhansen> you can find a useful definition of MSA and other acronyms in draft-ietf-msgtrk-model-07.txt, just approved for rfc-ness
[16:16:21] <tonyhansen> one of the reasons it was put in there was because the entire set of MSA/MTA/etc. acronyms hadn't been collected together into one place before
[16:20:19] <gordonf> I'm gone for now - back next week
[16:20:24] --- gordonf has left
[16:22:22] <gconnor> ok I'm out of here too... I will drop a short note to the list with that rfc info a bit later
[16:22:27] --- gconnor has left
[16:23:11] --- tonyhansen has left
[18:52:20] --- millenix has joined
[18:56:33] <millenix> hey, jlcjohn, who would be the responsible party to ask as list-admin whether adding the list archives to gmane is acceptable?
[19:59:15] --- millenix has left