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://permalink.gmane.org/gmane.ietf.asrg/15562 <pre> Dear Alessandro and Chris, Since RFC821, HELO/EHLO was defined as FQDN SMTP hostnames. There is no reason additional policy assertions such as those proposed for DMARC could not include authenticated email EHLO/HELO acceptance with a hostname from their domain, whether by a forward reference to an address list, or an SPF resource record. The domain validated would be determined by the domain of the SPF record and not by an SPF mechanism as Chris suggested. The goal of DMARC is to offer a safe method to reject messages in a way not likely to create support calls for receivers. A policy that can be extended to individual SMTP servers controlled by domains making compliance assertions should offer safe rejections having lower cost than message filtering or rejections based on the SMTP mail parameter. The mistake made by DMARC was not considering HELO/ELHO alignment against the parent domain rather than the hostname. Regards, Douglas Otis. </pre> Douglas Otis 2012-05-14T17:41:12 http://permalink.gmane.org/gmane.ietf.asrg/15561 <pre> Whatever the intent, I should get your permission before asserting that your server serves me. Shouldn't I? Then, yes, I suppose some judges still have difficulties understanding Internet protocols. I don't have specific experience, but it seems to me that when spammers leave enough evidence behind them they can be taken to court. You're right. Rejecting is cheap, but still bears a cost. </pre> Alessandro Vesely 2012-05-14T14:34:43 http://permalink.gmane.org/gmane.ietf.asrg/15560 <pre>On Sun, May 13, 2012 at 11:29:19AM -0400, Chris Lewis quoted: +1, and let me add: One of the many reasons to make the HELO consistent with the FQDN is that it can be helpful in debugging. ---rsk </pre> Rich Kulawiec 2012-05-14T14:22:39 http://permalink.gmane.org/gmane.ietf.asrg/15559 <pre> Who said anything about a deliberate DDOS? Think of it as spam with electronic countermeasures designed to confuse, confound and distract the recipients and third parties. Just like they already do. "national laws ... openly breaks". You can say that with a straight face considering that 80-90% of all spam already does? Big enough, the recipient site still loses before the 220. Eg: think back to when AOL bounced instead of rejected for no-such-user. </pre> Chris Lewis 2012-05-14T14:04:23 http://permalink.gmane.org/gmane.ietf.asrg/15558 <pre> And how does it discover abuse contacts? Yes, but it's not IP-based. It falls back to RFC 2142 role addresses, and relies on cooperative contributions (I think). Thanks for the pointers, I'll take a look at them. That would be a Good Thing. However, it may appear a double-edged sword, as it hides the network provider's abuse team. One could navigate whois records hierarchically, so if the virtual MTA operator is a bad guy, the abuse contact at the upper level should be its network provider. This operation can be done recursively, but homogeneity may obscure awareness. That is, by climbing the tree all the way up, one eventually gets at IANA's --which hopefully will never be a bad guy-- but might not realize what role corresponds to each level. </pre> Alessandro Vesely 2012-05-14T09:27:54 http://permalink.gmane.org/gmane.ietf.asrg/15557 <pre> More or less. That's plain abuse, though. There must be loads of national laws that the owner of that zone openly breaks. Isn't that too much risky from a legal POV, considering its effectiveness is probably less than other kinds of DDoS? 220 wmail.tana.it ESMTP HELO goofy.example 250 wmail.tana.it Ok. MAIL FROM:&lt;&gt; 250 Ok. RCPT TO:&lt;abuse&lt; at &gt;spammerdomain.com&gt; 513 Relaying denied. QUIT 221 Bye. </pre> Alessandro Vesely 2012-05-14T09:26:05 http://permalink.gmane.org/gmane.ietf.asrg/15556 <pre> Whoops, I meant: _smtp.spammerdomain.com IN MX 0 wmail.tana.it No. The spammer says "helo spammerdomain.com". Postmaster sends complaint to abuse&lt; at &gt;_smtp.spammerdomain.com. Where does that go? </pre> Chris Lewis 2012-05-13T19:56:49 http://permalink.gmane.org/gmane.ietf.asrg/15555 <pre> It should. But it doesn't. Right. As one said "the best thing about standards is that there's so many to choose from" ;-) That's an implementation detail. There's no reason that they'd _have_ to. Mine doesn't rely on whois for responsible domain or abuse contact. While it does the published RIR maps for allocations and countries, it does no whois queries. abuse.net's doesn't use whois for anything. I don't think Cymru's or Mynetwatchman's does. It's _very_ hard to get domains from whois in an even remotely "global sense", let alone abuse addresses. "Proper management" of IP whois records is probably coming as unlikely as it seems, so another reason for it wouldn't hurt. </pre> Chris Lewis 2012-05-13T19:55:08 http://permalink.gmane.org/gmane.ietf.asrg/15554 <pre> That's not quite how helo authentication works. When they say "helo wmail.tana.it" the server looks up wmail.tana.it. wmail.tana.it. IN TXT "v=spf1 redirect=tana.it" tana.it. IN TXT "v=spf1 +ip4:62.94.243.226 -all" They won't get a "pass" unless they are using that ip4. </pre> Alessandro Vesely 2012-05-13T18:49:08 http://permalink.gmane.org/gmane.ietf.asrg/15553 <pre> So it would be an error-prone technique? We are talking about /postmasters/ extracting target addresses for abuse reporting, not end users. Shouldn't that imply some knowledge? SPF records are going to sport a new ra= modifier, specifying an address for reporting authentication failures, not abuse. That may bring further confusion, in fact. Which one do you mean? DNS lists like abusix get their data from RIRs' whois databases. In that case, virtual MTA providers would have to restrict their choice of network providers based on proper management of whois records, besides cost, bandwidth, uptime, support, ... </pre> Alessandro Vesely 2012-05-13T18:40:32 http://permalink.gmane.org/gmane.ietf.asrg/15552 <pre> It doesn't help. spammerdomain.com IN MX 0 wmail.tana.it. spammerdomain.com IN TXT "v=spf1 ip4:0/0 -all" [May not be exact, but you get the idea.] 10 billion cutwail spams heloing as spammerdomain.com later... </pre> Chris Lewis 2012-05-13T18:30:14 http://permalink.gmane.org/gmane.ietf.asrg/15551 <pre> On the one hand, we have Klensin commenting on rejecting email based upon helo validation (despite which, helo factors very heavily into filtering anyway), versus _explicitly_ violating the RFC in a proposed standard. Klensin's argument doesn't apply to this proposal. At all. The reality is going to be is that since it relies on SPF to be valid, few people would bother implementing it on the sending side, and there will be more than enough people ignoring the requirement to SPF verify before trusting it, that kabooms! will still happen. There are other ways of doing this that doesn't require ancilliary gunk like SPF. There's at least one IP-based DNSBL that yields the same data. </pre> Chris Lewis 2012-05-13T18:03:31 http://permalink.gmane.org/gmane.ietf.asrg/15550 <pre> This has been discussed so many times that we don't need to do it once more. For one (John Klensin on Jan 2009): The 1123-imposed requirement (carried forward into Section 4.1.4 Paragraph 6 of 5321) that messages not be rejected on the basis of a validation failure with the EHLO argument would presumably remain even if we deprecated 821 and client use of HELO. http://www.imc.org/ietf-smtp/mail-archive/msg05420.html I'd agree that violating intents and/or practices is not a good start. That seems to imply that it is necessary to use scripts to keep helo names, IP addresses, and SPF in sync. Would that be worth? </pre> Alessandro Vesely 2012-05-13T17:21:44 http://permalink.gmane.org/gmane.ietf.asrg/15549 <pre> Uh what? RFC5321: Section 4.1.1.1: These commands are used to identify the SMTP client to the SMTP server. The argument clause contains the fully-qualified domain name of the SMTP client, if one is available. In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see Section 4.1.3). ... The SMTP server identifies itself to the SMTP client in the connection greeting reply and in the response to this command. Yeah, I suppose you could make all your outbounds have the same name (up to whatever limit DNS imposes), but clearly this violates the intent. And it's also very explicitly counter to industry practises/BCP. </pre> Chris Lewis 2012-05-13T15:29:19 http://permalink.gmane.org/gmane.ietf.asrg/15548 <pre> I see nothing wrong if an organization uses the same helo name for all its mailouts. A helo name does not have to be a label of any DNS record. However, in case it has an SPF record it could be validated. No, wait. Didn't I say it has to get an SPF "pass" to get usable? I must have considered it implied... my bad. An idea is that if you offer virtual MTA services, you may want to get complaints. Unless you hijack each customer's abuse&lt; at &gt;, using helo names might be more practical than relying on RIR's whois, depending on your network providers. But did anyone try that? And if anyone did, where do they publish their experiences? Where do postmasters learn to target complaints effectively? </pre> Alessandro Vesely 2012-05-13T09:58:40 http://permalink.gmane.org/gmane.ietf.asrg/15547 <pre> It would be nice if it could be made usable. This would tend to make a large organization having all of their servers helo exactly the same way, which flies in the face of industry BCP (eg: MAAWG), and even if it wasn't specifically RFC5321-illegal, clearly violates its intent. Or they use wildcarded MXes. Ick. Makes "divisional" abuse addresses very difficult. Or use the registration level domain (lop off the non-registration level FQDN qualifiers) - makes "divisional" abuse addresses impossible, and the registration level domain chop is real hard to do with some tlds. The absolute death of this proposal is, tho, that it puts the abuse reporting address under the control of the spammer and becomes a DDOS weapon. I could just see it - it gets implemented for tana.it, and the next day's blast of 10 billion cutwail botnet spams uses "HELO tana.it". Kaboom!!! </pre> Chris Lewis 2012-05-12T17:46:55 http://permalink.gmane.org/gmane.ietf.asrg/15546 <pre>This probably belongs to ASRG, not only because MARF has finished, but also because a *Taxonomy of reporting targets* should be hosted somewhere, and I'm unable to think of a better place than this list's wiki. Opinions? -------- Original Message -------- From: vesely&lt; at &gt;tana.it Date: Tue, 08 May 2012 12:56:10 +0200 To: marf&lt; at &gt;ietf.org Subject: SPF's helo identity as a reporting target Hi all, someone on the spf-discuss list noted that the smtp.helo is often of a different type than the domains usually branded in smtp.mailfrom, header.from, and dkim.d. That's because it seems to be quite common to outsource mail relaying as well as MX services. This situation characterizes relaying services as third parties that might manage complaints and/or enforce policies, much like ESPs and ISPs. MARF-AS generically allows any "domain that has been verified by the [relevant] authentication mechanism", as well as "Abuse addresses in WHOIS records of the IP address". Would it be feasible to correlate auth methods' properties to roles, in general? For example, ESPs normally wouldn't outsource mail relaying, since it's their core business. Thus, sending a complaint to abuse&lt; at &gt;_smtp.helo_ could be a way to target any involved ESP. Just mumbling... </pre> Alessandro Vesely 2012-05-12T07:59:55 http://permalink.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://permalink.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://permalink.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://permalink.gmane.org/gmane.ietf.asrg/15542 <pre>Dear Dave, When DNS transactions attempt to include all possible choices, necessary transactions are at a greater risk of being queued, rather than being ready in advance. Chrome offers a switch setting to disable this behavior that may actually result in reduced performance. Regards, Doug Otis </pre> Douglas Otis 2012-01-31T21:50:01 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.asrg