http://www.ietf.org/WG-WEB-Mail.html
I see that http://www.ietf.org/WG-WEB-Mail.html, which used to point to HTML working group mailing list archives, now points instead to the stuff on the WG charter pages, which consist mostly of text-based FTP archives, and in may cases the links are broken. I know that there were a lot of broken links on the old page, but IMHO this one is much worse. Can we please have the old page back? Mike Heard ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
On May 24, 2004, at 1:49 PM, [EMAIL PROTECTED] wrote: In fact, there isn't any sane way to detect inconsistent header information without external hints - this is the reason why there's the SPF proposal, the Yahoo domain-keys proposal, and Microsoft's proposal. And MARID. -andy ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Update on AdminRest activities
Since the Seoul plenary meetings, Harald and I have been working on our take-away action items. We had the opportunity to talk with the ISOC Board in mid-May. We reviewed briefly the trajectory set in motion from the AdvComm document, and outlined the framework that we presented in plenary in Seoul (the AdminRest framework, draft-daigle-adminrest). Following up on our statements in Seoul, we asked for support to address some of the cross-organization and specific organization tasks for current operational needs, and to support the task of exploring the AdminRest framework to the extent of producing more of a concrete proposal. I'm happy to report that the ISOC BoT was indeed very supportive of this effort. The specifics (i.e., ISOC Board resolution) will be published as part of the ISOC Board meeting minutes. The highlights of that support include the allocation of an ISOC budget sum, not to exceed $250,000, to be spent over a six month period for personnel, incidental expenses, and legal and accounting fees to hire and manage a consultant who will complete the analysis started in RFC 3716 and make recommendations regarding the organizational requirements and potential organizational models of the IETF. The first step, clearly, is to find and hire the appropriate person. We have a few people in mind to talk to, but as we can always use pointers to people we may not have thought of, here's an outline of the characteristics and expectations we're using as guidelines: This is a support function is not intended as a policy-making role, but intended to execute and clarify the policy set forth by the IETF leadership, reporting to the ISOC president (as an ISOC project). Essentially, we are looking for someone we can work with; the kinds of deliverables and requiremed skills are as outlined below. Deliverables for the project will include: Data Flow: a set of requirements for implementing appropriate tracking of IETF documents and reporting of status across the support organizations. RFC Editor contract: a negotiated contract that is agreeable to all concerned parties. Administrative restructuring: documentation and support as appropriate to the continued evolution of the restructuring effort, which is continuously reviewed by the IAB, IESG and the rest of the IETF community. Types of activities/tasks this will include: - Assist in drafting the proposed structure/bylaws for the IETF administrative entity - Revising proposed structure/bylaws based on the public review, including reviews by competent counsel - Negotiate the contracts for RFC Editor as a model for eventual use by the IETF administrative entity - Interacting with the RFC Editor, IANA and Secretariat to determine the requirements for inter-organizational document flow matched to overall IETF process needs So from this, we have the required skill set: - understanding inter-organizational relationships and document flows - ability in contract negotiation - insight into organization formalization - experience with the creation of organizations (preferably nonprofits) - understanding of the legal aspects of such an organization - understanding of the financial aspects of such an organization (all of this with the understanding that specific other expertise, e.g., financial and legal advice, can be brought in on an as-needed basis). We hope to identify a suitable candidate in the upcoming weeks. Leslie. -- --- Reality: Yours to discover. -- ThinkingCat Leslie Daigle [EMAIL PROTECTED] --- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: spoofing email addresses
From: Andrew Newton [EMAIL PROTECTED] On May 24, 2004, at 1:49 PM, [EMAIL PROTECTED] wrote: In fact, there isn't any sane way to detect inconsistent header information without external hints - this is the reason why there's the SPF proposal, the Yahoo domain-keys proposal, and Microsoft's proposal. And MARID. I don't see any of those proposals and their competitors as sane. Some of them, such as SPF, do not even meet their own design goals as stated informally by their advocates. Others such as domain-keys do not seem to do anything that is not already done by SMTP-TLS, despite the goals in the I-D that seem to be closer to S/MIME. None of them have much to do with spam, but only with a currently popular mode of attack used by spammers. None have any hope of affecting even that particular attack mode for years, because none can have any significant effect until deployed on most SMTP clients. Many seem to be based on insufficient familiarity with the nature of SMTP (e.g. SPF's incredible source-routing scheme) and the urge to Do Something Now regardless of actual results. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Request for comments on draft mail protocol
Hello, I am currently involved in a project to create an internet-draft for a domain/key based system allowing mail domains to be validated using rsa keys, distributed using the DNS system, with minimal modification to existing infrastructure. Does a specification for such a system already exist? I have many ideas for extentions to the existing SMTP protocol, as well as plans for a derivative protocol incorporating this key-based system as a more secure and verifiable method of exchanging mail. If anyone is interested, I would appreciate being contacted off-list to discuss the possible formation of a working group to discuss such ideas. Regards, James Denness On Wed, 26 May 2004, Vernon Schryver wrote: Date: Wed, 26 May 2004 15:00:00 -0600 (MDT) From: Vernon Schryver [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: spoofing email addresses From: Andrew Newton [EMAIL PROTECTED] On May 24, 2004, at 1:49 PM, [EMAIL PROTECTED] wrote: In fact, there isn't any sane way to detect inconsistent header information without external hints - this is the reason why there's the SPF proposal, the Yahoo domain-keys proposal, and Microsoft's proposal. And MARID. I don't see any of those proposals and their competitors as sane. Some of them, such as SPF, do not even meet their own design goals as stated informally by their advocates. Others such as domain-keys do not seem to do anything that is not already done by SMTP-TLS, despite the goals in the I-D that seem to be closer to S/MIME. None of them have much to do with spam, but only with a currently popular mode of attack used by spammers. None have any hope of affecting even that particular attack mode for years, because none can have any significant effect until deployed on most SMTP clients. Many seem to be based on insufficient familiarity with the nature of SMTP (e.g. SPF's incredible source-routing scheme) and the urge to Do Something Now regardless of actual results. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Request for comments on draft mail protocol
From: James Denness I am currently involved in a project to create an internet-draft for a domain/key based system allowing mail domains to be validated using rsa keys, distributed using the DNS system, with minimal modification to existing infrastructure. Does a specification for such a system already exist? I have many ideas for extentions to the existing SMTP protocol, as well as plans for a derivative protocol incorporating this key-based system as a more secure and verifiable method of exchanging mail. If anyone is interested, I would appreciate being contacted off-list to discuss the possible formation of a working group to discuss such ideas. what about http://ietf.org/html.charters/marid-charter.html ? It might be interesting to contact the author of draft-delany-domainkeys-base-00.txt or the authors of the at least half a dozen other proposals to use public keys or other mechanisms along with the domain name system to authenticate mail senders. My rather negative view of the area can be inferred from http://www.rhyolite.com/anti-spam/you-might-be.html Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
out-of-office notifications
How many years must this stuff continue? If someone asked me, I'd say that the people responsible for the enclosed meant to ask the Secretariat to be unsubscribed with prejudice from all IETF mailing lists. Then there are people who send HTML out-of-office noise. This stuff is a tad ironic given the recently expressed concerns about bad guys checking the IETF attendance list. How about a Modest Proposal: no one be allowed to subscribe to any IETF mailing list without submitting evidence that Microsoft MUAs or MTAs are not in use. Those with sufficient clues to contribute usefully could doubtless arrange things so that even if they were using Microsoft virus, worm, spam, and OFN distrubution malware, their mail headers would lie. Vernon Schryver[EMAIL PROTECTED] From: Eric Burger [EMAIL PROTECTED] To: Vernon Schryver [EMAIL PROTECTED] Subject: Out of Office AutoReply: spoofing email addresses Not reachable by e-mail or phone until 6/2, and then only by e-mail. From: Paul Georgiou [EMAIL PROTECTED] To: Vernon Schryver [EMAIL PROTECTED] Subject: Out of Office AutoReply: spoofing email addresses Please note I will be out of the office from Friday May 21st to Tuesday May 25th inclusive without access to email or Voicemail. For urgent matters please contact Rosemary Hagholm, [EMAIL PROTECTED], 416-410-6050, or David YoungPow, [EMAIL PROTECTED], 905-264-5785. From: WaterCove Email [EMAIL PROTECTED] To: Vernon Schryver [EMAIL PROTECTED] Subject: WaterCove Email Hello, The watercove.com email address you sent to is no longer active. With the recent acquisition of WaterCove by Alcatel, please contact the intended recipient directly to get their updated email address. Thank you. From: Joerg Reichelt [EMAIL PROTECTED] To: Vernon Schryver [EMAIL PROTECTED] Subject: Out of Office AutoReply: spoofing email addresses This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --_=_NextPart_001_01C4436B.0F91EDC0 Content-Type: text/plain; charset=windows-1252 I am currently out of the office and will be back on 6/14/2004. In case of urgent matters, please contact Eric Yuan (408) 944-4928 [EMAIL PROTECTED] Thanks, Joerg Reichelt --_=_NextPart_001_01C4436B.0F91EDC0 Content-Type: text/html; charset=windows-1252 !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=windows-1252 META NAME=Generator CONTENT=MS Exchange Server version 5.5.2654.45 TITLEOut of Office AutoReply: spoofing email addresses/TITLE /HEAD BODY PFONT SIZE=2I am currently out of the office and will be back on 6/14/2004. In case of urgent matters, please contact /FONT BRFONT SIZE=2nbsp;nbsp;nbsp; Eric Yuan /FONT BRFONT SIZE=2nbsp;nbsp;nbsp; (408) 944-4928/FONT BRFONT SIZE=2nbsp;nbsp; [EMAIL PROTECTED]/FONT /P PFONT SIZE=2Thanks, /FONT BRFONT SIZE=2Joerg Reichelt/FONT /P /BODY /HTML --_=_NextPart_001_01C4436B.0F91EDC0-- ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
