http://blog.gmane.org/gmane.ietf.asrg hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.asrg/15545 <pre> CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) 2012 http://irtf.org/anrp *** Submit nominations for the 2012 award period of the *** *** Applied Networking Research Prize until May 13, 2012! *** The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recently published results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). The goal of the Applied Networking Research Prize is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: * cash prize of $500 (USD) * travel grant to attend a week-long IETF meeting (airfare, hotel, registration, stipend) * invited talk at the IRTF Open Meeting * recognition at the IETF plenary * invitation to related social activities * potential for additional travel grants to future IETF meetings, based on community feedback HOW TO NOMINATE Only a single person can be nominated for the award. The basis of the nomination is a peer-reviewed, recently-published, original journal, conference or workshop paper they authored. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one’s own paper) and third-party nominations (nominating someone else’s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF research and experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how a presentation of these research results would foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend at least one of the year’s IETF meetings in person and in its entirety. Nominations must include: * the name and email address of the nominee * a bibliographic reference to the published nominated paper * a PDF copy of the nominated paper * a statement that describes how the nominated paper fulfills the goals of the award * a statement about which of the year’s IETF meetings the nominee would be available to attend in person and in its entirety * a brief biography or CV of the nominee * optionally, any other supporting information (link to nominee’s web site, etc.) Nominations are submitted via the submission site at http://irtf.org/anrp/2012/. In exceptional cases, nominations may also be submitted by email to anrp&lt; at &gt;irtf.org. SELECTION PROCESS A small selection committee comprised of individuals knowledgeable about the IRTF, IETF and the broader networking research community will evaluate the submissions against these selection criteria. IMPORTANT DATES Applications close: May 13, 2012 (hard) Notifications: June 1, 2012 SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF). HELP PUBLICIZE THE ANRP If you would like to help publicize the ANRP within your organization, you are welcome to print and use the flyer at http://irtf.org/anrp-2012-flyer.pdf _______________________________________________ Asrg mailing list Asrg&lt; at &gt;irtf.org http://www.irtf.org/mailman/listinfo/asrg </pre> Eggert, Lars 2012-04-10T09:39:25 http://comments.gmane.org/gmane.ietf.asrg/15544 <pre>I don't recall IPR issues ever coming up in the ASRG, but in case they do, here is our clarified IPR policy. Please note the parts about what you are required to disclose. R's, John ---------- Forwarded message ---------- Date: Thu, 16 Feb 2012 18:36:35 From: "Eggert, Lars" &lt;lars&lt; at &gt;netapp.com&gt; Reply-To: "irtf-discuss&lt; at &gt;irtf.org" &lt;irtf-discuss&lt; at &gt;irtf.org&gt; Subject: [irsg] IRTF IPR Disclosure Rules Until now, the IRTF didn't have a clearly formulated statement of how IPR is handled by the organization. For the last year, the IRSG has been discussing this topic with the IETF's legal counsel and other community members with a deep understanding of the issues. The result of this discussion is a short statement describing the IRTF's IPR disclosure rules, which you can find below as well as online at http://irtf.org/ipr. The short version is: the IRTF follows the IETF's IPR disclosure rules. Because researchers participating in the IRTF may not be very familiar with the IETF's rules, the IRTF IPR disclosure rules describe what is required of the individual participant in the most common cases. Just as the IETF, the IRTF expects participants to be familiar with these rules and follow them when they make contributions. Please email any comments or questions to irtf-discuss&lt; at &gt;irtf.org. Lars Eggert IRTF Chair --- IRTF IPR Disclosure Rules The IRTF follows the IETF IPR disclosure rules. This is a summary of these rules as they relate to IRTF research group discussions, mailing lists and Internet Drafts: - If you include your own or your employer's IPR in a contribution to an IRTF research group, then you must file an IPR disclosure with the IETF. - If you recognize your own or your employer's IPR in someone else's contribution and you are participating in the discussions in the research group relating to that contribution, then you must file an IPR disclosure with the IETF. Even if you are not participating in the discussion, the IRTF still requests that you file an IPR disclosure with the IETF. - Finally, the IRTF requests that you file an IPR disclosure with the IETF if you recognize IPR owned by others in any IRTF contribution. You may file an IPR disclosure here: http://www.ietf.org/ipr/file-disclosure See RFC 3979 (BCP 79) for definitions of "IPR" and "contribution" and for the detailed rules (substituting "IRTF" for "IETF"). </pre> John R. Levine 2012-02-17T00:36:32 http://comments.gmane.org/gmane.ietf.asrg/15543 <pre>See below. Submissions deadline is in just over a month from now. Martijn. Virus Bulletin is seeking submissions from those wishing to present papers at VB2012, the 22nd Virus Bulletin International Conference, which will take place 26-28 September 2012 at the Dallas Fairmont hotel, Dallas, TX, USA. The conference will include a programme of 30-minute presentations running in two concurrent streams: Technical and Corporate. Submissions are invited on all subjects relevant to anti-malware and anti-spam. In particular, VB welcomes the submission of papers that will provide delegates with ideas, advice and/or practical techniques, and encourages presentations that include practical demonstrations of techniques or new technologies. Abstracts should be submitted via the online abstract submission system at http://www.virusbtn.com/conference/abstracts/ and must be submitted no later than FRIDAY 9th MARCH 2012. Further details of the paper submission and selection process, including a list of suggested topics for papers, can be found at http://www.virusbtn.com/conference/vb2012/call/. Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. </pre> Martijn Grooten 2012-02-08T15:30:32 http://comments.gmane.org/gmane.ietf.asrg/15541 <pre>It's session scheduling time again. I'm not going to ask for a session for ASRG, since we don't have anything going on to merit one, but if people will be there we could arrange to all have lunch one day. Regards, John Levine, johnl&lt; at &gt;iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly </pre> John R. Levine 2012-01-30T19:44:12 http://comments.gmane.org/gmane.ietf.asrg/15510 <pre>It was nice to see the RFC being published. Good work. Then I came across this: http://blog.vamsoft.com/2012/01/24/ub-black-uribl-com-url-blacklist-started-to-block-everything/ (Vamsoft ORF is a spam-filter.) Basically uribl.com was returning 127.0.0.1 to _all_ queries from nameservers that are sending high volumes (presumably without paying for it) as some kind of punishment. http://uribl.com/ confirms that. Now, as Vamsoft mentions, it is not a good idea to use third-party nameservers on a server you're making DNS requests from. (Although, unlike openDNS, Google's nameservers do return NXDOMAIN when they can't resolve a domain.) Moreover, it does seem Google's nameservers are now getting REFUSED as a response to any uribl.com request. I was just wondering whether the RFC says anything about this kind of behaviour ('listing' everything as a punishment). To my reading it doesn't. Martijn. Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. </pre> Martijn Grooten 2012-01-24T15:07:50 http://comments.gmane.org/gmane.ietf.asrg/15508 <pre>FYI _______________________________________________ Asrg mailing list Asrg&lt; at &gt;irtf.org http://www.irtf.org/mailman/listinfo/asrg </pre> Murray S. Kucherawy 2012-01-19T03:38:21 http://comments.gmane.org/gmane.ietf.asrg/15504 <pre>This spamassassin bug comment provides some information on what happens when various methods of blocking abusive DNS queries are attempted. The tests were conducted on dnswl.org, a public email whitelist enabled by default in spamassassin, and presumably other things. There seems to be a surprising lack, in RFCs and BCPs, of statements that clients and forwarding DNS servers should stop querying if they receive an NXDOMAIN, REFUSED, or an answer with the TLD of "invalid", which seem likely to help if they were widely implemented. It also seems like it would be good to define best practices for handling this situation, quite possibly based on the information below. SpamAssassin is currently asking DNS black/white list providers to indicate the client is being blocked via a specified returned IP value for all queries, in the case of DNSWL, 127.0.0.255. There has been some debate on what would be an ideal value. This is not in line with the blacklist BCP's suggestion to check the values of 127.0.0.1 and 127.0.0.2, I guess because the SA devs feel it's easier to implement. Some related discussion was here: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6724 (My involvement - I'm not a SA dev, I've been participating on the dev mailing list for a number of months. I've been helping DNSWL on and off for about 5 years.) ----- Forwarded message from bugzilla-daemon&lt; at &gt;bugzilla.spamassassin.org ----- Date: Thu, 22 Dec 2011 10:32:43 +0000 From: bugzilla-daemon&lt; at &gt;bugzilla.spamassassin.org To: Darxus&lt; at &gt;ChaosReigns.com Subject: [Bug 6728] DNSBLs need a way to turn off queries based on BLOCKED rules triggering https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6728 --- Comment #13 from Matthias Leisi &lt;matthias&lt; at &gt;leisi.net&gt; 2011-12-22 10:32:43 UTC --- I did some additional tests on how best to block abusive query sources. "Best" is defined as three goals: 1) Reduce the overall traffic on parent (dnswl.org) and data (list.dnswl.org) zone 2) Avoid or minimize collateral damage on root and gTLD servers 3) Make it easy for operators of abusive query sources to find out what is happening We have built the mechanism to redirect defined IPs to a special view of the dnswl.org zone as part of bug 6724 (using BIND views). I wanted to do actual tests to base at least the decision on the first goal on hard facts. We tested three combinations: A. Explicit nameserver in "nowhere land" | list.dnswl.org. 21600 IN NS blockedview.dnswl.org. | blockedview.dnswl.org. 21600 IN A 127.0.0.255 B. Explicit nameserver for data zone in .invalid | list.dnswl.org. 21600 IN NS _ | you.are.blocked.from.using.dnswl.org.thorugh.public.nameservers.invalid. C. No zone apex (no NS records for list.dnswl.org) In all cases, we returned 127.0.0.255 for *.list.dnswl.org in this view. Also in all cases, we return 127.0.0.255 for the nameservers of the original data zone (a through l.ns.dnswl.org), which affected clients should not actually ever have seen. Also, if an affected client would ask a through l.ns.dnswl.org they would always receive 127.0.0.255 as an answer. A. and B. showed no measurable difference in traffic levels on the parent and the data zone. With C., the traffic on the parent zone nameservers grew by about 30%; traffic on the data zone did only shrink by about half the amount that was added on the parent zone. This rules out C. as a viable option and makes the choice depend only on goals 2 and 3 above: minimize collateral damage (on root servers) and maximize identifiability for operators. It can be expected that some resolvers will ask the roots for invalid., and it can also be expected that not all resolvers will do proper negative caching for B. This leaves A. as the most efficient option with the least collateral damage (except for the timeouts on the affected DNS resolver / forwarder when trying to reach 127.0.0.255). It should be remembered that this only applies to query sources who generate excessive amounts of traffic over some period of time, and who do not react to reasonable attempts at communication. The first line of defense would be to return 127.0.0.255 (or other BLOCKED triggering value, to be defined) from the regular data zone nameservers, as discussed in this bug. </pre> darxus< at >chaosreigns.com 2011-12-22T15:12:08 http://comments.gmane.org/gmane.ietf.asrg/15502 <pre>http://tompreston.deviantart.com/art/Welcome-to-the-Internet-273281497 </pre> darxus< at >chaosreigns.com 2011-12-11T19:24:32 http://comments.gmane.org/gmane.ietf.asrg/15465 <pre>Hi, I dont know if this is exactly the right place for discussing my idea but I want to do a little bit of brainstorming with experts. I come with a "crazy" thing but the logic is not so bad ! Please dont tell me "you are crazy" ! .....at least at first time! :p Users believe in what they read in the header from of the mail ! Users don't also know about the existence and differences between envelope and header From. And they also don't know that those addresses can be forged. They blindly believe ! My idea is to invert the logic of DNSBLs. That is, instead of asking third parties about spam/phishing why not asking the domain involved in envelope and header itself about non-spam ? Domains should have to publish in their DNSs the message-id (among any other thing) through a TXT or A record of any legit mail sent by them. The TTLs of those records can be adjusted to compensate for queued mails, etc. When you receive a mail from A and "aparently" from B you can query A and B DNSs looking for the message-id the mail has. If you have a nxdomain or whatever error from them you can score the mail as phishing! ..on the other hand if you have a hit from at least one of them you can be confident that this is the real domain that sends that mail or it sends it on behalf the real address! The check against both is to account for multi identities in what one mailer sends in behalf of another (like gmail). You can also check against any internal hop in the Received: chain in order to avoid breaks in the trust chain by means of plain forwarding (as happens in SPF without SRS). I know this requires all to implement it in order to work (also like SPF and DKIM). Time to think ! Cheers ! </pre> Christian Grunfeld 2011-11-17T18:30:07 http://comments.gmane.org/gmane.ietf.asrg/15464 <pre>The anti-phishing working group (APWG) published a report on phishing in the first half of 2011: http://www.apwg.org/reports/APWG_GlobalPhishingSurvey_1H2011.pdf Lots of statistics on phishing, such as a significant rise in attacks compared to the previous six months, which was largely due to attacks on Chinese organisations and their customers. One thing I found interesting, and which prompted me to post about it here, is that only 2% of the phishing domains contained the brand name of a variation thereof (e.g. paypaI dot com) and they've only seen two examples of phishing attacks using IDNs and homographs (e.g. fácebook dot com) in since 2007. Also, only 18% of the domains used (down from 28%) were registered by the phishers themselves; the other domains were hacked or compromised. It suggests that phishers do care about the reputation of domains as used by email/web filters (does the domain have a history of legitimate content?), but little about reputation among users (does the domain look like the one I expect for this site?). I'm not sure about their definition of 'phishing'. This could have some influence on their statistics. Martijn. Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. </pre> Martijn Grooten 2011-11-16T15:18:28 http://comments.gmane.org/gmane.ietf.asrg/15460 <pre>---------- Forwarded message ---------- Date: Mon, 14 Nov 2011 16:16:23 +0800 From: Joel M Snyder &lt;Joel.Snyder&lt; at &gt;Opus1.COM&gt; Subject: anti-spam updates for ISOC from the ASRG I am working with Sally Wentworth at ISOC on an update to ISOC's anti-spam web pages. I wonder if the ASRG folks would be willing to take a look at what Sally sent out and offer up any comments or suggestions? Sally's motivation is that some ITU Member States are proposing to define spam and include provisions related to spam in the ITR treaty at the WCIT. In preparation for this, she thought it was time to update ISOC's anti-spam websites to highlight what the technical, policy and commercial communities are doing to combat spam and unwanted traffic (without the "assistance" of a treaty). Here are the questions I have. I don't know whether you're comfortable with just passing them along (which would be fine with me) or whether you think I should try and connect more directly or whether you think I should just go away and be quiet? We are looking for short statements and pointers to work in the following areas: - general description of the spam problem, including definitions, statistics, academic research in the area, and other general overview discussion. The less commercial the better. - general discussion of technical solutions to spam, such as CPE filtering, cloud filtering, reputation systems, Any overview descriptions, comparisons, research, surveys. Again, nothing product-comparative. Remember, short statements and/or pointers to other people's work. - pointers to product lists, if they are current and generally comprehensive. - ISOC activities (including IETF, etc.). A single statement and a pointer to an RFC, paper, document, working group, etc. - architecture of a policy-based anti-spam solution; components of the solution and how they fit together. Short statements, or pointers to discussions. - current players (other than ISOC) in the policy-based anti-spam front. This would include governmental and NGO policy groups helping to craft policy, industry groups, etc. Anyone, in short, who is hoping to help write or influence legislation, regulation, or policy regarding spam. - current anti-spam policies/legislation/regulation AND a statement of evaluation. (e.g,, pointer to CAN-SPAM and an admission that it doesn't seem to have done anything) Thanks for any help, guidance, or advice you might have! jms </pre> John R. Levine 2011-11-14T09:40:49 http://comments.gmane.org/gmane.ietf.asrg/15429 <pre>Hi, RFC Editor, please publish draft-irtf-asrg-bcp-blacklists-10 as an Informational IRTF RFC. The document has been approved for publication by the IRSG and also received RFC5742 review by the IESG. See http://trac.tools.ietf.org/group/irtf/trac/ticket/47 for details and history. Specifically, see this comment for edits to the document that you should perform: http://wiki.tools.ietf.org/group/irtf/trac/ticket/47#comment:7 Please copy all correspondence to the document shepherd, John Levine (johnl&lt; at &gt;iecc.com). Thanks, Lars_______________________________________________ Asrg mailing list Asrg&lt; at &gt;irtf.org http://www.irtf.org/mailman/listinfo/asrg </pre> Lars Eggert 2011-10-24T06:32:28 http://comments.gmane.org/gmane.ietf.asrg/15402 <pre>After some chatter inside MAAWG and on the ietf-smtp mailing list, I've started an outline for a BCP on the practice of greylisting. The main purpose is to explain what it is, discuss the pros and cons of its variants, and give some recommendations for implementation and configuration for a few example installations and policies. The draft (which is currently only an outline) is here: https://datatracker.ietf.org/doc/draft-kucherawy-greylisting-bcp/ Comments welcome. -MSK _______________________________________________ Asrg mailing list Asrg&lt; at &gt;irtf.org http://www.irtf.org/mailman/listinfo/asrg </pre> Murray S. Kucherawy 2011-10-18T19:01:21 http://comments.gmane.org/gmane.ietf.asrg/15379 <pre>Hi, I'm wondering where I can find any information about discussed opt-out ideas? I only found these old ones in the archives: http://www.ietf.org/mail-archive/web/asrg/current/msg02082.html http://www.ietf.org/mail-archive/web/asrg/current/msg02167.html http://www.ietf.org/mail-archive/web/asrg/current/msg02252.html http://www.ietf.org/mail-archive/web/asrg/current/msg02280.html Has there been any more discussions regarding opt-out (which I must have missed), or is the opt-out track abandoned? Is there a subgroup I should join for further discussions regarding opt-out? Regards, /P </pre> Fredrik Pettai 2011-09-22T08:45:14 http://comments.gmane.org/gmane.ietf.asrg/15378 <pre>Hi, IESG secretary (BCC'ed), this is a request for the IESG to perform a RFC5742 review of the following draft from the ASRG, to be published as an RFC on the IRTF Stream: - draft-irtf-asrg-bcp-blacklists-10 (Informational RFC) The document has been approved for publication by the IRSG. See http://trac.tools.ietf.org/group/irtf/trac/ticket/47 for details on prior reviews. Please copy all correspondence to the document shepherd, John Levine (johnl&lt; at &gt;iecc.com). Thanks, Lars _______________________________________________ Asrg mailing list Asrg&lt; at &gt;irtf.org http://www.irtf.org/mailman/listinfo/asrg </pre> Lars Eggert 2011-09-20T06:17:26 http://comments.gmane.org/gmane.ietf.asrg/15375 <pre>These are the comments on the DNSBL BCP. I think they are minor enough that we can just ask the RFC editor to deal with them. Regards, John Levine, johnl&lt; at &gt;iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly ---------- Forwarded message ---------- Date: Mon, 25 Jul 2011 17:32:47 +0200 From: Olivier Festor &lt;Olivier.Festor&lt; at &gt;inria.fr&gt; To: Lars Eggert &lt;lars.eggert&lt; at &gt;nokia.com&gt;, "&lt;irsg&lt; at &gt;irtf.org&gt;" &lt;irsg&lt; at &gt;irtf.org&gt; Cc: Olivier Festor &lt;Olivier.Festor&lt; at &gt;loria.fr&gt; Subject: [irsg] Comments on draft-irtf-asrg-bcp-blacklists-09 Dear Lars Please find below my comments following the review of draft-irtf-asrg-bcp-blacklists-09. Overall the document is of good quality and contains useful information for DNSBL operators as well as users. References are accurate. I will also upload the comments on the tracking system as soon as I found out how to do it ;-) Best Regards /Olivier Festor Detailed comments : Introduction RHSBL : -&gt;give a description of what RHS means like it was done for WL in the DNSWL (WL = White List) 2.1.2 "Audit Trail SHOULD be maintained" -&gt; to be consistent with the other subsections, use capitals on words 2.1.3 3rd paragraph "This has resulted in some labeling such practises by the ....." -&gt; Alternative 1: "This has resulted in some labeling of such practises by the ....." -&gt; Alternative 2: Alternative 1: "This has resulted in labeling such practises by the ....." 2.2.2 3rd parapgrah The term "DDoS" has not been defined before in the document 2.2.5 3rd paragraph "Colloqially, " it smells bad"" While I personaly like the statement, I am wondering if it fits in a standard document. 3.3 What is the semantics of the proposed "test" entry in DNSBLs. What should be in the associated A record ? Is is recommended as a replacement of the 127.0.0.0/8 test approaches or as a complement ? 3.5 "Listing of Special and Reserved IP Addresses MUST be disclosed" - to be consistent with the other subsections, use capitals on words 3.6.1 "MUST NOT scan without provocation" - to be consistent with the other subsections, use capitals on words </pre> John R. Levine 2011-09-12T13:08:22 http://comments.gmane.org/gmane.ietf.asrg/15361 <pre>(Maybe my google-fu isn't up to par and this has been discussed previously - if so, my apologies) With PCs being owned and email accounts being owned, has anyone considered blacklisting individual email accounts? Within the past month, I've gotten an influx of spam from people who I have communicated with. Given the content, I doubt these people would be sending me random links to foreign websites designed to own my PC. Some of these senders are people who I haven't communicated with in years, but my email address is probably in their email box or address book. It's all been consumer-grade email (Comcast, AOL, Yahoo, etc.) from people for whom it would not be a stretch to imagine them getting owned. Considering that some of these providers don't seem to be interested in cleaning up their outbound mail, has anyone considered blacklisting email accounts like we do IPs/hostnames? I do this for my personal mail stream, and it scales - get a spam from an owned person I don't need email from, drop 'em in the local BL. But for this to be effective, there'd have to be some kind of DNSBL'ish thing to query. I do understand that there are an infinite amount of email addresses for freemail domains ;) So this wouldn't stop spammer-created accounts. But if Aunt Tilly has to change her email address (or go through some removal-from-blocklist stuff - possibly go through some education), that could have the necessary impact to change her behavior so she wouldn't get owned again. This could be use a strong password, don't run an insecure OS, don't use insecure wiifi, whatever is deemed good information to better their understanding of what they've done. Or am I giving people too much credit in hoping they'd change after they meet the clue by four? For some, the aversion to getting another email address might outlive the desire to be lackadaisical.. </pre> Jason W. 2011-08-30T22:08:40 http://comments.gmane.org/gmane.ietf.asrg/15353 <pre>URL shorteners (bit.ly, goo.gl, tinyurl.com etc.) have become popular in recent years for rather obvious reasons. They are being used by spammers for equally obvious reasons - both in email and on other platforms (e.g. Twitter). A filter that checks URLs/domains against a blacklist will either miss the bad domains hidden behind the shorteners or, if they blacklist the shortener, find itself blocking legitimate messages. Do Not Use (third-party) URL Shorteners is sound advice to those sending email, but it's not going to stop random users from copying shortened URLs from Twitter or Facebook and pasting them into emails and shortened URLs are unlikely to stop featuring on Twitter. Tell those providing shorteners to check URLs against blacklists is also a good idea - and probably necessary for them to stop ending up on blacklists themselves - but if a filter happens to prefer a different blacklist it doesn't help much. (I also don't know if checks are made every time someone clicks on the link or just when the shortened URL is generated.) So I was wondering if it would help if shorteners published the URLs in a DNS txt record. As the path of a shortened URL usually consists of lowercase, uppercase letters and numbers, the uppercase letters need to be encoded, e.g. by preceding them with an underscore. So for instance to look up the URL behind http://bit.ly/gkP0H would require a lookup of the TXT record for gk_p0_h._short.bit.ly Now I don't know if this is something that would actually help those developing spam-/content-filters. Doing a HTTP lookup to determine the URL isn't exactly rocket science - though intuitively, it seems more 'natural' to use DNS, especially if that's what is used for the URL blacklist lookup. Nor do I know if this would be something that would interest those providing shortening services. As it would allow browsers to avoid making a HTTP request to their services, it would mean they would stop having reliable click through statistics which, I guess, are a source of revenue to them. But I thought I'd post it here anyway as perhaps it is useful. In which case I'm sure it can be improved upon. Martijn. Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. </pre> Martijn Grooten 2011-08-22T16:35:05 http://comments.gmane.org/gmane.ietf.asrg/15352 <pre>See below. Martijn. You may already have seen this elsewhere - in which case please accept my apologies for bombarding you with the same information - but I would like to bring to your attention the call for last-minute papers for VB2011, the 21st Virus Bulletin International anti-malware and anti-spam conference. The conference will include a programme of 30-minute presentations running in two concurrent streams: Technical and Corporate, the running order for which has already been finalized and can be seen at http://www.virusbtn.com/conference/vb2011/programme/. In addition to the scheduled presentations, a portion of the technical stream has been set aside for last-minute presentations. VB is now seeking submissions for these last-minute presentations. The last-minute presentations will be selected by a committee who will be looking for presentations dealing with up-to-the-minute specialist topics. Those selected for the last-minute presentations will be notified 18 days prior to the conference start, and will be required to prepare a 30-minute presentation to be given on Thursday 6th October at the Hesperia Tower hotel in Barcelona, Spain. Those selected for the last-minute presentations will receive a 50% discount on the conference registration fee. HOW TO SUBMIT A PROPOSAL Please use our online abstract submission form at http://www.virusbtn.com/conference/abstracts/ You will need to include: - an abstract of approximately 300 words outlining the proposed paper - five key points your presentation will cover - full contact details with each submission The deadline for submissions is 8 September 2011. Submissions received later than 8 September 2011 will not be considered. Thank you for your time, I hope to hear from you. Kind regards Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. </pre> Martijn Grooten 2011-08-22T14:53:35 http://comments.gmane.org/gmane.ietf.asrg/15351 <pre> CALL FOR NOMINATIONS: APPLIED NETWORKING RESEARCH PRIZE (ANRP) http://irtf.org/anrp *** Submit nominations until August 28 for the ANRP for IETF-82, *** November 13-18, 2011 in Taipei, Taiwan: *** http://fit.nokia.com/anrp/82/ The Applied Networking Research Prize (ANRP) is awarded for recent results in applied networking research that are relevant for transitioning into shipping Internet products and related standardization efforts. Researchers with relevant, recently published results are encouraged to apply for this prize, which will offer them the opportunity to present and discuss their work with the engineers, network operators, policy makers and scientists that participate in the Internet Engineering Task Force (IETF) and its research arm, the Internet Research Task Force (IRTF). Third-party nominations for this prize are also encouraged. The goal of the Applied Networking Research Prize (ANRP) is to recognize the best new ideas in networking, and bring them to the IETF and IRTF especially in cases where they would not otherwise see much exposure or discussion. The Applied Networking Research Prize (ANRP) consists of: * cash prize of $500 (USD) * invited talk at the IRTF Open Meeting * travel grant to attend the week-long IETF meeting (airfare, hotel, registration, stipend) * recognition at the IETF plenary * invitation to related social activities * potential for additional travel grants to future IETF meetings, based on community feedback HOW TO APPLY Only a single person can be nominated based on a peer-reviewed, recently-published, original journal, conference or workshop paper they authored. The nominee must be one of the main authors of the nominated paper. Both self nominations (nominating one’s own paper) and third-party nominations (nominating someone else’s paper) are encouraged. The nominated paper should provide a scientific foundation for possible future IETF engineering work or IRTF experimentation, analyze the behavior of Internet protocols in operational deployments or realistic testbeds, make an important contribution to the understanding of Internet scalability, performance, reliability, security or capability, or otherwise be of relevance to ongoing or future IETF or IRTF activities. Applicants must briefly describe how the nominated paper relates to these goals, and are encouraged to describe how presentation of these research results will foster their transition into new IETF engineering or IRTF experimentation, or otherwise seed new activities that will have an impact on the real-world Internet. The goal of the Applied Networking Research Prize (ANRP) is to foster the transitioning of research results into real-world benefits for the Internet. Therefore, applicants must indicate that they (or the nominee, in case of third-party nominations) are available to attend the respective IETF meeting in person and in its entirety. Nominations must include: * the name and email address of the nominee * a reference to the published nominated paper * a PDF copy of the nominated paper * a statement that describes how the nominated paper fulfills the goals of the award * a statement that the nominee is available to attend the respective IETF meeting in person and in its entirety * a brief biography or CV of the nominee * optionally, any other supporting information (link to nominee's web site, etc.) *** Nominations are submitted via the submission site: *** http://fit.nokia.com/anrp/82/ SELECTION PROCESS A small selection committee comprised of individuals knowledgeable about the IRTF, IETF and the broader networking research community will evaluate the submissions against these selection criteria. The goal is to select 1-2 submissions for the Applied Networking Research Prize (ANRP) during each nomination period. All nominees will be notified by email. IMPORTANT DATES Applications open: August 1, 2011 Applications close: August 28, 2011 Notifications: September 20, 2011 IETF-82 Meeting: November 13-18, 2011 in Taipei, Taiwan SPONSORS The Applied Networking Research Prize (ANRP) is supported by the Internet Society (ISOC), as part of its Internet Research Award Programme, in coordination with the Internet Research Task Force (IRTF)._______________________________________________ Asrg mailing list Asrg&lt; at &gt;irtf.org http://www.irtf.org/mailman/listinfo/asrg </pre> Lars Eggert 2011-08-02T13:41:55 http://comments.gmane.org/gmane.ietf.asrg/15348 <pre>I asked if anyone was interested in an ASRG lunch, and only saw one reply. I'm perfectly happy to have lunch only with him, but surely there's more than the two of us going. Regards, John Levine, johnl&lt; at &gt;iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly </pre> John R. Levine 2011-07-06T18:32:37 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.asrg