[04:31:41] --- gritzko has left
[12:43:57] --- Hadmut has joined
[13:18:14] --- Brian Ross has joined
[13:32:53] <Hadmut> Hi
[14:01:51] <Brian Ross> Hello
[14:02:05] <Brian Ross> (sorry, didn't notice the message earlier)
[14:08:39] <Hadmut> Do you know where to get MBONE access?
[14:08:44] <Hadmut> My provider does not support this.
[14:10:23] <Brian Ross> For the multicast session?
[14:10:41] <Brian Ross> Sorry, I don't know off the top
[15:04:27] --- Hadmut has left: Replaced by new connection
[15:04:45] --- Hadmut has joined
[15:48:31] --- yakovsh has joined
[15:48:46] <yakovsh> hadmut: any luck with mbone so far?
[15:49:20] <Hadmut> yakovsh: No, no luck
[15:49:34] <Hadmut> Even worse: I found someone who could provide me a mbone tunnel,
[15:49:37] <yakovsh> its night in korea :(
[15:49:44] <Hadmut> because they want wo watch the same session,
[15:50:05] <Hadmut> but the link between german mbone on the university of oregon is broken.
[15:50:14] <Hadmut> I'm currently trying something else
[15:50:31] <yakovsh> let me know if you come up with anything
[15:50:37] <Hadmut> I will reboot a remote machine with a new linux kernel and hope that this provider may have mbone
[15:50:41] <yakovsh> there will also be a recording in ftp afterwards
[15:50:51] <Hadmut> ...afterwards...
[15:50:56] <yakovsh> i know :(
[15:51:10] <Hadmut> The problem is:
[15:51:40] <Hadmut> Everyone believes that mbone is available everywhere so we don't need tunnels anymore
[15:51:52] <Hadmut> So we have neither mbone nor tunnels
[15:52:06] <Hadmut> My provider's hotline didn't even understand what I was talking about.
[15:52:08] --- Maex has joined
[15:52:10] --- yakovsh has left: Replaced by new connection
[15:52:50] --- yakovsh has joined
[15:54:03] <Maex> Hadmut: we've tried our best but it looks like our peers and uplinks' tech had gone worse than better the last months
[15:54:37] <Hadmut> Any option available?
[15:54:44] <Hadmut> Any chance to get mbone running?
[15:55:01] <yakovsh> I will pass it by some ISPs I know, perhaps someone can provide something
[15:55:07] <Maex> nope ... Gert has tried since yesterday ... no change, not even an answer
[15:55:33] <Hadmut> Unfortunately it's late night in Germany, so difficult to reach any provider
[15:56:06] <yakovsh> its early morning in korea, if we can only get a hold of someone at the meeting
[15:56:50] <Maex> Yakov: the problem is that we don;treach the uoregon where the session is feeded
[15:57:13] <Hadmut> I have sent them an e-mail about 4 hours ago, but no answer at all.
[15:57:18] <yakovsh> can anyone reach them?
[15:58:12] <Maex> I'd think so otherwise there would have been probably a lot of complaints on IETF-general
[15:58:24] <yakovsh> weird
[15:58:50] <Maex> but neither CW nor GBLX can provide MBONE connects ... it drops somewhere within their net
[15:59:04] <yakovsh> have u tried contacting the NOC folks (59crew@noc.kr.apan.net)?
[15:59:31] <Hadmut> Not yet
[16:00:08] <Hadmut> Currently I can't because I'm just rebooting my remote e-mail relay trying to give it a multicast enabled linux kernel
[16:00:30] <Hadmut> So I'm cut from e-mail the next ~10 minutes
[16:00:41] <yakovsh> let me drop them a line
[16:00:53] <yakovsh> not sure if they are the right folks, but they might get the right people
[16:04:47] <Maex> I don't think they will provide a public tunnel ... the traffic would be enormous
[16:05:29] <yakovsh> but they probably know who at the conference is in charge of the multicasting and if we can find that person, he probably will know more
[16:11:03] --- yakovsh has left: Disconnected
[16:34:51] <Maex> n8 folx ... before this all is driving me really crazy I better go home.
[16:37:58] <Hadmut> Gute Nacht...
[16:40:22] --- yakovsh has joined
[17:10:31] --- yakovsh has left: Disconnected
[17:20:11] --- ggm has joined
[17:25:00] --- warlord has joined
[17:32:39] --- yakovsh has joined
[17:33:07] --- ggm has left
[17:33:07] <yakovsh> i got a hold of the multicasting people
[17:33:22] <yakovsh> if anyone is having problems with multicast, PM me
[17:34:26] --- jlcjohn has joined
[17:35:08] --- ggm has joined
[17:40:14] --- ogud has joined
[17:40:31] --- yakovsh has left: Replaced by new connection
[17:41:07] --- yakovsh has joined
[17:42:58] --- yakovsh has left: Disconnected
[17:43:21] --- AWGY has joined
[17:43:29] --- yakovsh has joined
[17:43:33] --- moc has joined
[17:43:39] --- ogud has left: Replaced by new connection.
[17:43:39] --- ogud has joined
[17:43:40] --- ogud has left
[17:43:50] --- mrose has joined
[17:44:12] <Brian Ross> Is the multicast stream showing anything yet?
[17:44:30] <moc> dont think so
[17:44:40] <Brian Ross> Ok. Thanks.
[17:45:02] --- ogud has joined
[17:45:50] --- cnewman has joined
[17:47:07] --- Blake has joined
[17:47:07] <ggm> supposed to start at 9:00 local (7 minutes)
[17:47:13] <ggm> chairs setting up
[17:47:19] <ggm> Ted Hardie, Patrik Falstrom
[17:47:50] --- yakovsh has left: Replaced by new connection
[17:47:50] --- xag has joined
[17:47:53] --- mccreary has joined
[17:47:57] --- yakovsh has joined
[17:49:38] --- SAH has joined
[17:51:30] --- randy_g has joined
[17:51:45] --- paf has joined
[17:51:55] --- anewton has joined
[17:52:09] <paf> My slides have just been sent to the mailing list.
[17:52:16] <yakovsh> thanx
[17:52:19] --- resnick has joined
[17:52:32] --- smb has joined
[17:53:07] --- jakob has joined
[17:53:44] <Hadmut> paf: Did you receive the second version of my slides?
[17:54:20] <paf> FYI: While I am presenting, I will not see (obviously) what is happening in this jabber-thing, so people in the audience have to jump, scream, whatever and read what people say...
[17:54:30] <yakovsh> is there a scribe?
[17:54:34] * paf received the 2nd version of the slides...
[17:54:35] <ggm> oh, I can do that. I can *so* do that
[17:54:42] --- marid has joined
[17:54:42] <paf> Yes, there is a jabber scribe...
[17:54:53] <Brian Ross> are the slides available on the web anywhere (Not on the mailing list)
[17:55:02] <Hadmut> Unfortunately I don't get mcast stream, so I can't see or hear you...
[17:55:15] <Hadmut> RMX++ slides at http://www.danisch.de/work/security/antispam.html
[17:55:28] <yakovsh> what about paf's slides?
[17:55:34] --- dcrocker has joined
[17:55:37] <yakovsh> they haven't made it to the mailing list yet
[17:56:55] <Brian Ross> anybody getting audio on the mcast?
[17:57:13] <smb> we haven't started talking yet.
[17:58:15] <ggm> slides being moved to webserver.
[17:58:20] <yakovsh> url?
[17:58:21] <Hadmut> Any idea where to get a mcast tunnel?
[17:58:28] <paf> http://paf.se/marid-bof.pdf
[17:59:05] <resnick> http://videolab.uoregon.edu/events/ietf/ietf59.html
[17:59:09] <resnick> Choose channel 1
[17:59:10] <ggm> Ted is scoping out what a BoF is
[17:59:48] <ggm> critical issue is 'timeliness' -is there engineering work to be done here, can the IETF do this work quickly enough to be of use to the community
[17:59:49] --- tonyhansen has joined
[18:00:34] --- hta has joined
[18:00:41] --- eric_allman has joined
[18:00:43] <ggm> one of the things BoFs can be is discussion of much broader topics. this bof is NOT the place for a general discussion of spam, spam-abatement mechanisms, principles, as you make your comments this is not the focus of this session. this is to determine if there is work for the IETF and if the iETF can complete the work in a reasonable period of time.
[18:00:52] --- Gordon58 has joined
[18:01:00] <ggm> please behave in a collegiate fashion, focus on issues not personalities. behave as engineers
[18:01:09] <ggm> PAF is goodguy, Ted is BadGuy
[18:01:33] <ggm> stray from topic, ad hominem, agendas outside the Bof, you will be asked to sit down and let the bof proceed
[18:01:38] <ggm> focus
[18:02:15] <ggm> Paf, if we don't see cooperation here, too much 'my proposal better than yours' then IETF not able to make anything quickly enough, IETF wont do anything.
[18:02:32] <ggm> first item, is agenda bashing
[18:02:45] --- galvinjamesm has joined
[18:02:54] --- kivinen has joined
[18:02:55] <ggm> ted thanks me.me me me. its all about me
[18:03:07] <ggm> please be respectful of jabber/multicast.
[18:03:10] <eric_allman> alas, i've had no luck getting into the mcast. the instructions just give me a screen with a quicktime logo
[18:03:17] --- rlbob has joined
[18:03:27] --- Joe Touch has joined
[18:03:30] <ggm> ted/paf will not be watching multicast.
[18:03:31] --- mstjohns has joined
[18:03:40] <yakovsh> is the agenda the same as http://www.ietf.org/ietf/04mar/marid.txt?
[18:03:43] --- falk has joined
[18:03:50] <ggm> [eric, I passed that on. ted is trying to get this looked at asap]
[18:03:56] --- alexeymelnikov has joined
[18:04:04] --- agaton has joined
[18:04:12] <ggm> yes. its the same agenda
[18:04:16] <yakovsh> thankx
[18:04:47] <eric_allman> thx -- i'm betting it's some firewall wierdness. i have no idea where to look though, so i may just have to live with the running commentary
[18:04:54] --- sommerfeld has joined
[18:04:55] <ggm> PAF: background of why its being done. discussions with Paxson, ASRG group. found that this is probably the right time to verify if there is something, part of the subset of ASRGs topics, which is this verification mechanism
[18:05:08] <ggm> looking at proposals, saw myself to a certain degree the discussion is 'wrong'
[18:05:35] <ggm> looking at wrong angle. fine tuning, looking for problems the solutions solve. name calling. not agreement
[18:05:56] <ggm> no meta discussion on the problem we might agree on, might solve any real problem. so take 30,000 ft level see if we can agree
[18:06:07] <ggm> on what problem we are looking at, without this difficult to agree on what we're doing.
[18:06:20] <ggm> so when go through different proposals, discussions can be on this level.
[18:06:40] --- galvinjamesm has left
[18:07:00] <ggm> ALternative method: look at problem, agree what problem is, find solution. some laugh, but this is a top-down design method. extremely difficult to do this. time to take step back. hope not too late.
[18:07:05] <ggm> now slide HOS is SMTP Used
[18:07:15] --- dkclinger has joined
[18:07:40] <ggm> many arguments on this. lots of different entities using it. MTAs. mailclients, people using MX directly from laptop, ISPs, the ones responsible for moving around IP packets, not the ones doing email.
[18:07:55] --- Glenn Parsons has joined
[18:08:12] --- dmayne has joined
[18:08:17] <ggm> ISPs blocking port 25, use outgoing SMTP relays, imply users have to reconfigure email client. mesh of SMTP flows matches mesh of IP flows. not seen real discussion if this good design or not. topology of SMTP allow to be different to IP?
[18:09:04] <ggm> various spams, trojans, injected in a 'proper' mailflow. planted in laptops/computers, can grab whatever info is local incl. private keys, look in address bk. SPAM itself will inject itslef at src just like ordinary email given the way s/w is done at the moment.
[18:09:16] <ggm> so one of the Q is 'how much what we do here will help'?
[18:09:33] <ggm> want to discuss how and where we are using SMTP. what to attack with technical solutions, discuss if helping.
[18:09:44] <ggm> PAF goes to amazingly complex slide of mail
[18:10:04] <ggm> paf sidenote: problems with definitions/ontology. what IS a spam/virus/worm etc. but not for today
[18:10:06] --- motonori has joined
[18:10:19] <ggm> [I cannot ASCII art the slide. ya gotta flip to it.]
[18:10:49] <ggm> can do local sub, with trusted IP client, or sender AUTH. through submission server. different outbound server to inbound is possible. one or more hops inside ISP.
[18:11:14] <ggm> receiving MTA. mailing lists, forwarding, users now and then using diff ISP. so have 3 different paths.
[18:11:47] <ggm> can submit to normal SMTP relay, using AUTH. can see port-25 intercept (eg in hotels) pretty popular. [paf thinks its bad]
[18:11:52] <sommerfeld> message paths classed as "good, bad, ugly"
[18:12:18] <ggm> [right. the colours are so muddy I can't really document which is which from here]
[18:12:52] <ggm> dont have agreement which is good/bad/ugly at this time.
[18:13:09] <ggm> paf thinks the mta-to-mta over open internet, not so much the sender-mta thing.
[18:13:15] <ggm> is what we are talking about.
[18:13:15] <sommerfeld> slide shows intermediate forwarding serevr as "ugly"
[18:13:19] <ggm> now slide about basic flow.
[18:13:25] <sommerfeld> normal direct send as "good"
[18:13:37] <ggm> now foreign domain slide
[18:13:43] <sommerfeld> sends from unusual paths as "bad"
[18:13:58] <ggm> presents choices. talk via normal MTA or via local MTA
[18:14:00] --- mengwong has joined
[18:14:13] <ggm> now open relay slide, and on to direct.
[18:14:24] <ggm> hes not saying much about this stuff btw.
[18:14:41] <ggm> MTA forwarding with env-to rewrite. how to handle?
[18:14:54] <ggm> ML rewrites, env-from rewrite accepted norm
[18:14:57] <ggm> Q1.
[18:15:05] <ggm> will verification of SMTP peer help?
[18:15:05] <mengwong> (a slightly different version of the amazingly complex mailflows slide is at http://spf.pobox.com/mailflows-l.png)
[18:15:26] <ggm> was thinking of going through them all first. take one at time, or take presentation of proposals and go back.
[18:15:53] <ggm> what will transition strategies be? how much deployed before has impact? what other mechanisms do we need in the world?
[18:16:13] <ggm> Q2. if deployed, what will spammers do? pretty sure will change behaviour. part of Q1.
[18:16:14] --- LMasinter has joined
[18:16:23] <falk> Did anyone take a poll of how many spammers were in the room?
[18:16:31] <yakovsh> he he :)
[18:16:39] <yakovsh> the log is open they don't even have to be in the room
[18:16:40] <ggm> Q3. proposals have impact on SMTP relay. is RFC2476 what should be used? SMTP AUTH+port587
[18:17:08] <ggm> first hop from MUA, people really should use auth+587.
[18:17:09] <rlbob> we're all spammers in the eyes of the Architect ...
[18:17:13] <smb> they've just hijacked other people's jabber accounts...
[18:17:29] <ggm> Q4 most proposals force ml/forwarders to be more strict. rewrites, not rewrite.
[18:17:34] <ggm> is this something which will be deployed?
[18:17:43] <ggm> Q5. what type of RR in DNS?
[18:17:57] <ggm> paf asks if DNS people in room doesnt want to argue with self [laughter]
[18:18:15] <ogud> Yes there are some here :-)
[18:18:28] <ggm> summary. http://dumbo.pobox.com/~mengwong/tmp/comparisons/buildyourown.png
[18:18:41] <yakovsh> i see that even caller id made it in here
[18:18:50] <ggm> (table of choices, scope etc)
[18:19:06] <ggm> end of background.
[18:19:08] <mengwong> i put that in to be complete, since CID is a designated sender.
[18:19:15] <ggm> Paf calls for comments
[18:19:23] <ggm> Matt Mathis. what is approx pop of MTAs and how measured?
[18:19:28] <ggm> PAF anyone want to try and answer?
[18:19:31] <eric_allman> what's the "rp" column?
[18:19:34] <ggm> Ted: many
[18:19:35] <mengwong> return-path.
[18:19:41] <mstjohns> many^2
[18:19:43] <eric_allman> ah, thanks
[18:19:51] <ggm> [please be explicit if you want interjections made]
[18:19:59] <ggm> smaller than number of IP addresses.
[18:20:00] <mengwong> when the scope is "IP x return-path", that means "is the IP an allowed sender *for that return-path domain*".
[18:20:14] <mengwong> when the scope is just "IP", as in MTAMark, that means "is the IP an allowed sender *at all*, for *all* domains"
[18:20:16] <ggm> Ted still many millions. go on with Q. assume its 20 million. off by factor of 10, does it change things?
[18:20:46] <ggm> from terabyte datacentre. db with million recs not problems. other problems with DB problems, don't know dimensionality of problem
[18:20:51] <ggm> [this is Questioner]
[18:20:58] <ggm> Ted single DB source impractical,
[18:20:58] <falk> Questioner is Matt Mathis, PSC
[18:21:17] <ggm> Matt easier to understand using DB/datamining high traffic mta's non-compliant, undermining the system. look at logs etc
[18:21:27] <ggm> Paf haven't explain what youre getting at
[18:21:38] <ggm> Matt going through couple of days of logs with supercomputers not a problem
[18:21:51] <ggm> Ted wont change the approach much. talking about vectors of attack changing constantly.
[18:22:09] <yakovsh> ggm: they are assuming that they have supercomputers, small isps will not
[18:22:21] <ggm> Matt. feels like limiting case;
[18:22:28] <dcrocker> one approach for requesting that someone "channel" your jabber entry into a bof microphone is to yse the /me feature. The convention i've developed is to being with /me says:...
[18:22:36] <yakovsh> thankx
[18:22:36] <falk> ggm: can you format speakernames as [speakername]
[18:22:38] <ggm> Ted: little further on in discussion than we are at the moment. we're on 'problem statement' youre further along at this point
[18:22:38] --- Hadmut has left: Lost connection
[18:22:47] <ggm> Sam
[18:23:06] <ggm> record type. marginally interesting. forward or reverse tree, impact on ops more interesting.
[18:23:35] <mengwong> there's a companion diagram for the comparisons/buildyourown chart: http://dumbo.pobox.com/~mengwong/tmp/comparisons/familytree.png
[18:23:43] <ggm> Gordon. repeat plz.
[18:24:07] --- galvinjamesm has joined
[18:24:07] <ggm> PAF. last column on right of summary. more important to look at WHERE in DNS tree record placed
[18:24:22] <ggm> <?> confused problem statement with scope of the BoF.
[18:24:39] <ggm> some solve spam, some solve fraud. looking at this, saying 'will spammers stop' is wrong problem statement.
[18:24:45] <ggm> Dave Crocker.
[18:24:52] <ggm> PAF thinking previous question.
[18:24:55] <ggm> DK ok
[18:25:17] <ggm> Paf not intention to claim solve spam problem. Q is, is it worth putting eng effort in.
[18:25:34] <mengwong> draft-irtf-asrg-lmap-discussion-00.txt section 2.1 identifies four classes of forgeries.
[18:25:57] <ggm> <?> agree in principle. Q is, verification in SMTP will help what? from op standpoint, large amount of problem for zombies comes from social engineering, opening files, giving up passwds etc. because of beliefs. orthogonal to spam but contributes.
[18:26:06] <ggm> in that sense think..
[18:26:10] <ggm> PAF happy to change Q.
[18:26:12] <mengwong> the four classes of spam identified in the LMAP discussion document are: regular spam with forged senders; worms/viruses; phishing; and joe jobs.
[18:26:25] <ggm> <?> Q is really is an expansion. will SMTP verification help, what is the problem that it solves.
[18:26:37] <ggm> Ted: heard you answer that. solves fraudulent domain problem.
[18:26:46] <ggm> <?> thats my belief
[18:26:49] <ggm> Sam followup
[18:27:34] <ggm> last speaker saying Q asking here don't look like original statement of WG. impact DNS/infrastructure. look like going of into political Q.s next Q. what spammers do. this one impacts operations. will they do <x> even worse on infrastructure. so need Q.
[18:27:36] <ggm> Dave Crocker.
[18:27:49] <ggm> when you buy car, worry about first statement. then after 1 day, used to the car.
[18:27:58] <ggm> what I think has just been talked about is implications.
[18:28:35] --- sra has joined
[18:28:47] <ggm> what are implications on spam path, motivations of people in room to solve. may well just be motivation, technique may have broader use. looking for broader use as well as, not instead of, strikes me as good thing to do. operations issue being raised, suggest we look hard at effects techniques have on broad range of email use/users, not well understood
[18:28:48] * cnewman: My view of problem statement: reduce the number of permissible channels to inject mail into the SMTP infrastructure so the necessary auditing problem with abuse of those channels is more approachable.
[18:28:53] <ggm> Rob Elz
[18:29:10] --- joew has joined
[18:29:29] <ggm> Q. is when we're talking about 'solving' domain forgery in SMTP like to know which SMTP domain usage forgery we're looking at stopping there are three, all potential. different places in SMTP. might want to solve any one, all have different implications. one is
[18:29:35] <dcrocker> correction to ggm scribing of my talking: worry about the first "ding".
[18:29:35] <ggm> very unlikely to be solved. thats a Q.
[18:30:20] <ggm> secondly on mail usage. know pats diagrams fit, but in some senses don't . my laptop connects to your MTA, send you mail. dont understand line from MUA up, cannot possibly exist. when talking to MTA are an MTA even if code claims to be MUA. if somebody is
[18:30:33] --- jon has joined
[18:30:59] <ggm> trying to verify this thing with any verification apart from in-mail sigs, its going to fail. who it claims to be when its at one of its homes, its currently some other domain name in all other places. eg here we're all .kr. that name isn't going to verify well
[18:30:59] <ggm> PAF
[18:31:28] --- leslie has joined
[18:31:45] <ggm> I agree I am MUA becomes MTA. you have what I have roaming MTA. for your domain. if it is the case, using DNS based mechanism, from my personal POV you as owner fo email domain have to update recs with dynDNS or whatever.
[18:31:51] <ggm> step back to mailer level
[18:32:04] <ggm> Ted going into implementations. problem statement Q not tech fix.
[18:32:17] <ggm> ANswer is yes. other Q/statement is more for later.
[18:32:33] <ggm> Rob. yes asking which one.
[18:32:40] <ggm> Ted fair problem to bring up during this part of agenda
[18:33:11] <ggm> Rob keep reading on ML. claim auth <x> because mail bounces wont go back. assume one ID being authorised, not usually the one wanted to be authorized
[18:33:44] <ggm> Ted. ok. need to think about which ID to auth, mechanisms need to work.
[18:33:49] <ggm> Still at problem statement.
[18:33:52] <ggm> Pete Resnick
[18:33:58] <ggm> in answer to one of Robs points.
[18:33:58] --- shane_ripe has joined
[18:34:04] --- bkhabs has joined
[18:34:31] <ggm> proposals on table for different identities to use. Roberts point should be honed down to folks who get up to talk about specific solns better address which identity they are using and which problem being solved by that identify. problems for each.
[18:35:01] <ggm> With regard to arch, paf presneted, Rob should keep in mind, because of port 587, servers which do something different to be relay mtas. MUAs are using MS behaviour, something difereing going on there
[18:35:04] <ggm> Harald Alvestrand
[18:35:13] <ggm> many years ago in ted position of trying to make standards run
[18:35:31] --- Melinda has joined
[18:35:34] <ggm> in answer to bullet 1. (will help) is a little. reasons will be more apparent as we go through mechanisms
[18:35:42] <ggm> enocurage chairs to move on to presentations
[18:35:47] <ggm> Chris Newman from jabber.
[18:35:49] <ggm> by Dave
[18:36:14] <ggm> my view of problem statement. reduce number of permissable channels, audit problem for use of those channels more approachable
[18:36:38] <ggm> [bad paraphrase of what dave read from paper, which I think was more exactly what CHris wanted said]
[18:36:50] <cnewman> Thanks, Dave
[18:37:25] <ggm> Gordon.
[18:38:13] <ggm> talking about DMP.
[18:38:33] <dcrocker> [i read Chris' text exactly.]
[18:38:51] <ggm> looking at things from admin PoV.
[18:39:06] <ggm> DMP has lightest load on DNS. reduces response sizes. quick. cacheable
[18:39:15] <ggm> DMP recs quieried on every SMTP delivery
[18:39:32] <ggm> <meta conversation about language to use here>
[18:39:37] --- marushin has joined
[18:39:50] <ggm> better chance for roving user. to get successful query.
[18:39:57] <ggm> better support for dynamicDNS.
[18:40:11] <yakovsh> is he presenting?
[18:40:13] <yakovsh> or asking?
[18:40:22] <ggm> no changes to DNS servers required. no new record types.. RFC1464 used to do DMP.
[18:40:40] <ggm> lack of 2317 makes it hard to use reverse-DNS.
[18:40:50] <cnewman> Anyone have the URL to this presentation?
[18:40:51] <ggm> DMP has clearest protocol path.
[18:41:07] <ggm> effectiveness demonstrated. SMTP volume dropped 1/5th from this method.
[18:41:18] <ggm> if other proposals can come up with similar numbers.
[18:41:20] <ggm> drawbacks.
[18:41:40] <ggm> DMP requires more individual recs in zone.
[18:41:48] <ggm> wildcard DNS recs supported.
[18:41:51] <ggm> more work for admin.
[18:42:03] <ggm> more work upfront, but reduces work on mail servers, BW.
[18:42:20] <ggm> no easy way in DMP to designate another domains recs as authoritative for your domain. extra work
[18:42:33] <dcrocker> [the discussion about the fact that there are multiple identities in email is part of a brief presentation that i've offered for this session. a copy of the slides is at <http:brandenburg.com/presentations/MTA-Registration.ppt>. The number of different types of identity is impressive.
[18:42:40] <ggm> does overload record used for other purposes TXT but can change to another RR.
[18:42:54] <ggm> end of DMP in a nutshell.
[18:43:00] --- jon has left
[18:43:07] <mccreary> http://www.pan-am.ca/lmapbof/DMPdrawback.html
[18:43:19] <paf> http://www.pan-am.ca/lmapbof/
[18:43:36] <yakovsh> thankx
[18:43:48] --- cabo-tzi-org has joined
[18:43:59] <ggm> Yakovsh: is this rhetorical Q or do you want it asked. best if want asked eg is to ask Dave C to do it for you in a 1to1
[18:44:13] <ggm> Ted: RMX proposers here?
[18:44:13] --- moc has left: Disconnected
[18:44:16] <ggm> Ted: no.
[18:44:35] <ggm> Ted will go through RMX ppt.
[18:44:46] --- mrose has left
[18:44:46] <dcrocker> yakov - i lost the context. is what a rhetorical q?
[18:45:45] --- HannesTschofenig has joined
[18:45:45] --- LMasinter has left: Disconnected
[18:45:46] <ggm> PAF. Hadmut Danish. slides
[18:45:56] <ggm> want so speak Hadmuds text in jabber and I'll work slides?
[18:46:00] --- admcd has joined
[18:46:00] <ggm> Ted is getting set for this.
[18:46:02] --- jon has joined
[18:46:13] <mengwong> hadmut, please step up to the microphone.
[18:46:13] <ggm> Hadmut: willing to go through slides with Ted?
[18:46:28] --- shane_ripe has left
[18:46:40] --- kjd has joined
[18:46:48] <resnick> hadmut: I'll read your presentation from jabber
[18:46:49] --- rlbob has left
[18:46:56] <yakovsh> rmx slides: http://www.danisch.de/work/security/antispam.html
[18:47:00] <resnick> You should give me what to say.
[18:47:18] <ggm> ok. if issues come up, will ask. now going through slides.
[18:47:24] --- Ted Faber has joined
[18:47:30] <ggm> Hadmut appears not to be there. failure when try IM on him
[18:47:34] <resnick> Are you there hadmut?
[18:47:40] <ggm> SO. why not use content filters
[18:47:48] <yakovsh> i am getting failures also
[18:47:49] --- Ted Faber has left
[18:47:57] <ggm> -spammers adapt
[18:48:01] --- bkhabs has left
[18:48:10] --- moc has joined
[18:48:15] --- MattMathis has joined
[18:48:34] <ggm> kind of 'reverse MX'
[18:48:51] <ggm> compact encoding in new RR
[18:49:00] <ggm> DNS not a good choice
[18:49:12] <resnick> hadmut seems to be missing. If someone has his direct JID, please send it to me.
[18:49:26] <marid> too bad this isn't being presented; these are good slides
[18:49:48] <ggm> dynamic auth.
[18:49:52] <ggm> map into URLspace
[18:50:15] <ggm> Gordon to mike. Q.
[18:50:41] <ggm> if were not using DNS in this approach, how are we looking up the resource, to find where to get the new information?
[18:50:48] --- leslie has left: Replaced by new connection
[18:50:51] <ggm> Ted: use DNS to bootstrap via SRV, then look in new service.
[18:50:58] --- admcd has left
[18:51:07] <ggm> Gordon on every mail transaction or cached? may impact DNS, even if primary src in DNS.
[18:51:17] --- leslie has joined
[18:51:19] <ggm> Ted: has ttl. can store. equiv to local cache in DNS.
[18:51:21] --- fneves has joined
[18:51:43] <ggm> Gordon: dont see much of a difference. may be causing as much bandwidth.
[18:51:49] <ggm> PAF but saying don't use DNS as storage.
[18:52:01] --- kivinen has left: Logged out
[18:52:01] --- kivinen has joined
[18:52:01] --- kivinen has left: Logged out
[18:52:08] <ggm> dont stick to todays DNS, keep it open for future extensions
[18:52:17] <ggm> why HTTP.
[18:52:27] <ggm> lots of text about benefits of HTTP
[18:53:01] <ggm> Qs/issues about back-end technology. examples of DynAuth declarations in english text
[18:53:15] <ggm> (forms of limits to mail reception/sending policy)
[18:53:50] --- AWGY has left
[18:53:54] <ggm> polemic against crypto.
[18:54:01] <ggm> stops forgery, not spam
[18:54:09] --- AWGY has joined
[18:54:14] <ggm> need other mechanisms. eg blacklisting
[18:54:22] <ggm> Ted: read draft
[18:54:28] --- admcd has joined
[18:54:31] <ggm> Harald.
[18:55:11] <mengwong> http://dumbo.pobox.com/~mengwong/tmp/comparisons/familytree.png
[18:55:18] <ggm> having draft author giving draft presenting one technology then give ppt showing 'best to go to another technology' because it prevents sensible use of the meeting. cannot pre-plan. not happy about Hadmut hving done that
[18:55:49] <ggm> [Passing bat to Andy -restroom visit -ggm]
[18:55:50] <anewton> ming, leader of the spf community
[18:56:03] <anewton> showing big diagram
[18:56:09] <yakovsh> [meng]
[18:56:13] <anewton> all lmap proposals are from same family
[18:56:13] <anewton> ted
[18:56:17] <anewton> focus on your proposal
[18:56:20] <anewton> ming
[18:56:33] <anewton> from rmx and dmp
[18:56:43] <anewton> takes best from rmx and dmp
[18:57:10] <anewton> rmx defines everything up front and can be cached in dns
[18:57:32] <anewton> there are benefits to both appoaches, spf leaves it up to the sender domain
[18:57:45] <anewton> explaining macro in spf
[18:58:06] <anewton> sender domain can do dmp style records
[18:58:23] <mccreary> The diagram is at http://dumbo.pobox.com/~mengwong/tmp/comparisons/familytree.pdf
[18:58:27] <anewton> if dns server is low bandwidth, you can predefine all servers they way rmx does it
[18:58:57] <anewton> simple txt record that makes it easy to make these differentiations
[18:59:46] <anewton> allows transitioning domain to switch to spf, allow for soft fail, allows testing before going all the way
[19:00:06] <anewton> scope of authentication, spf will look at return path and hello, but differently from dmp
[19:00:29] <anewton> drip said checking helo domain could be useful
[19:00:55] <anewton> gordon
[19:01:04] <anewton> makes correction is discription on drop
[19:01:06] <anewton> ming
[19:01:36] <anewton> domin in envelope comes from to place, return path and helo
[19:02:11] <anewton> if you auth on return path, problems with forwarding. forwarders have rewrite return path. problematic
[19:02:16] <anewton> on hello this is not needed
[19:02:26] --- cabo-tzi-org has left: Disconnected
[19:02:27] --- stastny56 has joined
[19:02:35] <anewton> s/ming/meng/
[19:02:47] <anewton> ted
[19:02:55] <anewton> which identities are you proposing to authenticate
[19:02:56] <anewton> ?
[19:03:06] <anewton> meng
[19:03:18] <anewton> spf checks return path domain, only if that is null does it check helo
[19:03:25] <anewton> ted
[19:03:29] <anewton> auth is up down
[19:03:31] <anewton> meng
[19:03:51] <anewton> seven response codes. down says this is forgery
[19:04:06] <anewton> ted
[19:04:17] <anewton> policy to limit # per day
[19:04:18] <anewton> meng
[19:04:44] <anewton> yes, can be done with macro mechanism that contains user name and with custom dns server can be done with rate limiting... has been done
[19:04:47] <anewton> questions?
[19:04:51] <anewton> gordon
[19:05:02] <anewton> how did macro language come about?
[19:05:12] <anewton> smtp may be obsoleted.
[19:05:30] <anewton> this macro language suggests extending smtp indefinitely
[19:05:40] <anewton> keep smtp alive or obsolete it
[19:05:41] <anewton> ted
[19:05:43] <anewton> out of scope
[19:05:45] <anewton> meng
[19:05:49] <anewton> can't decide future of smtp
[19:06:11] <anewton> explaining exceptions with macros, per user restrictions
[19:06:15] <anewton> aurthur ??
[19:06:30] <anewton> trying to solve problem with auth or broader policy problem?
[19:06:53] <anewton> ted:
[19:07:03] <anewton> 2 things, authentication and authorization
[19:07:08] --- dmayne has left
[19:07:28] <anewton> some of these proposals have arbitrarily complex rules which the community must consider
[19:07:34] <mccreary> The previous question came from Arthur Bebak
[19:07:45] <anewton> thanks
[19:07:51] <anewton> harald
[19:08:04] <anewton> when I see a language I ask where is the debugger?
[19:08:25] --- motonori has left: Replaced by new connection
[19:08:28] <anewton> contructs to allow publishing domain to determine if the desired policy is working
[19:08:36] <anewton> hard to debug
[19:08:36] --- Maex has left: Disconnected
[19:08:44] <anewton> meng:
[19:08:57] <anewton> interoperability is a concern for this, but we have a big test suite
[19:09:00] <anewton> harald:
[19:09:30] <anewton> that's not what I am talking about. what about misconfigurations? how is that detected.
[19:09:32] <anewton> meng:
[19:09:35] --- motonori has joined
[19:09:41] <anewton> field model of debugging done by users
[19:09:43] <anewton> harald:
[19:09:53] <anewton> somebody has to send mail to me saying they don't get my mail anymore?
[19:10:19] <anewton> put in a trigger rule to alarm the domain owner
[19:10:22] <anewton> meng:
[19:10:23] <anewton> yes
[19:10:36] <anewton> dig altavista.com txt
[19:10:52] --- mrose has joined
[19:10:55] <anewton> now explaining this dig
[19:12:01] <anewton> steve bellovin:
[19:12:12] <paf> v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.altavista.com -all
[19:12:18] <anewton> concern about arbitarily complex policy languages
[19:12:37] <anewton> it doesn't tell wanna be sender what they have to do to send the mail
[19:12:42] --- galvinjamesm has left: Replaced by new connection
[19:12:42] --- galvinjamesm has joined
[19:12:42] --- galvinjamesm has left
[19:12:44] --- stastny56 has left: Disconnected
[19:12:48] --- stastny56 has joined
[19:12:54] <anewton> don't know how to conform to the mail sending protocol when the rules are arbitrarily complex
[19:13:22] <anewton> rules for sending to ted and paf are different for meng. not good
[19:13:52] <anewton> meng:
[19:13:56] <anewton> sender writes the policy
[19:14:02] <anewton> ted:
[19:14:09] <anewton> what do you mean by sender?
[19:14:11] <anewton> steve:
[19:14:18] <anewton> the senders domain
[19:14:30] <anewton> the rules are not simple enough to know what is legit
[19:14:34] <anewton> nathaniel ?:
[19:14:47] <warlord> bornstein
[19:14:58] <anewton> doesn't this just allow spammers to harvest from dns
[19:15:10] <anewton> not a useful feature
[19:15:10] --- stastny56 has left: Disconnected
[19:15:13] <anewton> meng:
[19:15:17] --- stastny56 has joined
[19:15:24] <anewton> agrees that user names in dns is bad, but that is a user decision
[19:15:27] <anewton> ted:
[19:15:31] --- galvinjamesm has joined
[19:15:33] <anewton> confusion on senders vs. zone admins
[19:15:45] <anewton> person who sends is not the same as zone admin
[19:16:20] * anewton if people catch me not getting the speakers name, please jabber it for me. I appreciate the help others are giving
[19:16:31] <anewton> meng:
[19:16:52] <anewton> that mechanism doesn't exist unless you put in some type of user macro, by default all users are constrained
[19:17:08] <anewton> yakov (channeling by dave):
[19:17:17] --- xag has left
[19:17:29] <anewton> all lmap proposals are about domain relationships, why is spf going into policy
[19:17:32] <anewton> meng:
[19:17:43] --- xag has joined
[19:17:45] <anewton> people try to sound all outbound mail with pgp
[19:17:54] <anewton> but that golden age is long in coming
[19:18:05] <anewton> in that future, spf will still be useful
[19:18:20] <anewton> pgp alone cannot say that.
[19:18:48] <anewton> [ggm back at it]
[19:18:57] <hta> note from me: policy language for email correspondents ..... see RESCAP (ex-WG).
[19:18:58] <ggm> Dave Crocker.
[19:19:07] <ggm> Role of Authentication
[19:19:09] --- yakovsh has left: Replaced by new connection
[19:19:32] --- yakovsh has joined
[19:19:32] <ggm> slides intended to look at broad context, think about proposals in.
[19:19:51] --- Bob.Hinden has joined
[19:19:54] --- mengwong has left: Disconnected
[19:20:18] <ggm> distinction between identities, vs authentication is really from or associated with, or whatever association is supposed to be. is that a valid email address? ip? domain?
[19:20:26] --- xag has left
[19:20:31] --- xag has joined
[19:20:49] --- mengwong has joined
[19:20:57] <ggm> once you validate, all you have is a string. don't know what to do with it. CC schemes include things like enforcement to ensure semantics behind the utility. so once authenticated, have to figure out what to do with it.
[19:21:09] <ggm> multiple identities. list on slide. more than on slide.
[19:21:25] <ggm> mail-from semantic definition is quite correct: its a bounces address. not mail-from.
[19:21:33] <ggm> doesn't pertain to message.
[19:21:42] <ggm> registration schemes seem to fall into 2 categories.
[19:21:55] <yakovsh> http:brandenburg.com/presentations/MTA-Registration.ppt
[19:21:58] <yakovsh> slides
[19:21:59] <ggm> one is validating author of message. concepts of author. use DNS record
[19:22:18] <ggm> other approaches validate network. net auths mta to do its thing. almost certainly need to use in-addr.arpa
[19:22:23] <ggm> major concerns.
[19:22:27] <ggm> think about implications of proposal
[19:22:36] <ggm> quick view, of author based MTA schemes
[19:22:48] <ggm> admin challanges. for many usage scenarios. scaling problems
[19:23:20] <ggm> cites kiosk, mobiles, apply to scheme, see if viable in scheme. do they alter usage patterns in ways which problem?
[19:23:45] <ggm> calling them authentication: not really. deployment is expensive. value measure:
[19:24:13] <ggm> some proposals re-define email semantics. mail-from/ sender re-writes. big implications
[19:24:33] <ggm> some alter dynamics of emails, not just semantics. store-&-forward goes away.
[19:24:39] <ggm> 'nothing inbetween'
[19:24:55] <ggm> policy.
[19:25:13] <ggm> the universal spam crackpot solution rebuttal. cite Robert Berger
[19:25:31] <mengwong> http://craphound.com/spamsolutions.txt
[19:25:38] <ggm> Dave thinks its a valid form. may piss people off, but useful.
[19:25:59] * yakovsh XMPP uses a SRV scheme to match IPs and domains, it was useful there why not here?
[19:26:04] <ggm> Gordon. redefining core email semantics.
[19:26:17] <yakovsh> ggm: can someone channel my question?
[19:26:19] --- kjd has left
[19:26:20] <ggm> these are ones being abused to limits.
[19:26:22] <ggm> I will.
[19:26:25] <yakovsh> dave is gone :(
[19:26:52] <ggm> dave is presenting. andy will give your Q.
[19:27:00] <ggm> Harald.
[19:27:07] <ggm> dave shocked. I really do agree with you [applause]
[19:27:17] --- kjd has joined
[19:27:23] <ggm> Dave I even agree with John Klensin. proves I cant be wrong all the time
[19:28:01] <ggm> Harald. mail from == bounce-to. matches my thinking. by checking mail from can do beautiful things. if we agree thats what a lot of these things do, then we're better off.
[19:28:15] <ggm> Dave if particular bounce add is registered with particular MTA
[19:28:40] <mengwong> harald wants: when someone gets a mail that bounces, and it came from an MTA that has no business sending mail on my behalf, i don't get the bounce.
[19:28:44] <ggm> Harald. hoping for, when someone gets mail that bounces, and came from MTA that has no business sendning mail on my behalf then I should not get the bounce. devil in the details
[19:28:49] <mengwong> sorry :)
[19:28:56] <ggm> no worries mate!
[19:29:07] <ggm> Andy reads Yakovs comment
[19:29:10] <mengwong> for the record, this is the scenario i call the joe-job, and it is what SPF is aimed at.
[19:29:19] <ggm> Dave not a Q to me, not trying to answer those Qs but it is a good Q.
[19:29:28] <ggm> Ted throws to chair of relevant WG
[19:29:40] <ggm> Pete Resnick to mike
[19:30:00] <ggm> Not sure. should say that Yakov has asked me about SRV in personal mail before. not completely sure I know what he's asking.
[19:30:19] <ggm> used so you can locate your destination. I get the feeling most spam solutions are about finding out about source. don't know if
[19:30:20] <ggm> that helps him any.
[19:30:27] <ggm> Dave saying its used exactly as MX record.
[19:30:38] <ggm> Pete yes. forward direction, not the back. followup with more Q will try to answer
[19:30:58] <ggm> Dave is now back at seat.
[19:31:01] <ggm> Ted.
[19:31:02] --- galvinjamesm has left: Replaced by new connection
[19:31:07] --- galvinjamesm has joined
[19:31:12] <ggm> move on to discussion part. implications for DNS, implications for SMTP
[19:31:46] <anewton> ggm.
[19:31:49] <resnick> Yakovsh: Re: SRV: I'm not sure what's being asked. Feel free to IM me directly.
[19:32:02] <anewton> objservation on reverse tree. use of the reverse dns is in the minority
[19:32:13] <anewton> dependency on reverse is decreasing
[19:32:15] <anewton> ted.
[19:32:17] <resnick> Short answer: XMPP uses SRV like SMTP uses MX
[19:32:18] <anewton> ipv6?
[19:32:33] <anewton> ggm.
[19:32:47] <anewton> not an issue yet
[19:33:06] <randy_g> Deployment of reverse is decreasing, I think his point is
[19:33:11] <anewton> 20% of delegated domains are functionally lame
[19:33:28] <cnewman> To Dave: yes, these proposals won't solve the spam problem. Yes, they remove useful functionality from email infrastructure. But they do reduce the number of channels usable to introduce traffic into the email system and that makes the auditing problem for abuse of those channels simpler. One of these proposals will happen, the only question is if the IETF will choose to express a preference for which proposal.
[19:33:35] <anewton> problems with reverse scheme
[19:33:42] <anewton> ted.
[19:33:46] <randy_g> I've always heard that reverse DNS is the most often screwed up
[19:33:50] <anewton> comments on george's use of decimal
[19:34:03] <anewton> rob austein.
[19:34:20] <anewton> the dns follows admin lines, but they are different in forward and reverse trees
[19:34:43] <marid> I completely agree with Chris. The only question is whether or not the IETF gets a say in what gets done in this space; we cannot prevent this from happening.
[19:34:45] <anewton> in reverse tree, means it is about address space. it is not clear that network topology maps well to structure for spam control
[19:34:48] <dcrocker> meng -- i've researched the term joe-job and its a bit different from what you've had in your slides. it can be spoofing mail-from, yes, but it also can be spoofing from. Hence, phishing is a subset of joe-jobbing.
[19:35:03] --- marid has left
[19:35:18] <anewton> almost everybody wants to use some existing record type and overload it.
[19:35:20] <anewton> not good.
[19:35:29] --- NFreed has joined
[19:35:30] <anewton> dns technical reasons for not doing this
[19:35:48] <anewton> explaining why re-using txt records is bad
[19:35:52] <dcrocker> marid - you might want to consider moving the political discussion to another forum. the current forum is for technical considerations.
[19:35:56] <anewton> use distinct rr types
[19:36:14] <anewton> issues in protocol have nailed issues with unknown rr types
[19:36:27] <anewton> so not a problem... rfc 3597
[19:36:33] <mengwong> in theory new rrtypes are a fixed problem, in practice ...
[19:36:44] <anewton> it is not the general upgrade problem everyone talks about
[19:37:21] <anewton> need support of iterative resolvers that are associated with mta's, which tend to be better maintained
[19:37:31] <anewton> dns is fragile and easy to attack. dnssec!
[19:37:46] <anewton> going to need dnssec if we start doing this. that has implications for upgrade problem
[19:38:18] <anewton> so need upgrade for dnssec. gonna have to upgrade installed base for dnssec anyway, even re-using txt records
[19:38:23] <anewton> ted.
[19:38:36] <anewton> relatively easy to attack dns, need dnssec to avoid this
[19:38:37] <dcrocker> pretty much all proposals, not just limited to mta registration, depend on the safety of the DNS. rob is making a _very_ big point.
[19:38:40] <anewton> rob.
[19:38:53] <anewton> not advocating changing the format, just us a new type code
[19:39:22] <anewton> spare room rant on dns labels, wildcards stuff
[19:39:34] <anewton> sam w.
[19:39:49] <anewton> rfc 2929 allocates dns rr types that only require specification
[19:39:53] <anewton> easy to get new rr type
[19:39:57] <anewton> gordon.
[19:40:09] <anewton> understand the overloading issue
[19:40:11] --- kjd has left
[19:40:43] <ggm> my point, badly made: RIRs delegation point for reverse, see declining registration levels. basically stable, but nothing like total. secondly, that for delegated reverse, 20%-?25% are lame. so this means proposals wanting to use reverse have to cope with (a) lower leves of adoption than we'd want and (b) significant runtime error rate
[19:40:44] <anewton> looking at implementations that are ten years old, would like to support those
[19:41:03] <dcrocker> chris - the current discussion is, i hope, focusing on implications. this morning i had a discussion with a very senior email contributor and an even more senior security contributor. they had entirely missed the various admin and ops implications of these registration schemes. so
[19:41:04] <ggm> [badly made by me I mean]
[19:41:09] <anewton> is dns that fragile and under attack
[19:41:27] <anewton> rob.
[19:41:32] <anewton> is not an either or question
[19:41:33] <dcrocker> rather than just say 'one of these is going to happen' let's make a point of making very sure that we understand the implications of the different proposals. also
[19:41:48] <anewton> draft on current known threats to dns
[19:42:07] <anewton> draft-dnsext-dns-threats ??
[19:42:12] <anewton> ted.
[19:42:22] <dcrocker> let's not be quite so cavalier about eliminating usage scenarios for email without getting a broader understanding and some consensus from the user community. on the average,
[19:42:35] <anewton> comment on platform api's. it is really nice that the os has this.
[19:42:43] --- memo56 has joined
[19:42:45] <dcrocker> i think none of us has all that good an understanding of the broad, human aspects of messaging./
[19:42:51] <paf> draft-ietf-dnsext-dns-threats-06.txt
[19:42:53] <anewton> we have experience that lookups in the dns can be done without help of the OS
[19:43:02] <NFreed> Dave, the point of saying "one of this is going to happen:" is that it profoundly affects timing and that, in turn affects technical considerations.
[19:43:12] <anewton> issues about api on client side are somewhat overblown.
[19:43:32] <mengwong> all my concerns re RRtypes are about the server side.
[19:43:35] <dcrocker> ggm - "...we'd want and ??" it came out as a beer mug.
[19:43:42] <anewton> there are paths forward for new rr types that can be relatively quick.
[19:43:51] <anewton> words about getting this into client or zones is overblown
[19:43:59] <anewton> ed lewis (super guy).
[19:44:17] <dcrocker> ned - most of the references to
[19:44:36] <anewton> don't want to overload txt records, dns needs to work and overloading causes operational issues
[19:44:57] <anewton> speaking to one of Dave's slides
[19:45:15] <anewton> some proposals redefine dns semantics, that is a concern
[19:45:36] <yakovsh> who is speaking?
[19:45:37] <anewton> never seen any application where putting policy in dns has been successful
[19:45:43] <dcrocker> ned - "it's going to happen" are being use to short-circuit any serious discussion about the details and implications. obviously i'm not saying that is what you or chris or "marin" are doing, but it is a consistent problem in the public fora (and lots of private ones) for spam control discussion.
[19:45:45] <anewton> one concern is that dns needs to be looked at
[19:45:48] <anewton> gordon.
[19:45:51] <anewton> agrees
[19:46:01] <anewton> nothing wrong with new rr type
[19:46:09] <mengwong> i've been working on a bunch of summaries: http://dumbo.pobox.com/~mengwong/tmp/comparisons/spf.gif
[19:46:10] <anewton> just worried about legacy installed base
[19:46:15] <memo56> Can anybody provide the URL for the slides of Patrick?
[19:46:18] <anewton> rob.
[19:46:40] <ggm> http://paf.se/marid-bof.pdf
[19:46:47] <anewton> distinction between dns zone admins and mail admins may lead to dynamic update, but may need to look at it
[19:46:53] <mengwong> all those things are very preliminary, i'd like feedback from other people so they're less subjective. http://dumbo.pobox.com/~mengwong/tmp/comparisons/dmp.gif http://dumbo.pobox.com/~mengwong/tmp/comparisons/rmx.gif http://dumbo.pobox.com/~mengwong/tmp/comparisons/mtamark.gif
[19:46:54] <memo56> thx
[19:46:58] <cnewman> Dave: I concur we need to understand and preferably document the impact of these proposals. The point is we have to do that rather quickly if we're going to influence which one is deployed.
[19:47:06] <anewton> gordon.
[19:47:31] <anewton> talking about common flaws in all proposals.
[19:47:42] <NFreed> Dave - I agree it is being used this way. But it is nevertheless true, and ignoring it as an input to our own _technical_ process seems unwise to me.
[19:47:51] <anewton> dig babelfish.altavista.com txt
[19:47:52] <NFreed> And that is what some have suggested we do.
[19:48:03] <dcrocker> chris -- translated into "this is an absolutely dire problem with an overwhelming need to do _something_ quickly, then of course I agree.
[19:48:14] <anewton> what stops a spammer from forging babelfish?
[19:48:32] <anewton> questioning subzones.
[19:48:37] <dcrocker> chris, ned, et al - let me stress that we have a multi-cultural communication challenge, here, now.
[19:48:41] <anewton> asks for a better solution.
[19:48:46] <dcrocker> we have the ietf folks and we have the anti-spam folks
[19:48:50] <anewton> rob.
[19:49:01] <dcrocker> and the styles and content of discussion are massively different.
[19:49:02] <anewton> pointing out how dns wildcards work, using them is a mistake
[19:49:02] <mengwong> nice, thank you gordon.
[19:49:11] <anewton> harald.
[19:49:21] <mccreary> The LMAP summary slide was http://www.pan-am.ca/lmapbof/lmapflaws.html
[19:49:33] <mengwong> i just realized how to solve the demon problem. you add a match_subdomains modifier to the SPF record, and then you can allow ancestor lookups.
[19:49:35] <anewton> spammers faking domain names with no legit mailbox attached is ok for bounces
[19:49:49] <anewton> sam.
[19:49:56] --- galvinjamesm has left: Disconnected
[19:50:11] <anewton> curious about where query load will land.
[19:50:22] <anewton> rir's? roots? other tld's?
[19:50:37] <anewton> ted.
[19:51:13] <anewton> tree walking question. if you believe you are asserting a record for the tree below it, dns zone admin boundaries are not always same causes problems
[19:51:44] <anewton> robert elz.
[19:52:18] <anewton> for system bouncing mail to nonexistent mailbox, there are problems
[19:52:31] <anewton> gordon.
[19:52:44] <ggm> Sams Q. rirs. we will see a marked increase in reverse traffic. we can scale, we are well under provisioning limits here. but we will see an operational increase. esp. since so many DNS reverses do not exist, that goes to us and we have to NXDOMAIN it.
[19:52:56] <anewton> asking a dns question.
[19:53:11] <anewton> will query load fall on senders servers
[19:53:13] <anewton> rob.
[19:53:19] <anewton> depends on where the caching is done
[19:53:25] --- Bill has joined
[19:53:28] --- MattMathis has left
[19:53:30] --- MattMathis has joined
[19:53:32] <anewton> you need to write down what the behaviour is
[19:54:28] <anewton> refers to dns resolvers are sometimes abusive of the infrastructure and that effects of new spaming fighting technology will be problematic
[19:54:35] <anewton> [ggm back at it]
[19:54:40] <ggm> Dave
[19:54:53] <ggm> trying to figure out fake responding as if I had been listening [laughter]
[19:55:22] <ggm> Ted re-injects cache prep datafetches on Daves drum store.
[19:55:29] <ggm> [churn]
[19:55:31] <ggm> Dave
[19:55:48] <ggm> mentioned it before, want to mention it again, something I missed on slides, list of identities.
[19:56:09] <ggm> list of operators, administrators, players. who has to do what, in large scale. diff groups, incentives, is it true that the people who
[19:56:23] --- memo56 has left
[19:56:30] <ggm> want the in-addr.arpa for MTAMARK etc different from those who update the records. those Q apply to absolutely everything in the space
[19:56:57] <ggm> fewer things to line up the better. trying not to crit. proposals. each as admin overhead. sure some scale better. some alter email semantics
[19:57:54] <ggm> "here is what mail has meant since 25 years" may be good goal to seek to change, but makes me leery. easier to add than change. concerned about that. altering store-&-forward behaviour. what I call the exit SMTP g/w -your own, or enterprise, no intermediaries, operational implications huge.
[19:58:29] <ggm> third party, kiosks, most of the schemes for channel based trust require significant additional mechanisms. starting to get complex sequence of mechanisms. worry when something to fix problem, have to fix problem in it, cascading set, fragile ..
[19:59:17] <ggm> Higher level. some of these schemes alter human usage of email in non-trivial manners. never get talked about, handwaved away. how I use it, you use it, we think we understand broad basis of use bothers me. email as human communication, outside of the realm of most of our expertise, need to respect that, and we dont
[19:59:24] <ggm> Example.
[19:59:26] <ggm> Dave
[19:59:44] <ggm> no longer send postal maile xcept through the slot you register. no longer make phonecall through any random phone
[20:00:00] <ggm> Gordon. problems. Senderpays applies. pause - am I out of scope?
[20:00:15] <ggm> Ted> try to address different way. can these proposals be carried forward without limiting current usage of email
[20:00:56] <ggm> Gordon majority of clients use OutlookExpress. don't run own mail server, unless small enterprise. run clients. not superly technical. know where send button is and thats about it. try to design around that, existing s/w works with that. believe I've done that. want feedback.
[20:01:08] <ggm> Gordon. like idea of treating mail-from as bounces-to.
[20:01:25] <ggm> get to greeting card sites, etc may want bounces to go somewhere else. can shift thinking around that
[20:01:55] <ggm> haveproblem with store&forward. this, like anything else I see overly abused gets taken away. some parts, some semantics may need changing to correct things. too far abused
[20:02:06] <ggm> Edwin agrees with Dave.
[20:02:10] <ggm> Dave calls for statistics on this.
[20:02:17] <ggm> Edwin. fundamental change to way we talk about mail
[20:03:14] <ggm> greetingcard/forwarding services will need to change. but from op perspective current systems cannot continue with all the loopholes left open. AOL blocked 4billion already in 1st 4 months. if thats what we're trying to protect we have real problems [applause]
[20:03:15] <ggm> Dave
[20:04:43] <ggm> trying not to directly respond to response. believe that response is representative to class of responses we see here, appreciated the way this BoF is being done. here to do technical discussions. typical response in other fora as soon as you start to raise tech concerns, tradeoffs, people say 'don't bother me with details' ie hysteria. hysteria doesn't help. I'm not saying dont make tradeoffs, lets be very clear about effects, benefits of change would be
[20:04:51] <ggm> Ed Lewis
[20:05:00] --- dcrocker has left: Replaced by new connection
[20:05:42] <cnewman> /Me: we need to be constructive rather than obstructionist about this. Saying we can't do this because it breaks email is not helpful. Saying this breaks this email, here's one way to address that breakage is helpful. Saying this breaks an email feature, but the cost of the present forgery problem is higher than the value of that feature may also be constructive.
[20:05:45] <ggm> been following DNSSEC since start. go back to old archives. one thing I think made them take so long to develop, was not about putting security into DNS, more understanding how DNS works. mail not scaling any more, be true to email. otherwise will spend all time fixing all the things broken making this fit. DNSSEC taking years to come out because of this
[20:06:00] <ggm> thnk about base principles from when it was designed.
[20:06:07] <ggm> Nethanial Borenstien: joining dk love-fest
[20:06:11] <ggm> [laughter]
[20:06:13] --- dcrocker has joined
[20:06:26] --- cabo-tzi-org has joined
[20:07:05] <ggm> spirit of previous comments, explicitly recognize tradeoffs. has been evolving pretty steadily since deployed. need to take a stand on what we are willing to loose. store&forward aspect, until recently thought of as fundamental, I think we can loose, if we solve disconnected mobile clients with auth droppoff protocols. so I think one thing we CAN give up is store&forward
[20:07:15] <ggm> Ted
[20:07:24] <ggm> fundamental design of email is any-to-any mesh
[20:07:34] <ggm> we build 1to1 or 1tomany on top of that.
[20:07:56] * paf is collecting presentations, and I think I have from Hadmut, Dave, myself, meng and Gordon -- can others please send other "data" to paf@cisco.com *NOW* please?
[20:07:58] <ggm> implication of that is, SPammers work WITH the design of email, for their work. taking advantage of the fundamental design of email to deliver their message to the recipient.
[20:08:13] <ggm> all the work we do works against that fundamental design. I think implied by what dave/nathanial said.
[20:08:24] <ggm> Ted
[20:08:31] <ggm> limit damage from work done
[20:08:52] <ggm> hard engineering problem. come up with spam abatement method so damaging to any to any, breaks or wont be deployed as too hard
[20:09:06] <ggm> what we are looking for are places in this where we can improve the situation without damage to any to any mesh
[20:09:19] <ggm> may be looking for places where spammers wont fight us
[20:09:47] <eric_allman> a place where spammers won't fight us? dream on....
[20:09:49] <ggm> if bounces fail in new way which no longer bothers Mail system. improves edwins life for a few months, that might be deployable solution because nobody fighting against it
[20:09:53] <ggm> Dave
[20:10:09] <ggm> for Chris Newman. chris didn't say he loved me too. [laughter]
[20:10:27] <ggm> I wont re-type this. its up in the log.
[20:10:55] <ggm> Ted other comments
[20:11:11] <ggm> any to any mesh already broken. [no name]
[20:11:20] <ggm> may be trying to preserve something which only theoretically exists
[20:11:28] <ggm> Ted may be true, but proto design is for that.
[20:11:37] <ggm> Gordon.
[20:11:50] <dcrocker> eric - i think he meant something a little more interesting. it's a bit of a martial arts distinction between
[20:11:50] <ggm> reminded of problem brought up.. steve gibson here? no. ok.
[20:11:59] <ggm> reminded of raw sockets hysteria.
[20:12:17] <ggm> group of people tried to get MS, Sun to abandon raw sockets "for the good of the internet" -but have to agree with dave.
[20:12:18] <mccreary> [mo name] was Arthur Bebak again
[20:12:20] <dcrocker> hard and soft techniques. you try to strike me and i block your blow, versus you try to strike me and i move out of the way.
[20:12:43] <ggm> Spencer Dawkins.
[20:13:04] --- Melinda has left
[20:13:06] --- galvinjamesm has joined
[20:13:08] <ggm> support of idea we're loosing the any to any mesh. we're sending email people are afraid to open. or entire domain blacklisted. its just not happening. problem is severe.
[20:13:16] <ggm> Robert ELz
[20:13:33] <ggm> first off, to get into the love fest, its not THAT unusual I'm agreeing with him.
[20:13:35] <eric_allman> ok, perhaps. but i'm bored of doing things where we know they can fight back, and we just hope it will take them a while to figure out how. they always figure it out, and it's often sooner rather than later. we go to a lot of work and get maybe a few weeks of relief. a waste of time.
[20:13:48] <ggm> anyway, trying to figure out what the problem is we're trying to solve here.
[20:13:57] <ggm> I didn't think this was the anti-spam BoF. thought it was something different.
[20:14:13] <ggm> lot of things could do to improve email in various ways, add functionality. most will hve zero effect on spam
[20:14:23] --- Joe Touch has left: Replaced by new connection
[20:14:54] <eric_allman> that's one of the reasons i'm not excited about SPF. it seems to me like it relies on the current behavior of spammers, not what they might do in the future. joe-jobbing (the mmw version) is a problem, but i suspect it is minor after we deal with the larger issues.
[20:14:58] <ggm> the comment was the analogy of registering phones vs spammers paying for email. if they had to pay the cost, they wouldn't give a stuff. nothing we do [..] spam is just email. as long as we want email to survive, spam will survive. various interpretations
[20:15:00] <ggm> Ted not in scope.
[20:15:03] <ggm> Rob: ok.
[20:15:16] <ggm> Ted excellent segue to 'is there IETF work in this arena'
[20:15:38] <yakovsh> eric: it makes the playing field smaller, less channels to deal with
[20:16:12] <ggm> Ted does this group there is work the IETF should take on in developing an MTA authorization, DNS record, for the use of MTAs which wish to check if their PEER MTAs are authrorized to send mail for one of two identities: the bounces-to,
[20:16:28] <ggm> Dave[ you are eliminating MTAMARK and ???] clarify is good, but I think you don't want to do that.
[20:16:37] <ggm> :PAF I will edit Q on screen, argue about words on screen.
[20:16:39] <ggm> Ted
[20:16:49] --- yakovsh has left: Replaced by new connection
[20:16:52] --- yakovsh has joined
[20:17:02] --- ddp has joined
[20:17:03] <ggm> Is there scope for IETF work, which relates to MTA auth for use by peer MTAs where DNS rr may be used in the authentication
[20:17:09] <ggm> PAF put up IEFsdfasdfasdfkbasdmn asdnfb
[20:17:12] <ggm> [laughter]
[20:17:24] <ggm> Ted. ok again. slides now being typed by PAF.
[20:17:33] <Brian Ross> So am I off in left field here or isn't spam reduction merely a fringe benefit of being able to authenticate the sender. I thought the authentication piece is what we are really working on here?
[20:17:45] <ggm> Is there IETF work that we should take on to develop an MTA auth mechnaism based on the DNS?
[20:17:45] <eric_allman> yakovsh: yes, i agree. but they still have tactics available. we've done a lot to make it harder for them, but the problem still grows. we've slowed what, the 3rd derivative? i want more than that.
[20:17:48] <ggm> [this is the first cut]
[20:18:30] <ggm> guys, I can't do the slide wordsmithing realtime. I will post when its done. ok?
[20:18:44] <yakovsh> eric: its one tool in the toolchest, the problem has many aspects, we are addressing different parts of it, this addresses one part
[20:19:11] <ggm> KRE calls for us to spell the words
[20:19:38] <eric_allman> authentication is a necessary precondition to be able to use some of the more interesting anti-spam techniques. allowlisting is worthless if anyone can forge -- viruses will collect this info. but allowlists are going to be critical to both reduced expense and to address false positives. and some auth (notably DK) addresses phishing directly.
[20:20:14] <eric_allman> y: i agree about addressing one part. a very important part.
[20:20:17] <paf> Is there IETF work that we should take on to develop a mechanism that allows an MTA to use a DNS-based record to signal to peer MTA’s that it is authorized to send mail.
[20:20:19] <ggm> ok. this text is now stable to post to jabber
[20:20:40] <ggm> Dave: good language. focus attention on a class of proposals.
[20:20:54] <ggm> Dave have concerns about some of them, all of them. concerns about in-addr arpa concerning.
[20:21:04] <ggm> this discription is about useful work on email ?
[20:21:07] <yakovsh> do we get to vote :) ?
[20:21:12] <eric_allman> paf: i really think that SS should be adopted quickly. it seems to have minimal collateral damage, and helps deal with the zombies out there.
[20:21:13] <ggm> some proposals we have to look at
[20:21:16] <warlord> we dont vote in the IETF
[20:21:21] <randy_g> Can you hum on Jabber?
[20:21:24] <yakovsh> just kidding :)
[20:21:28] <eric_allman> hmmmmmmmmmmm
[20:21:32] <ggm> some mechanisms are not spam mechanisms, relevant to control of spam. just plain good ideas. spam is the motivation.
[20:21:49] <ggm> but if spam not around, these would still be useful. distinction will help evaluate some proposals for short/longterm
[20:22:03] <ggm> do *I* think this feature would be good even if we had no spam? yes. totally appropriate for IETF to persue it
[20:22:12] <ggm> Pete Resnick.
[20:22:50] <ggm> by way of answer to simplest of KRE's Qs. I think what we're at here, is solving a problem (none of them would say it this way) for folks who get on the order of 4bn mail msgs, some clearly coming from folks clearly not auth, and some from some of the folks
[20:22:55] <ggm> who also get 4bn, some bounces.
[20:23:12] <dcrocker> eric -- i'm a fan of mta mark / ss, also. however i'm _very_ concerned about the dns issues that have been raised by the dns geeks.
[20:23:17] --- falk has left: Disconnected
[20:23:19] <ggm> class of problem we want to solve for those big folks first. will eliminiate some relatively small amount of general spam , but will plug a hole for those people.
[20:23:35] --- ddp has left: Disconnected
[20:23:45] --- yakovsh has left: Replaced by new connection
[20:23:46] <ggm> we're seeing those folk throw out solns because they need quick fix,. what we can do is tool a solution they ahven't thought about because its more complex than they have wanted.
[20:23:50] --- yakovsh has joined
[20:23:59] <ggm> I think don't take on work using TXT. others can screw that up on their own [laughter]
[20:24:01] <ggm> Ted be nice
[20:24:06] <eric_allman> dcrocker: yes, i suspect we don't understand that as well as we should. however, DNS is already an issue -- a big one -- and perhaps something like this gives us real incentive to get DNSSEC deployed. Of course, that doesn't address the performance issues.
[20:24:07] <ggm> Pete I'll buy him a drink.
[20:24:11] <dcrocker> brian - the fringe benefit perspective is very useful, for distinguish spam-only vs. 'just plain good enhancement'.
[20:24:29] <ggm> Pete but do some other DNS based system, cleaner architecture, see if give them tool to work with. Dont think take on any of the current solns as such.
[20:24:31] <ggm> Ted take work?
[20:24:36] <ggm> Pete ambivalent.
[20:24:54] <ggm> Nat Borenstein. resounding yes. tech reasons elucidated. also important political ones
[20:24:57] <yakovsh> eric and dave: I like SS also but I am concerned whether it is viable to be deployed considering the rare use of rDNS in the real world by regular users
[20:25:35] <ggm> seen today how complex these propsals are. keep in scope. large cpy has announced doing one of these without any evidence of understanding depth of tech issues. so do something here as prophylactic to somehting worse happening [claps]
[20:25:45] <ggm> Mike St Johns. delete all but one word .......... [laughter]
[20:25:58] --- ddp has joined
[20:26:07] <ggm> agree with statement. dont know we've made the case DNS based approach to allow MTA signal to peer is auth has been established as right approach.
[20:26:16] <ggm> Larrt.
[20:26:24] <ggm> sorry Larry
[20:26:33] <ggm> intend it to be binary? send or not send, or auth for some and not others?
[20:27:11] <ggm> Ted dont want to answer Q in this thing. tradeoff. engineering. deployed and run binary can be done, something with policy may take 2 years. choice to make, not to buiold in here. dont intend to restrict scope
[20:27:18] <ggm> Larry so not restrict Q to only binary.
[20:27:31] <ggm> Harald
[20:27:39] <ggm> to get back to Q and not wordsmith. I think yes
[20:27:41] <eric_allman> yakovsh: what does rDNS have to do with it? if a sender wants to support SS they do it. Yes, that means they will have to effectively do rDNS, but there are no restrictions there.
[20:27:49] <ggm> I thnk pete is wrong.
[20:28:00] <yakovsh> eric: I am assuming SS is refering to MTA MARK which uses rDNS
[20:28:05] <ggm> built internet out of stuff that didnt work in first place, then fixing it.
[20:28:18] <ogud> Erik which performance issue are you mainily concerned about
[20:28:22] <ggm> doing something that is not perfect, will cause breakage, for unknowable reasons is not news to IETF.
[20:28:30] <ggm> have to take some chances to get somewhere with this.
[20:28:31] --- mstjohns has left: Replaced by new connection
[20:28:31] <eric_allman> ah, sorry, i think i
[20:28:31] --- mstjohns has joined
[20:28:31] --- mstjohns has left
[20:28:32] --- leslie has left: Disconnected
[20:28:36] <ggm> IETF work, do it. now.
[20:28:37] <ggm> Sam W
[20:28:37] <yakovsh> eric: my concern is more with support by ISPs
[20:28:40] <ogud> Sorry s/Erik/Eric/
[20:28:43] <eric_allman> sorry, i'm thinking of something slightly different.
[20:28:52] <yakovsh> eric: a penny for ur thoughts?
[20:29:11] <ggm> not sure in good position to judge utility of stuff presneted to us, want them into IETF so we can avoid TXT and damaging behaviour. happy to see us, welcome proposals to look at this for bad effects, independent of any merit
[20:29:27] <ggm> ?? useful to thing to do for any system
[20:29:32] <ggm> keep in mind for other systems
[20:29:40] --- cabo-tzi-org has left: Disconnected
[20:29:46] <ggm> Q in my mind. work. useful. how much time to deploy, how much time to change mechanism.
[20:30:03] <ggm> average time to change, months. not saying wont be done. but ..
[20:30:05] <eric_allman> the SS i'm thinking of uses a structure like rDNS, but the point is that people who don't use rDNS today are no more penalized than they already are. It's TXT records, not PTR. I can't recall right offhand where this one comes from, but I can check if you want.
[20:30:11] <randy_g> (how mich time for spammers to change their mechanism)
[20:30:25] <ggm> Ted get in line now for people to comment., then close mike. go to HUM
[20:30:27] <dcrocker> eric - just saw your comment to me. i have a split reaction to your comment. on the one hand, yes i like having strong, near-term impetus to _finally_ fix some critical problems with the DNS. on the other hand, i never, ever trust critical change and adoptions depencies for critical, internet-scale infrastructure.
[20:30:51] <eric_allman> ogud: perf primarily just from total number of queries. Increases load on network and servers. It's not clear how effective caching will be.
[20:30:52] <ggm> HUM now people have to leave
[20:31:01] <yakovsh> eric: please, u can email it more after the meeting if u can't find it now
[20:31:07] <eric_allman> BTW, this is an issue with SS.
[20:31:10] <ggm> Ted is humming the Q
[20:31:13] <ggm> HUMMMMMMMMMMMM
[20:31:20] <ggm> room now nobody said no.
[20:31:24] --- admcd has left
[20:31:24] <eric_allman> hold on.
[20:31:39] <ggm> hold on? we're out of time, half the people are leaving
[20:31:48] --- anewton has left
[20:31:54] --- jakob has left
[20:32:00] <eric_allman> http://www.taugh.com/mp/ss.html
[20:32:02] <ggm> person: something is going to be done even if we do nothing
[20:32:03] <Brian Ross> Physically leaving, but some of us are still virtually present.
[20:32:17] <yakovsh> eric: aha, johns proposal
[20:32:18] <ggm> for reasons of PM if nothing else. limit to auth.
[20:32:36] <yakovsh> eric: its also in rDNS tree
[20:32:41] <ggm> disagree its engineering. specify as 'just auth' gives clear target, tractable problem.
[20:32:43] --- pgmillard has joined
[20:32:51] --- Gordon58 has left: Disconnected
[20:33:01] <ggm> not clear to me DNS methods are best way. may be. seem to be expedient. want more discussions on other mechanisms. not to sau DNS is not right, but want to see choices
[20:33:09] <eric_allman> dave, i concur about the deployment problem. but just maybe people care enough now to actually get off their butts and do something.
[20:33:12] <ggm> Pete Resnick
[20:33:14] <randy_g> BTW, no one hummed against IETF taking on this work
[20:33:15] <ogud> Erik: glad you are thinking about that performance issue, same as today looking up peername, we can do this in parallel if API allows, my concern was more with the cost of DNSSEC.
[20:33:20] <ggm> ambivalent, not opposition to starting WG.
[20:33:36] <yakovsh> does that mean there is going to be a wG?
[20:33:45] <randy_g> Very likely yes
[20:33:51] <eric_allman> yakovsh: i don't care about the details of the impl: the point is to somehow label hosts that you should never, ever get SMTP connections from.
[20:33:58] <ggm> concerned about doing this kind of work, bring current proposals to table, in open format going to generate great deal of interest, lots of people, folks with proposals but no interest of coming to consensus. warning.
[20:33:59] <randy_g> Pete is expressing concern that this could turn into a wide-open food fight
[20:34:13] <ogud> Just there is going to be proposal to IESG to form one, they hope they appove it.
[20:34:17] <ggm> Harald not the only way to run a WG.
[20:34:32] <yakovsh> eric: I like SS because rDNS is the logical place for IP address data
[20:34:40] <ggm> person2 sounds like people want an -NG protocol. if thats the case, temporary relief, spam/abuse. I believe it will get support
[20:34:49] <ggm> avoid getting bogged down.
[20:34:56] <eric_allman> ah, DNSSEC. Yeah, I don't really understand the implications of this, other than that signing everything is going to have costs (just like DK, sigh). DNS queries are relatively light compared to SMTP transactions though, so this cost could really hurt.
[20:35:04] <ggm> Ted
[20:35:13] <randy_g> Eric -- would enough organizations set the 'no SMTP' flag to make it worthwhile?
[20:35:14] <ggm> my intent putting up Q to focus on current generation of email protocols.
[20:35:14] --- claudioallocchio has joined
[20:35:23] --- stastny56 has left: Disconnected
[20:35:27] --- stastny56 has joined
[20:35:29] <ggm> enough people looking to next gen, scope has to apply to this gen. thats what I intended
[20:35:29] <cnewman> Eric: The domain authorization stuff by itself isn't too useful, but it makes whitelists much more useful. And for the subset of the user community that can use whitelists (maybe 60%-70%) that's a significant step forward.
[20:35:34] <ggm> Rob Austein.
[20:35:44] <eric_allman> yakovsh: yes, rDNS seems logical. maybe some poeple will actually do it.
[20:35:49] --- fneves has left
[20:35:53] --- Bill has left: Disconnected
[20:35:56] <ggm> since likely to go down DNS based path. WG should concentrate on semantics of data wanted in DNS. don't sweat the representation
[20:36:17] <yakovsh> eric: I am thinking the same
[20:36:18] <eric_allman> randy: i;m betting yes, based on what i've heard recently from a lot of the big providers. they are hurting.
[20:36:20] <ggm> we've been down this path. plenty of DNS geeks will figure out representation. done by others has to be re-done. think about semantics
[20:36:26] <ggm> Dave Crocker. respond to Pete R. concerns
[20:36:31] <ggm> in a lot of peoples minds. important.
[20:36:35] <eric_allman> chris: yes, absolutely.
[20:36:36] <randy_g> I like Ted's comments that some parts of this problem are in areas where spammers don't care; if we can fix the fprged mail bounce problem, spammers won't change because they don't case, and we'll have helped
[20:36:44] <ggm> not a newsflash, people active in IETF with agendas we dont like. thats ok.
[20:36:57] <ggm> this is a topic which excites emotion/confusion.
[20:36:58] --- MattMathis has left: Disconnected
[20:37:04] <ggm> Ted asks Dave to speak to screeen. its blue.
[20:37:07] <ggm> Dave doesnt feel blue
[20:37:10] <randy_g> Eric -- big providers in US, sure, but what about everyone/everywhere else?
[20:37:22] <ggm> ok. slide back.
[20:37:36] --- SAH has left
[20:37:44] <ggm> Dave I like the task. problem is that to paraphrase, process will get distorted, abused. wont be productive.
[20:37:51] <eric_allman> randy: who knows? but if the alternative is to find themselves seriously blacklisted, they might be willing to do something. Of course, that's a stick, not a carrot.
[20:37:54] <ggm> I thjink this session is an example that good discussion can happen.
[20:37:59] <yakovsh> randy: outside of the north america rDNS support is a problem but the RIRs are willing to support the change
[20:38:08] <ggm> clear also that this requires an enormous amount of careful work. overhead painful. can be done.
[20:38:11] <ogud> Reverse tree is badly maintained and there are issues with many ISP's refusing to put any information from customers in the map.
[20:38:28] <yakovsh> ogud: The ISPs are a problem which is my main concern
[20:38:29] <eric_allman> rDNS is badly maintained, but perhaps because there hasn't been a lot of incentive to do so.
[20:38:49] <ggm> task as described is useful upgrade to email even without spam. careful persuit of that goal in this forum is warranted. wouild be irresponsible of us to ignore existing outside proposals
[20:38:57] <yakovsh> ogud: its more of a business issue, ISPs need an incentive to give people access to rDNS
[20:39:02] <ggm> ?person?
[20:39:06] <yakovsh> ogud: a business incentive
[20:39:09] <ogud> Second there is a debate going on among DNS operators to not support reverse map for various reasons, there is a strong opposition to a document in DNSOP requiring Reverse map.
[20:39:23] <ggm> reinforce semantics based on model of how mail works. work previously failed because unwilling to do that.
[20:39:43] <ggm> TWO followon Q.
[20:39:44] <ggm> Ted
[20:39:54] <ggm> aim to have charter WG in 4-6 weeks. put on fast path
[20:40:12] <ggm> are you willing to participate in WG to the tune of 5 hrs week or more. please stand up.
[20:40:13] <ogud> Yakovsh: Yes we need to motivate ISP's to do lots fo good things at the same time.
[20:40:19] <eric_allman> ogud: what are the arguments for not supporting rDNS?
[20:40:27] <ggm> 10+ stand up.
[20:40:30] <yakovsh> ogud: that's the problem with any proposal so far
[20:40:45] <NFreed> I am willing to do this.
[20:40:51] <yakovsh> me too
[20:40:55] <sra> ogud: reverse tree seems wrong to me anyway, authority is by network topology, not organization
[20:40:55] --- Bob.Hinden has left: Disconnected
[20:41:04] <ggm> if we have experimental deployment [looks at edwin] is the pain horrendous? do we need a final answer or is interim ok?
[20:41:17] <ggm> Edwin to mike. to discuss deployment
[20:41:17] --- HannesTschofenig has left: Disconnected
[20:41:17] --- AWGY has left: Disconnected
[20:41:28] <ogud> Privacy, extra work, some people think reverse map as security mechanishm, and security geeks worry about that.
[20:41:32] <ggm> Edwin obvious not going to get this right. experiment is only way. cant speak for developers.
[20:41:32] <NFreed> experimentation is _essential_.
[20:41:49] <yakovsh> ogud: isn't the rDNS tree the logical place to store information about IP addresses?
[20:42:10] <ogud> Rob: I agree forward tree is where information whould go about policy.
[20:42:27] <ggm> Ted WG functional
[20:42:28] <randy_g> Ned -- Ted thanks you for actually standing up on camera
[20:42:28] --- ddp has left: Disconnected
[20:42:33] <ggm> thanks for love-fest [claps]
[20:42:34] <ggm> done here.
[20:42:38] --- galvinjamesm has left
[20:42:39] <ggm> Eric. can I address rDNS please?
[20:42:40] <Blake> NFreed: amen.
[20:42:44] --- agaton has left: Logged out
[20:42:51] --- alexeymelnikov has left
[20:42:52] <eric_allman> i can see privacy, i suppose. extra work can be ameliorated with tools. i don't understand security problems. but in any case adding SS doesn't expose privacy details -- it's all IP based.
[20:43:00] <ggm> please do not assume RIR do not want or are not willing to do rDNS delegation. my observations were only about the observed
[20:43:08] <ogud> Yakovsh: yes about the properties of an address. but not about the capabilities of the address (remember update control of reverse map is frequently outside an organization)
[20:43:17] <ggm> uptake. not meant to be about deprecation. I agree other communities do deprecate rDNS, do see problems, but RIR are not
[20:43:21] <eric_allman> ggm: of course
[20:43:21] <ggm> saying 'we cant do it'
[20:43:27] <yakovsh> ogud: how would u fit this into the forward tree?
[20:43:34] --- joew has left
[20:43:47] <ggm> I have to go eat now. I hope the jabber helped you guys
[20:43:50] <yakovsh> ggm: RIRs response to me personally has been that they are keeping rDNS
[20:43:56] <yakovsh> ggm: thanks!
[20:43:56] <eric_allman> sorry, RIR?
[20:44:02] --- sra has left: Disconnected
[20:44:07] <yakovsh> regional registries that give out IPs
[20:44:08] <ggm> Regional Internet Registires. the /8 delegeee for the reverse trees
[20:44:09] <ogud> GGM and andyN thanks a lot for great log.
[20:44:11] --- warlord has left
[20:44:13] <eric_allman> thx
[20:44:14] --- xag has left
[20:44:19] <yakovsh> ARIN/ for ex
[20:44:29] <eric_allman> jabber rocks
[20:44:55] --- ggm has left
[20:45:28] --- randy_g has left
[20:45:33] --- paf has left
[20:45:34] <yakovsh> i didn;'t catch the final decision, is there going to be a wg?
[20:46:18] <ogud> Yakovsh: aol.com would list all severs that can speak for aol.com. so when mailer sees a the appropriate name field it checks.
[20:46:19] --- claudioallocchio has left: Disconnected
[20:46:36] <yakovsh> ogud: how would I know at SMTP connect time which domain is this IP for?
[20:47:42] <eric_allman> yakovsh: further more, why would you care if you are doing SS?
[20:48:00] <yakovsh> eric: exactly
[20:48:07] <yakovsh> ogud: the point of SS is different
[20:48:11] --- resnick has left: Disconnected
[20:48:16] <yakovsh> ogud: it addresses the issue of hijacked computers
[20:48:29] <eric_allman> zombies are a big problem
[20:48:30] <yakovsh> relaying mail for any domain
[20:48:32] --- NFreed has left: Disconnected
[20:48:45] <eric_allman> enough to make computational puzzles extremely problematic
[20:48:51] <ogud> yakovsh: you can in theory check the peername, but to check policy you need to parse some/all of the mail message header before sending reject
[20:48:57] --- hta has left: Disconnected
[20:49:09] <eric_allman> i saw an estimate that the sum of the zombied machines today exceeds that of the top three supercomputers in the world combined.
[20:49:28] <yakovsh> ogud: with SS what they want to do is reject at the connect time, with a 4xx or 5xx response before even HELO
[20:49:34] --- smb has left: Disconnected
[20:50:12] --- moc has left: Disconnected
[20:50:32] --- mrose has left
[20:50:36] <yakovsh> ogud: it can possibly be used for other things like indicating other protocols, for example forbidding an IP to send out web packets if it is an SMTP host,
[20:50:59] <ogud> SS addresses the hijacked computers when the operator of the reverse map is telling the truth and customers that run mail servers (like me) can have the reverse map reflect that.
[20:51:13] <yakovsh> ogud: yes
[20:51:17] --- marushin has left: Replaced by new connection.
[20:51:29] <yakovsh> ogud: big isps would use it like DUL lists
[20:51:55] <yakovsh> ogud: small isps are a problem
[20:52:29] <yakovsh> something to talk about in the future
[20:52:46] <ogud> SS is not complete solution it may help stem the current spam problem with hijacked machines but it does not address lying about where email is from.
[20:53:01] --- Glenn Parsons has left: Disconnected
[20:53:06] <yakovsh> ogud: correct it only addresses the hijacked machines issue
[20:53:15] <yakovsh> a subset of the entire problem
[20:53:29] --- jon has left: Disconnected
[20:54:24] <eric_allman> SS is one of those approaches that doesn't stop spammers. but it sure does give them heartburn. and i love that idea.
[20:54:38] <yakovsh> its basicallt like DUL
[20:55:03] <eric_allman> yep. a good idea, imho.
[20:55:28] <yakovsh> ogud: i am sure the dns geeks will rip through the different aspects of it, we definatly need more discussions on this
[20:55:59] <ogud> we are in a war of attrition with them so anything that makes their life more difficult is a good thing but we need to look out for innocent victims
[20:56:50] <eric_allman> i think that SS, although not perfect, hurts them with minimal collateral damage. if it had c damage i would say it isn't worth it.
[20:58:04] <yakovsh> did the ending discussion of the WG include MTA MARK in its scope?
[20:58:08] <yakovsh> and SS?
[20:58:23] <eric_allman> i don't think i've ever looked at MTA MARK. is there a good ref?
[20:58:30] <yakovsh> one sec
[20:59:00] <ogud> Meta question (speaking as a DNS geek) Do we want a good solution in 2 years or few small steps to get there ? if we go for the small steps we may never get to the good solution.
[20:59:05] <yakovsh> http://www.ietf.org/internet-drafts/draft-stumpf-dns-mtamark-01.txt
[20:59:15] <yakovsh> eric :johns's SS is a version of it
[20:59:58] <eric_allman> geez, now how could i have missed that one? thanks.
[21:00:14] <eric_allman> ogud: great question.
[21:00:14] --- dcrocker has left: Disconnected
[21:00:17] <yakovsh> ogud: r u referring to the entire spam issue or only hijacked machines?
[21:00:26] <eric_allman> if we wait two years we're probably already dead.
[21:00:33] <eric_allman> but if we don't do it right, we're dead anyway.
[21:00:40] --- marushin has joined
[21:02:45] <ogud> you underestimate the resiliency of humans :-) Maybe we need to make it more profitable for criminal gangs to kill spammers than spam :-))
[21:02:59] <yakovsh> except the criminal gangs are sending it
[21:03:10] <yakovsh> the problem is that this may be a never ending war
[21:03:16] <eric_allman> hmmmm..... yakovsh, haven't you ever heard of gang wars?
[21:03:36] <yakovsh> eric: i like the idea actuall :)
[21:04:11] <yakovsh> if all of us get only one spam every day that might become more manageable
[21:04:13] <eric_allman> well, i have my doubts. one of the ways the nazis got into power was in creating crisis, and they did use gangs to do that. be careful of what you wish for.
[21:04:23] <eric_allman> one spam a day. bliss.......
[21:04:27] <yakovsh> eric: either way u can't win :)
[21:04:40] <yakovsh> the one spam/day thing is a quote from dave's document
[21:04:42] <eric_allman> maybe not. but i still intend to win.
[21:05:09] <eric_allman> i think we have ways of making it computationally exceedingly difficult for spammers to do their nasty deed.
[21:05:16] <yakovsh> we cannot end it totally but we can shoot for 1-5 spams a day
[21:05:17] --- motonori has left: Disconnected
[21:05:24] <yakovsh> eric: except they will steal ur pc to do it
[21:05:37] <eric_allman> the problems are (a) we have to break things, so choose carefully, and (b) we have to convince enough people to buy in.
[21:05:47] <yakovsh> that's the problem here, in the real world post offices do not get hijacked and neither do phones or faxes
[21:05:56] <eric_allman> zombies are a really really bad problem. they break a lot of the interesting approaches.
[21:06:08] <yakovsh> e-postage for example
[21:06:15] <eric_allman> we could outlaw all msft systems on the internet?
[21:06:29] <yakovsh> this is a public log :)
[21:06:36] <eric_allman> ah, yes, i forget.
[21:06:59] --- mengwong has left: Disconnected
[21:07:27] <yakovsh> I agree with both points above: we must tread carefully before changing things, and we need people to be convinced
[21:07:28] <ogud> we need to take this offline before Eric and I violate any more articles in the Patriot act :-)
[21:07:30] <eric_allman> but seriously, spam is becoming a serious security problem. not because spam itself threatens security, but because spammers are increasingly using cracker methods to send the mail.
[21:07:45] <yakovsh> yep
[21:07:56] <eric_allman> ogud, are you a u.s. type? or am i the main one at risk here?
[21:08:11] <yakovsh> we need to break the overall problem down and see which pieces of the puzzle can be addressed
[21:08:22] <ogud> US PR, right now in MD (just outside DC)
[21:08:37] <eric_allman> ah, close to the action. you better watch what you say.
[21:08:53] <eric_allman> berkeley is a different jurisdiction. at least we seem to think so.
[21:08:58] <yakovsh> ft mead is near dc
[21:09:04] <eric_allman> very close
[21:09:30] <ogud> 15 mintues from here (driving),
[21:09:37] --- yakovsh has left: Disconnected
[21:09:46] <eric_allman> watch your back.
[21:09:58] --- yakovsh has joined
[21:10:42] <ogud> Spam makes life difficult for them because it drives up traffic, so my guess they would be happy to see spam disapear.
[21:10:45] --- cnewman has left: Disconnected
[21:10:47] <eric_allman> at this point i'm willing to go ahead and break some things. i say that as one of the most adament people in favor of not breaking things. people hate it when their email breaks. but at this point i think they hate spam more.
[21:11:30] <yakovsh> i think most people agree that we need a change, the question is what kind
[21:11:46] <yakovsh> the puzzle has many pieces
[21:12:01] <eric_allman> exactly. what kind indeed.
[21:13:04] <eric_allman> i've just been told that if i want dinner, i should get it now. so i suspect this needs to go offline. but i'll stay in the channel and may be able to join you later.
[21:13:26] <yakovsh> well lets stay in touch, i gotta run
[21:13:39] <eric_allman> sounds great -- later.....
[21:13:43] <yakovsh> nice discussion I really would have liked to be in korea :(
[21:13:56] <eric_allman> i'm not sure i woudl have liked that
[21:13:56] <yakovsh> hopefully san diego I will make it :)
[21:14:02] <eric_allman> that's a deal.
[21:14:16] <yakovsh> good night or morning to all of u
[21:14:17] --- yakovsh has left
[21:14:23] --- Brian Ross has left
[21:14:27] <ogud> Good night
[21:14:45] --- dkclinger has left
[21:15:01] <eric_allman> 'nigght
[21:15:24] --- ogud has left
[21:15:44] --- marushin has left: Disconnected.
[21:17:10] --- tonyhansen has left: Disconnected
[21:30:36] --- stastny56 has left: Disconnected
[21:30:49] --- stastny56 has joined
[21:30:55] --- pgmillard has left
[21:37:51] --- stastny56 has left: Replaced by new connection
[21:37:53] --- stastny56 has joined
[21:37:53] --- stastny56 has left
[21:44:39] --- HannesTschofenig has joined
[21:48:50] --- HannesTschofenig has left
[21:51:11] --- yakovsh has joined
[21:51:11] --- sommerfeld has left: Lost connection
[21:51:18] --- yakovsh has left
[21:57:46] --- cabo-tzi-org has joined
[21:58:27] --- jakob has joined
[21:59:38] --- jakob has left
[21:59:53] --- cabo-tzi-org has left: Disconnected
[22:05:29] --- hta has joined
[22:08:13] --- hta has left
[22:10:12] --- resnick has joined
[22:15:56] --- tonyhansen has joined
[22:16:34] --- smb has joined
[22:16:39] --- smb has left
[22:18:38] --- Blake has left
[22:31:21] --- marushin has joined
[22:33:26] --- tonyhansen has left
[22:38:37] --- motonori has joined
[22:39:03] --- eric_allman has left
[22:39:39] --- motonori has left
[22:45:28] --- sruffino has joined
[22:46:11] --- sruffino has left
[23:01:13] --- sommerfeld has joined
[23:02:46] --- resnick has left
[23:59:25] --- AWGY has joined
[23:59:35] --- AWGY has left