- NANOG - lists.nanog.org

Re: Motion for a new POST NSF AUP
by Havard.Eidnes＠runit.sintef.no 16 Oct '95

16 Oct '95

> Another suggestion was that SMTP headers always contain the > IP address. I've seen this in quite a few mailers already. > All we need is a slight modification to the SMTP Receipt > standard. This could be a Best Current Practice, quickly > published! Hm, this is already covered. RFC 1123 says: 5.2.8 DATA Command: RFC-821 Section 4.1.1 ... * The FROM field SHOULD contain both (1) the name of the source host as presented in the HELO command and (2) a domain literal containing the IP address of the source, determined from the TCP connection. ... DISCUSSION: Including both the source host and the IP source address in the Received: line may provide enough information for tracking illicit mail sources and eliminate a need to explicitly verify the HELO parameter. Thus, this is not a new suggestion (RFC 1123 is dated Oct 1989). Regards, - Håvard

1 0

Re: Motion for a new POST NSF AUP
by Vadim Antonov 16 Oct '95

16 Oct '95

-----BEGIN PGP SIGNED MESSAGE----- I would really like to see mailing lists starting to distribute *only* PGP-signed messages, with PGP key published in a keyserver with appropriate credentials. There already are mailers which call PGP automatically, so the user is not required to type something like ~| pgp -fsat every time. This is not a high magic. This is a matter of three lines of code, and some patience of the list maintainer. It is also good as it will proliferate good encryption software, and teach people how to protect themselves. - --vadim -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMIIlOUDODjim2XUVAQFhPQP/dS+LMSX5eJ1x4v/nL3eHYlX1DmCAxt6M Uor3umYz7moHo8ztBe6NoMUj/ovncq4oQhqZEnXj6RtHXHX+zZbupVISnNw+GUUB E/TJTGRgTkyadqGINA5lHopZJp/tsQ9Rmn1PE6uQelLkkHJ9FS3J5gcpwewmRlQv oylV8EQ1P48= =oLiq -----END PGP SIGNATURE-----

1 0

Re: Motion for a new POST NSF AUP
by William Allen Simpson 16 Oct '95

16 Oct '95

> From: Tim Bass <bass(a)dune.silkroad.com> > a) Unenforceable; > b) Subject to abuse; and > c) Virtually impossible to authenticate. > I disagree with all of these premises. c) I have been working for years on authentication. Many if not most PPP links are now authenticated. We finally have a IETF Proposed Standard for IP authentication. Another suggestion was that SMTP headers always contain the IP address. I've seen this in quite a few mailers already. All we need is a slight modification to the SMTP Receipt standard. This could be a Best Current Practice, quickly published! b) Given some degree of authentication, I do not believe that abuse will be a serious problem. Fake postings "on behalf" of other parties will be reasonably refutable. There is the problem of dial-in links and such where the ISP refuses to disclose who the perpetrator actually is, for "privacy" reasons. In that case, the message appears to be from the ISP. If the ISP wishes to take responsibility, and protect the client, that is certainly the option of the ISP. But it has a cost! a) I have told folks how to enforce this on the IETF list (last year), and the DNS list more recently. In the "Janet Dove" spam, here is what I replied to janetdove(a)infosat.com: > Date: Fri, 08 Sep 1995 18:28:18 -0500 > From: janetdove(a)infosat.com (Janet Dove) > Subject: ===>> FREE 1 yr. Magazine Sub sent worldwide- 315+ Popular USA Titles > Newsgroups: info.ietf.isoc,info.ietf.njm,info.ietf.smtp,info.inet.access,info.isode,info.jethro-tull,info.labmgr,info.mach,info.mh.workers,info.nets,info.nsf.grants,info.nsfnet.cert,info.nsfnet.status,info.nupop,info.nysersnmp,info.osf,info.pem- Your spammed message was sent to multiple newsgroups and mailing lists. It cost the providers of the service several million US dollars to carry your spam. Please justify why this message pertains to the IETF or the Internet Society. My fee for use of my computers, line and time to read your message is $150 each. Please remit $450 to: William Allen Simpson 1384 Fontaine Madison Heights, Michigan 48071 Payable within 30 days; compound interest at 2% per each successive 30 days or fraction thereof. Please note that failure to remit timely payment may result in a class action suit on behalf of all parties spammed, including each such list and each individual subscriber. You may question whether this is enforceable? I assert that it is. This is based on previous reported case history for unsolicited fax advertisements. I understand (I am not a lawyer) that charging for actual losses to my property (cost of my personal equipment and time) is enforceable. In short, _money_ is what we are talking about here! > If we define a Post NSF AUP, then at least everyone who uses the Internet > will have had the opportunity to have read and understood what the current > Internet AUP describes. > I agree! Or, if they don't read it and understand it: "ignorance is no defense". Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Motion for a new POST NSF AUP
by Tim Bass 15 Oct '95

15 Oct '95

