Any RFCs describing mailing list subscription practice?

2000-07-09 Thread Ross Finlayson

Do we have any RFCs (or even I-Ds) that describe the preferred '3-way 
handshake' method for validating a request to subscribe to a mailing list - 
i.e., to first send back - to the requester's source email address - a 
"please confirm your subscription" response message (preferably containing 
a random token), and then add the address to the mailing list *only if* the 
user responds to this second message?

I am constantly fighting with clueless (or lazy, or opportunistic) mailing 
list operators who insist on adding bogus email addresses - containing my 
domain name - to their mailing lists, without first confirming their 
validity.  It would be nice if there were an IETF document that I could 
point them at.

Ross.




Re: draft-ietf-nat-protocol-complications-02.txt

2000-07-09 Thread Masataka Ohta

Dear all;

Based on the previous discussion,

Jon In message [EMAIL PROTECTED], Masataka Ohta ty
Jon ped:
Jon  
Jon  Is it fair if providers using iMODE or WAP are advertised
Jon  to be ISPs?
Jon  
Jon  Is it fair if providers using NAT are advertised to be ISPs?
Jon  
Jon  My answer to both questions is
Jon  
Jon  No, while they may be Internet Service Access Providers and
Jon  NAT users may be IP Service Providers, they don't provide
Jon  Internet service and are no ISPs.
Jon 
Jon i agree:
Jon in the UK, i would say that someone claiming internet access via WAP
Jon would be in breach of the trades description act.
Jon 
Jon  Any oppositions?
Jon  
Jon not from here (for wap - i dont know enough about iMODE to comment)

and lack of oppsitions in the thread, I have drafted an attached ID.

However, IESG is blocking the publication of the ID (it is just an
Internet Draft, NOT an Informational RFC)!

IESG says they have not even saw the content, which means a lot of
time will be wasted further.

So, I post the draft to the Mailing List.

Any comments on the content of the draft? Comments for the blockage,
if any, should be given with a separate subject?

I hope IESG has not taken the obvious next step of the moderation
of the Mailing List.

Masataka Ohta
---






INTERNET DRAFT   M. Ohta
draft-ohta-isps-00.txt Tokyo Institute of Technology
   July 2000

 The Internet and ISPs

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Copyright (C) The Internet Society (May/1/2000).  All Rights
   Reserved.

Abstract

   This memo gives definitions on the Internet and ISPs (Internet
   Service Providers).

1. The Internet

   The Internet is a public IP [1, 2] network globally connected end to
   end [3] at the Internetworking layer.

2. ISPs

   A network provider is an ISP, if and only if its network, including
   access parts of the network to its subscribers, is a part of the
   Internet.

   As such, ISPs must preserve the end to end and globally connected
   principles of the Internet at the Internetworking layer.



M. OhtaExpires on January 1, 2001   [Page 1]

INTERNET DRAFTISPs July 2000


   A network provider of a private IP or non-IP network, which is
   connected to the Internet through an application and/or transport
   gateway is not an ISP.

   Dispit the requirement of "global connectivity", a network provider
   may use transparent firewalls to the Internet with no translation to
   filter out a limited number of problematic well known ports of TCP
   and/or UDP and can still be an ISP.  However, if filtering out is a
   default and only a limited number of protocols are allowed to pass
   the firewalls (which means snooping of transport/application layer
   protocols), it can not be regarded as full connectivity to the
   Internet and the provider is not an ISP.

3. Security Considerations

   While some people may think that filtering by application/transport
   gateways offer some sort of security, they should recognize that
   macro virus in e-mails can pass and are passing through all such
   gateways.

4. References

   [1] J. Postel, "Internet Protocol", RFC791, September 1981.

   [2] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
   Specification", RFC2460, December 1998.

   [3] B. Carpenter, "Architectural Principles of the Internet",
   RFC1958, June 1996.

5. Author's Address

   Masataka Ohta
   Computer Center, Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku, Tokyo 152-8550, JAPAN

   Phone: +81-3-5734-3299
   Fax: +81-3-5734-3415
   EMail: [EMAIL PROTECTED]












M. OhtaExpires on January 1, 2001   [Page 2]

INTERNET DRAFTISPs July 2000


6. Full Copyright Statement

   "Copyright (C) The Internet Society (July/1/2000).  All Rights
   Reserved.

   This document and translations 

Re: Defining Internet (or internet)

2000-07-09 Thread Lyman Chapin

Craig,

 From RFC 1287:

"If I could PING you, and you could PING me, then we were both on the 
Internet, and a satisfying working definition of the Internet could 
be constructed as a roughly transitive closure of IP-speaking 
systems. This model of the Internet was simple, uniform, and - 
perhaps most important - testable. The IP-connectivity model clearly 
distinguished systems that were "on the Internet" from those that 
were not."

In the same RFC, we proposed a different answer to your "what *IS* 
the Internet?" question, based not on IP (network address) 
connectivity but on the shared domain name space managed by DNS - 
"the Internet" consists of entities nameable within the DNS, however 
they may be interconnected by underlying networks.

- Lyman

At 1:43 AM -0400 7/8/00, Craig Simon wrote:
Eric Brunner wrote:
   Anyone else with a normative legal reference, your favorite
...

I saw this in someone's sig line.

But what *IS* the internet?

It's the largest equivalence class in the reflexive transitive symmetric
closure of the relationship "can be reached by an IP packet from".
--Seth Breidbart


cls

-
This message was passed through [EMAIL PROTECTED], which
is a sublist of [EMAIL PROTECTED] Not all messages are passed.
Decisions on what to pass are made solely by Harald Alvestrand.




Re: Any RFCs describing mailing list subscription practice?

2000-07-09 Thread Donald E. Eastlake 3rd


As far as I know, there is no such IETF document.  The only even
vaguely related RFCs I know of are 2369 and 1211.  Standardizing list
processor commands has proven to be very controversial.  But a BCP
supporting use of a mail loop to confirm subscription would be a good
thing and should be doable...

Thanks,
Donald

From:  Ross Finlayson [EMAIL PROTECTED]
Message-Id:  [EMAIL PROTECTED]
X-Sender:  [EMAIL PROTECTED]
Date:  Sun, 09 Jul 2000 17:18:32 -0700
To:  [EMAIL PROTECTED]

Do we have any RFCs (or even I-Ds) that describe the preferred '3-way 
handshake' method for validating a request to subscribe to a mailing list - 
i.e., to first send back - to the requester's source email address - a 
"please confirm your subscription" response message (preferably containing 
a random token), and then add the address to the mailing list *only if* the 
user responds to this second message?

I am constantly fighting with clueless (or lazy, or opportunistic) mailing 
list operators who insist on adding bogus email addresses - containing my 
domain name - to their mailing lists, without first confirming their 
validity.  It would be nice if there were an IETF document that I could 
point them at.

   Ross.