[19:07:58] jume joins the room [19:09:15] ...Paul joins the room [19:09:34] aflury joins the room [19:17:18] aflury leaves the room [19:24:21] aflury joins the room [19:49:47] sm joins the room [19:55:14] Barry Leiba joins the room [19:57:00] <...Paul> Ah, Dizz Knee Land. [19:59:35] happiest place on earth. [20:01:25] jume leaves the room [20:02:24] <...Paul> Yes, audio is working. :) [20:02:30] Here too. [20:02:48] =JeffH joins the room [20:02:53] resnick joins the room [20:03:01] resnick leaves the room [20:03:02] tonyhansen joins the room [20:03:20] fenton joins the room [20:03:34] JD Falk presenting on history of MARF [20:03:40] cnewman joins the room [20:03:56] <...Paul> http://tools.ietf.org/agenda/77/slides/marf-0.pdf [20:04:08] spam buttons in MUAs [20:04:26] Mailbox provider uses feedback to improve their filtering [20:04:40] But mailbox filters want to share their findings [20:04:51] resnick joins the room [20:05:41] Feedback loops start at mailbox providers and 3rd parties [20:05:46] mckeon joins the room [20:05:54] ...and end at hosting companies, ESPs, etc. [20:06:54] Slide on approval process (out of scope) [20:07:40] Typically feedback was like a message forward (headers/body encap into a new msg) [20:08:12] Spam buttons appeared in 1998, abuse reporting spinoff from MAAWG in 2005 [20:08:30] feedback-report-00 March 2005 [20:09:13] Open discussions followed, then feedback-report-02 in May 2007 [20:09:57] feedback-report-04 added DKIM failure reports, later removed [20:10:23] draft-ietf-marf-base Jan 2010 removed all reports not currently in use [20:10:32] Things can be added as extensions [20:10:50] 12 big ISPs are the big ARG fenerators [20:11:39] Outliers: ARF from MUA, ARG to abuse@ without arrangement, etc. [20:12:05] New MIME type: message/feedback-report [20:12:30] Where these are to be sent is outside scope [20:12:55] Should be human, machine readable, entire msg enclosed, extensible [20:13:08] Also have to deal with installed base [20:13:27] Not intended to be human-generated [20:13:36] Redaction probably required [20:14:27] Message is muiltipart/report at top level [20:14:39] inside text/plain for human readable part [20:15:30] then message/feedback (looks like a message header, but isn't). Not always accurate. [20:17:40] <...Paul> The unique Message-ID ? [20:17:51] <...Paul> Ah. [20:18:09] Q about envelope-id: Ned Freed: an extension to MAIL FROM. [20:18:30] (Ned's comment was the answer, not the Q) [20:19:03] End JD's history talk. [20:19:27] <...Paul> I believe the next slide deck is http://tools.ietf.org/agenda/77/slides/marf-1.pdf [20:19:40] Murray: Outstanding issues in marf-base draft [20:19:48] yep [20:19:59] Just reviewing perceived consensus. [20:20:39] Redaction: Required by generator's counsel [20:21:05] Consensus apprears not to have a redaction flag [20:21:47] Message-Id can often be used to identify the message anyway [20:22:23] Reported-Domain: semantics not well defined [20:22:43] Same as Reported-URI: ? [20:23:07] Consensus appears not to make any changes; value of field is advisory [20:23:45] WGLC begins April 2, to last two weeks. [20:24:45] Barry reviewing organization of document to make sure that payload can be used elsewhere [20:25:26] Next: Parallel activity at GSMA/OMA (Murray) [20:25:33] Mobile provider alliances [20:25:41] jdfalk joins the room [20:25:50] http://tools.ietf.org/agenda/77/slides/marf-2.pdf [20:26:12] 404 [20:26:42] Mobile spam growing fast, SMS lagging by 5-10 years but on same trajectory [20:27:04] daniel.keen joins the room [20:27:11] <...Paul> AFAIK, there are no other materials for this session. [20:27:57] Mpbile carriers trying to figure out how to engage subscribers to identify spam [20:28:40] French test: Forward spam to a short code, then send source info [20:28:49] slides at http://disgruntled.net/~jdfalk/marf-2.pdf (not permanent) [20:28:53] It disappeared from the site. Sorry. [20:29:11] Thanks JD [20:29:12] There ya go. [20:29:22] <...Paul> Thanks JD. [20:29:31] 495000 reports identified as spam, 460 numbers shut down and lotsa warnings [20:30:38] Igor: asking what a "Completed" report was (A: two-phase process complete) [20:31:03] Murray's company is working with GSMA, Barry points out it's in the WG's charter too [20:31:24] Seasonal attacks identified [20:31:39] Spammers moved to smaller operators not participating in the test. [20:31:49] Law enforcement engaged too [20:32:15] GSMA planning a pilot on global scale with another short code [20:32:53] "report spam" button on handsets: OMA looking at this. [20:33:35] Inter-carrier reporting, data sharing with bulk senders [20:34:14] OMA SpamRep proposal [20:34:57] One option is for user select ARG-style Feedback-Report type [20:35:41] meaning end user classifies spam, fraud, etc [20:35:48] when reporting [20:35:52] User can select what type of abuse is reported [20:36:58] End Murray's mobile talk === [20:37:27] Next: Topics for a BCP Draft (Murray leading discussion, no slides) [20:39:06] Barry as IETF liaison to MAAWG: Checking to see what documents MAAWG might want to bring to IETF. [20:39:40] JD Falk: BCP from MAAWG is not in IETF style, needs some work [20:40:44] Probably ready for discussion at Maastricht [20:41:21] Pat Cain: What is value of IETF also publishing a BCP that is also a MAAWG BCP? [20:41:54] Barry: More exposure if informational. IETF BCP has additional "standards" status. [20:43:06] spamfighter joins the room [20:43:20] ? from Huawei: Is it possible to put something in BCP to tell implementer how (where?) to report? [20:43:54] Barry: Might be able to work with OMA to define payload [20:44:33] Spamrep people in OMA are defining new reporting mechanism [20:45:17] Murray: Report spam button on handset will go to your own provider. [20:46:01] Hannes Tschofenig: Can OMA and IETF work together on transport mechanisms? [20:46:35] Barry: OMA specifically wants a way to report from handset, even if msg not entirely reported from handset [20:47:53] HT: Transport mechanism would be nice to define [20:49:31] JF: Scope SMS or email or both? [20:49:39] Barry: Both [20:50:33] Murray: Different reporting mechanisms might be needed for SMS vs. email [20:50:58] two-phase thing used in France is because there isn't a standard for the report [20:51:11] aflury leaves the room [20:51:18] aflury joins the room [20:52:12] Murray will keep the WG apprised with what GSMA/OMA are doing. [20:52:29] Bring up suggestiond for what BCP should cover on the mailing list. [20:52:51] Next: DKIM Extensions draft (Murray; no slides) [20:53:25] Bunch of proposed reporting extensions exist [20:53:32] dkim-reporting-06 [20:53:43] http://tools.ietf.org/html/draft-kucherawy-dkim-reporting-06 [20:54:09] Adds some middle header fields: verification failure vs. policy failure. Some forensics as to why. [20:54:34] Also touched DKIM spec, adding reporting address to key records [20:54:49] Added reporting address to ADSP records too [20:55:09] Could have a different reporting address for each selector [20:55:32] Interoperability between Murray's two implementations (!!) [20:56:13] MAAWG has a WG-equivalent devoted to brand protection [20:56:57] jim fenton asks: will it be a working group draft? [20:57:12] msk replies: it's our third charter item [20:57:23] barry adds: murray will bring it to the DKIM WG [20:57:41] Any other business? [20:58:35] ?/Huawei: More extensions? A: Neeed to recharter for that. [20:58:50] Igor: How to liase with OMA/GSMA? [20:59:11] Barry: Dean WIllis is IETF OMA liaison [20:59:24] No GSMA liaison currently (probably not needed) [20:59:34] JS: MAAWG has connections there too [20:59:53] (JD, not JS) [21:00:28] =JeffH leaves the room [21:00:35] Adjourned! [21:00:53] "The bar is downstairs". Nice. [21:01:00] spamfighter leaves the room [21:01:36] Barry Leiba leaves the room [21:01:46] aflury leaves the room [21:01:50] daniel.keen leaves the room [21:01:51] sm leaves the room [21:02:44] mckeon leaves the room [21:04:38] fenton leaves the room: Disconnected. [21:05:30] aflury joins the room [21:05:34] resnick leaves the room [21:14:26] jdfalk leaves the room [21:18:01] ...Paul leaves the room [21:21:57] aflury leaves the room [21:24:31] cnewman leaves the room [21:50:15] fenton joins the room [22:02:07] fenton leaves the room: Disconnected. [22:11:08] fenton joins the room [22:15:43] fenton leaves the room: Replaced by new connection. [22:15:43] fenton joins the room [23:59:20] fenton leaves the room: Replaced by new connection. [23:59:20] fenton joins the room