Ladies and Gentlemen...... A couple of interesting points have developed as a result of the latest 'spam event'. The first one is debatable, but I would like to comment, that my mailbox received 'one spam message' (which I deleted in a few milliseconds) that generated hundereds of 'anti-spam messages'. Causal to the 'spam' I would like to refer to the anti-spam messages as 'son-of-spam' :-) Second, it is somewhat clear that as long as we have 'spam' we will have a causal event 'son-of-spam' . Neither 'spam' nor 'son-of-spam' are welcome e-mail in most in-boxes, and I assume by the responses, many people find 'son-of-spam' just as annoying as 'spam'. Given that both sides of the coin are correct (in their own perception space) as we have seen, I would like to put this on the table to the network: Should we define an new 'postNSF AUP' that addresses what types of messages are Acceptable Use of the Internet? Should transit and end user providers require customers to agree to 'the new "agreed upon someday" commercial AUP'? Could we even agree on what a new AUP would look like? Most everyone agrees that spam and son-on-spam are a waste of precious bandwidth, time, and energy; and unacceptable messages detract everyone from more important daily issues and ideas. I motion we create a working group to develop a draft POST NSF AUP. ------------------------------------------------------------------ We all agree we need to manage what type of messages are acceptable use of the net..... Can we make POST NSF AUP a reality? Any seconds to the motion? Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include<campfire.h> | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+

2 1

New and Improved Traceroute (semi-annual posting)
by Ehud Gavron 14 Oct '95

14 Oct '95

Date Sent: 14-OCT-1995 16:24:39 In May, I mentioned the new and improved nanog traceroute was at ftp://ftp.aces.com/software/traceroute/traceroute.c and ftp://ftp.aces.com/software/traceroute/0_readme.txt The new version now builds cleanly on: BSDI 1.1 Ultrix 4.3 SunOs 5.4 Solaris VMS Supported features: AS lookups - updated for dealing with SPRINT's Reasonable Default project and ANS's AS0 stuff. Classless support for DNS ownership Doesn't hang on network with lots of ICMP packets Wishlist: 1. That someone with FreeBSD make it work on there ;-) 2. Ditto for anyone with AIX... Ehud -- Ehud Gavron (EG76) gavron(a)Hearts.ACES.COM

1 0

Re: BGP4 peering wiht Sprint, and MCI
by rcraig＠cisco.com 14 Oct '95

14 Oct '95

Hey, Nathan, try using static routes, then exporting them to BGP: static { 204.17.64.0 masklen 24 gateway <gwaddr>; 204.183.0.0 masklen 19 gateway <gwaddr>; 205.215.0.0 masklen 18 gateway <gwaddr>; }; export proto bgp as <asnum> { # connected networks, if necessary proto direct { ALL metric <whatever>; }; # statics, you may want to do less than all, see gated docs ;-) proto static { ALL metric <whatever>; }; }; At 14:34 95/10/14, Nathan Stratton wrote: >We have a 486 DX4 100 with 40 megs of ram running FreeBSD and gated with a >T1 to Sprint and a T1 to MCI. I have a few questions that someone may be >able to answer. > >If my Sprint T1 goes down, how long will it take for route to drop out of >the routing table? Should be pretty quick. > >I have peering going with sprint and MCI and I have about 31,000 routes >in my routing table. When I called up sprint and MCI they said they were >not getting routes form me. How do I advertize my CIDR blocks to sprint >and mci via BGP4? > >I have: > >204.17.64.0/24 >204.183.0.0/19 >205.215.0.0/18 > >Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! >--------------------------------------------------------------------------- >Phone (703)524-4800 NetRail, Inc. >Fax (703)534-5033 2007 N. 15 St. Suite B-5 >Email sales(a)netrail.net Arlington, Va. 22201 >WWW http://www.netrail.net/ Access: (703) 524-4802 guest >--------------------------------------------------------------------------- Robert.

1 0

Re: DNS delegation for non-octet boundaries
by sob＠academ.com 12 Oct '95

12 Oct '95

1 0

Re: DNS delegation for non-octet boundaries
by William Allen Simpson 12 Oct '95

12 Oct '95

> From: Geert Jan de Groot <GeertJan.deGroot(a)ripe.net> > People have been using this for some time already, it is just not > widely known which is why havard and I wrote it down. > > Re-sending the (slightly updated) draft is long overdue. > I'll try to fix that ASAP > Better yet, send an updated version directly to IESG(a)cnri.reston.va.us for publication as a Best Current Practice! Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

DNS delegation for non-octet boundaries
by Jeremy Porter 12 Oct '95

12 Oct '95

At the most receint NANOG some methods of delegating DNS (in-addr.arpa's) on non octet boundaries was disccused. If I remember correclty there were two parts to this, regarding delegating individual records, and some other process. If anyone has any references to this, I would apprecated it. We are looking into this and also automatic or assisted renumbering to help reduce allocation growth and router table sizes. -- ---------------------------------------------------------------------------- | Jeremy Porter (512)-339-6094 Freeside Communications, Inc. info(a)fc.net | | jerry(a)fc.net (512)-339-4466 (data) P.O. Box 530264 Austin, TX 78753 | ----------------------------------------------------------------------------

3 3

None
by Lucia Cerbai 10 Oct '95

10 Oct '95

subscribe l.cerbai(a)iunet.it

1 0