***SPAM*** 17.826 (5) Resend: RFC 7157 on IPv6 Multihoming without Network Address Translation (announced in March)
Below is the original publication announcement for RFC 7157. It is being resent because the original announcement does not seem to have made it through to the ietf-announce list. Please note that the date of publication is 31 March 2014, as indicated in the message below. - Forwarded message from rfc-edi...@rfc-editor.org - Date: Mon, 31 Mar 2014 17:36:01 -0700 (PDT) From: rfc-edi...@rfc-editor.org To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, drafts-update-...@iana.org, v6...@ietf.org Subject: RFC 7157 on IPv6 Multihoming without Network Address Translation A new Request for Comments is now available in online RFC libraries. RFC 7157 Title: IPv6 Multihoming without Network Address Translation Author: O. Troan, Ed., D. Miles, S. Matsushima, T. Okimoto, D. Wing Status: Informational Stream: IETF Date: March 2014 Mailbox:o...@cisco.com, davidmi...@google.com, satoru.matsush...@g.softbank.co.jp, t.okim...@west.ntt.co.jp, dw...@cisco.com Pages: 22 Characters: 49038 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06.txt URL:http://www.rfc-editor.org/rfc/rfc7157.txt Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution. For IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network Prefix Translation (NPTv6). However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria. We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - - End forwarded message -
***SPAM*** 17.826 (5) Resend: RFC 7157 on IPv6 Multihoming without Network Address Translation (announced in March)
Greetings, Below is the original publication announcement for RFC 7157. It is being resent because the original announcement does not seem to have made it through to the ietf-announce list. Please note that the date of publication is 31 March 2014, as indicated in the message below. - Forwarded message from rfc-edi...@rfc-editor.org - Date: Mon, 31 Mar 2014 17:36:01 -0700 (PDT) From: rfc-edi...@rfc-editor.org To: ietf-announce@ietf.org, rfc-d...@rfc-editor.org Cc: rfc-edi...@rfc-editor.org, drafts-update-...@iana.org, v6...@ietf.org Subject: RFC 7157 on IPv6 Multihoming without Network Address Translation A new Request for Comments is now available in online RFC libraries. RFC 7157 Title: IPv6 Multihoming without Network Address Translation Author: O. Troan, Ed., D. Miles, S. Matsushima, T. Okimoto, D. Wing Status: Informational Stream: IETF Date: March 2014 Mailbox:o...@cisco.com, davidmi...@google.com, satoru.matsush...@g.softbank.co.jp, t.okim...@west.ntt.co.jp, dw...@cisco.com Pages: 22 Characters: 49038 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-06.txt URL:http://www.rfc-editor.org/rfc/rfc7157.txt Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution. For IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network Prefix Translation (NPTv6). However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria. We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC - End forwarded message - - End forwarded message - - End forwarded message -
DNS Rule Transmission is a new tool in anti-spam controls
I want to point out that the ability and use of DNS to transmit policy statements is a valuable tool in dealing with certain types of DMA sponsored emails which many of us wish would go away. The idea of being able to send a statement of the use rules for a MX record for instance is a very powerful process in new networking models which are more policy driven in form. Clearly the TXT records can carry these types of statements but it would seem to make sense to allow some pre-approved tags and response mandates to be used as well. Todd -- Todd S. Glassey - CISM CIFI CTO Certichron Inc This message contains information which may be confidential and/or privileged. Unless you are the intended recipient (or authorized to receive for the intended recipient), you may not read, use, copy or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message and any attachment(s) thereto without retaining any copies. Further we have a formal OPT OUT Policy posted on our website pertaining to the use of any Email Addresses gleaned or taken from any source, web, mailing lists, previous customer lists etc. In all instances we choose to formally OPT OUT and this notice constitutes formal disclosure that you may not collect, buy or sell or provide access to this email address or any pertaining to our DNS MX Record Publication License posted on the web at http://www-wp.certichron.com/?page_id=3947. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS Rule Transmission is a new tool in anti-spam controls
Todd Glassey wrote: I want to point out that the ability and use of DNS to transmit policy statements is a valuable tool in dealing with certain types of DMA sponsored emails which many of us wish would go away. But we are also encouraging them to do so. It is now BCP by the DMA community to support these new Email Mouse Trap policy based mechanisms. My view is that the *power* is in the domain policy fault detection for compliancy. So at the top level, as long as they are domain compliant as expected for all, they should be treated equally as just another anonymous domain transaction exposing their policies. The idea of being able to send a statement of the use rules for a MX record for instance is a very powerful process in new networking models which are more policy driven in form. +1, again, in my view, when enforced from a fault detection standpoint the higher payoff is more realized. Clearly the TXT records can carry these types of statements but it would seem to make sense to allow some pre-approved tags and response mandates to be used as well. +1. I see the issue as following: 1) Using the same name space where there is no standard for the separation of TXT strings requiring the the individual protocols to have its own string detection mechanism. 2) Due to#1 and the lower feasibility of using RR types, use a special namespace (subdomain). Some existing protocols such as AD and XMPP would not get wide support until RR types such as SRV was widely supported. And even then, for backward compatibility, had to include fall back for widest support discovery. A major part of the dilemma is the overhead with the migration path with the hope its only a initial short term impact, but an eventual long term benefit in lowering the impact on DNS. I believe what is required is a Batch call of Multiple Query Packets under a single call feature to be proposed for DNS servers to support because currently the recommendation is to use an async emulation of two independent by managed DNS calls. I see this helping with the usage and consideration of new protocols considering new RR types but may have to first use a fast entry, widest support TXT record mechanism just to get started. This will automatically cause a migration requirement. Thanks Hector Santos/CTO Santronics Software, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Please remove draft-ordogh-spam-reporting-using-imap-kleansed fromI-D repository
- Original Message - From: todd glassey tglas...@earthlink.net To: t.petch daedu...@btconnect.com Cc: Alessandro Vesely ves...@tana.it; ietf ietf@ietf.org Sent: Sunday, January 22, 2012 8:38 PM On 1/21/2012 10:53 AM, t.petch wrote: Alessandro You could, of course, issue an updated version which simply says that its predecessor should not have been filed for the reasons you give in the e-mail. No need to include any other text whatsoever (except, of course, the relevant boiler plate). Tom No actually he cant. That will complicate the matter since the IETF publishing manner has specifically been set up to destroy the ability to recall anything. The license to use per the copyright statement is irrevocable even through the revisions process. Yes, you are right. The I-D has now vanished from the 'current' archive but is still accessible through the expired archive; mmm. It is very difficult to eliminate something from the Internet, so I think my suggestion of a later version explaining what happened could be valuable as belt and braces, reckoning people are more likely to retrieve it than an earlier version; or perhaps it would just draw people's attention to what should never have been:-( I dunno - IPR is so complicated. Tom Petch That's right - it was published with a set of specific rights use statements which are factually wrong and now the IETF is stuck with that - unless a recall practice is put in place immediately like all other publications houses have. Todd That seems simpler to me than asking the system to do something rather unusual that it may not have a mechanism to do. In future, there could always be another version moving the process forward in the appropriate direction. Tom Petch - Original Message - From: Alessandro Vesely ves...@tana.it To: ietf-act...@ietf.org Cc: Zoltan Ordogh zord...@rim.com; apps discuss apps-disc...@ietf.org; ietf ietf@ietf.org Sent: Friday, January 20, 2012 4:03 PM Subject: Please remove draft-ordogh-spam-reporting-using-imap-kleansed fromI-D repository Dear IETF Secretariat, I hereby ask that draft-ordogh-spam-reporting-using-imap-kleansed be removed from the I-D repository. I submitted it on 10 Jan 2012, in a clumsy attempt to speed up a discussion about a similarly named I-D, draft-ordogh-spam-reporting-using-imap. The editing I carried out was based on previous writing about, both privately and on IETF lists. However, I hadn't obtained the author's permission to alter the boilerplate-type of the original document. Thus, the document I posted bears wrong copyright information. In particular, unwitting editors may derive their own work from this document if they just abide by its boilerplate text, while the original post did not imply a handoff of change control. I apologize for any inconveniences that my action might have caused. Regards Alessandro Vesely ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Please remove draft-ordogh-spam-reporting-using-imap-kleansed fromI-D repository
On 1/21/2012 10:53 AM, t.petch wrote: Alessandro You could, of course, issue an updated version which simply says that its predecessor should not have been filed for the reasons you give in the e-mail. No need to include any other text whatsoever (except, of course, the relevant boiler plate). Tom No actually he cant. That will complicate the matter since the IETF publishing manner has specifically been set up to destroy the ability to recall anything. The license to use per the copyright statement is irrevocable even through the revisions process. That's right - it was published with a set of specific rights use statements which are factually wrong and now the IETF is stuck with that - unless a recall practice is put in place immediately like all other publications houses have. Todd That seems simpler to me than asking the system to do something rather unusual that it may not have a mechanism to do. In future, there could always be another version moving the process forward in the appropriate direction. Tom Petch - Original Message - From: Alessandro Vesely ves...@tana.it To: ietf-act...@ietf.org Cc: Zoltan Ordogh zord...@rim.com; apps discuss apps-disc...@ietf.org; ietf ietf@ietf.org Sent: Friday, January 20, 2012 4:03 PM Subject: Please remove draft-ordogh-spam-reporting-using-imap-kleansed fromI-D repository Dear IETF Secretariat, I hereby ask that draft-ordogh-spam-reporting-using-imap-kleansed be removed from the I-D repository. I submitted it on 10 Jan 2012, in a clumsy attempt to speed up a discussion about a similarly named I-D, draft-ordogh-spam-reporting-using-imap. The editing I carried out was based on previous writing about, both privately and on IETF lists. However, I hadn't obtained the author's permission to alter the boilerplate-type of the original document. Thus, the document I posted bears wrong copyright information. In particular, unwitting editors may derive their own work from this document if they just abide by its boilerplate text, while the original post did not imply a handoff of change control. I apologize for any inconveniences that my action might have caused. Regards Alessandro Vesely ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Please remove draft-ordogh-spam-reporting-using-imap-kleansed fromI-D repository
Alessandro You could, of course, issue an updated version which simply says that its predecessor should not have been filed for the reasons you give in the e-mail. No need to include any other text whatsoever (except, of course, the relevant boiler plate). That seems simpler to me than asking the system to do something rather unusual that it may not have a mechanism to do. In future, there could always be another version moving the process forward in the appropriate direction. Tom Petch - Original Message - From: Alessandro Vesely ves...@tana.it To: ietf-act...@ietf.org Cc: Zoltan Ordogh zord...@rim.com; apps discuss apps-disc...@ietf.org; ietf ietf@ietf.org Sent: Friday, January 20, 2012 4:03 PM Subject: Please remove draft-ordogh-spam-reporting-using-imap-kleansed fromI-D repository Dear IETF Secretariat, I hereby ask that draft-ordogh-spam-reporting-using-imap-kleansed be removed from the I-D repository. I submitted it on 10 Jan 2012, in a clumsy attempt to speed up a discussion about a similarly named I-D, draft-ordogh-spam-reporting-using-imap. The editing I carried out was based on previous writing about, both privately and on IETF lists. However, I hadn't obtained the author's permission to alter the boilerplate-type of the original document. Thus, the document I posted bears wrong copyright information. In particular, unwitting editors may derive their own work from this document if they just abide by its boilerplate text, while the original post did not imply a handoff of change control. I apologize for any inconveniences that my action might have caused. Regards Alessandro Vesely ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Please remove draft-ordogh-spam-reporting-using-imap-kleansed from I-D repository
Dear IETF Secretariat, I hereby ask that draft-ordogh-spam-reporting-using-imap-kleansed be removed from the I-D repository. I submitted it on 10 Jan 2012, in a clumsy attempt to speed up a discussion about a similarly named I-D, draft-ordogh-spam-reporting-using-imap. The editing I carried out was based on previous writing about, both privately and on IETF lists. However, I hadn't obtained the author's permission to alter the boilerplate-type of the original document. Thus, the document I posted bears wrong copyright information. In particular, unwitting editors may derive their own work from this document if they just abide by its boilerplate text, while the original post did not imply a handoff of change control. I apologize for any inconveniences that my action might have caused. Regards Alessandro Vesely ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
FW: [apps-discuss] Spam reporting over IMAP
Hi all, I would like to address the issues that involve SM, Alessandro and John first. I understand the confusion has risen because my name is listed as an author on draft-ordogh-spam-reporting-using-imap-kleansed-00. I would like to make it clear that while draft-ordogh-spam-reporting-using-imap-kleansed-00 bears my name and I am listed as the author of this, I was not involved - nor consulted - on its development. I am of course happy to work with anyone who wishes to progress either draft as long as the work gets done in IETF. As I said before, if there is no interest to keep the work in IETF, while not desirable, it is perfectly fine; the work will happen in OMA EVVM. I noticed that a declaration has been made on draft-ordogh-spam-reporting-using-imap-kleansed-00. This simple fact should answer SM's question. Alessandro said he emailed Sarah and got no response. I asked Sarah and she told me she have not received any emails from Alessandro. The only thing I can add here is that RIM has very strict spam filters in place. The sender or the recipient will not know what happened to an email. If you do not get a response within a reasonable timeframe, please email the person again (with a different subject and body, to ensure that there's absolutely nothing in the mail that might trigger a spam filter). BTW, since I am bound by RIM's policies as Sarah, this holds true for my emails as well. Speaking of IT policies. Regarding John's concern about the disclaimer in the email message. It is an IT policy in RIM, there is nothing I can do about it as it is beyond my control. Since the emails are sent to a public mailing list, all information in the email can be considered public - in which case I believe that disclaimer does not apply. If I accidently put some information into that email that was not meant to be public, I will have to follow up on it and you will know. Next, I try to do my best to address John's other comments below (2 through 4). -Original Message- From: John C Klensin [mailto:john-i...@jck.com] Sent: January 14, 2012 12:40 PM To: Alessandro Vesely; Zoltan Ordogh Cc: ietf; apps-disc...@ietf.org Subject: Re: [apps-discuss] Spam reporting over IMAP --On Saturday, January 14, 2012 14:32 +0100 Alessandro Vesely ves...@tana.it wrote: ... A bit later, a liaison statement was sent from OMA to IETF, seeking collaboration and a home for the draft; as required by RFC3975. I assume you're still talking about SREP. I read a reply by John Klensin, whom I consider a sort of IETF guru, and it didn't prospect a bright future for the draft. I posted a kleansed version trying to address some of those concerns, in an attempt to improve the chances that APPSAWG will adopt it. Somewhat arbitrarily, I changed the IPR qualification of the document too. In fact, I had the impression that the IPR was that way because OMA SpamRep was being mentioned, albeit not being specified, and also because that was one of the points raised. I hope my editing was correct, but your approval as author is needed. ... Alessandro, Zoltan, Guru or not (some would certainly dispute that), this is strictly a personal comment and personal opinion. Just to clarify my view of this (other may have different opinions)... (1) I think SM's question, and anything else having to do with the IRP status of this document (or pair of documents) has to be completely clear. The IETF could certainly decide to process the document even if the technology were encumbered (has happened many times before), but uncertainty is pretty much a showstopper. Alessandro's concerns about distribution disclaimers on email messages that discuss the topic only reinforce my concern in this area. [ZÖr] I addressed this above. (2) Similarly, both of you, and RIM and OMA, need to understand that handing something like this off to IETF, especially for standards-track processing, is a handoff of change control. The IETF can modify (we hope improve) things as it likes, even after approval of the first version of the document as a Proposed Standard. Joint ownership/ change control arrangements are possible, but they are very hard and time-consuming to negotiate and perhaps, due to some bad experience, likely to get harder. [ZÖr] I think I understand your concern. The draft contains one possible solution - one that fulfills the requirements set and was 'good enough' for OMA. It is not a draft from OMA. It is an individual contribution; OMA merely endorses it because it fulfills the requirement they need. I am fairly confident that if IETF can find a more efficient solution than the one in my draft, one that fulfills the requirement OMA needs, then OMA will be more than happy to discard my draft - even as a whole if need be - and go with the more efficient solution instead. The only concern I would expect OMA to raise
Re: [apps-discuss] FW: Spam reporting over IMAP
Hi Zoltan, At 14:10 19-01-2012, Zoltan Ordogh wrote: I understand the confusion has risen because my name is listed as an author on draft-ordogh-spam-reporting-using-imap-kleansed-00. I would like to make it clear that while draft-ordogh-spam-reporting-using-imap-kleansed-00 bears my name and I am listed as the author of this, I was not involved - nor consulted - on its development. I am of course happy to work with anyone who wishes to progress either draft as long as the work gets done in IETF. As I said before, if there Thanks for the explanation. I noticed that a declaration has been made on draft-ordogh-spam-reporting-using-imap-kleansed-00. This simple fact should answer SM's question. I would like to thank you and Research In Motion Limited for resolving the issue. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [apps-discuss] Spam reporting over IMAP
Hi Zoltan, At 11:11 13-01-2012, Zoltan Ordogh wrote: Instead of responding to individual emails one by one, I try to clarify some of the concerns at least in a single response. The single response does not address the issue I raised ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04079.html ). PS. I am solely a technical contributor, so asking me IPR-related questions will always be a dead end. Please direct those questions directly to the appropriate contact person, which, in, this case is Sarah Guichard. Thank you. draft-ordogh-spam-reporting-using-imap-kleansed-00 lists Zoltan Ordogh, Research In Motion Limited, as the author of the Internet-Draft. The document states that: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Do you have any concerns about draft-ordogh-spam-reporting-using-imap-kleansed-00 in respect to BCP 78 and BCP 79? Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [apps-discuss] Spam reporting over IMAP
Hi Zoltan, On 13/Jan/12 20:11, Zoltan Ordogh wrote: I would like to start with a story. A rather similar story is summarized here: http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs A bit later, a liaison statement was sent from OMA to IETF, seeking collaboration and a “home” for the draft; as required by RFC3975. I assume you're still talking about SREP. I read a reply by John Klensin, whom I consider a sort of IETF guru, and it didn't prospect a bright future for the draft. I posted a kleansed version trying to address some of those concerns, in an attempt to improve the chances that APPSAWG will adopt it. Somewhat arbitrarily, I changed the IPR qualification of the document too. In fact, I had the impression that the IPR was that way because OMA SpamRep was being mentioned, albeit not being specified, and also because that was one of the points raised. I hope my editing was correct, but your approval as author is needed. PS. I am solely a technical contributor, So am I (but I signed no contract.) so asking me IPR-related questions will always be a dead end. As a survival requirement, you have to be able to answer SM's question, though. Please direct those questions directly to the appropriate contact person, which, in, this case is Sarah Guichard. I sent my previous comment on this to Jon M. Jurgovan, cc Sarah Guichard, but had no reply either. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. The above boilerplate formally makes of no effect whatever else you wrote in that message, according to Andrew's explanation: http://www.ietf.org/mail-archive/web/ietf/current/msg67516.html I usually group these issues to the same bin I use for IPRs, as I guess many others on this list do. Unfortunately, at times they become relevant, which is why we have to deal with them. See survival above :-) Specifically, if you need a written authorization of your employer in order to contribute technical specifications to the IETF under IETF's terms, please ask them to provide it. I guess we need that paperwork. Ciao Ale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [apps-discuss] Spam reporting over IMAP
--On Saturday, January 14, 2012 14:32 +0100 Alessandro Vesely ves...@tana.it wrote: ... A bit later, a liaison statement was sent from OMA to IETF, seeking collaboration and a home for the draft; as required by RFC3975. I assume you're still talking about SREP. I read a reply by John Klensin, whom I consider a sort of IETF guru, and it didn't prospect a bright future for the draft. I posted a kleansed version trying to address some of those concerns, in an attempt to improve the chances that APPSAWG will adopt it. Somewhat arbitrarily, I changed the IPR qualification of the document too. In fact, I had the impression that the IPR was that way because OMA SpamRep was being mentioned, albeit not being specified, and also because that was one of the points raised. I hope my editing was correct, but your approval as author is needed. ... Alessandro, Zoltan, Guru or not (some would certainly dispute that), this is strictly a personal comment and personal opinion. Just to clarify my view of this (other may have different opinions)... (1) I think SM's question, and anything else having to do with the IRP status of this document (or pair of documents) has to be completely clear. The IETF could certainly decide to process the document even if the technology were encumbered (has happened many times before), but uncertainty is pretty much a showstopper. Alessandro's concerns about distribution disclaimers on email messages that discuss the topic only reinforce my concern in this area. (2) Similarly, both of you, and RIM and OMA, need to understand that handing something like this off to IETF, especially for standards-track processing, is a handoff of change control. The IETF can modify (we hope improve) things as it likes, even after approval of the first version of the document as a Proposed Standard. Joint ownership/ change control arrangements are possible, but they are very hard and time-consuming to negotiate and perhaps, due to some bad experience, likely to get harder. (3) The leadership of AppAWG, and the ADs, will do as they think appropriate, but, if I were making the rules, no one would spend energy trying to sort out the differences between a pair of competing documents. I suggest that the two of you get together, offlist, and see if you can reach clear agreement on a single draft that supercedes both documents. That is a matter of courtesy to those of us you are asking to consider the work and is quite independent of the IPR concerns (although they do interact). All three of those issues are administrative, not technical. They should be easily solved. My personal preferences is that the AppsAWG, and the apps-discuss list, spend no more time on this until/unless they are resolved. YMMD, of course. (4) The core of my previous comments was a technical concern, not an administrative one. Even if one ignores the security concerns, the stability issues for normative references, and so on, many of us believe that the IMAP protocol has become far too complicated, with too many options and features. That complexity increases the requirements on IMAP servers that wish to support a wide range of clients and applications and on clients that wish to support a reasonable range of features but work with servers that may not support all of them. Whatever the advantages, too much code and too many code paths are not conducive to very high quality, bug-free, implementations. This proposal seems to me to take IMAP into a whole new area. I'm not questions whether or not that is possible because I'd be certain it would be, even without the assertiosn that there are implementations out there. I am questioning whether there is a strong enough case to be made that this belongs in IMAP to justify further clutter in the protocol and even lower odds of seeing high-quality clients. I observe that probably the best general-purpose --as distinct from, e.g., specialized for mobile devices-- IMAP client out there is now quite old, largely unmaintained, and has not picked up on any of the new features added in the last several years.Neither version of the document really addresses that issue. Some of the comments from the two of you about why it is hard and/or expensive to do it in other ways certainly have merit, but need, IMO, to be balanced off against other considerations including the above. That balance won't be easy to find especially since, as I am sure you both know, there is no community agreement about the degree to which it is appropriate to make normal, desired, email work worse in order to provide better facilities for spam-handling, especially spam-handling at or after the final delivery MTA. Bottom line: I think we should see a single draft that really addresses all of the technical issues, including the design tradeoffs and security topics, _and_ addresses the IPR/administrative one in a way with which we can all be comfortable before being asked to decide whether
IEEE spam (was [CfP] IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) - April 16, 2012 - Hawaii, USA)
-Original Message- From: apps-discuss-boun...@ietf.org [mailto:apps-discuss-boun...@ietf.org] On Behalf Of Peoples, Cathryn Sent: Friday, November 25, 2011 2:09 AM To: apps-disc...@ietf.org Subject: [apps-discuss] [CfP] IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) - April 16, 2012 - Hawaii, USA --- -- Please accept our apologies if you receive multiple copies of this CfP --- -- IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) As this was blasted to a lot of IETF lists (three that I watch, at least), I suspect this might have been better handled, i.e., in a less irritating manner, by using the IEEE-IETF Liaison position. Such a role does exist, as shown at http://www.ietf.org/liaison/managers.html. That person could have posted the CfP in a single conspicuous place within the IETF on behalf of IEEE. In any case, a single posting to ietf@ietf.org would have been more than sufficient. I note that on at least one list I watch, the IEEE poster has been blocked from further postings as a result. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC 6430 on Email Feedback Report Type Value: not-spam
A new Request for Comments is now available in online RFC libraries. RFC 6430 Title: Email Feedback Report Type Value: not-spam Author: K. Li, B. Leiba Status: Standards Track Stream: IETF Date: November 2011 Mailbox:likep...@huawei.com, barryle...@computer.org Pages: 7 Characters: 12678 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-marf-not-spam-feedback-03.txt URL:http://www.rfc-editor.org/rfc/rfc6430.txt This document defines a new Abuse Reporting Format (ARF) feedback report type value: not-spam. It can be used to report an email message that was mistakenly marked as spam. [STANDARDS-TRACK] This document is a product of the Messaging Abuse Reporting Format Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Email Feedback Report Type Value : not-spam' to Proposed Standard (draft-ietf-marf-not-spam-feedback-03.txt)
The IESG has approved the following document: - 'Email Feedback Report Type Value : not-spam' (draft-ietf-marf-not-spam-feedback-03.txt) as a Proposed Standard This document is the product of the Messaging Abuse Reporting Format Working Group. The IESG contact persons are Pete Resnick and Peter Saint-Andre. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-marf-not-spam-feedback/ Technical Summary This document defines a new Abuse Reporting Format (ARF) feedback report type value: not-spam. It can be used to report a message that was mistakenly marked as spam. Working Group Summary The Working Group found this a simple and non-controversial extension. Document Quality This extension is added to parallel similar capabilities in the mobile equivalent of ARF, known as SpamRep. In that light, there are existing implementations on the mobile side, and this work seeks to maintain the same parallelism that otherwise already exists. Thus, the requirement for this capability has already received thorough review and assent within the OMA. Personnel Murray S. Kucherawy m...@cloudmark.com is the document shepherd. Pete Resnick presn...@qualcomm.com is the responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-ietf-marf-not-spam-feedback-01.txt (Email Feedback Report Type Value : not-spam) to Proposed Standard
At 06:51 08-09-2011, The IESG wrote: The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Email Feedback Report Type Value : not-spam' draft-ietf-marf-not-spam-feedback-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-09-22. Exceptionally, comments may be I read the document. As an editorial nit, Section 1.2 (terminology) seems superfluous given that there is only one optional requirement. In the example in Section 3, I suggest referencing RFC 5965 or pointing to the authoritative source. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-marf-not-spam-feedback-01.txt (Email Feedback Report Type Value : not-spam) to Proposed Standard
The IESG has received a request from the Messaging Abuse Reporting Format WG (marf) to consider the following document: - 'Email Feedback Report Type Value : not-spam' draft-ietf-marf-not-spam-feedback-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-09-22. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a new Abuse Reporting Format (ARF) feedback report type value: not-spam. It can be used to report a message that was mistakenly marked as spam. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-marf-not-spam-feedback/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-marf-not-spam-feedback/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RE: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt and SPAM
guys - does EVERYONE need to see this - I've removed some of the list aliases to bcc - please be careful when you REPLY all -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of David Allan I Sent: Wednesday, July 13, 2011 11:24 PM To: erminio.ottone...@libero.it; l...@pi.nu; Rui Costa Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce Subject: RE: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard HI Erminio: The comments that were raised during the day long discussion with the editors at the SG15 plenary resulted in those comments appearing in the liasion IMO in an actionable form and resulted in a constructive outcome. I enjoyed that level of cooperation. The comments that were punted over the wall with no discussion (depsite requests to allocate meeting time to do so) in some cases were sufficiently vague as to have no constructive value or not have a recognizable issue to be addressed. A request to have the commenters identified in the liaison so that comments that were unclear could be followed up upon by the editors was refused. Apparently that is not done and I would go so far as to suggest that blanket of anonymity diminished the quality of the liaison. The result of this process was that the only recourse to go what does this mean? was a complete liaison cycle. For some comments, stomaching a multi-month delay to clarify what the actual issue was that resulted in a comment like describe the start-up procedure was not reasonable, especially given SG15s continual complaint on how slow the IETF was. Such comments had to be weighed against the nature of comments from the larger reviewing community that seemed to have no issue with the completeness of the document content and perhaps had actually read it and the supporting documents. I'll call out an example: a comment that appeared more than once in the liaison was clarify the raising/clearing of defects as well as any consequent actions which I can only interpret as section 3.7 of the document not having been read. E.g. the TOC is: 3.7.1. Session initiation and Modification 13 3.7.2. Defect entry criteria13 3.7.3. Defect entry consequent action 14 3.7.4. Defect exit criteria 15 3.7.5. State machines 15 ...and if there was a deficiency in the descriptions it was not identified, and we're not mind readers. So that is both the history and why some comments were rejected. If you can suggest a constructive way to proceed that is not simply a waste of everyone's time, I'll listen.. Cheers Dave -Original Message- From: erminio.ottone...@libero.it [mailto:erminio.ottone...@libero.it] Sent: Wednesday, July 13, 2011 1:28 PM To: David Allan I; l...@pi.nu; Rui Costa Cc: m...@ietf.org; ietf@ietf.org; IETF-Announce Subject: R: RE: [mpls] R: Re: Last Call: draft-ietf-mpls-tp-cc-cv-rdi-05.txt (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile) to Proposed Standard Do you mean that ITU-T comments were discussed and resolution agreed during the ITU-T meeting? If this is the case, why the LS just provides the comments and not the agreed resolution? Why some ITU-T comments have been then rejected? Messaggio originale Da: david.i.al...@ericsson.com Data: 6-lug-2011 19.35 A: erminio.ottone...@libero.iterminio.ottone...@libero.it, l...@pi.nu l...@pi.nu, Rui Costarco...@ptinovacao.pt Cc: m...@ietf.orgm...@ietf.org, ietf@ietf.orgietf@ietf.org, IETF- Announceietf-annou...@ietf.org Ogg: RE: [mpls] R: Re: Last Call: lt;draft-ietf-mpls-tp-cc-cv-rdi-05.txtgt; (Proactive Connectivity Verification, Continuity Check and Remote Defect indication for MPLSTransport Profile) to Proposed Standard Hi Erminio: Two of the three document editors were present at SG15 plenary in February where the comments originated. The revised meeting schedule resulted in a day spent going through the document with the editors. IMO there were lots of discussion and legitimate issues with the document identified and corrected so it was a useful session. The liaison of same was in many ways *after the fact*. Cheers Dave ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ This email has been scanned
Re: Buckets of spam coming through IETF lists
On 4/1/2011 9:08 PM, Fred Baker wrote: On Apr 1, 2011, at 10:28 PM, John R. Levine wrote: Some clever spambot seems to have scraped a bunch of addresses out of the archives and is sending spam with multiple addresses on the From: line through IETF and IRTF mailing lists. Surely I'm not the only one who's seeing it. DKIM is directly designed to address this... What do we need to do to put it in play? Unfortunately, DKIM is /not/ design to address this. DKIM is designed to provide a reliable, accurate identifier upon which reputation data can be developed. That's a fundamentally different task from detected invalid From: field contents. ADSP, and add-on to DKIM, is felt by its promoters to be useful for detecting invalid From: fields, but it does not work through mailing lists. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Buckets of spam coming through IETF lists
John, If you want to report a SPAM problem with an IETF mailing list, please report it to ietf-act...@ietf.org. It will get prompt response. From the email you forwarded, it looks like a problem with lists hosted at ISI.EDU (that is, not at ietf.org). Bob p.s. Or should I have taken the date you sent this more seriously? On Apr 1, 2011, at 10:28 PM, John R. Levine wrote: Some clever spambot seems to have scraped a bunch of addresses out of the archives and is sending spam with multiple addresses on the From: line through IETF and IRTF mailing lists. Surely I'm not the only one who's seeing it. Given the amount of legitimate mail with multiple From: addresses (none, in practice) a quick shim in front of Mailman should deal with it until someone can go fix the underlying code. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly -- Forwarded message -- Date: Thu, 31 Mar 2011 14:47:22 -0700 (PDT) From: g...@isi.edu, j...@isi.edu, cak...@isi.edu, i...@isi.edu, cor...@isi.edu, jean...@isi.edu, galst...@isi.edu, ra...@isi.edu, end2end...@isi.edu, ns-us...@isi.edu, ns-commits-ow...@isi.edu, to...@isi.edu, kyam...@isi.edu, newu...@isi.edu, prob...@isi.edu, c...@isi.edu, management-requ...@isi.edu, han...@isi.edu, rba...@isi.edu To: g...@isi.edu, j...@isi.edu, cak...@isi.edu, i...@isi.edu, cor...@isi.edu, jean...@isi.edu, galst...@isi.edu, ra...@isi.edu, end2end...@isi.edu, ns-us...@isi.edu, ns-commits-ow...@isi.edu, to...@isi.edu, kyam...@isi.edu, newu...@isi.edu, prob...@isi.edu, c...@isi.edu, management-requ...@isi.edu, han...@isi.edu, rba...@isi.edu Subject: [IRSG] An offer you can't refuse ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Buckets of spam coming through IETF lists
Some clever spambot seems to have scraped a bunch of addresses out of the archives and is sending spam with multiple addresses on the From: line through IETF and IRTF mailing lists. Surely I'm not the only one who's seeing it. Given the amount of legitimate mail with multiple From: addresses (none, in practice) a quick shim in front of Mailman should deal with it until someone can go fix the underlying code. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly -- Forwarded message -- Date: Thu, 31 Mar 2011 14:47:22 -0700 (PDT) From: g...@isi.edu, j...@isi.edu, cak...@isi.edu, i...@isi.edu, cor...@isi.edu, jean...@isi.edu, galst...@isi.edu, ra...@isi.edu, end2end...@isi.edu, ns-us...@isi.edu, ns-commits-ow...@isi.edu, to...@isi.edu, kyam...@isi.edu, newu...@isi.edu, prob...@isi.edu, c...@isi.edu, management-requ...@isi.edu, han...@isi.edu, rba...@isi.edu To: g...@isi.edu, j...@isi.edu, cak...@isi.edu, i...@isi.edu, cor...@isi.edu, jean...@isi.edu, galst...@isi.edu, ra...@isi.edu, end2end...@isi.edu, ns-us...@isi.edu, ns-commits-ow...@isi.edu, to...@isi.edu, kyam...@isi.edu, newu...@isi.edu, prob...@isi.edu, c...@isi.edu, management-requ...@isi.edu, han...@isi.edu, rba...@isi.edu Subject: [IRSG] An offer you can't refuse ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Buckets of spam coming through IETF lists
--On Friday, April 01, 2011 16:28 -0400 John R. Levine jo...@iecc.com wrote: Some clever spambot seems to have scraped a bunch of addresses out of the archives and is sending spam with multiple addresses on the From: line through IETF and IRTF mailing lists. Surely I'm not the only one who's seeing it. Wouldn't that be ironic. :-( Given the amount of legitimate mail with multiple From: addresses (none, in practice) a quick shim in front of Mailman should deal with it until someone can go fix the underlying code. Yeah, although I find it really sad when the IETF concludes that it needs to be non-conformant to its own standards. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Buckets of spam coming through IETF lists
On Apr 1, 2011, at 10:28 PM, John R. Levine wrote: Some clever spambot seems to have scraped a bunch of addresses out of the archives and is sending spam with multiple addresses on the From: line through IETF and IRTF mailing lists. Surely I'm not the only one who's seeing it. DKIM is directly designed to address this... What do we need to do to put it in play? Given the amount of legitimate mail with multiple From: addresses (none, in practice) a quick shim in front of Mailman should deal with it until someone can go fix the underlying code. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly -- Forwarded message -- Date: Thu, 31 Mar 2011 14:47:22 -0700 (PDT) From: g...@isi.edu, j...@isi.edu, cak...@isi.edu, i...@isi.edu, cor...@isi.edu, jean...@isi.edu, galst...@isi.edu, ra...@isi.edu, end2end...@isi.edu, ns-us...@isi.edu, ns-commits-ow...@isi.edu, to...@isi.edu, kyam...@isi.edu, newu...@isi.edu, prob...@isi.edu, c...@isi.edu, management-requ...@isi.edu, han...@isi.edu, rba...@isi.edu To: g...@isi.edu, j...@isi.edu, cak...@isi.edu, i...@isi.edu, cor...@isi.edu, jean...@isi.edu, galst...@isi.edu, ra...@isi.edu, end2end...@isi.edu, ns-us...@isi.edu, ns-commits-ow...@isi.edu, to...@isi.edu, kyam...@isi.edu, newu...@isi.edu, prob...@isi.edu, c...@isi.edu, management-requ...@isi.edu, han...@isi.edu, rba...@isi.edu Subject: [IRSG] An offer you can't refuse ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On Mon, May 03, 2010 at 05:42:16PM -, John Levine wrote: He still uses 130.105/16 that he stole from the OSF and 198.3.136.0/21 that he got in 2004. Nullrouting those blocks can improve your quality of life. +1 If null-routing is not an available option, firewalling those blocks appears to be an equally effective way of causing the abuse to stop. ---Rsk ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On 2010-05-06, at 05:01, Robert Stangarone wrote: I did just as you suggest (contact the FTC) some time ago, and Dean stopped the SPAM. This sounds like valuable operational data. Given your experience, can you confirm exactly what you had to send and to whom in order to make this happen? Of course, he stated that I had never requested to be UNSUBSCRIBED from his list, which I had. Of course. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
Joe, I responded to Dean directly and asked to be removed for the second time, and noted that I had already contacted the FTC, which I had. Here's the FTC link if you need it: https://www.ftccomplaintassistant.gov/FTC_Wizard.aspx?Lang=en Bob On 05/06/2010 04:58 AM, Joe Abley wrote: On 2010-05-06, at 05:01, Robert Stangarone wrote: I did just as you suggest (contact the FTC) some time ago, and Dean stopped the SPAM. This sounds like valuable operational data. Given your experience, can you confirm exactly what you had to send and to whom in order to make this happen? Of course, he stated that I had never requested to be UNSUBSCRIBED from his list, which I had. Of course. Joe This mail originated from the whataboutbob.org domain. For any issues related to this mail, or the whataboutbob.org domain, contact supp...@whataboutbob.org Processed by .25 This mail originated from the whataboutbob.org domain. For any issues related to this mail, or the whataboutbob.org domain, contact supp...@whataboutbob.org Processed by .254 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On 5/4/2010 9:30 PM, Joe Baptista wrote: Has anyone bother by Dean considered using filters as a means of dealing with this? The problem with Filters is that you miss communications as part of the vetting process, so you are not properly informed. From a professional standards practice this is a serious issue. What that means is like auditors NO email may be excluded from the history of the vetting process lest the practice be subjected to random and uncontrolled censorship. Todd Joe On Mon, May 3, 2010 at 2:21 PM, todd glassey tglas...@earthlink.net wrote: On 5/3/2010 11:06 AM, Arnt Gulbrandsen wrote: On 05/03/2010 07:48 PM, todd glassey wrote: Maybe Joe but I do not want to be a party to his mailing lists, and he will not allow me off of them, so I have no choice but to file the spam compliant. I direct your attention to the IETF's standard for unilateral list unsubscription, RFC 5228 as extended by RFC 5429. Arnt These are extensions for Sendmail. The problem is that Dean created a list outside of the IETF and subscribed IETF members to it. The members have NO passwords and cant get them without interacting with Dean making this harassment. As to whether the IETF postings are commercial or not they clearly are since they are work on standards for commercial networking. Todd Dean subscribed me too, but I had forgotten about it until just now. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf attachment: tglassey.vcf___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On 05/05/2010 03:48 PM, todd glassey wrote: What that means is like auditors NO email may be excluded from the history of the vetting process lest the practice be subjected to random and uncontrolled censorship. You seem to be saying that pests cannot be kicked off WG/IETF lists... or do I misunderstand? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
All human systems of sufficient size and significance need a means of protection from abuse of process. This IETF process uses email and thus needs protection from the abuse thereof. In my opinion, the IETF method of deciding to bar people from various mailing lists is fine and the IETF is pretty liberal in this regard, allowing people to continue to post who would be barred in other groups. Thanks, Donald On Wed, May 5, 2010 at 10:06 AM, Arnt Gulbrandsen a...@gulbrandsen.priv.no wrote: On 05/05/2010 03:48 PM, todd glassey wrote: What that means is like auditors NO email may be excluded from the history of the vetting process lest the practice be subjected to random and uncontrolled censorship. You seem to be saying that pests cannot be kicked off WG/IETF lists... or do I misunderstand? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On 05/03/2010 08:21 PM, todd glassey wrote: These are extensions for Sendmail. No. Sendmail is just one implementer. There's at least a dozen others. The problem is that Dean created a list outside of the IETF and subscribed IETF members to it. Just use a sieve script (or anything else) to reject the mail. The list software will eventually see that mail to you is persistently undeliverable, and unsubscribe you. The members have NO passwords and cant get them without interacting with Dean making this harassment. You don't need the password to unsubscribe. Just let the mail bounce, and have a nice day. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On 5/5/2010 8:05 AM, Arnt Gulbrandsen wrote: On 05/03/2010 08:21 PM, todd glassey wrote: These are extensions for Sendmail. No. Sendmail is just one implementer. There's at least a dozen others. The problem is that Dean created a list outside of the IETF and subscribed IETF members to it. Just use a sieve script (or anything else) to reject the mail. The list software will eventually see that mail to you is persistently undeliverable, and unsubscribe you. This alters the email stream meaning its use as evidence is made non-functional. The members have NO passwords and cant get them without interacting with Dean making this harassment. You don't need the password to unsubscribe. Just let the mail bounce, and have a nice day. Then I have filters in place which edit my reception of list business and prevent or alter my participation. It also means I may miss critical information someone else responds to and that is unacceptable. Sorry, but this needs to get resolved, either in the IETF itself or in court. Todd Glassey Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf attachment: tglassey.vcf___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
--On Wednesday, May 05, 2010 17:05 +0200 Arnt Gulbrandsen a...@gulbrandsen.priv.no wrote: Just use a sieve script (or anything else) to reject the mail. The list software will eventually see that mail to you is persistently undeliverable, and unsubscribe you. Arnt, However appropriate it may be in this case, I have to object to that particular advice. More conventional spammers (the unsolicited, unambiguously-commercial, email variety) turn it around to say you can apply filters and therefore we are causing no harm.Setting up the filters (sieve script or otherwise) has a cost, having the hardware and bandwidth needed to receive (at least to the filtering point), analyze, and reject the mail has a cost, and so on. Sending mail to people who clearly don't want it is discourteous and abusive at best and should not be encouraged in any way, especially by telling the recipients that they can always filter. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On May 5, 2010, at 11:37 AM, John C Klensin wrote: Sending mail to people who clearly don't want it is discourteous and abusive at best and should not be encouraged in any way, especially by telling the recipients that they can always filter. What can I say. I don't receive email from Dean, and there are a few - very few - others that I don't receive email from. But when people feed the troll by replying to the email, the abuse affects me. At minimum, I have to delete the well-meaning burst of chatter that follows. Yes, I filter. None-the-less, I would appreciate it if courtesy prevailed. If it takes a court action to instill a modicum of courtesy, so be it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On 5/5/2010 11:46 AM, Fred Baker wrote: On May 5, 2010, at 11:37 AM, John C Klensin wrote: Sending mail to people who clearly don't want it is discourteous and abusive at best and should not be encouraged in any way, especially by telling the recipients that they can always filter. What can I say. I don't receive email from Dean, and there are a few - very few - others that I don't receive email from. But when people feed the troll by replying to the email, the abuse affects me. At minimum, I have to delete the well-meaning burst of chatter that follows. Yes, I filter. None-the-less, I would appreciate it if courtesy prevailed. If it takes a court action to instill a modicum of courtesy, so be it. Thanks Fred! Todd ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf attachment: tglassey.vcf___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
Todd, I did just as you suggest (contact the FTC) some time ago, and Dean stopped the SPAM. Of course, he stated that I had never requested to be UNSUBSCRIBED from his list, which I had. Bob On 05/03/2010 08:28 AM, todd glassey wrote: Folks - I have had it with Dean and his actions in spamming me after being thrown off of IETF lists. Mr. Anderson has created a set of IETF mirror lists which he calls IETF-Honest and which he subscribes IETF members to against their will after being told numerous times to cease and desist. Obviously the only recourse is a formal spam compliant with the FTC so the first complaint's filing number is 26303937. I would encourage all of you - and I mean all of you who are as annoyed with this spamming as I am to visit the FTC website and file your own complaint as if there are 10 or 20 of them independently filed, the FTC will in fact take action on this abuse. http://www.ftc.gov/spam Have a nice day. Todd Glassey This mail originated from the whataboutbob.org domain. For any issues related to this mail, or the whataboutbob.org domain, contact supp...@whataboutbob.org Processed by .25 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf This mail originated from the whataboutbob.org domain. For any issues related to this mail, or the whataboutbob.org domain, contact supp...@whataboutbob.org Processed by .254 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
Has anyone bother by Dean considered using filters as a means of dealing with this? Joe On Mon, May 3, 2010 at 2:21 PM, todd glassey tglas...@earthlink.net wrote: On 5/3/2010 11:06 AM, Arnt Gulbrandsen wrote: On 05/03/2010 07:48 PM, todd glassey wrote: Maybe Joe but I do not want to be a party to his mailing lists, and he will not allow me off of them, so I have no choice but to file the spam compliant. I direct your attention to the IETF's standard for unilateral list unsubscription, RFC 5228 as extended by RFC 5429. Arnt These are extensions for Sendmail. The problem is that Dean created a list outside of the IETF and subscribed IETF members to it. The members have NO passwords and cant get them without interacting with Dean making this harassment. As to whether the IETF postings are commercial or not they clearly are since they are work on standards for commercial networking. Todd Dean subscribed me too, but I had forgotten about it until just now. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: http://baptista.cynikal.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Formal SPAM Compliant filed against Anderson...
Folks - I have had it with Dean and his actions in spamming me after being thrown off of IETF lists. Mr. Anderson has created a set of IETF mirror lists which he calls IETF-Honest and which he subscribes IETF members to against their will after being told numerous times to cease and desist. Obviously the only recourse is a formal spam compliant with the FTC so the first complaint's filing number is 26303937. I would encourage all of you - and I mean all of you who are as annoyed with this spamming as I am to visit the FTC website and file your own complaint as if there are 10 or 20 of them independently filed, the FTC will in fact take action on this abuse. http://www.ftc.gov/spam Have a nice day. Todd Glassey attachment: tglassey.vcf___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
I think Dean does a good job of keeping the IETF honest. cheers joe baptista On Mon, May 3, 2010 at 11:28 AM, todd glassey tglas...@earthlink.netwrote: Folks - I have had it with Dean and his actions in spamming me after being thrown off of IETF lists. Mr. Anderson has created a set of IETF mirror lists which he calls IETF-Honest and which he subscribes IETF members to against their will after being told numerous times to cease and desist. Obviously the only recourse is a formal spam compliant with the FTC so the first complaint's filing number is 26303937. I would encourage all of you - and I mean all of you who are as annoyed with this spamming as I am to visit the FTC website and file your own complaint as if there are 10 or 20 of them independently filed, the FTC will in fact take action on this abuse. http://www.ftc.gov/spam Have a nice day. Todd Glassey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 Personal: http://baptista.cynikal.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On 5/3/10 11:25 AM, Joe Baptista wrote: I think Dean does a good job of keeping the IETF honest. If only we could say the same thing about the IETF's effect on Dean. /psa smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
Obviously the only recourse is a formal spam compliant with the FTC so the first complaint's filing number is 26303937. CAN SPAM only regulates commercial mail. Dean's mail is incoherent and annoying, but it's not commercial. He still uses 130.105/16 that he stole from the OSF and 198.3.136.0/21 that he got in 2004. Nullrouting those blocks can improve your quality of life. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On 5/3/2010 10:25 AM, Joe Baptista wrote: I think Dean does a good job of keeping the IETF honest. cheers joe baptista Maybe Joe but I do not want to be a party to his mailing lists, and he will not allow me off of them, so I have no choice but to file the spam compliant. Todd On Mon, May 3, 2010 at 11:28 AM, todd glassey tglas...@earthlink.netwrote: Folks - I have had it with Dean and his actions in spamming me after being thrown off of IETF lists. Mr. Anderson has created a set of IETF mirror lists which he calls IETF-Honest and which he subscribes IETF members to against their will after being told numerous times to cease and desist. Obviously the only recourse is a formal spam compliant with the FTC so the first complaint's filing number is 26303937. I would encourage all of you - and I mean all of you who are as annoyed with this spamming as I am to visit the FTC website and file your own complaint as if there are 10 or 20 of them independently filed, the FTC will in fact take action on this abuse. http://www.ftc.gov/spam Have a nice day. Todd Glassey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf attachment: tglassey.vcf___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On 05/03/2010 07:48 PM, todd glassey wrote: Maybe Joe but I do not want to be a party to his mailing lists, and he will not allow me off of them, so I have no choice but to file the spam compliant. I direct your attention to the IETF's standard for unilateral list unsubscription, RFC 5228 as extended by RFC 5429. Dean subscribed me too, but I had forgotten about it until just now. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On 5/3/2010 11:06 AM, Arnt Gulbrandsen wrote: On 05/03/2010 07:48 PM, todd glassey wrote: Maybe Joe but I do not want to be a party to his mailing lists, and he will not allow me off of them, so I have no choice but to file the spam compliant. I direct your attention to the IETF's standard for unilateral list unsubscription, RFC 5228 as extended by RFC 5429. Arnt These are extensions for Sendmail. The problem is that Dean created a list outside of the IETF and subscribed IETF members to it. The members have NO passwords and cant get them without interacting with Dean making this harassment. As to whether the IETF postings are commercial or not they clearly are since they are work on standards for commercial networking. Todd Dean subscribed me too, but I had forgotten about it until just now. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf attachment: tglassey.vcf___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Formal SPAM Compliant filed against Anderson...
On Mon, May 3, 2010 at 7:28 AM, todd glassey tglas...@earthlink.net wrote: I would encourage all of you - and I mean all of you who are as annoyed with this spamming as I am [ ... ] One is reminded of the old saw about not having to be faster than the bear, just faster than your hiking companion. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: spam emails from antonyjeyase...@gmail.com
I'm more impressed that my spam filter caught it and the only reason I known about it is this blowback complaint discussion. On Thu, 15 Apr 2010, Yoav Nir wrote: You have to admit, though, that sending spam in a link to Google docs is impressive. Shows real ingenuity and innovation from the spamming community. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Robert Stangarone Sent: Thursday, April 15, 2010 5:35 AM To: ietf@ietf.org Subject: spam emails from antonyjeyase...@gmail.com Today I see a second spam email from antonyjeyase...@gmail.com. Is it possible to remove him from the mailing list? Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
spam emails from antonyjeyase...@gmail.com
Today I see a second spam email from antonyjeyase...@gmail.com. Is it possible to remove him from the mailing list? Bob This mail originated from the whataboutbob.org domain. For any issues related to this mail, or the whataboutbob.org domain, contact supp...@whataboutbob.org Processed by .254 ---BeginMessage--- http://docs.google.com/View?id=dfs6wf29_14jj9n62dh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf This mail originated from the whataboutbob.org domain. For any issues related to this mail, or the whataboutbob.org domain, contact supp...@whataboutbob.org Processed by .25 ---End Message--- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: spam emails from antonyjeyase...@gmail.com
You have to admit, though, that sending spam in a link to Google docs is impressive. Shows real ingenuity and innovation from the spamming community. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Robert Stangarone Sent: Thursday, April 15, 2010 5:35 AM To: ietf@ietf.org Subject: spam emails from antonyjeyase...@gmail.com Today I see a second spam email from antonyjeyase...@gmail.com. Is it possible to remove him from the mailing list? Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
+1 John C Klensin пишет: +1 Well, OK. Let me rephrase my question: why do you believe that removing the IETF's MX record will a) decrease the amount of spam it receives? b) not damage its legitimate mail flow? Based on my experience and that of other people, neither is true. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
On 26 Feb 2010, at 16:45, SM wrote: At 20:11 25-02-10, Sabahattin Gucukoglu wrote: Discussion, please. See below for my take; the IETF is one host, MX is really meaningless, and there are benefits to avoiding a ton of spambot zombie spam. While we are on this topic, which of the following methods would you recommend for a point of contact: 1. mailto [1] [2] [7] [8] [10] [12] [13] 2. email address without mailto [9] 3. AT [3] 4. at [4] [11] 5. [5] 6. email address as an image [6] The only one I object to strongly is 6, and that's because I can't see it and nor can anybody using a textmode browser. Other than that, it makes sense to avoid spam by not doing 1 or 2, although I would sooner not hide from spammers by breaking functionality, which 2-5 implies. Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
there is an MX. Where did you get the idea that not having an MX offers protection from spambots? That's interesting, but not what I described. Well, OK. Let me rephrase my question: why do you believe that removing the IETF's MX record will a) decrease the amount of spam it receives? b) not damage its legitimate mail flow? Based on my experience and that of other people, neither is true. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
+1 --On Saturday, February 27, 2010 08:49 -0500 John R. Levine jo...@iecc.com wrote: there is an MX. Where did you get the idea that not having an MX offers protection from spambots? That's interesting, but not what I described. Well, OK. Let me rephrase my question: why do you believe that removing the IETF's MX record will a) decrease the amount of spam it receives? b) not damage its legitimate mail flow? Based on my experience and that of other people, neither is true. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
On 27 Feb 2010, at 13:49, John R. Levine wrote: there is an MX. Where did you get the idea that not having an MX offers protection from spambots? That's interesting, but not what I described. Well, OK. Let me rephrase my question: why do you believe that removing the IETF's MX record will a) decrease the amount of spam it receives? b) not damage its legitimate mail flow? Because, on inspection, both now and in the past, that is what it seems to do, for my personal domains. The difference in spam, and the apparent lack of lost mail, leads me to the conclusion that this small hack is worth the keeping, for now. Of course, I am more concerned about the lost mail, and I suspect that the IETF is more exposed to that possibility. In that case, it would be unwise. But it works for me, and given that it's in no way improper or non-standard, I don't see why it shouldn't for the IETF. Based on my experience and that of other people, neither is true. O.K. I must be very lucky indeed. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
MX records are the norm. There is even a constituency in the email ops community that believes use of A (and ) records should be deprecated. In any event, the kind of anti-abuse techniques that are predicated on having abusers be lazy or sloppy has, at best, short-term benefits, because the bad actors are quite good at adapting. d/ On 2/26/2010 12:11 PM, Sabahattin Gucukoglu wrote: Discussion, please. See below for my take; the IETF is one host, MX is really meaningless, and there are benefits to avoiding a ton of spambot zombie spam. Begin forwarded message: From: Glen via RTietf-act...@ietf.org Date: 25 February 2010 18:16:44 GMT To: m...@sabahattin-gucukoglu.com Subject: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam Reply-To: ietf-act...@ietf.org in-reply-to:30d38818-daa2-4439-a168-3aed6b3e0...@sabahattin-gucukoglu.com references:rt-ticket-24...@rt.ietf.org 30d38818-daa2-4439-a168-3aed6b3e0...@sabahattin-gucukoglu.com message-id:rt-3.6.5-24276-1267121804-1766.24364-...@rt.ietf.org rt-ticket: rt.ietf.org #24364 rt-originator: g...@amsl.com Thank you! Regrettably, we got many MANY complaints in the past from IETF community members who objected strongly to the absence of MX records. So although I personally feel as you do, I cannot make the suggested change at this time. Perhaps the spirit of things has changed. You are welcome to bring this up on the IETF list if you want, and to quote this response. Having been beaten down once, I'm not prepared to fight that battle again just yet. :-) Glen On Thu Feb 25 06:08:22 2010, m...@sabahattin-gucukoglu.com wrote: In the spirit of abiding by the rules we strive so hard to write ... :-) mail.ietf.org. is ietf.org., so you can remove your MX records for ietf.org. This should cut down on spam since a lot of spambots will skip over domains whose MX list cannot be obtained. Real mailers will of course fall back to A/ as per RFC 2821/5321. A few hosts will have trouble, but very, very few indeed, and that isn't your (our?) fault. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
mail.ietf.org. is ietf.org., so you can remove your MX records for ietf.org. This should cut down on spam since a lot of spambots will skip over domains whose MX list cannot be obtained. Real mailers will of course fall back to A/ as per RFC 2821/5321. A few hosts will have trouble, but very, very few indeed, and that isn't your (our?) fault. I checked with some people who run mail for a lot of domains, and they assure me that spambots will try to deliver to the A record even if there is an MX. Where did you get the idea that not having an MX offers protection from spambots? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
Hi Sabahattin, At 20:11 25-02-10, Sabahattin Gucukoglu wrote: Discussion, please. See below for my take; the IETF is one host, MX is really meaningless, and there are benefits to avoiding a ton of spambot zombie spam. While we are on this topic, which of the following methods would you recommend for a point of contact: 1. mailto [1] [2] [7] [8] [10] [12] [13] 2. email address without mailto [9] 3. AT [3] 4. at [4] [11] 5. [5] 6. email address as an image [6] Regards, -sm 1. http://www.ietf.org/secretariat.html 2. http://www.icann.org/en/announcements/announcement-18feb10-en.htm 3. http://www.iab.org/about/members.html 4. http://www.itu.int/ITU-T/othergroups/ipv6/ 5. http://www.iana.org/assignments/dns-parameters 6. http://www.rfc-editor.org/ 7. https://www.arin.net/announcements/2010/20100224.html 8. http://www.ripe.net/news/2010-be-heard.html 9. http://www.apnic.net/publications/news/2010/apnic-29-consultation 10. http://lacnic.net/en/anuncios/2010_lacnicxiii-becas.html 11. http://www.afrinic.net/press_release_le_050210.htm 12. http://isoc.org/wp/newsletter/?p=1567 13. http://www.un.int/wcm/content/site/portal ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
--On Friday, February 26, 2010 6:49 AM + John Levine jo...@iecc.com wrote: Discussion, please. See below for my take; the IETF is one host, MX is really meaningless, and there are benefits to avoiding a ton of spambot zombie spam. That's not a very good idea. I wouldn't count on zombies ignoring the IETF, nor would I count on there not being real MTAs that will hiccup if there's no MX. I've certainly seen filtering setups that view mail from domains without MX records with scepticism, since there would now be no techincal difference between mail from the IETF and mail from a bot-infected wifi printer. I very much agree with this statement. Not having an MX won't do a single bit of good against bots. In fact I'd argue the *opposite* case, that not having an A record does more. They definitely seem to deliver more often to the A rather than the MX. Having worked at and built a number of large hosting operations where the WWW servers (A records) would get *LOTS* of SPAM bot attempts. I'd argue not having an MX will cause far more problems with legitimate mail servers and e-mail activity. If you want to filter the spam, filter the spam like everyone else does. It's not rocket science. Don't set a bad example for the rest of the world. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
On 26 Feb 2010, at 05:19, Dean Anderson wrote: I get spam to hosts with MX records. I don't think removing MX records will have any effect on spam. Spambots, aren't fully autonomous agents I just transitioned my email host for a few small domains, and didn't trouble to bring along the MX records, because I didn't have to. I noticed the IETF didn't have to either, when it kept rejecting my IPv6 connections for not having Reverse DNS (fixed by preferring IPv4 for now). It's not the first time, and this technique is still damned effective. I added MX records just to reassure myself, and indeed I was being spammed at my usual 300/day level within almost half an hour of my name servers being updated. Now I'm waiting for the TTL to expire the record on caches. I'm convinced that is useful, anyway. Sure, it's a short-term hack (like all spam countermeasures), but it works. And why should we be afraid of standards compliance, in the very organisation that standardises? existing independently, they are programs written by people who want to conduct abuse for some purpose (annoyance, extortion, etc). The ones I'm talking about are distributed by viruses and trojan horses. They run on Windows, of course. They receive their instructions from the botmaster to spam a list of addresses with the spam content, and they do it directly using the MX resolution process. They barf when MX records fail to appear in a query result for MXs of a domain, for the most. Regarding the effect (if there even is one) of skipping domains without MX records, there are only two cases to analyze: Its either an oversight in the program, or its done on purpose. Even supposing their current programs skip domains without MX records by some oversight, the spambot programmers will easily fix that. Supposing the current programs skip domains without MX records on purpose, then do you really want to go along with whatever purpose that might be? I wouldn't. Spam is a social problem that cannot be solved by technical means to any degree of satisfaction; we only put up with the methods available because they're all we have. Every filtering technique other than manual inspection is subject to attacks, even the best ones, and as long as there's a gain in doing so that will continue to be the case. On that basis, even if there were something wrong with removing MX records for a single-host domain that just happens to be called ietf.org. and have aliases of mail and www, and I personally don't think there is apart from the possibility that it may lose some broken MTAs, it is a valid spam prevention technique until spammers take their dozy time (and, if we're honest, quite low cunning as well) to fix their agents, just as they do with every other kind of filtering out there. The IETF is one domain inhabited by a bunch of guys, so frankly I don't think it will be all that soon when so much of the world is happily being spammed to d eath on redundantly-hosted mail servers. And even if it isn't a silver bullet tomorrow, it's a useful metric nonetheless, just as graylisting was before it was totally failed and made blacklists the only way to use it conveniently. But I do find it noteworthy that the IETF doesn't even follow its own recommendations on email. The level of IETF spew, by which I mean telling other people what to do by issuing standards while not doing it themselves, grows more ever day. This incident is another discredit to the IETF, particularly to the leadership of the IETF or perhaps the IETF secretariat, that I will have to document at IETF watch. I want to say that I would *prefer* that MX records be published for host which *do not* receive mail. This is considerate since it allows mail originating from a host to be answered, or for postmaster to be reached. I also want to say that I am in support of the Purist point of view with regard to fallback since it allows any host with a name to be part of the SMTP infrastructure with no added configuration in DNS by properly using the semantics of addresses in DNS, before the use of MX muddied the waters sufficiently. There can therefore be no doubt that any software relying on the existence or not of MX records as license to *send* mail is broken since RFC 974. I don't want to start a debate on these points, at least outside of ietf-smtp, since in neither case does it wrong the secretariat with regard to the use or not of MX records, but I will say I have been a little bit surprised by the force of responses so far. I would be much obliged if the required work were done for clarifying any opposing view to current standards. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
Ever heard about not cross-posting and not feeding trolls? -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sabahattin Gucukoglu Sent: Friday, February 26, 2010 10:57 PM To: Dean Anderson Cc: ietf-hon...@lists.iadl.org; ietf-s...@imc.org; ietf@ietf.org; postmas...@ops.ietf.org Subject: Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org.,Remove MX Records For Less Spam On 26 Feb 2010, at 05:19, Dean Anderson wrote: I get spam to hosts with MX records. I don't think removing MX records will have any effect on spam. Spambots, aren't fully autonomous agents I just transitioned my email host for a few small domains, and didn't trouble to bring along the MX records, because I didn't have to. I noticed the IETF didn't have to either, when it kept rejecting my IPv6 connections for not having Reverse DNS (fixed by preferring IPv4 for now). It's not the first time, and this technique is still damned effective. I added MX records just to reassure myself, and indeed I was being spammed at my usual 300/day level within almost half an hour of my name servers being updated. Now I'm waiting for the TTL to expire the record on caches. I'm convinced that is useful, anyway. Sure, it's a short-term hack (like all spam countermeasures), but it works. And why should we be afraid of standards compliance, in the very organisation that standardises? existing independently, they are programs written by people who want to conduct abuse for some purpose (annoyance, extortion, etc). The ones I'm talking about are distributed by viruses and trojan horses. They run on Windows, of course. They receive their instructions from the botmaster to spam a list of addresses with the spam content, and they do it directly using the MX resolution process. They barf when MX records fail to appear in a query result for MXs of a domain, for the most. Regarding the effect (if there even is one) of skipping domains without MX records, there are only two cases to analyze: Its either an oversight in the program, or its done on purpose. Even supposing their current programs skip domains without MX records by some oversight, the spambot programmers will easily fix that. Supposing the current programs skip domains without MX records on purpose, then do you really want to go along with whatever purpose that might be? I wouldn't. Spam is a social problem that cannot be solved by technical means to any degree of satisfaction; we only put up with the methods available because they're all we have. Every filtering technique other than manual inspection is subject to attacks, even the best ones, and as long as there's a gain in doing so that will continue to be the case. On that basis, even if there were something wrong with removing MX records for a single-host domain that just happens to be called ietf.org. and have aliases of mail and www, and I personally don't think there is apart from the possibility that it may lose some broken MTAs, it is a valid spam prevention technique until spammers take their dozy time (and, if we're honest, quite low cunning as well) to fix their agents, just as they do with every other kind of filtering out there. The IETF is one domain inhabited by a bunch of guys, so frankly I don't think it will be all that soon when so much of the world is happily being spammed to d eath on redundantly-hosted mail servers. And even if it isn't a silver bullet tomorrow, it's a useful metric nonetheless, just as graylisting was before it was totally failed and made blacklists the only way to use it conveniently. But I do find it noteworthy that the IETF doesn't even follow its own recommendations on email. The level of IETF spew, by which I mean telling other people what to do by issuing standards while not doing it themselves, grows more ever day. This incident is another discredit to the IETF, particularly to the leadership of the IETF or perhaps the IETF secretariat, that I will have to document at IETF watch. I want to say that I would *prefer* that MX records be published for host which *do not* receive mail. This is considerate since it allows mail originating from a host to be answered, or for postmaster to be reached. I also want to say that I am in support of the Purist point of view with regard to fallback since it allows any host with a name to be part of the SMTP infrastructure with no added configuration in DNS by properly using the semantics of addresses in DNS, before the use of MX muddied the waters sufficiently. There can therefore be no doubt that any software relying on the existence or not of MX records as license to *send* mail is broken since RFC 974. I don't want to start a debate on these points, at least outside of ietf-smtp, since in neither case does it wrong the secretariat with regard to the use or not of MX records, but I will say I have been a little bit surprised by the force of responses so far. I would be much
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
On 26 Feb 2010, at 15:42, John Levine wrote: mail.ietf.org. is ietf.org., so you can remove your MX records for ietf.org. This should cut down on spam since a lot of spambots will skip over domains whose MX list cannot be obtained. Real mailers will of course fall back to A/ as per RFC 2821/5321. A few hosts will have trouble, but very, very few indeed, and that isn't your (our?) fault. I checked with some people who run mail for a lot of domains, and they assure me that spambots will try to deliver to the A record even if there is an MX. Where did you get the idea that not having an MX offers protection from spambots? That's interesting, but not what I described. To answer your question, you'd have to try that for yourself. I am now getting mostly phishes and scams, but very few member enhancement, expensive watches, wonder cures or viral mails. A few, of course - but not many. And yes, some of them are originated from PBL-listed addresses. Oh, and an IPv6-enabled foreign language spam or three. Lovely. The spammers have got there first. Brief and superficial inspection shows that the scams and phishes are submitted mostly via webmails and legit relays. I'm not sure why that is, though I have read stories about hijacked Internet cafes. Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
Discussion, please. See below for my take; the IETF is one host, MX is really meaningless, and there are benefits to avoiding a ton of spambot zombie spam. Begin forwarded message: From: Glen via RT ietf-act...@ietf.org Date: 25 February 2010 18:16:44 GMT To: m...@sabahattin-gucukoglu.com Subject: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam Reply-To: ietf-act...@ietf.org in-reply-to: 30d38818-daa2-4439-a168-3aed6b3e0...@sabahattin-gucukoglu.com references: rt-ticket-24...@rt.ietf.org 30d38818-daa2-4439-a168-3aed6b3e0...@sabahattin-gucukoglu.com message-id: rt-3.6.5-24276-1267121804-1766.24364-...@rt.ietf.org rt-ticket: rt.ietf.org #24364 rt-originator: g...@amsl.com Thank you! Regrettably, we got many MANY complaints in the past from IETF community members who objected strongly to the absence of MX records. So although I personally feel as you do, I cannot make the suggested change at this time. Perhaps the spirit of things has changed. You are welcome to bring this up on the IETF list if you want, and to quote this response. Having been beaten down once, I'm not prepared to fight that battle again just yet. :-) Glen On Thu Feb 25 06:08:22 2010, m...@sabahattin-gucukoglu.com wrote: In the spirit of abiding by the rules we strive so hard to write ... :-) mail.ietf.org. is ietf.org., so you can remove your MX records for ietf.org. This should cut down on spam since a lot of spambots will skip over domains whose MX list cannot be obtained. Real mailers will of course fall back to A/ as per RFC 2821/5321. A few hosts will have trouble, but very, very few indeed, and that isn't your (our?) fault. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
Discussion, please. See below for my take; the IETF is one host, MX is really meaningless, and there are benefits to avoiding a ton of spambot zombie spam. That's not a very good idea. I wouldn't count on zombies ignoring the IETF, nor would I count on there not being real MTAs that will hiccup if there's no MX. I've certainly seen filtering setups that view mail from domains without MX records with scepticism, since there would now be no techincal difference between mail from the IETF and mail from a bot-infected wifi printer. If you want to filter the spam, filter the spam like everyone else does. It's not rocket science. Don't set a bad example for the rest of the world. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Spam Filter Y2.1K Bug
On Sat, Jan 02, 2010 at 12:45:07PM -0800, Glen wrote: All - For those of you who may have experienced alcohol-related blackouts in the past 48 hours, please be advised that the year is now 2010. Good morning/day: I have received a surprising number of messages over the past 72 hours pointing out that the problem was not a Y2.1K bug, but rather a Y2.01K bug. In my defense... The problem in question surrounded a specific rule: FH_DATE_PAST_20XX . As you can see from the name of the rule, it is only supposed to hit email that was dated past 2099. However, it turns out that the rule was hitting all email past 2009. Because the rule had a base score of 20, which is well above the threshhold of 5 used by the IETF lists, almost every email sent was being tagged as Spam. ... so I was beguiled by the name of the rule, which clearly clouded by decimal-point-placement-judgement. Only in this community could I expect such overwhelming dedication to such precision. :-D I bow to the wisdom of the collective, and humbly acknowledge my decimal-point error. :-D On a more serious note... This problem exists globally, in all SpamAssassin installations worldwide, and doubtless will take days or longer for every IT department in the world to notice, research, figure out and fix. Until every SpamAssassin installtion in a user's chain of email is fixed, some email will continue to be incorrectly tagged as Spam for many of you. However, THIS PROBLEM HAS BEEN FIXED AT AMS, and was fixed as of January 1. What I did, on January 1, in the late evening, was to apply a new score rule: SCORE FH_DATE_PAST_20XX 0 This effectively disabled that rule, so that 2010 mail would no longer be tagged as Spam. I've gotten several reports this morning that mail to some lists is still being tagged as Spam. I've taken extra steps, such as resetting the autowhitelist system built into SpamAssassin, to try to bring things back to normal. In the meantime, SpamAssassin may have additional problems or interactions we haven't discovered yet, and I will be working with list moderators to identify and analyze any other spam filtering issues that may be present. One thing that often happens is that people reply to a message, but they don't end up removing the SPAM wording from the Subject. Therefore, that wording can be preserved through the thread and sent back and forth through the list. This does not indicate that the spam system here is still broken, this only indicates that people are resending the spam tagging in the Subject line, by hitting reply and not editing the subject. Please be mindful of this if it occurs. A happy new year - which is NOT a new century! - to you all. Glen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Spam Filter Y2.1K Bug
All - For those of you who may have experienced alcohol-related blackouts in the past 48 hours, please be advised that the year is now 2010. This is relevant for many reasons, one of which is that there appears to be a bug in SpamAssassin, one of the spam filtering programs used on our servers. A particular rule that checks the date of messages with the purpose of finding messages that are far in the future apparently does NOT know that the year is 2010. As a result, as of yesterday morning, this rule started to be applied to all mail processed by SpamAssassin installations worldwide, resulting in a significant increase in legitimate mail being incorrectly tagged as Spam. The rule in question was designed to find mail that was extremely off-date, and, therefore, the rule had a very high default score, which would push tagged mail well over all reasonable spam thresholds. This bug affects everyone, and has been documented everywhere: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269 et al. I found this problem in my own mail yesterday evening, and removed that rule from all of our servers at that time. However, from 00:01 until about 19:30 Pacific time January 1, some legitimate mail sent through our servers may have been incorrectly tagged as spam. Please check your spam folders, mailing list moderation queues, and other relevant locations to ensure that any held mail gets found and released. If you sent mail through our servers, and it did not go through, you may wish to simply send it again. The rule has been cleared, and mail is flowing normally once again. You may wish to notify your clients and/or associates about this problem. As this is a global problem, you should consider checking all mail servers you have interaction with, worldwide, until this gets fixed. Happy new year. Glen Glen Barney IT Director AMS ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Spam Filter Y2.1K Bug
All - For those of you who may have experienced alcohol-related blackouts in the past 48 hours, please be advised that the year is now 2010. This is relevant for many reasons, one of which is that there appears to be a bug in SpamAssassin, one of the spam filtering programs used on our servers. A particular rule that checks the date of messages with the purpose of finding messages that are far in the future apparently does NOT know that the year is 2010. As a result, as of yesterday morning, this rule started to be applied to all mail processed by SpamAssassin installations worldwide, resulting in a significant increase in legitimate mail being incorrectly tagged as Spam. The rule in question was designed to find mail that was extremely off-date, and, therefore, the rule had a very high default score, which would push tagged mail well over all reasonable spam thresholds. This bug affects everyone, and has been documented everywhere: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269 et al. I found this problem in my own mail yesterday evening, and removed that rule from all of our servers at that time. However, from 00:01 until about 19:30 Pacific time January 1, some legitimate mail sent through our servers may have been incorrectly tagged as spam. Please check your spam folders, mailing list moderation queues, and other relevant locations to ensure that any held mail gets found and released. If you sent mail through our servers, and it did not go through, you may wish to simply send it again. The rule has been cleared, and mail is flowing normally once again. You may wish to notify your clients and/or associates about this problem. As this is a global problem, you should consider checking all mail servers you have interaction with, worldwide, until this gets fixed. Happy new year. Glen Glen Barney IT Director AMS ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: [SPAM] Re: Last Call: draft-iana-ipv4-examples (IPv4 Address Blocks Reserved for Documentation) to Informational RFC
On 29/08/2009, at 2:50 PM, Jari Arkko wrote: I'd like to push back a little on this. My personal preference is a specification style which makes everything very explicit. If a block has been used for examples, I think we owe it to the reader to say what its fate was. I do agree though that we should not set a precedent that every block not listed in RFC 3330(bis)* needs to be explicitly mentioned or else they are still somehow reserved. But maybe there is a way to write the text that this becomes clearer. How about this: Note that 128.66.0.0/16 has been used for some examples in the past. However, this role was never specified formally and RFC 3330 confirmed that this block has no special role by not listing it. I'm not sure if its push back or working though to an acceptable consensus in wording that does not set a precedent. I think its a case of the latter, and this wording certainly works for me. regards, Geoff ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [SPAM] Re: Last Call: draft-iana-ipv4-examples (IPv4 Address Blocks Reserved for Documentation) to Informational RFC
Geoff, Is everyone happy with this course of action? works for me Good. I would avoid this - the problem is that if a future rfc3330 revision drops another block from the reserved set, then this raises the question of if you really meant it if the explicit documentation is missing. I'd like to push back a little on this. My personal preference is a specification style which makes everything very explicit. If a block has been used for examples, I think we owe it to the reader to say what its fate was. I do agree though that we should not set a precedent that every block not listed in RFC 3330(bis)* needs to be explicitly mentioned or else they are still somehow reserved. But maybe there is a way to write the text that this becomes clearer. How about this: Note that 128.66.0.0/16 has been used for some examples in the past. However, this role was never specified formally and RFC 3330 confirmed that this block has no special role by not listing it. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
More anti-spam (was: Re: several messages)
--On Wednesday, 12 November, 2008 12:40 -0800 David Romerstein [EMAIL PROTECTED] wrote: [roughly 37 bajillion To: addresses removed] On Wed, 12 Nov 2008, Dean Anderson wrote: On Wed, 12 Nov 2008, David Romerstein wrote: If they don't notice the dropped subscription, I'd say they're not negatively impacted. Hmm. Wonder if you'd say the same if it was your bank account, or your house robbed: Gee your honor, I waited and waited, and nobody noticed, so it must be ok to take his money and possessions. You do realize that, in this context, your 'argument' makes no sense, right? The point is that, someday, long after the opportunity to participate has passed, they find out they've been dropped. I'm on many mailing lists. I participate in all of them. I am aware of the approximate volume of mail I get from them everyday, at least by orders of magnitude. If a list that normally sees 20-30 emails a day doesn't have any for a day, I'm likely to start investigating. That may make me unusual; based on my experiences blocking spam at A Large ISP several years ago, though, I suspect that I am not. People complain to their postmasters *vociferously* when expected mail is not received, and that shows that those emails have value to them. David, I'm on many mailing lists, at several different addresses. Many of them, including some IETF ones, operate in start-and-stop mode, i.e., it is a common pattern for there to be a large volume of messages over a short period of time, then nothing for weeks. Requiring that I notice when I am not being sent mail from one of those lists borders on the absurd. I also have arrangements with various financial institutions who send out alerts under a variety of circumstances. If things are normal, I see no alerts, ever. Expecting that I notice non-receipt of a message from them that is intended to give me timely notification of an event borders on the ludicrous. Expecting that I notice non-receipt of a revised prospectus or proxy statement is almost equally problematic. Then there is the mailing list case you advocate in which the sender to the list, or the list maintainer, is expected to use an out-of-band (non-email) mechanism, such as a phone call, to tell the end user that something didn't go through. In addition to the obvious privacy concerns (I don't know who is on the IETF list, have no way to find out, and, if I did find out, might not be able to match addresses to people and their other contact information and identity credentials) this comes close to requiring authentication of those who subscribe to email lists, even if they merely watch the list but don't ever post. I've got some fairly severe problems with that idea. I note that it is not even a requirement for postal mail: e.g., if I subscribe to a newsletter you operate that is distributed through the post, and give a post office box address, in the US it is a felony for someone at the post office to supply you with my other contact information (to save Dean, with whom I usually disagree on these matters, the trouble), it is also a felony if someone decides that they don't like me or my sanitary habits, and, on that basis, refuses to deliver mail addressed to me. While I'm not a fan of RBLs, I still see the debate about their usability as being one of tradeoffs (and the debate about whether a few ASIRG documents should be standardized as about IETF operational philosophy and procedures much more than about the specific content of those documents). But, when you or others start making arguments that sound like a few false positives and consequent lost mail are ok, and especially if you also take the position that such messages are the expected recepient's fault (or at least exclusively that recipient's problem), then I stop seeing tradeoffs and start seeing a much more severe threat to the Internet's mail environment than that posed by the spammers. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
Hi Matthew, --On September 10, 2008 3:13:33 PM -0700 Matthew Elvey [EMAIL PROTECTED] wrote: Lisa D reported being told: There is strong WG consensus behind [-07]. Lisa D specifically claimed the WG chairs indicated there was. CHAIRS: Can you each please confirm that you stated that there is strong WG consensus behind [-07]? Yes, I can confirm that and firmly believe that the overall consensus of the WG is to publish the -07 draft. I don't believe there is a need to re-poll the WG on this, but if the IESG would be more comfortable doing so given your comments I am happy to do so. Also, if other WG participants wish to speak up in support of one position or another right now, they are certainly free to do so. The history of this effort is quite clear in my opinion. The WG decided to enhance the existing 3028 reject command to allow use of reject behavior at SMTP/LMTP protocol time. At the moment I believe your main point is that you want the spec to mandate that ereject MUST only result in SMTP/LTMP protocol rejection and indeed that all implementations must support protocol level rejection. On the several occasions you have brought this issue to the WG mailing list it has been explained in detail that there are plenty of key use cases where only doing SMTP protocol rejection is not possible (e.g. in the very common case where there are multiple recipients of the message and one recipient's script erejects, whilst another does not). I think the current wording in the -07 spec is perfectly clear that implementations must make every effort to do protocol level rejection whenever possible. For example, the first section of 2.1.1 states: Sieve implementations that are able to reject messages at the SMTP/ LMTP level MUST do so and SHOULD use the 550 response code. Also, section 2.1 states: The ereject action MUST NOT be available in environments that do not support protocol level rejection I think those are pretty strong statements about the use of ereject and protocol level rejections. I don't see why or how these need to be changed. Unfortunately, claiming that the current specification results in a spam-friendly RFC is going to anger a lot of people who have spent a lot of time trying to address spam issues as best as possible. It totally misrepresents the efforts of the SIEVE WG. I realize, Matthew, that you have very strong opinions on this, but I fear such comments are not going to result in forward progress. If you feel that the IETF needs to publish a document stating that all email systems MUST support protocol level rejections (which I think is what you want to require of all implementors), then I suggest that you publish a new I-D to do just that and garner support for moving that forward in the IETF. At this point I consider WG consensus to be for publishing -07 - albeit with the various comments from IETF last call appropriately addressed by the authors. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
Matthew Elvey writes: If a system implementing the specs we're working on works on a store-and-forward basis, then it MUST NOT MISLEAD, i.e. LIE TO ITS USERS by claiming to support the enhanced standard we are writing. -07 allows an implementation to mislead its users by claiming to support enhanced functionality when it does no such thing. Why not? My code (I implemented -07 a few weeks ago) advertises support for the standard even if it may or may not provide enhanced functionality. I think that's fine. It does provide in-protocol rejection when possible, and the rules have very pleasant consequences. Most importantly, it's possible to make system configuration changes that affect system's ability to to in-protocol rejection without invalidating anyone's sieve script. That would simply be dishonest. It's just another RFC about best-effort something something. There are many others already, so most implementers are familiar with the concept. And AFAICT, implementers generally implement a best effort, not behave dishonestly. (I read some more of this monster mail, but IMHO it degenerates into a pure rant around the point where Aaron Stone is first called «the author of -07». Not worth answering.) Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
Hi. A little additional perspective on this from someone who has (deliberately) not been active in the SIEVE effort. Cyrus has alluded to some of this, but the real constraint is with SMTP, not SIEVE, and should be addressed in the SMTP context. The issue of NDN blowback has come up repeatedly in discussions of SMTP. The bottom-line answer, despite complaints from zealous anti-blowback advocates and clever alternate readings of the spec, is that the SMTP model simply doesn't work without the possibility of non-delivery messages. While there are other issues, the most important and obvious of them is that SMTP permits and encourages multiple-recipient messages and has no in-protocol mechanism for returning per-recipient replies. In theory, that problem could be overcome with an SMTP extension for per-recipient replies. There is a long-expired I-D that discussed doing just that, but it never got an traction (and may or may not have been the best way to do it). However, while per-recipient responses have other advantages, there is no reason to assume that spammers would voluntarily make their lives more difficult by invoking such an extension. Conversely, the blowback problem could be solved in principle by authenticating message senders (probably beyond their authorization to send mail, which is more or less the problem to which DKIM and SPF are addressed). But there is again a deployment problem unless one assumes that legitimate deployed SMTP implementations can be changed in only a short period of time. See http://www.rhyolite.com/anti-spam/you-might-be.html#senior-IETF-member-5 and the surrounding context for further discussion on that issue. The bottom line is that a debate about prohibiting SIEVE from returning NDNs is meaningless without changes to SMTP. We don't have any proposals on the table for such SMTP changes and don't know how to get from here to there with any of the proposals that have been made.I guess that makes this I-D a more tempting target, but it still does not make it relevant. If the SIEVE WG somehow decided that it liked one of the proposals for suppressing the possibility of NDNs, we would then be having a discussion about whether or not that WG is permitted to write a spec that requires violations of SMTP. Fortunately, they did not present us with that choice. best, john --On Thursday, 11 September, 2008 10:38 -0400 Cyrus Daboo [EMAIL PROTECTED] wrote: Hi Matthew, --On September 10, 2008 3:13:33 PM -0700 Matthew Elvey [EMAIL PROTECTED] wrote: Lisa D reported being told: There is strong WG consensus behind [-07]. Lisa D specifically claimed the WG chairs indicated there was. CHAIRS: Can you each please confirm that you stated that there is strong WG consensus behind [-07]? Yes, I can confirm that and firmly believe that the overall consensus of the WG is to publish the -07 draft. I don't believe there is a need to re-poll the WG on this, but if the ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
I had hoped to be able to stay out of this discussion, but repeated references to me and to Sun's Sieve implementation, many of them inaccurate and some fairly disparaging, have created a situation where it seems I have no choice but to respond. I tried writing a point by point response to Mr. Elvey's latest message but soon gave up - it's just too long and a point by point response is too confusing. So what I'm going to do instead is try and give my view of how we got here, where we are, and what I think should happen now. The base specification for the Sieve language was first published in January 2001 as RFC 3028. In addition to defining the core language, this document also specified several extensions, most notably the reject extension, used to reject messages around the time of final delivery. Reject as specified in RFC 3028 was _required_ to return a Message Disposition Notification, or MDN. (MDNs were themselves defined in RFC 2298, now obsoleted by RFC 3798.) This choice was made in order to facilitate implementation of reject in MUAs. Sun's initial implementation of Sieve included support for reject as defined in RFC 3028. But because use of reject necessarily creates additional message traffic, and more specifically when used to deal with joe-jobs can itself be a source of blowback spam, Sun's filtering GUI did not offer an out-of-the-box option for users to specify use of reject. We have also pushed back hard on any suggested use of reject to deal with spam. However, several of our customers found other legitimate uses for reject. For example, one fairly popular use case is to use Sieve for processing workflows in email: When invalid messages are found reject is the method of choice to inform the sender of the problem. (Note that ingress filtering on such setups is invariably extremely strict so there's essentially no risk of reject being applied to spam.) Silently discarding messages, as the discard action would do, is unacceptable in this case - the sender has to be informed of what happened and why. An especially important aspect of such usage is the ability to report errors in languages other than i-internet. This is something that cannot be done using SMTP-level errors because SMTP currently lacks any internationalized error response facility. When work began on revising the Sieve base specification (now published as RFC 5228) there was a lot more concern over the blowback aspects of reject, so much so that the WG decided to move the extension from the Sieve base to this separate specification. Various choices were available to the WG, ranging from deprecating the extension in toto, changing or enhancing how it worked, defining a replacement extension, or even leaving it is-as. As part of the ensuing discussion I attempted to explain the situation Sun found itself in: Sun's customers have literally tens of millions of end users, if not more, many if not most of whom are using Sieve (although the vast majority are completely insulated from the underlying technology by a GUI interface and are therefore unaware that Sieve is involved). We know that some number of these are using reject for purposes other than dealing with spam and who depend on its ability to return properly internationalized error messages. Exactly how many, we have no way of determining. Accordingly, we cannot and will not abandon customers that depend on these facilities, irrespective of what the IETF says about it. If, for example, the WG had decided to eliminate reject completely, we probably would have done is add an option to enable or disable reject support so sites could then choose whether or not to comply. Similarly, a substantial change in reject semantics would probably have caused us to add some sort of mode setting option. And so on. I laid all of this out in a message to the WG list back in 2006: http://www.imc.org/ietf-mta-filters/mail-archive/msg03336.html This was at a point when the proposal under discussion was to completely change reject semantics and ban the use of MDNs entirely. I attempted to explain Sun's situation and how we would deal with such a change. I also attempted to make a case for preserving existing reject semantics because I believed then, and continue to believe now, that there are legitimate uses for it that have nothing to do with spam. After much discussion, what the WG eventually decided to do in this document was essentially to (1) Loosen the rules around reject so as to allow the use of SMTP-level errors when possible and (2) Define a new extension, ereject, which requires the use of SMTP-level errors in all cases where it is possible to use them. I believe this to be a reasonable approach. Moreover, once it became clear where all this was headed I proceeded to updaate Sun's implementation. Here's how things currently stand for us: (1) Sun's implementation has always operated exclusively at the SMTP level prior to final delivery. We have always performed
Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard
This is an argument opposing the proposal to have the IETF's IESG make draft-ietf-sieve-refuse-reject-07 a Proposed Standard (i.e. RFC). Sieve is widely used for email processing; it competes with procmail and other rules-processing systems. My reason for opposing -07 and drafting and supporting -08 is this: In plain English, the specification up for vote (-07) allows compliant email system implementations to continue to be a source for vast amounts of spam, while the current draft (-08) does not. Support for ereject (in the form of a successful require [ereject]) MUST be a clear message to users that the implementation used actually is a modern implementation that successfully avoids sending floods of unsolicited MDNs (spam) by rejecting messages during the SMTP transaction (instead of accepting them and then sending MDNs back to the alleged sender) wherever possible, thereby reducing the backscatter problem. If a system implementing the specs we're working on works on a store-and-forward basis, then it MUST NOT MISLEAD, i.e. LIE TO ITS USERS by claiming to support the enhanced standard we are writing. -07 allows an implementation to mislead its users by claiming to support enhanced functionality when it does no such thing. That would simply be dishonest. Archaic implementations are free to support the old SIEVE - RFC 3028. -07 needs to be rectified so that the intro from earlier versions remains true: This document updates the definition of reject to require rejecting messages during the SMTP transaction (instead of accepting them and then sending MDNs back to the alleged sender) wherever possible, thereby reducing the problem. (Where 'possible' does NOT include the case where the reject string is one that cannot be sent during the SMTP transaction.) I wonder if Ned and I have argued past each other. AFAICT Ned is arguing that he/Sun must be allowed to continue to send unsolicited MDNs (even when the reject string is ASCII, and there is one recipient) e.g. when Sun's server is used with someone else's LMTP server. And yet he claims that I'm misrepresenting his implementation and the reasoning behind it. (It's hard to know what he thinks, as he repeatedly avoid answering my questions.) Ned acts like saying that I'm against allowing Japanese users to fall back to out-of-transaction rejects when non-ASCII reject strings need to be used. I'm not. Look at the drafts I wrote! They don't do that! Obviously, a developer cannot control how his product is deployed by a customer. Consider a Sieve implementation within an SMTP server that is hidden behind a store-and-forward SMTP proxy; call this whole system B. It's beyond the control of the developer of SMTP server software to prevent a customer from creating a system like B. Any SMTP server can be hidden thus. However, as authors of the Sieve implementation, we can specify what it can and cannot be connected to. We specify how and when SMTP servers deliver their messages to recipients, by transmitting the messages only to specified systems, after all. Naysayers say otherwise, but provide no argument. What I am trying to restore is the demand that a)any SMTP (or LMTP) server software implementing this Sieve extension be capable of performing in-transaction ereject and b) that if such software is incorporated into a larger system by a customer, that that customer not claim that that system, if it is like B, supports ereject, because that would be dishonest. The software should cause require [ereject] to fail in such a case, either because of a configuration option the the customer sets (truthfully, one hopes) or by detecting that it has been deployed in such a system, or a combination (e.g. a smart installation script could poke around and if appropriate, ask: You appear to have installed this system behind a store-and-forward SMTP proxy; therefore it cannot support the Sieve ereject action. Accept this configuration? [Yes]/No. This would ensure that the system does not LIE TO ITS USERS. It would alert the customer to the issue, perhaps leading them to abandon the store-and-forward system for a modern one. Tim Polk just mentioned I would encourage the authors to add a brief discussion describing why rejecting messages before delivery is better than accepting and bouncing them. There was such a discussion in an earlier draft. It was removed by the author of -07. I've restored it in -08 (which I'm about to submit to the queue). Tim also says Consider noting that silent discard of legitimate messages constitutes denial of service and that determination of a forged return-path should be performed very carefully. This is true. Likewise, sending MDNs containing spam and viruses also has security implications. Both need to be mentioned. I believe all the nits and other issues that have been raised need to be addressed; a WGLC and LC are also needed. I think
Re: Strong Opposition due to spam blowback issues - Re: Last Call: draft-ietf-sieve-refuse-reject
On Aug 13, 2008, at 11:16 PM, Matthew Elvey wrote: Hi. I have a court-imposed filing deadline to meet of Aug 31 (See www.caringaboutsecurity.wordpress.com and/or www.elvey.com/spam/70-ORDER-GrantingElveyLeaveToFileMemorandumExplainingObjections.pdf - it's apropos my representation of 6 million TD Ameritrade customers in an Identity Theft Class Action lawsuit) and am working and going camping this month as well, so I anticipate being unable to respond this month. If you would wait 'till the first September telechat, please. Will you do that? I can do that. I will state that I don't believe your characterization of the WG view is accurate, or appropriate. There was WG rough consensus earlier versions of the draft which, unlike the current one, would not knowingly exacerbate the spam problem. There was not much evidence of either broad support for or opposition to the current draft in the WG. Who do you count as having expressed being in consensus. I asked the WG chairs. If you question their evaluation, the appropriate thing for the chairs to do is to make an explicit call for consensus (they are following this discussion of course). The appropriate thing for you to do, independent of what the chairs do, is make your case and ask people to speak up to agree with you. More on making that case below... *ECONOMICS* There's a strong economic incentive for those behind implementations that would require a lot of work to fix to make a concerted effort to actively support weakening the standard. The economic costs due to the blowback are very diffuse - spread out over most of the Internet-using population, in contrast to the concentrated, but IMO relatively small cost of fixing the archaic implementations... I'm all for considering economic efficiency, but both sides need to be weighed and weighed fairly Can you make or point to arguments (perhaps you've posted them to the SIEVE list already) about why the changes weaken the standard? Another point that needs a little more explanation is why the original design would be more expensive to implement than the current requirements, although implementation costs aren't always the same across implementations anyway. Then we might be able to get to the economic arguments. At this point your economic arguments are impugning the motives of strawman opponents rather than addressing the fitness of the proposed RFC. You do/did do work for Sun, right? Seems like there's the appearance of a conflict of interest to me. Note: I'm not accusing you of anything; I'm just saying that there seems to be a conflict of interest, and you did request the Last Call and characterize the WG views. I do not and have not worked for Sun. I requested the Last Call in order to get input about the fitness of this document as a proposed RFC, which is standard practice, as I'm the Advising Area Director for the SIEVE WG and process all the documents of that WG. I did a personal review before requesting the Last Call. I did not, and still do not, see how this knowingly exacerbates the spam problem -- in fact it encourages servers to reduce backscatter, itself a form of spam. Lisa -Matthew On 8/7/08 6:44 PM, Lisa Dusseault wrote: Hi, I'm on vacation next week so I haven't put this document on the Aug 14 IESG telechat. The Aug 28 telechat is the next opportunity for IESG Evaluation. That timing gives you three weeks before the first possible decision on the document. The WG considered your arguments in the past year, so presumably new arguments, a fleshed-out compromise proposal, or an IETF-wide consensus would be needed to sway or overrule the WG. I understand the frustration of having work you initiated and contributed to taken in a direction you do not like, but that in itself isn't an argument against the WG's decision. I look forward to your alternative proposal. Thanks, Lisa On Aug 7, 2008, at 12:09 PM, Matthew Elvey wrote: Hello. I am the original author of this I-D. I am strongly opposed to the document in its current form (-07). I wrote the original draft primarily to address the backscatter problem* from Sieve implementations that I worked with, problems the creation of which was mandated by the original Sieve specification. I wrote (with assistance from Alexey Melnikov) several drafts, which effectively addressed my concerns. Versions that accomplished the goal that motivated the whole effort were developed that were entirely adequate for becoming an RFC-level standard, however bitrot set in, along with an effort to simplify the base specification which created a need for significant changes.  They also received a stronger level of support than -07. I will be introducing and arguing for a revision subsequent to the current -07 draft to address the concerns I have raised on-list, and request
Re: Strong Opposition due to spam blowback issues - Re: Last Call: draft-ietf-sieve-refuse-reject
Hi. I have a court-imposed filing deadline to meet of Aug 31 (See www.caringaboutsecurity.wordpress.com and/or www.elvey.com/spam/70-ORDER-GrantingElveyLeaveToFileMemorandumExplainingObjections.pdf - it's apropos my representation of 6 million TD Ameritrade customers in an Identity Theft Class Action lawsuit) and am working and going camping this month as well, so I anticipate being unable to respond this month. If you would wait 'till the first September telechat, please. Will you do that? I will state that I don't believe your characterization of the WG view is accurate, or appropriate. There was WG rough consensus earlier versions of the draft which, unlike the current one, would not knowingly exacerbate the spam problem. There was not much evidence of either broad support for or opposition to the current draft in the WG. Who do you count as having expressed being in consensus. *ECONOMICS* There's a strong economic incentive for those behind implementations that would require a lot of work to fix to make a concerted effort to actively support weakening the standard. The economic costs due to the blowback are very diffuse - spread out over most of the Internet-using population, in contrast to the concentrated, but IMO relatively small cost of fixing the archaic implementations... I'm all for considering economic efficiency, but both sides need to be weighed and weighed fairly You do/did do work for Sun, right? Seems like there's the appearance of a conflict of interest to me. Note: I'm not accusing you of anything; I'm just saying that there seems to be a conflict of interest, and you did request the Last Call and characterize the WG views. -Matthew On 8/7/08 6:44 PM, Lisa Dusseault wrote: Hi, I'm on vacation next week so I haven't put this document on the Aug 14 IESG telechat. The Aug 28 telechat is the next opportunity for IESG Evaluation. That timing gives you three weeks before the first possible decision on the document. The WG considered your arguments in the past year, so presumably new arguments, a fleshed-out compromise proposal, or an IETF-wide consensus would be needed to sway or overrule the WG. I understand the frustration of having work you initiated and contributed to taken in a direction you do not like, but that in itself isn't an argument against the WG's decision. I look forward to your alternative proposal. Thanks, Lisa On Aug 7, 2008, at 12:09 PM, Matthew Elvey wrote: Hello. I am the original author of this I-D. I am strongly opposed to the document in its current form (-07). I wrote the original draft primarily to address the backscatter problem* from Sieve implementations that I worked with, problems the creation of which was mandated by the original Sieve specification. I wrote (with assistance from Alexey Melnikov) several drafts, which effectively addressed my concerns. Versions that accomplished the goal that motivated the whole effort were developed that were entirely adequate for becoming an RFC-level standard, however bitrot set in, along with an effort to simplify the base specification which created a need for significant changes.  They also received a stronger level of support than -07. I will be introducing and arguing for a revision subsequent to the current -07 draft to address the concerns I have raised on-list, and request that the IESG not make a decision in less than a few weeks so I have a chance to do so and receive feedback. Recent versions have been a fundamental departure from the versions that have Alexey and I listed as coauthors, and pervert the goal of the standard I initiated. I do not believe the IETF wants to be known for knowingly exacerbating the spam problem, in particular the backscatter problem, and I belive adoption of -07 does that by endorsing a practice and architecture that does so, i.e. the archaic store-and-forward, instead of the modern 'transparent SMTP proxy'** architecture. *http://en.wikipedia.org/wiki/Backscatter_(e-mail) **http://en.wikipedia.org/wiki/Transparent_SMTP_proxy On 7/27/08 8:02 AM, The IESG wrote: The IESG has received a request from the Sieve Mail Filtering Language WG (sieve) to consider the following document: - 'Sieve Email Filtering: Reject and Extended Reject Extensions ' draft-ietf-sieve-refuse-reject-07.txt as a Proposed Standard This document has a normative reference to RFC 2033 which documents LMTP, Local Mail Transfor Protocol. Support for LMTP is not required for servers supporting the mechanisms in this specification. The procedure of RFC 3967 is applied in this last call to approve the downward reference. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-08-10. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject
Re: IESG Statement on Spam Control on IETF Mailing Lists
Hi Cullen, On 2008-04-16 00:01 Cullen Jennings said the following: Hi Henrik, Seems this email about email still needs some more discussion - I have not been involved much with this much but I suspect that Chris Newman would probably be the best person on the IESG to work with on both clarifications and changes. Ok, I'll contact Chris off-list. Henrik signature.asc Description: OpenPGP digital signature ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
-- On Tuesday, April 15, 2008 11:36 PM +0200 Frank Ellermann [EMAIL PROTECTED] wrote regarding Re: IESG Statement on Spam Control on IETF Mailing Lists -- | As a service to the community, the IETF Secretariat | operates a mailing list archive for working group | mailing lists. Most lists I submitted to the other lists are in fact former WG lists. I guess there is nothing to do for the submitter / AD / list owner for former IETF WG lists, the official archives are likely still subscribed. I would suggest that there needs to be a back-office process in place to ensure that when a working group (or BOF or any other list) shuts down, the IETF should make sure it has a copy of the complete archive. This does not currently exist. Maybe the two archive subscriptions could be added to the verification procedure. As far as I can tell it the Web form creates a request to the chosen AD, the AD can then accept, reject, or ignore it. The accept state could be split to arrange the archive subscriptions. Lots of fun there, but there aren't many other list, and most have a mailman Web interface. Which web form are you referring to? I think what you're talking about is the one for the web page that lists other lists. If that's true, I agree, there should be a back-office process that checks the archive subscriptions before (perhaps in parallel) with the list getting listed on the other lists web page. Of course this does not address the maintenance issue of keeping the subscription live If you're talking about the mailing list request form, that's for getting a list hosted at ietf.org so the archives are not an issue in that case. Or did you mean some other form? My opinion is that the IETF should just create a mailing list for every WG and then these other lists should just subscribe the IETF list to their list. The opposition can then still pretend to send mail from the old list to the new list, and vice versa. The position of the gateway on the IETF side (directly above the archives vs. before the new list) won't necessarily change the spam problem. But what it facilitates is using the same mechanisms in the same way to control the SPAM problem. It is an operational simplification that obviates a bifurcation. Instead of a message coming in, getting tagged by SpamAssassin and then having to be directed either to an archive or Mailman, it always goes to Mailman. The SPAM filtering is already part of Mailman. If it goes to the archive you have to add a module or function to do the SPAM filtering that Mailman does. Mailman provides some useful built-in features. Unfortunately it doesn't let me say for each subscribed [EMAIL PROTECTED] add a new address [EMAIL PROTECTED], it also doesn't let me say now please consider [EMAIL PROTECTED] to have write access on all existing lists. Well, I'm not exactly a Mailman expert but I believe these features are relatively straightforward to do if you are the Mailman site administrator and have shell access to the server. Therefore, an ambitious person could setup a web interface to support them. :-) Jim ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
James Galvin wrote: Or did you mean some other form? Yes, not the request list form, I've never used it. I meant IETF - lists - note well - other lists - non-WG - non-WG posting page (five clicks deep ;-) https://datatracker.ietf.org/list/nonwg/update/ - step 1 add new entry - proceed - step 2 **THIS**. [gateway old - new list instead of list - archive] what it facilitates is using the same mechanisms in the same way to control the SPAM problem. It is an operational simplification that obviates a bifurcation. If it obviates bifurcation I didn't get what you were talking about. Maybe you want to *replace* the old list elsewhere by a new list at ietf.org, preserving only the subscriptions. IME moving lists or groups, just renaming them, is a guaranteed way to lose 80% of all readers forever, and annoying a significant part of the rest. The other lists have owners, why should they hand over their list to the IETF ? Change as much as lists.ietf.org to ietf.org and it will cause havoc somewhere, and months to figure out what's broken. As an example, from my POV two review lists are dead, and I will dump review requests directly to iesg@ or whatever it takes to get them on public record (it's a formal thing, tried to send is not good enough ;-) Frank ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
On 2008-04-15 05:12 Ned Freed said the following: On 2008-04-15 00:35 Ned Freed said the following: On 2008-04-14 23:11 Ned Freed said the following: I guess I should be flattered, but really, I fail to see why. Guaranteed bypass of moderation is simply an allowed-poster whitelist. So it seems to me that you've failed to see the problem. Anybody who considers themselves a valid poster is supposed to be able to bypass moderation, challenge-response and spam-filtering. I see nothing in the requirements that says this supposed to be possible as a unilateral action on the part of the poster. That's clearly preposterous - it should go without saying that whitelisting arrangements are just that: Arrangements. The requirements leave open how such arrangements are made; IMO that's entirely appropriate. This would also include a spammer who considers himself a valid poster. At the same time, the IETF lists MUST provide spam control. I see this as a contradiction in the announced text. Only if you engage in a VERY creative reading of what's there. As has been painfully clear for some email round-trips, we obviously don't agree. Henrik ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
Having a single system for all WG lists has the appeal that whatever process(es) handle the lists, it will be the same for all lists, so you don't have to figure out how N different lists are run. As a shameless plug, we have a free open source solution developed here which is widely used against spam/viruses and that could do the job, see http://www.mailscanner.info/ -- Tim ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
- Original Message - From: IESG Secretary [EMAIL PROTECTED] To: IETF Announcement list [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, April 14, 2008 5:39 PM Subject: IESG Statement on Spam Control on IETF Mailing Lists The following principles apply to spam control on IETF mailing lists: * IETF mailing lists MUST provide spam control. And what is spam? I have seen this discussed on several occasions on lists whose prime concern is spam and there has been no rough consensus. For example, Phillip Hallam-Baker, on asrg, summed up one discussion well with OK so defining the term spam is off limits to the group because it ends up in definitional flame wars. For me, it is dead obvious that the 397kbyte PowerPoint file I received on an IETF list last week is spam, and I know some IETF moderators who would not have allowed it on to the list; but equally, I am sure that the sender would protest his innocence. If we do not agree what spam is, then the whole of this statement seems to me pointless. Tom Petch * Such spam control SHOULD track accepted practices used on the Internet. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to bypass moderation, challenge-response, or other techniques that would interfere with a prompt technical debate on the mailing list without requiring such participants to receive list traffic. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to determine if an attempt to post was dropped as apparent spam. * The Internet draft editor, RFC editor, IESG secretary, IETF chair and IANA MUST be able to post to IETF mailing lists. The relevant identity information for these roles will be added to any white-list mechanism used by an IETF mailing list. * There MUST be a mechanism to complain that a message was inappropriately blocked. The realization of these principles is expected to change over time. List moderators, working group chairs and area directors are expected to interpret these principles reasonably and within the context of IETF policy and philosophy. This supercedes a previous IESG statement on this topic: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt That statement contains justification and implementation advice that may be helpful to anyone applying these principles. A separate IESG statement applies to moderation of IETF mailing lists: http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/ietf-announce ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
- Original Message - From: Tom.Petch [EMAIL PROTECTED] To: Eliot Lear [EMAIL PROTECTED] Cc: IETF Discussion ietf@ietf.org Sent: Tuesday, April 15, 2008 6:09 AM Subject: Re: IESG Statement on Spam Control on IETF Mailing Lists - Original Message - From: Eliot Lear [EMAIL PROTECTED] To: Russ Housley [EMAIL PROTECTED] Cc: IETF Discussion ietf@ietf.org Sent: Monday, April 14, 2008 8:13 PM Subject: Re: IESG Statement on Spam Control on IETF Mailing Lists Russ, When IETF lists are housed somewhere other than ietf.org, they are supposed to include an archive recipient so that there is an archive available at ietf.org (perhaps in addition to the one kept at the place where the list is housed). I'll agree with Phill's conclusion on this one. I think there is probably convenience value to housing the mailing lists at the IETF. It allows for a single whitelist, reduction in those annoying monthly messages that we eventually all filter into the bitbucket. Err, no! I have been silently discarded from IETF lists on a number of occasions - v6ops is the worst offender - and that monthly message is an invaluable check as to whether I have been discarded again or whether the list has been dormant. That is addressable though tom. The real issue is the legal controls which the IETF is obligated by its creation under the ISOC Charter to put in place. These include managing the electronic archive and legal culpability for changes (authorized or not) to that content as well as dealing with instances where individuals were 'quietly edited out' of various WG's Tom Petch Also, it probably is easier to effect and audit policy (such as we have any) in terms of message retention, uniform access, etc. Regards, Eliot ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
-- On Monday, April 14, 2008 10:25 PM +0200 Henrik Levkowetz [EMAIL PROTECTED] wrote regarding Re: IESG Statement on Spam Control on IETF Mailing Lists -- * IETF mailing lists MUST provide a mechanism for legitimate technical participants to determine if an attempt to post was dropped as apparent spam. Again, an umm... I'm not sure I'm aware of an available technical solution which out-of-the-box will ensure this is followed, without at the same time resulting in a deluge of back-scatter. If there was a SHOULD here, I could imagine working over a bit of time at setting up Mailman to drop-and-archive, but currently the solution which comes to mind is to reject, which (I believe) potentially will result in backscatter and more work and/or junk for the list admin. There is another method, which is currently used on the IETF mailing lists with a public archive. First, the current statement does point you at the older statement: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt Which says this: In other cases, it MUST be possible for the sender of a legitimate message, whether a mailing list subscriber or not, to determine if it is has been dropped as apparent spam. This can be done in several ways; all of these have their advantages and disadvantages. b. Provide an up-to-date archive of accepted postings. Unfortunately, while this can show dropped messages, it doesn't help if the email is merely delayed, nor does it say why a message was dropped. This MAY be used. This is the method currently employed on IETF lists with a public archive. Thus, the onus is on the originator of a message to make sure it was distributed. I'll also note for completeness that the IETF does not reject messages after they have been accepted for delivery by the SMTP server. Messages may be rejected by the SMTP server, in which case the originator should get a notice. After that point the message is either delivered or, in the case of lists with public archives, it may be dropped. Jim ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
-- On Monday, April 14, 2008 8:58 PM +0200 Frank Ellermann [EMAIL PROTECTED] wrote regarding Re: IESG Statement on Spam Control on IETF Mailing Lists -- Russ Housley wrote: When IETF lists are housed somewhere other than ietf.org, they are supposed to include an archive recipient so that there is an archive available at ietf.org Makes sense. I have submitted some lists to other lists, how is this archive recipient magic arranged ? I can tell you what is supposed to happen. The short answer is that RFC2418 tells you one of the two email addresses to subscribe to your other list to get an archive on the IETF web site. However, I think that guidance is at best incomplete. The rest of this message is the long answer and why I think that guidance is incomplete. RFC2418, IETF Working Group Guidelines and Procedures, says this in Section 2.2 Charter: As a service to the community, the IETF Secretariat operates a mailing list archive for working group mailing lists. In order to take advantage of this service, working group mailing lists MUST include the address [EMAIL PROTECTED] (where wg_acronym is the working group acronym) in the mailing list in order that a copy of all mailing list messages be recorded in the Secretariat's archive. Those archives are located at ftp://ftp.ietf.org/ietf-mail-archive. For robustness, WGs SHOULD maintain an additional archive separate from that maintained by the Secretariat. In turns out that this guidance is both incomplete in practice and, unfortunately, wrong in one detail. The incorrect detail is that the IETF no longer uses the domain lists.ietf.org. In fact, it never used it correctly. During the transition we discovered 7 domains used for mailing lists, the predominant one being the domain ietf.org. As part of the cut-over it was decided to use the domain ietf.org exclusively for all IETF lists. Everything was setup that way with backwards compatibility in place for all existing lists that used some other domain. Today, all lists are created in ietf.org, unless they are IAB, IESG, or IRTF lists. In practice, there are a few incomplete details. First, there are actually two aliases that need to be subscribed: [EMAIL PROTECTED] [EMAIL PROTECTED] Some might ask how this separation came to be? I don't know and never asked. It is continued today mostly for convenience; it's quite tedious to undo the current setup and there are more important things to be done. Second, except for the guideline in 2418, there's no process or documentation to go with this whole model on the IT side. Here's a sampling of some questions. 1. There's no maintenance of this practice. Last year the IETF did an audit, for the first time in forever, and brought everything up-to-date. This means that at that time all the other lists had an archive on the IETF web site. However, we're out of date again. 2. These archives have a SPAM problem. Well, they had a much more serious SPAM problem. Early in the post cut-over process AMS (Glen Barney) added some SPAM protection to these archives. However, all the best work has been put into getting Mailman firmly entrenched and protected. My opinion is that the IETF should just create a mailing list for every WG and then these other lists should just subscribe the IETF list to their list. This way there's no extra work on the IT side to protect things, particularly since Mailman provides some useful built-in features. In addition, we don't need these magic aliases any more. 3. Part of the maintenance problem is that for obscure reasons the IETF subscriber on these other lists will drop off the list occasionally. I'd be interested in hearing any good ideas for how to deal with this issue. 4. The Secretariat has to take action to make these email addresses work. I realize this is probably obvious to everyone here, but in the interests of completeness it should be documented that if you're going to setup an other list you need to ask to have the archives created. Or, perhaps, a back-office process should exist (does not currently) that says these archive should be automatically created whenever a working group is created. 5. These questions and issues are frequently asked or framed in the context of WGs. However, on the IT side, they apply more broadly, i.e., they apply to BOFs, directorate mailing lists, and other private lists. This not normally visible to the community-at-large, and perhaps should be at least accessible in some way even if it's not announced, but my comment here is that none of it is documented in any way. Jim ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
I'm not sure I agree. I do agree with Henrik's comments to the extent that I think we need to be clear. Obviously there's some ambiguity and we should clear that up. My interpretation of the two statements is that they are complementary, not conflicting. I would say that the third bullet is a response to the first bullet running amok. In other words, if you're going to have SPAM control, you have to deal with the problem of false negatives. It seems to me that all the third bullet is trying to say is that when individuals find themselves subject to a denial-of-service because of a false negative report from the SPAM control, there has to be a way for them to get through. I don't know if that's what was intended. If it was then that needs to be made clear. This could be helped by explicitly suggesting a way around, which is to forward the message to a Chair, list moderator (easily visible on the Mailman listinfo page for the list), Area Director, or perhaps even to the Secretariat for forwarding to one of these people if the person is having trouble even getting to them. If that's not what was intended then I agree completely with Henrik. Jim -- On Tuesday, April 15, 2008 9:00 AM +1200 Brian E Carpenter [EMAIL PROTECTED] wrote regarding Re: IESG Statement on Spam Control on IETF Mailing Lists -- +1 to Henrik's comments. I don't think the two MUSTs that he comments on are algorithmically possible. Brian On 2008-04-15 08:25, Henrik Levkowetz wrote: Hi, On 2008-04-14 17:39 IESG Secretary said the following: The following principles apply to spam control on IETF mailing lists: * IETF mailing lists MUST provide spam control. * Such spam control SHOULD track accepted practices used on the Internet. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to bypass moderation, challenge-response, or other techniques that would interfere with a prompt technical debate on the mailing list without requiring such participants to receive list traffic. Umm -- I think I understand what this *intends* to say, but I'm not sure. What I'm reading it as actually saying, though, is that a poster who thinks he is a legitimate technical participant is to be provided means of *bypassing* moderation. A means of bypassing challenge-response could be to send a mail to one of the list admins to forward to the list, but since moderation is (at least normally) provided by the list admins, and essentially any human who receives a message and is asked to forward it to the list will have to judge whether the message is relevant and appropriate, which constitutes moderation as I understand it, the statement above seems to imply that there has to be some way, untouched by a human making any kind of evaluation, to force a message to be posted to a list??? It would be rather helpful for an explanation or rationale to be provided for a statement such as the above, which to me reads as a very categorical statement that no kind of challenge-response, moderation, or other reasonable guard against spam can be put in place without extraordinary efforts at providing means to *force* a circumvention of the same. I'm pretty sure that the third bullet above isn't intended to almost completely nullify the first bullet, but I'm actually not sure how to set up anything but painstaking manual inspection of every spam in order to adhere to the third bullet as written. None of the mechanisms currently available, including TMDA, spam-assassin, and blocking of posts from non-subscribers followed by manual inspection seems to fulfil this as I read it, which leaves me at a loss. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to determine if an attempt to post was dropped as apparent spam. Again, an umm... I'm not sure I'm aware of an available technical solution which out-of-the-box will ensure this is followed, without at the same time resulting in a deluge of back-scatter. If there was a SHOULD here, I could imagine working over a bit of time at setting up Mailman to drop-and-archive, but currently the solution which comes to mind is to reject, which (I believe) potentially will result in backscatter and more work and/or junk for the list admin. Overall, I'm slightly surprised at how categorical several of the statements above are, without providing rationale and background information which would have made it possible to fully understand them. It seems as if they are presented as decrees from on-high which have to be followed even if they aren't understood to be sensible or implementable... * The Internet draft editor, RFC editor, IESG secretary, IETF chair and IANA MUST be able to post to IETF mailing lists. The relevant identity information for these roles will be added to any white-list mechanism used
Re: IESG Statement on Spam Control on IETF Mailing Lists
-- On Monday, April 14, 2008 2:11 PM -0700 Ned Freed [EMAIL PROTECTED] wrote regarding Re: IESG Statement on Spam Control on IETF Mailing Lists -- +1 to Henrik's comments. I don't think the two MUSTs that he comments on are algorithmically possible. These two MUSTs (the ability to whitelist specific posters without them having to receive list mail and spam rejection) are both completely trivial to implement with our software. The latter is normally done (and definitely should be done) at the SMTP level, minimizing blowback. To be fair, and I know Ned that you know this, it depends on where and how you implement specific controls. Some software makes this easier than other software. In general, the more integrated the components the finer granularity one gets in what you can do. Specifically, the whitelisting has to occur either before or within the SPAM filtering. If a source is whitelisted it has to bypass all other checks. The IETF setup uses SpamAssassin for tagging purposes. This is done outside of the SMTP service and outside of Mailman, which supports the mailing lists. The whitelisting is done with TMDA, which is also outside of SpamAssassin and outside of Mailman. Getting all three of these things to work together is not trivial. I don't mean to suggest it's rocket science, but you have to sit down and think about how each of them provide the various services they provide and get them to cooperate. Changes in any one require a re-evaluation of the entire setup, just to make sure there are no unintended consequences. The fact that TMDA does whitelisting means that Mailman does not have to do it. This reduces the SPAM load on Mailman but it does not change the fact that you have to be a subscriber to get a message through. If you're not a subscriber you're still going to get moderated. For Mailman to do the whitelisting it means that every mailing list would have to have the same database that TMDA has, which has 40,000 entries in it. Yes, that's right, there are 40,000 unique email addresses across all IETF mailing lists. This is how Mailman works. My point here is that there are choices to be made, and those choices have implications. Obviously the IETF could make different choices, but I do think it's important to understand the advantages and disadvantages of different choices. Jim ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
On Mon, Apr 14, 2008 at 08:13:23PM +0200, Eliot Lear wrote: I think there is probably convenience value to housing the mailing lists at the IETF. It allows for a single whitelist, reduction in those annoying monthly messages that we eventually all filter into the bitbucket. I'll concur with the general sentiment here, although I don't think there's any need for DKIM or any of the other related flavor-of-the-month technologies (SenderID, SPF, etc). A suggestion -- to Eliot's point about monthly reminders -- would be to consider consolidating those into a single reminder that covers all IETF mailing lists. This would cut down IETF-outbound mail volume as well as per-recipient inbound mail volume, while (I think) still serving the same function. ---Rsk ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
On 2008-04-15 16:59 James Galvin said the following: -- On Monday, April 14, 2008 10:25 PM +0200 Henrik Levkowetz [EMAIL PROTECTED] wrote regarding Re: IESG Statement on Spam Control on IETF Mailing Lists -- * IETF mailing lists MUST provide a mechanism for legitimate technical participants to determine if an attempt to post was dropped as apparent spam. Again, an umm... I'm not sure I'm aware of an available technical solution which out-of-the-box will ensure this is followed, without at the same time resulting in a deluge of back-scatter. If there was a SHOULD here, I could imagine working over a bit of time at setting up Mailman to drop-and-archive, but currently the solution which comes to mind is to reject, which (I believe) potentially will result in backscatter and more work and/or junk for the list admin. There is another method, which is currently used on the IETF mailing lists with a public archive. First, the current statement does point you at the older statement: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt Which says this: In other cases, it MUST be possible for the sender of a legitimate message, whether a mailing list subscriber or not, to determine if it is has been dropped as apparent spam. This can be done in several ways; all of these have their advantages and disadvantages. b. Provide an up-to-date archive of accepted postings. Unfortunately, while this can show dropped messages, it doesn't help if the email is merely delayed, nor does it say why a message was dropped. This MAY be used. If this is acceptable, I'm happy. Unfortunately, I wouldn't have thought this solution would have been acceptable after reading the statement of the original posting, and as long as the IESG doesn't indicate that it is acceptable, I'll continue to be uncertain. So as far as I can tell, the essence of my original response remains: The original posting would have benefited greatly by including a bit of rationale and examples; and my suggestion would be to do any needed revision to the older statement: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt and issue a new version of that, which seems to give the background, rationale and examples missing from the latest statement. If the latest statement is going to be allowed to stand, at least I am going to feel that I'm guessing far more than I'm comfortable with regarding exactly where the line between acceptable and non-acceptable technical solutions to spam filtering goes. If the IESG finds itself unable to find the time needed to revise the older document I'm also offering to provide revised text based on that document, in the interest of having policy I feel can be read, understood and followed without too much ambiguity. Henrik ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
James Galvin wrote: Hi, thanks for the explanation, I add some notes of what I think this means, please correct me if I got it wrong. [2418] | As a service to the community, the IETF Secretariat | operates a mailing list archive for working group | mailing lists. Most lists I submitted to the other lists are in fact former WG lists. I guess there is nothing to do for the submitter / AD / list owner for former IETF WG lists, the official archives are likely still subscribed. Today, all lists are created in ietf.org, unless they are IAB, IESG, or IRTF lists. Okay. Existing other lists are not necessarily hosted by ietf.org, they can be anywhere (Harald, IMC, Pobox, W3C, Google, Yahoo!, etc.) Last year the IETF did an audit, for the first time in forever, and brought everything up-to-date. This means that at that time all the other lists had an archive on the IETF web site. Great, that should take care of any list I ever submitted with one or two fresher exceptions. However, we're out of date again. Maybe the two archive subscriptions could be added to the verification procedure. As far as I can tell it the Web form creates a request to the chosen AD, the AD can then accept, reject, or ignore it. The accept state could be split to arrange the archive subscriptions. Lots of fun there, but there aren't many other list, and most have a mailman Web interface. These archives have a SPAM problem. Willing to explain the secrets of RFC 4408, but maybe not again here... :-) My opinion is that the IETF should just create a mailing list for every WG and then these other lists should just subscribe the IETF list to their list. The opposition can then still pretend to send mail from the old list to the new list, and vice versa. The position of the gateway on the IETF side (directly above the archives vs. before the new list) won't necessarily change the spam problem. If something breaks you have a split, articles appearing only in the old or new list. A gateway directly above the archives has the same problem, but archives at least don't try to post... :-) Or if they apparently post it must be spam. Mailman provides some useful built-in features. Unfortunately it doesn't let me say for each subscribed [EMAIL PROTECTED] add a new address [EMAIL PROTECTED], it also doesn't let me say now please consider [EMAIL PROTECTED] to have write access on all existing lists. Part of the maintenance problem is that for obscure reasons the ETF subscriber on these other lists will drop off the list occasionally. I'd be interested in hearing any good ideas for how to deal with this issue. Pass. Disable password reminder, maybe ? The Secretariat has to take action to make these email addresses work. I realize this is probably obvious to everyone here, but in the interests of completeness it should be documented that if you're going to setup an other list you need to ask to have the archives created. Certainly not obvious for me, I never did this. I just filled out the submission form, staying away from using + , because that breaks the other lists script. ADs are annoyed when they have to confirm updates only because + breaks the other lists Web page ;-) Frank ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IESG Statement on Spam Control on IETF Mailing Lists
I don't think it is helpful for the IETF to describe its work product as 'flavor-of-the-month'. DKIM is an IETF Proposed Standard. Using DKIM is thus a dog-food issue. SPF/Sender-ID on the other hand are arguably not at the same status but there is a general consensus amongst the spam community that they help the spam-fighters. That said, I also +1 on the monthly reminders issue. I would like the monthly reminder to include a NOTE WELL section. It would also enable services such as allowing mail to be redirected en-mass for a given recipient when they change jobs or email provider. Or simply decide that they would prefer to direct all their IETF mail to another account so they don't run up an incredible bill on the pager. From: [EMAIL PROTECTED] on behalf of Rich Kulawiec Sent: Mon 14/04/2008 2:38 PM To: IETF Discussion Subject: Re: IESG Statement on Spam Control on IETF Mailing Lists On Mon, Apr 14, 2008 at 08:13:23PM +0200, Eliot Lear wrote: I think there is probably convenience value to housing the mailing lists at the IETF. It allows for a single whitelist, reduction in those annoying monthly messages that we eventually all filter into the bitbucket. I'll concur with the general sentiment here, although I don't think there's any need for DKIM or any of the other related flavor-of-the-month technologies (SenderID, SPF, etc). A suggestion -- to Eliot's point about monthly reminders -- would be to consider consolidating those into a single reminder that covers all IETF mailing lists. This would cut down IETF-outbound mail volume as well as per-recipient inbound mail volume, while (I think) still serving the same function. ---Rsk ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
Hi Henrik, Seems this email about email still needs some more discussion - I have not been involved much with this much but I suspect that Chris Newman would probably be the best person on the IESG to work with on both clarifications and changes. Cullen On Apr 15, 2008, at 10:49 AM, Henrik Levkowetz wrote: On 2008-04-15 16:59 James Galvin said the following: -- On Monday, April 14, 2008 10:25 PM +0200 Henrik Levkowetz [EMAIL PROTECTED] wrote regarding Re: IESG Statement on Spam Control on IETF Mailing Lists -- * IETF mailing lists MUST provide a mechanism for legitimate technical participants to determine if an attempt to post was dropped as apparent spam. Again, an umm... I'm not sure I'm aware of an available technical solution which out-of-the-box will ensure this is followed, without at the same time resulting in a deluge of back-scatter. If there was a SHOULD here, I could imagine working over a bit of time at setting up Mailman to drop-and-archive, but currently the solution which comes to mind is to reject, which (I believe) potentially will result in backscatter and more work and/or junk for the list admin. There is another method, which is currently used on the IETF mailing lists with a public archive. First, the current statement does point you at the older statement: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt Which says this: In other cases, it MUST be possible for the sender of a legitimate message, whether a mailing list subscriber or not, to determine if it is has been dropped as apparent spam. This can be done in several ways; all of these have their advantages and disadvantages. b. Provide an up-to-date archive of accepted postings. Unfortunately, while this can show dropped messages, it doesn't help if the email is merely delayed, nor does it say why a message was dropped. This MAY be used. If this is acceptable, I'm happy. Unfortunately, I wouldn't have thought this solution would have been acceptable after reading the statement of the original posting, and as long as the IESG doesn't indicate that it is acceptable, I'll continue to be uncertain. So as far as I can tell, the essence of my original response remains: The original posting would have benefited greatly by including a bit of rationale and examples; and my suggestion would be to do any needed revision to the older statement: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt and issue a new version of that, which seems to give the background, rationale and examples missing from the latest statement. If the latest statement is going to be allowed to stand, at least I am going to feel that I'm guessing far more than I'm comfortable with regarding exactly where the line between acceptable and non-acceptable technical solutions to spam filtering goes. If the IESG finds itself unable to find the time needed to revise the older document I'm also offering to provide revised text based on that document, in the interest of having policy I feel can be read, understood and followed without too much ambiguity. Henrik ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IESG Statement on Spam Control on IETF Mailing Lists
The following principles apply to spam control on IETF mailing lists: * IETF mailing lists MUST provide spam control. * Such spam control SHOULD track accepted practices used on the Internet. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to bypass moderation, challenge-response, or other techniques that would interfere with a prompt technical debate on the mailing list without requiring such participants to receive list traffic. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to determine if an attempt to post was dropped as apparent spam. * The Internet draft editor, RFC editor, IESG secretary, IETF chair and IANA MUST be able to post to IETF mailing lists. The relevant identity information for these roles will be added to any white-list mechanism used by an IETF mailing list. * There MUST be a mechanism to complain that a message was inappropriately blocked. The realization of these principles is expected to change over time. List moderators, working group chairs and area directors are expected to interpret these principles reasonably and within the context of IETF policy and philosophy. This supercedes a previous IESG statement on this topic: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt That statement contains justification and implementation advice that may be helpful to anyone applying these principles. A separate IESG statement applies to moderation of IETF mailing lists: http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IESG Statement on Spam Control on IETF Mailing Lists
I would suggest that the IESG also think about hosting all IETF lists in house in the future. The main reason for this is legal, a list that is maintained by the IETF is much more satisfactory in a patent dispute than one run by a third party. Last thing we want is to have patent trolls dragging a third party list maintainer into a dispute while they try to argue that the list somehow does not count. And yes, I am aware that the 'law', might be on our side here. The problem is that it can cost a ridiculous amount of money to have a court decide the most obvious and basic question you might imagine. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of IESG Secretary Sent: Monday, April 14, 2008 8:40 AM To: IETF Announcement list Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: IESG Statement on Spam Control on IETF Mailing Lists The following principles apply to spam control on IETF mailing lists: * IETF mailing lists MUST provide spam control. * Such spam control SHOULD track accepted practices used on the Internet. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to bypass moderation, challenge-response, or other techniques that would interfere with a prompt technical debate on the mailing list without requiring such participants to receive list traffic. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to determine if an attempt to post was dropped as apparent spam. * The Internet draft editor, RFC editor, IESG secretary, IETF chair and IANA MUST be able to post to IETF mailing lists. The relevant identity information for these roles will be added to any white-list mechanism used by an IETF mailing list. * There MUST be a mechanism to complain that a message was inappropriately blocked. The realization of these principles is expected to change over time. List moderators, working group chairs and area directors are expected to interpret these principles reasonably and within the context of IETF policy and philosophy. This supercedes a previous IESG statement on this topic: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt That statement contains justification and implementation advice that may be helpful to anyone applying these principles. A separate IESG statement applies to moderation of IETF mailing lists: http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
On Mon, Apr 14, 2008 at 1:02 PM, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: I would suggest that the IESG also think about hosting all IETF lists in house in the future. The main reason for this is legal, a list that is maintained by the IETF is much more satisfactory in a patent dispute than one run by a third party. Last thing we want is to have patent trolls dragging a third party list maintainer into a dispute while they try to argue that the list somehow does not count. The question I'd have in response to that point though, Phillip, is how the cost vs. benefit of hosting all data in-house with consideration to changing privacy and data retention laws weighs out. Apologies for the run-on sentence. -- /Daniel P. Brown Ask me about: Dedicated servers starting @ $59.99/mo., VPS starting @ $19.99/mo., and shared hosting starting @ $2.50/mo. Unmanaged, managed, and fully-managed! ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IESG Statement on Spam Control on IETF Mailing Lists
Phill: When IETF lists are housed somewhere other than ietf.org, they are supposed to include an archive recipient so that there is an archive available at ietf.org (perhaps in addition to the one kept at the place where the list is housed). Russ At 01:02 PM 4/14/2008, Hallam-Baker, Phillip wrote: I would suggest that the IESG also think about hosting all IETF lists in house in the future. The main reason for this is legal, a list that is maintained by the IETF is much more satisfactory in a patent dispute than one run by a third party. Last thing we want is to have patent trolls dragging a third party list maintainer into a dispute while they try to argue that the list somehow does not count. And yes, I am aware that the 'law', might be on our side here. The problem is that it can cost a ridiculous amount of money to have a court decide the most obvious and basic question you might imagine. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of IESG Secretary Sent: Monday, April 14, 2008 8:40 AM To: IETF Announcement list Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: IESG Statement on Spam Control on IETF Mailing Lists The following principles apply to spam control on IETF mailing lists: * IETF mailing lists MUST provide spam control. * Such spam control SHOULD track accepted practices used on the Internet. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to bypass moderation, challenge-response, or other techniques that would interfere with a prompt technical debate on the mailing list without requiring such participants to receive list traffic. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to determine if an attempt to post was dropped as apparent spam. * The Internet draft editor, RFC editor, IESG secretary, IETF chair and IANA MUST be able to post to IETF mailing lists. The relevant identity information for these roles will be added to any white-list mechanism used by an IETF mailing list. * There MUST be a mechanism to complain that a message was inappropriately blocked. The realization of these principles is expected to change over time. List moderators, working group chairs and area directors are expected to interpret these principles reasonably and within the context of IETF policy and philosophy. This supercedes a previous IESG statement on this topic: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt That statement contains justification and implementation advice that may be helpful to anyone applying these principles. A separate IESG statement applies to moderation of IETF mailing lists: http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
Russ, When IETF lists are housed somewhere other than ietf.org, they are supposed to include an archive recipient so that there is an archive available at ietf.org (perhaps in addition to the one kept at the place where the list is housed). I'll agree with Phill's conclusion on this one. I think there is probably convenience value to housing the mailing lists at the IETF. It allows for a single whitelist, reduction in those annoying monthly messages that we eventually all filter into the bitbucket. Also, it probably is easier to effect and audit policy (such as we have any) in terms of message retention, uniform access, etc. Regards, Eliot ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dkim unverified] Re: IESG Statement on Spam Control on IETF Mailing Lists
Eliot Lear wrote: Russ, When IETF lists are housed somewhere other than ietf.org, they are supposed to include an archive recipient so that there is an archive available at ietf.org (perhaps in addition to the one kept at the place where the list is housed). I'll agree with Phill's conclusion on this one. I think there is probably convenience value to housing the mailing lists at the IETF. It allows for a single whitelist, reduction in those annoying monthly messages that we eventually all filter into the bitbucket. Also, it probably is easier to effect and audit policy (such as we have any) in terms of message retention, uniform access, etc. The other things is when we start DKIM signing (HINT HINT), it will give a single identity for reputation, etc to latch onto. Mike ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
Russ Housley wrote: When IETF lists are housed somewhere other than ietf.org, they are supposed to include an archive recipient so that there is an archive available at ietf.org Makes sense. I have submitted some lists to other lists, how is this archive recipient magic arranged ? Frank ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IESG Statement on Spam Control on IETF Mailing Lists
Hi, On 2008-04-14 17:39 IESG Secretary said the following: The following principles apply to spam control on IETF mailing lists: * IETF mailing lists MUST provide spam control. * Such spam control SHOULD track accepted practices used on the Internet. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to bypass moderation, challenge-response, or other techniques that would interfere with a prompt technical debate on the mailing list without requiring such participants to receive list traffic. Umm -- I think I understand what this *intends* to say, but I'm not sure. What I'm reading it as actually saying, though, is that a poster who thinks he is a legitimate technical participant is to be provided means of *bypassing* moderation. A means of bypassing challenge-response could be to send a mail to one of the list admins to forward to the list, but since moderation is (at least normally) provided by the list admins, and essentially any human who receives a message and is asked to forward it to the list will have to judge whether the message is relevant and appropriate, which constitutes moderation as I understand it, the statement above seems to imply that there has to be some way, untouched by a human making any kind of evaluation, to force a message to be posted to a list??? It would be rather helpful for an explanation or rationale to be provided for a statement such as the above, which to me reads as a very categorical statement that no kind of challenge-response, moderation, or other reasonable guard against spam can be put in place without extraordinary efforts at providing means to *force* a circumvention of the same. I'm pretty sure that the third bullet above isn't intended to almost completely nullify the first bullet, but I'm actually not sure how to set up anything but painstaking manual inspection of every spam in order to adhere to the third bullet as written. None of the mechanisms currently available, including TMDA, spam-assassin, and blocking of posts from non-subscribers followed by manual inspection seems to fulfil this as I read it, which leaves me at a loss. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to determine if an attempt to post was dropped as apparent spam. Again, an umm... I'm not sure I'm aware of an available technical solution which out-of-the-box will ensure this is followed, without at the same time resulting in a deluge of back-scatter. If there was a SHOULD here, I could imagine working over a bit of time at setting up Mailman to drop-and-archive, but currently the solution which comes to mind is to reject, which (I believe) potentially will result in backscatter and more work and/or junk for the list admin. Overall, I'm slightly surprised at how categorical several of the statements above are, without providing rationale and background information which would have made it possible to fully understand them. It seems as if they are presented as decrees from on-high which have to be followed even if they aren't understood to be sensible or implementable... * The Internet draft editor, RFC editor, IESG secretary, IETF chair and IANA MUST be able to post to IETF mailing lists. The relevant identity information for these roles will be added to any white-list mechanism used by an IETF mailing list. * There MUST be a mechanism to complain that a message was inappropriately blocked. The realization of these principles is expected to change over time. List moderators, working group chairs and area directors are expected to interpret these principles reasonably and within the context of IETF policy and philosophy. This supercedes a previous IESG statement on this topic: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt That statement contains justification and implementation advice that may be helpful to anyone applying these principles. A separate IESG statement applies to moderation of IETF mailing lists: http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt Henrik ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IESG Statement on Spam Control on IETF Mailing Lists
The problem here is that what might appear to be a reasonable approach and what can be proven to be a verifiable approach at reasonable cost are not necessarily the same. I would rather anticipate the problem rather than wait for an issue. It is not just the message archives that are relevant, the membership lists are also very relevant, as are the mail server logs. It is also questions of procedure, does the mail server corrupt DKIM headers ct? it is also about notice, does the list provide appropriate NOTE WELL advice on subscribing to the list and on regular intervals thereafter? Easy to set up if all the lists are set up in one place, impossible if they are all over the place. It seems to me that we have reached the point where it is rather easier to ensure standards are met by bringing the process in house rather than asking third party list maintainers about their practices. I would suggest doing this gradually by making in house maintenance a requirement for all new lists as they are created. -Original Message- From: Russ Housley [mailto:[EMAIL PROTECTED] Sent: Monday, April 14, 2008 10:25 AM To: Hallam-Baker, Phillip Cc: ietf@ietf.org; [EMAIL PROTECTED] Subject: RE: IESG Statement on Spam Control on IETF Mailing Lists Phill: When IETF lists are housed somewhere other than ietf.org, they are supposed to include an archive recipient so that there is an archive available at ietf.org (perhaps in addition to the one kept at the place where the list is housed). Russ At 01:02 PM 4/14/2008, Hallam-Baker, Phillip wrote: I would suggest that the IESG also think about hosting all IETF lists in house in the future. The main reason for this is legal, a list that is maintained by the IETF is much more satisfactory in a patent dispute than one run by a third party. Last thing we want is to have patent trolls dragging a third party list maintainer into a dispute while they try to argue that the list somehow does not count. And yes, I am aware that the 'law', might be on our side here. The problem is that it can cost a ridiculous amount of money to have a court decide the most obvious and basic question you might imagine. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of IESG Secretary Sent: Monday, April 14, 2008 8:40 AM To: IETF Announcement list Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: IESG Statement on Spam Control on IETF Mailing Lists The following principles apply to spam control on IETF mailing lists: * IETF mailing lists MUST provide spam control. * Such spam control SHOULD track accepted practices used on the Internet. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to bypass moderation, challenge-response, or other techniques that would interfere with a prompt technical debate on the mailing list without requiring such participants to receive list traffic. * IETF mailing lists MUST provide a mechanism for legitimate technical participants to determine if an attempt to post was dropped as apparent spam. * The Internet draft editor, RFC editor, IESG secretary, IETF chair and IANA MUST be able to post to IETF mailing lists. The relevant identity information for these roles will be added to any white-list mechanism used by an IETF mailing list. * There MUST be a mechanism to complain that a message was inappropriately blocked. The realization of these principles is expected to change over time. List moderators, working group chairs and area directors are expected to interpret these principles reasonably and within the context of IETF policy and philosophy. This supercedes a previous IESG statement on this topic: http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt That statement contains justification and implementation advice that may be helpful to anyone applying these principles. A separate IESG statement applies to moderation of IETF mailing lists: http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
