Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 23 Jan 87 21:46:41 EST Received: from jade.berkeley.edu (TCP 20010104011) by AI.AI.MIT.EDU 23 Jan 87 21:33:39 EST Received: from web.berkeley.edu by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.8) id AA11371; Fri, 23 Jan 87 18:33:26 PST Received: by web.Berkeley.Edu (1.1/SMI-3.0DEV3.4) id AA18502; Fri, 23 Jan 87 18:36:16 PST Date: Fri, 23 Jan 87 18:36:16 PST From: netinfo%web.Berkeley.EDU@BERKELEY.EDU (Postmaster & BITINFO) Message-Id: <8701240236.AA18502@web.Berkeley.Edu> To: header-people@ai.ai.mit.edu Subject: mail tranfer agent/gateway on an IBM PC Cc: RAF@NIHCU.BITNET Can anyone help RAF%NIHCU.BITNET@WISCVM.WISC.EDU? Anybody know of anyone running a mail tranfer agent on an IBM-PC? From: "Roger Fajman" Date: Sat, 17 Jan 87 20:58:19 EST Subject: RFC822 parsing on IBM PC Do you have any programs that parse RFC822 headers that might be portable to an IBM PC running under DOS? I want to build a BITNET-3COM Ethernet gateway. Alan Crosswell suggested Berkeley Unix Mail. Roger Bill Wells postmaster%jade@Berkeley.EDU  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 27 Jan 87 13:38:40 EST Received: from BRL-SEM.ARPA (TCP 30001213410) by AI.AI.MIT.EDU 27 Jan 87 13:36:41 EST Received: by SEM.BRL.ARPA id aa05682; 27 Jan 87 13:17 EST Date: Tue, 27 Jan 87 12:41:53 EST From: Ron Natalie To: Postmaster & BITINFO cc: header-people@ai.ai.mit.EDU, RAF%nihcu.bitnet@BRL.ARPA Subject: Re: mail tranfer agent/gateway on an IBM PC Message-ID: <8701271241.aa05311@SEM.BRL.ARPA> Yes, I have two routines written in C. One parses any arbitrary legal format "address" such as found in FROM, TO, CC lines, etc. The other processes most date formats found in mail, legal or otherwise. ------------------------------------------------------------- #include "stdio.h" #include "ctype.h" char *qindex(); /* * G E T _ A D D R * * Reads one address from the string and returns a pointer to * the next address in the string. */ char * get_addr(cp, ap) register char *cp; struct addr_p *ap; { char linebuf[128]; register char *dp; ap->a_phrase = 0; ap->a_local = 0; ap->a_domain = 0; cp = eatwhite(cp); if(cp == 0 || *cp == 0) return cp; dp = qindex(cp, ":@<,;", 0); switch(*dp) { case ':': /* * Was beginning of "List" operation. * Discard before colon and go again. */ return get_addr(dp+1, ap); case '<': ap->a_phrase = strnalloc(cp, dp - cp); break; case '@': case ',': case 0: case ';': ap->a_local = strnalloc(cp, dp - cp); if(*dp == '@') break; if(*dp) dp++; return dp; } if(*dp != '@') { cp = eatwhite(dp+1); /* * At-sign here means route spec. */ if(*cp == '@') { cp = qindex(cp, ":", 1); if(*cp) cp++; } if(*cp == 0) return cp; dp = qindex(cp,"@,;>", 0); ap->a_local = strnalloc(cp, dp - cp); if(*dp != '@') { if(*dp == '>') { dp = qindex(dp+1, ",;",0); } if(*dp) dp++; return dp; } } cp = eatwhite(dp+1); if(*cp == 0) return cp; dp = qindex(cp, ">,;", 1); ap->a_domain = strnalloc(cp, dp - cp); if(*dp == '>') dp = qindex(dp+1, ",;", 1); if(*dp) dp++; return dp; } /* * Q I N D E X * * Look for the first occurence of one of the characters in * the string "lookfor" in "s". Apply commenting and quoting * conventions so atoms are not looked into. "domain" when non-zero * causes check to made for domain literals. */ char * qindex(s, lookfor, domain) register char *s; char *lookfor; int domain; { register char *lp; int commentlevel; while(*s) { switch(*s) { case '"': s++; while(1) { if(*s == '"') break; if(*s == '\\') s++; if(*s == 0) return s; s++; } break; case '(': commentlevel = 1; s++; while(commentlevel) { if(*s == ')') { --commentlevel; continue; } if(*s == '(') commentlevel++; if(*s == '\\') s++; if(*s == 0) return s; s++; } break; case '[': if(domain) { s++; while(1) { if(*s == ']') break; if(*s == '\\') s++; if(*s == 0) return s; s++; } break; } /* FALLTHROUGH */ default: lp = lookfor; while(*lp) if(*lp++ == *s) return s; } s++; } return s; } -------------------------------------------------------- #include "stdio.h" #include "ctype.h" #include "time.h" /* * S M T P _ D A T E * * Take a RFC822 (more or less) date a string cp and turn in to * unix time and queue up couple. Allows a variety of illegal * formats commonly in use. * * BUG: Should do something with time zone. * Algorithm stolen from system V date program. */ /* * Month tab matches month names to number. */ struct match_tab month_tab[] = { "jan", 1, "feb", 2, "mar", 3, "apr", 4, "may", 5, "jun", 6, "jul", 7, "aug", 8, "sep", 9, "oct", 10, "nov", 11, "dec", 12, NULL, 0 }; #define H(x) ( (x)*60*60) struct match_tab zone_tab[] = { "ut", 0, "gmt", 0, "est", H(-5), "edt", H(-4), "cst", H(-6), "cdt", H(-5), "mst", H(-7), "mdt", H(-6), "pst", H(-8), "pdt", H(-7), "z", 0, "a", H(-1), "b", H(-2), "c", H(-3), "d", H(-4), "e", H(-5), "f", H(-6), "g", H(-7), "h", H(-8), "i", H(-9), "k", H(-10), "l", H(-11), "m", H(-12), "n", H(1), "o", H(2), "p", H(3), "q", H(4), "r", H(5), "s", H(6), "t", H(7), "u", H(8), "v", H(9), "w", H(10), "x", H(11), "y", H(12), NULL, 1 }; #define dysize(A) (((A)%4) ? 365: 366) static int dmsize[12] = { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }; extern int timezone, daylight; long smtpdate(cp) register char *cp; { int day, month, year, hours, minutes, seconds; int dayno; struct couple *c, *pc; long tval; int i; char *dp; int zone; cp = eatwhite(cp); dp = cp; /* * Look for digit, supposed to be day of the month, skipping * over day of the week stuff. */ while(1) { if(*cp == 0) goto bad_date; if(isdigit(*cp)) break; cp++; } day = atoi(cp); /* Skip digits and white space to get to month. */ while(isdigit(*cp)) cp++; while( *cp == SPACE || *cp == HTAB || *cp == '-') cp++; month = match(month_tab, cp, 3); if(month == 0) { /* Hack here, look for ctime format. */ day = atoi(&dp[8]); month = match(month_tab, &dp[4], 3); if(month == 0) goto bad_date; year = atoi(&dp[24]); hours = atoi(&dp[11]); minutes = atoi(&dp[14]); seconds = atoi(&dp[17]); zone = -match(zone_tab, &dp[20], 3); printf("year = %d, zone = %d\n", year, zone); if(zone == -1 && year == 0) year = atoi(&dp[20]); printf("year = %d\n", year); } else { /* Skip over to the year */ while(1) { if(*cp == 0) goto bad_date; if(isdigit(*cp)) break; cp++; } year = atoi(cp); while(isdigit(*cp)) cp++; while(*cp && !isdigit(*cp)) cp++; /* Hours, minutes, seconds */ hours = atoi(cp); if(hours > 60) { minutes = hours %100; hours = hours/100; } else { cp = strchr(cp, ':'); if(cp == NULL) goto bad_date; minutes = atoi(++cp); } dp = strchr(cp, ':'); if(dp) { seconds = atoi(++dp); cp = dp; } else seconds = 0; while(isdigit(*cp)) cp++; cp = eatwhite(cp); if( (*cp == '+' || *cp == '-') && isdigit(cp[1]) && isdigit(cp[2]) && isdigit(cp[3]) && isdigit(cp[4]) ) { zone = atoi(cp+3); cp[3] = 0; zone = atoi(cp+1); if(*cp == '-') zone = -zone; } else { dp = cp; while(isalpha(*cp)) cp++; *cp = 0; zone = -match(zone_tab, dp, 0); } } if(year < 1900) year += 1900; if(month < 1 || month > 12) goto bad_date; if(day < 1 || day > 31) goto bad_date; if(hours == 24) { hours = 0; day++; } if(hours < 0 || hours > 23) goto bad_date; if(minutes < 0 || minutes > 59) goto bad_date; if(seconds < 0 || seconds > 59) goto bad_date; tval = 0; dayno = 0; for(i = 1970; i < year; i++) tval += dysize(i); if(dysize(year) == 366 && month >= 3) dayno += 1; while(--month) dayno += dmsize[month-1]; tval += dayno; tval += day-1; tval *= 24; tval += hours; tval *= 60; tval += minutes; tval *= 60; tval += seconds; if(zone == -1) { int beg, end; beg = sunday(119, year); end = sunday(303, year); tzset(); zone = -timezone; if(daylight && (dayno>beg || (dayno==beg && hours >=2)) && (dayno= 58 && dysize(year) == 366) d++; pdays = (pdays - 3) % 7; /* Day of week, day 0 was thurs */ if(pdays) d += 7-pdays; return d; }  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 28 Jan 87 02:59:32 EST Received: from BRL-SEM.ARPA (TCP 30001213410) by AI.AI.MIT.EDU 28 Jan 87 02:57:55 EST Received: by SEM.BRL.ARPA id aa05682; 27 Jan 87 13:17 EST Date: Tue, 27 Jan 87 12:41:53 EST From: Ron Natalie To: Postmaster & BITINFO cc: header-people@ai.ai.mit.EDU, RAF%nihcu.bitnet@BRL.ARPA Subject: Re: mail tranfer agent/gateway on an IBM PC Message-ID: <8701271241.aa05311@SEM.BRL.ARPA> Yes, I have two routines written in C. One parses any arbitrary legal format "address" such as found in FROM, TO, CC lines, etc. The other processes most date formats found in mail, legal or otherwise. ------------------------------------------------------------- #include "stdio.h" #include "ctype.h" char *qindex(); /* * G E T _ A D D R * * Reads one address from the string and returns a pointer to * the next address in the string. */ char * get_addr(cp, ap) register char *cp; struct addr_p *ap; { char linebuf[128]; register char *dp; ap->a_phrase = 0; ap->a_local = 0; ap->a_domain = 0; cp = eatwhite(cp); if(cp == 0 || *cp == 0) return cp; dp = qindex(cp, ":@<,;", 0); switch(*dp) { case ':': /* * Was beginning of "List" operation. * Discard before colon and go again. */ return get_addr(dp+1, ap); case '<': ap->a_phrase = strnalloc(cp, dp - cp); break; case '@': case ',': case 0: case ';': ap->a_local = strnalloc(cp, dp - cp); if(*dp == '@') break; if(*dp) dp++; return dp; } if(*dp != '@') { cp = eatwhite(dp+1); /* * At-sign here means route spec. */ if(*cp == '@') { cp = qindex(cp, ":", 1); if(*cp) cp++; } if(*cp == 0) return cp; dp = qindex(cp,"@,;>", 0); ap->a_local = strnalloc(cp, dp - cp); if(*dp != '@') { if(*dp == '>') { dp = qindex(dp+1, ",;",0); } if(*dp) dp++; return dp; } } cp = eatwhite(dp+1); if(*cp == 0) return cp; dp = qindex(cp, ">,;", 1); ap->a_domain = strnalloc(cp, dp - cp); if(*dp == '>') dp = qindex(dp+1, ",;", 1); if(*dp) dp++; return dp; } /* * Q I N D E X * * Look for the first occurence of one of the characters in * the string "lookfor" in "s". Apply commenting and quoting * conventions so atoms are not looked into. "domain" when non-zero * causes check to made for domain literals. */ char * qindex(s, lookfor, domain) register char *s; char *lookfor; int domain; { register char *lp; int commentlevel; while(*s) { switch(*s) { case '"': s++; while(1) { if(*s == '"') break; if(*s == '\\') s++; if(*s == 0) return s; s++; } break; case '(': commentlevel = 1; s++; while(commentlevel) { if(*s == ')') { --commentlevel; continue; } if(*s == '(') commentlevel++; if(*s == '\\') s++; if(*s == 0) return s; s++; } break; case '[': if(domain) { s++; while(1) { if(*s == ']') break; if(*s == '\\') s++; if(*s == 0) return s; s++; } break; } /* FALLTHROUGH */ default: lp = lookfor; while(*lp) if(*lp++ == *s) return s; } s++; } return s; } -------------------------------------------------------- #include "stdio.h" #include "ctype.h" #include "time.h" /* * S M T P _ D A T E * * Take a RFC822 (more or less) date a string cp and turn in to * unix time and queue up couple. Allows a variety of illegal * formats commonly in use. * * BUG: Should do something with time zone. * Algorithm stolen from system V date program. */ /* * Month tab matches month names to number. */ struct match_tab month_tab[] = { "jan", 1, "feb", 2, "mar", 3, "apr", 4, "may", 5, "jun", 6, "jul", 7, "aug", 8, "sep", 9, "oct", 10, "nov", 11, "dec", 12, NULL, 0 }; #define H(x) ( (x)*60*60) struct match_tab zone_tab[] = { "ut", 0, "gmt", 0, "est", H(-5), "edt", H(-4), "cst", H(-6), "cdt", H(-5), "mst", H(-7), "mdt", H(-6), "pst", H(-8), "pdt", H(-7), "z", 0, "a", H(-1), "b", H(-2), "c", H(-3), "d", H(-4), "e", H(-5), "f", H(-6), "g", H(-7), "h", H(-8), "i", H(-9), "k", H(-10), "l", H(-11), "m", H(-12), "n", H(1), "o", H(2), "p", H(3), "q", H(4), "r", H(5), "s", H(6), "t", H(7), "u", H(8), "v", H(9), "w", H(10), "x", H(11), "y", H(12), NULL, 1 }; #define dysize(A) (((A)%4) ? 365: 366) static int dmsize[12] = { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }; extern int timezone, daylight; long smtpdate(cp) register char *cp; { int day, month, year, hours, minutes, seconds; int dayno; struct couple *c, *pc; long tval; int i; char *dp; int zone; cp = eatwhite(cp); dp = cp; /* * Look for digit, supposed to be day of the month, skipping * over day of the week stuff. */ while(1) { if(*cp == 0) goto bad_date; if(isdigit(*cp)) break; cp++; } day = atoi(cp); /* Skip digits and white space to get to month. */ while(isdigit(*cp)) cp++; while( *cp == SPACE || *cp == HTAB || *cp == '-') cp++; month = match(month_tab, cp, 3); if(month == 0) { /* Hack here, look for ctime format. */ day = atoi(&dp[8]); month = match(month_tab, &dp[4], 3); if(month == 0) goto bad_date; year = atoi(&dp[24]); hours = atoi(&dp[11]); minutes = atoi(&dp[14]); seconds = atoi(&dp[17]); zone = -match(zone_tab, &dp[20], 3); printf("year = %d, zone = %d\n", year, zone); if(zone == -1 && year == 0) year = atoi(&dp[20]); printf("year = %d\n", year); } else { /* Skip over to the year */ while(1) { if(*cp == 0) goto bad_date; if(isdigit(*cp)) break; cp++; } year = atoi(cp); while(isdigit(*cp)) cp++; while(*cp && !isdigit(*cp)) cp++; /* Hours, minutes, seconds */ hours = atoi(cp); if(hours > 60) { minutes = hours %100; hours = hours/100; } else { cp = strchr(cp, ':'); if(cp == NULL) goto bad_date; minutes = atoi(++cp); } dp = strchr(cp, ':'); if(dp) { seconds = atoi(++dp); cp = dp; } else seconds = 0; while(isdigit(*cp)) cp++; cp = eatwhite(cp); if( (*cp == '+' || *cp == '-') && isdigit(cp[1]) && isdigit(cp[2]) && isdigit(cp[3]) && isdigit(cp[4]) ) { zone = atoi(cp+3); cp[3] = 0; zone = atoi(cp+1); if(*cp == '-') zone = -zone; } else { dp = cp; while(isalpha(*cp)) cp++; *cp = 0; zone = -match(zone_tab, dp, 0); } } if(year < 1900) year += 1900; if(month < 1 || month > 12) goto bad_date; if(day < 1 || day > 31) goto bad_date; if(hours == 24) { hours = 0; day++; } if(hours < 0 || hours > 23) goto bad_date; if(minutes < 0 || minutes > 59) goto bad_date; if(seconds < 0 || seconds > 59) goto bad_date; tval = 0; dayno = 0; for(i = 1970; i < year; i++) tval += dysize(i); if(dysize(year) == 366 && month >= 3) dayno += 1; while(--month) dayno += dmsize[month-1]; tval += dayno; tval += day-1; tval *= 24; tval += hours; tval *= 60; tval += minutes; tval *= 60; tval += seconds; if(zone == -1) { int beg, end; beg = sunday(119, year); end = sunday(303, year); tzset(); zone = -timezone; if(daylight && (dayno>beg || (dayno==beg && hours >=2)) && (dayno= 58 && dysize(year) == 366) d++; pdays = (pdays - 3) % 7; /* Day of week, day 0 was thurs */ if(pdays) d += 7-pdays; return d; }  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 4 Feb 87 19:57:56 EST Received: from RELAY.CS.NET (TCP 1201000005) by AI.AI.MIT.EDU 4 Feb 87 19:37:06 EST Received: from wellesley.edu by csnet-relay.csnet id aa24485; 4 Feb 87 15:20 EST Received: by bambam (4.12/) id AA16476; Wed, 4 Feb 87 10:17:11 est Date: Wed, 4 Feb 87 10:17:11 est From: Scott Shurr To: header-people@AI.AI.MIT.EDU Subject: sendmail Cc: sshurr@wellesley.edu I am working on improving the mail system we have running here on an Ultrix-32m V1.2 system. Unfortunately the documentation I have on sendmail (Sendmail Installation and Operation Guide, and Sendmail: An Internetwork Mail Router) does not tell me all that I need to know. Does anyone out there have any better documentation than that? Or better yet, does anyone have the source code for sendmail? I'm not interested in modifying it; only in understanding how it works. Scott Shurr - Academic Computing | internet: sshurr@wellesley.edu Science Center, Wellesley College | phone: 617-235-0320 X3262 Wellesley, MA 02181 |  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 6 Feb 87 12:57:57 EST Received: from relay2.cs.net by RELAY.CS.NET id br00958; 6 Feb 87 10:20 EST Received: from wellesley.edu by csnet-relay.csnet id ae04833; 6 Feb 87 9:04 EST Received: by bambam (4.12/) id AA18494; Thu, 5 Feb 87 10:07:58 est Date: Thu, 5 Feb 87 10:07:58 est From: Scott Shurr To: HEADER-PEOPLE@MC.LCS.MIT.EDU Subject: Sendmail I am working on improving the mail system we have running here on an Ultrix-32m V1.2 system. Unfortunately the documentation I have on sendmail (Sendmail Installation and Operation Guide, and Sendmail: An Internetwork Mail Router) does not tell me all that I need to know. Does anyone out there have any better documentation than that? Or better yet, does anyone have the source code for sendmail? I'm not interested in modifying it; only in understanding how it works. Scott Shurr - Academic Computing | internet: sshurr@wellesley.edu Science Center, Wellesley College | phone: 617-235-0320 X3262 Wellesley, MA 02181 |  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 22 Feb 87 19:36:44 EST Received: from nrtc-gremlin.arpa (TCP 20030600021) by AI.AI.MIT.EDU 22 Feb 87 19:36:19 EST Received: from nrtc-gremlin by nrtc-gremlin.arpa id a005895; 22 Feb 87 16:31 PST To: ARPANET-BBOARDS@mc.lcs.mit.EDU, Header-People@ai.ai.mit.EDU, HUMAN-NETS@rutgers.rutgers.EDU, INFO-NETS%MIT-OZ@mc.lcs.mit.EDU, MMM-PEOPLE@c.isi.EDU, NAMEDROPPERS@sri-nic.ARPA, TELECOM@xx.lcs.mit.EDU, MHS_IMPLEMENTATION@rsch.wisc.EDU Subject: IFIP 6.5 Conference Programme Date: Sun, 22 Feb 87 16:31:10 -0800 Message-ID: <5892.541038670@nrtc-gremlin.arpa> From: Einar Stefferud ------- Forwarded Message Subject: IFIP 6.5 Conference Programme From: Hugh Smith To: mailgroup@cs.ucl.ac.UK, msp%cs.qmc.ac.uk@cs.ucl.ac.UK, ifip6pt5%computer-science.nottingham.ac.uk@cs.ucl.ac.UK Date: Fri, 20 Feb 87 12:03:27 GMT ******************************************************************************* IFIP WG 6.5 Working Conference on Message Handling Systems Munich, April 27 to 29, 1987 ------------------------------------------------------------------------------ Final Program ------------------------------------------------------------------------------ Monday, April 27 **************** 1000-1130 Opening Session Chair: Peter Schicker, Chairman of IFIP WG 6.5 Welcome Address IFIP WG 6.5 Report Peter Schicker(*), Einar Stefferud(#), Hugh T. Smith(%) (*)Zellweger Telecommunications AG, Hombrechtikon, CH (#)Network Management Associates Inc., Huntington Beach, USA (%)University of Nottingham, UK 1130-1300 Session 1 "MHS Interconnection and Interworking" Chair: Horst Santo, GMD, St. Augustin, FRG "Interconnection of X.400 Systems and Notable Gateways" Thomas Magedanz, Michael Tschichholz, Karl-Heinz Weiss Hahn-Meitner Institut, Berlin "X.400, Towards Global Connectivity" Bernhard Laborie, Christian Huitema, INRIA, Rocquencourt, F "MHS-PDS Interworking and Teleimpression Postale" Jean-Bernard Stefani, SEPT, Caen, F "A Gateway between COM and X.400" Pierre Godelaine, Isabelle Debry, Andre Danthine Universite de Liege, B 1430-1600 Session 2 "Interconnection, Directory Services Chair: Christian Huitema, INRIA, Rocquencourt, F "Adaptation and Connection of KOMEX to X.400" Robert Babatz, Manfred Bogen, GMD, St. Augustin, FRG "Norman: A Multiple Protocol Mail Reading/Composing Program" John Callahan, Mark Weiser, University of Maryland, USA "Distributed Name Management" Karen R. Sollins, David D. Clark, MIT, Boston, USA "Addressing in an Office Procedure System" Thomas Kreifelts, Peter Seuffert, GMD, St. Augustin, FRG 1630-1800 Session 3 "Directory Services" Chair: Ole Jorgen Jacobsen, SRI, Menlo Park, USA "The ISO/CCITT Directory as a Distributed Data Base: Data Models" Thomas Lenggenhager(*), Bernhard Plattner(*), Rolf Stadler(#), Andreas Zogg(*) (*)ETH Zurich, CH (#)Universitat Zurich, CH "The Design of a Directory System" E. Bertino(*), F. Dilonardo(#), P. Penelli(#), F. Rabatti(*) P. Romanazzi(#), C. Thanos(*) (*)Instituto Elaborazione Informazione, Pisa, I (#)CSATA, Bari, I "MHS Use of Directory Service for Routing" Steve E. Kille, University College London, UK "Pilot Distribution Lists - Agents and Directories" Steve Benford, Julian Onions, University of Nottingham, UK 1830 Bayrische Brotzeit Special Bavarian Get-together Tuesday, April 28 ***************** 0900-1100 Session 4 "Group Communication" Chair: Hugh T. Smith, University of Nottingham, UK "The Use of Distribution Lists in MHS" Christian Huitema(*), Juan Antonio Saras(#) (*)INRIA, Rocquencourt, F (#)ETSITM, Madrid, E "Requirements for Group Communication - Support in Electronic Communication" Uta Pankoke-Babatz, GMD, St. Augustin, FRG "Group Communication and Related Aspects in Office Automation" Wolfgang Prinz(*), Rolf Speth(#) (*)GMD, St. Augustin, FRG (#)CEC, Bruxelles, B "CRMM - A Distributed Bulletin Board" Paul Andre Pays, Phillip Brun, Ecole Nationale Superieure de Mines, Saint-Etienne, F "Relation and Inheritance in Group Communication" Thore Danielson(*), Trine Folkow(#), Per Wiggo Richardsen(#) (*)GMD, St. Augustin, FRG (#)University of Tromsoe, N 1130-1300 Session 5 "Message Management" Chair: Uta Pankoke-Babatz, GMD, St. Augustin, FRG "Key Issues in Structured Messaging" Paul Wilson, Computer Science Company Ltd, Slough, UK "Electronic Message Processing: Aspects of Filing and Retrieving Messages" Bernhard Plattner(*), Franz X. Steinparz(#) (*) ETH Zurich, CH (#) Universitat Zurich, CH "AMIGO: Document Storage and Retrieval" Jakob Palme, QZ, Stockholm, S "Use of SQL for Message Storage and Retrieval" Jaime Delgado(*), Manuel Medina(*), Berthold Butscher(#), Michael Tschichholz(#) (*)ETSIT, Barcelona, E (#)Hahn-Meitner Institut, Berlin 1430-1800 Workshop Discussions Discussion Topics include - Document Structure and Multi-media Messaging - Human Interfaces - Generic User Agent - MHS Interconnection - Access Protocols - Directories Wednesday, April 29 ******************* 0900-1100 Session 6 Reports from Workshops Chair: Einar Stefferud, Network Management Associates Inc., Huntington Beach, USA 1130-1300 Session 7 "Access Protocols, Workstations, and Security" Chair: Eric Lillevold, Norwegian Telecom Administration, Kjeller, N "Enhancements to X.400 Recommendations for Personal Computer Communication" Masayuki Nomura, NTT, Tokio, J "A Distributed User Agent: Concept and Implementation" Nancy Green(*), Roland Tissot(#) (*)EPFL, Lausanne, CH (#)XMIT AG, Dietikon, CH "ULLAR, a User Friendly and Flexible System for Handling Electronic Mail, Messages, and Forms" O. Lambert, V. Marcatte, SEPT, Caen, F "A Large Scale Mail Service Based on Privacy" Martin Turnbull, The Hatfield Polytechnic, Hatfield, UK 1430-1600 Session 8 "Impacts of MHS" Chair: Bernhard Plattner, ETH Zurich, CH "Access to and Usage of Integrated Office Systems: Implications for Organizational Communication" Ronald E. Rice, Douglas Shook, University of Southern California, USA "The Use of Computer Conferencing by a University Faculty" Paul J. Friedl(*), Jackie Schmidt-Posner(#), Ron Danielson(%) (*)IBM, Palo Alto, USA (#)Stanford University, USA (%)Santa Clara University, USA "The Impact of Naming on the Costs of a Computer Bulletin Board System" Judy L. Edighoffer, Keith A. Lantz, Stanford University, USA "Legally Relevant Communication via MHS?" W. J. Jaburek, Radio-Austria AG, Vienna, A 1630-1720 Session 9 "Tools and Conformance Testing" Chair: Peter Schicker, Zellweger Telecommunications AG, Hombrechtikon, CH "X.400 Conformance Testing - Quo Vadis?" Ulf Beyschlag, Softlab, Munich, FRG "PROSPECT, a Tool for Protocol Specification and Conformance Testing" Eugen A. Blau, Bernhard Plattner, Thomas Walter, ETH Zurich, CH 1720-1730 Closing Session Chair: Peter Schicker, Chairman IFIP WG 6.5 - ----------- 1830-1930 IFIP WG 6.5 Business Meeting ****************************************************************************** Conference Language: English Venue: Technische Universitat Munchen South Campus Lecture Hall S 0320 Entrance: Barer Strasse 23 or: Arcisstrasse 16 Conference Fee: DM 340.00 (before April 1); DM 50.00 late registration fee Fee includes: - conference participation - preprint of proceedings - Bayrische Brotzeit - refreshments For Registration please end the registration form with an enclosed Cheque in DM to the conference secretariat: Message Systems '87 Mrs. H. Lind Siemens AG D-AP 11 Otto-Hahn-Ring 6 D-8000 Munich 83 Tf: +49 89 6364 5379 Telex: 5 21 090 d Late registration will also be accepted at the conference itself (no credit cards). Conference Office: Institut fur Informatik Technische Universitat Conference Office MHS '87 Arcisstrasse 21 D-8000 Munich 2 Tf: +49 89 2105 8254 Email: ifip-mhs@infovax.informatik.tu-muenchen.dbp.de Transportation: A public bus (Flughafenbus) connects the airport with the main railway station. The conference site is within walking distance from the main railway station. Nearest underground station: Konigsplatz (U8); nearest tram station: Karolinenplatz (line 18). Hotel Reservation: NO hotel reservation will be done by the conference secretariat. On receipt of your registration, a map of Munich and a list of hotels (annotated) will be sent to you such that you can make direct bookings. Otherwise contact: Landeshauptstadt Munchen Fremdenverkehrsamt Postfach D-8000 Munich Tf: +49 89 239 1237 Registration Form: Name: . . . . . . . . . . . . . . . . . . . . Organization: . . . . . . . . . . . . . . . . . . . . Address: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Country: . . . . . . . . . . . . . . . . . . . . Telephone: . . . . . . . . . . . . . . . . . . . . Telex: . . . . . . . . . . . . . . . . . . . . Email: . . . . . . . . . . . . . . . . . . . . ------------------------------------------------------------------------------ ------- End of Forwarded Message  Received: from ucbarpa.Berkeley.EDU (TCP 1200000116) by MC.LCS.MIT.EDU 24 Feb 87 13:04:01 EST Received: by ucbarpa.Berkeley.EDU (5.57/1.22) id AA17243; Tue, 24 Feb 87 10:02:33 PST Date: Tue, 24 Feb 87 10:02:33 PST From: jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) Message-Id: <8702241802.AA17243@ucbarpa.Berkeley.EDU> To: header-people@mc.lcs.mit.edu Subject: Pony Express implements TURN in SMTP ...? Cc: postmaster@star.stanford.edu I keep getting indications in my log files that star.stanford.edu is trying to use the SMTP command "TURN" ... is there someone out there who thinks this should work? /jordan  Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 24 Feb 87 19:40:09 EST Received: from BIONET by SUMEX-AIM.STANFORD.EDU with Cafard; Tue 24 Feb 87 12:48:25-PST Date: Tue 24 Feb 87 12:35:10-PST From: David Roode Subject: Re: Pony Express implements TURN in SMTP ...? To: jordan@UCBARPA.BERKELEY.EDU cc: header-people@MC.LCS.MIT.EDU In-Reply-To: <8702241802.AA17243@ucbarpa.Berkeley.EDU> Phone: (415) 962-7322 Message-ID: <12281671254.47.ROODE@BIONET-20> NoNothing wrong in trying TURN. It is easy to recover from failure to implement it. -------  Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 24 Feb 87 19:40:09 EST Received: from BIONET by SUMEX-AIM.STANFORD.EDU with Cafard; Tue 24 Feb 87 12:48:25-PST Date: Tue 24 Feb 87 12:35:10-PST From: David Roode Subject: Re: Pony Express implements TURN in SMTP ...? To: jordan@UCBARPA.BERKELEY.EDU cc: header-people@MC.LCS.MIT.EDU In-Reply-To: <8702241802.AA17243@ucbarpa.Berkeley.EDU> Phone: (415) 962-7322 Message-ID: <12281671254.47.ROODE@BIONET-20> NoNothing wrong in trying TURN. It is easy to recover from failure to implement it. -------  Received: from ucbarpa.Berkeley.EDU (TCP 1200000116) by MC.LCS.MIT.EDU 24 Feb 87 19:46:05 EST Received: by ucbarpa.Berkeley.EDU (5.57/1.22) id AA01131; Tue, 24 Feb 87 16:44:28 PST Date: Tue, 24 Feb 87 16:44:28 PST From: jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) Message-Id: <8702250044.AA01131@ucbarpa.Berkeley.EDU> To: header-people@mc.lcs.mit.edu Subject: Re: Pony Express implements TURN in SMTP ...? Yes, easy to recover from failure to implement it, but who out there has implemented it and trusts it? I'd certainly like to know. Do you trust it on your machine? Why don't I just telnet there right now and see ... /jordan  Received: from SRI-IU.ARPA (TCP 1201200002) by MC.LCS.MIT.EDU 24 Feb 87 23:26:57 EST Date: Tue 24 Feb 87 19:03:45-PST From: Peter Karp Subject: Re: Pony Express implements TURN in SMTP ...? To: jordan@UCBARPA.BERKELEY.EDU Cc: header-people@MC.LCS.MIT.EDU, POSTMASTER@STAR.STANFORD.EDU Message-ID: In-Reply-To: Message from "jordan@ucbarpa.Berkeley.EDU (Jordan Hayes)" of Tue, 24 Feb 87 16:44:28 PST At the time I implemented TURN in Pony Express I wasn't aware of the security hole it involved. I have since become aware of it but have yet to get around to TURNing off this feature. I will shortly do so, thanks. Peter -------  Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 25 Feb 87 01:36:18 EST Date: Wed, 25 Feb 87 01:28 EST From: Barry Margolin Subject: Re: Pony Express implements TURN in SMTP ...? To: header-people@MC.LCS.MIT.EDU Message-ID: <870225062843.397340@MIT-MULTICS.ARPA> TURN was used in Mailnet (which is being phased out), because in this mail-only network all the connections were established by MIT-Multics, so TURN was necessary to allow the member systems to send mail. It is secure because Mailnet allowed sites to require passwords when the Multics daemon connected to member sites. TURN is only insecure when you can't verify the identity of the caller. barmar  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 25 Feb 87 11:16:34 EST Received: from relay2.cs.net by RELAY.CS.NET id ag21201; 25 Feb 87 10:56 EST Received: from buffalo by csnet-relay.csnet id ad10822; 25 Feb 87 10:20 EST Received: by gort.SUNYAB (5.51/4.7) id AA02322; Wed, 25 Feb 87 10:07:26 EST Received: by gloria.SUNYAB (5.31/5.2) id AA24947; Wed, 25 Feb 87 10:07:21 EST Date: Wed, 25 Feb 87 10:07:21 EST From: John Robert LoVerso Message-Id: <8702251507.AA24947@gloria.SUNYAB> To: jordan@UCBARPA.BERKELEY.EDU, header-people@MC.LCS.MIT.EDU Subject: Re: Pony Express implements TURN in SMTP ...? Has anybody ever implemented TURN as a call-back? I.e., I connect to you, issue TURN, and then you disconnect, and re-establish a connection back to who I said I was. This defeats the security problem with TURN.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 25 Feb 87 13:56:09 EST Received: from relay2.cs.net by RELAY.CS.NET id aa22821; 25 Feb 87 13:47 EST Received: from ub.com by RELAY.CS.NET id aa11750; 25 Feb 87 13:43 EST Date: Wed, 25 Feb 87 8:04:48 PST From: Dave Crocker To: Jordan Hayes cc: header-people@MC.LCS.MIT.EDU Subject: Re: Pony Express implements TURN in SMTP ...? Organization: Ungermann-Bass, Inc., Santa Clara, CA TURN was added to SMTP based upon similar functionality in some mail systems that existed at the time. For example, the MMDF telephone-based channel (now used by CSNet) had/has this mechanism. The principle is simply to allow the caller to hand over control of the session to the callee, whereby the callee then conducts a message-posting process, as if it had called the caller. There is a key problem with doing this on the standard Internet: security. The MMDF mechanism was tied to a standard Unix login. The standard SMTP mechanism is not. If you believe that the IP address that you can obtain, which specifies the caller, is to be trusted, then you can figure out which subset of pending mail to give to the caller. If you do not trust this derived IP address, then you are stopped cold. Dave  Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 25 Feb 87 14:20:14 EST Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Wed 25 Feb 87 11:06:28-PST Date: Wed 25 Feb 87 09:49:37-PST From: Mark Crispin Subject: Re: Pony Express implements TURN in SMTP ...? To: loverso%buffalo.csnet@CSNET-RELAY.ARPA cc: jordan@UCBARPA.BERKELEY.EDU, header-people@MC.LCS.MIT.EDU In-Reply-To: <8702251507.AA24947@gloria.SUNYAB> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12281903262.7.MRC@PANDA> There's pretty much no point to implementing TURN as a call-back, since if you have mail for the other guy you're going to try connecting to him periodically to deliver it. -------  Received: from gjetost.wisc.edu (TCP 20032201041) by MC.LCS.MIT.EDU 25 Feb 87 19:08:19 EST Date: Wed, 25 Feb 87 16:24:17 CST From: solomon@gjetost.wisc.edu (Marvin Solomon) Message-Id: <8702252224.AA05787@gjetost.wisc.edu> Received: by gjetost.wisc.edu; Wed, 25 Feb 87 16:24:17 CST To: dcrocker%engr.ub.com@relay.cs.net Subject: Re: Pony Express implements TURN in SMTP ...? Cc: header-people@mc.lcs.mit.edu The whole question of security in Internet mail systems is on a pretty shaky basis. At first glance it would seem that TURN introduces a significant additional security whole. After all, if an imposter calls me and delivers mail, the worst that could happen is that I believe forged mail, but if an imposter calls and PICKS UP mail, I can have outgoing mail stolen (which seems to upset people more). On the other hand, if I can believe TCP's idea of the other guy's internet address (and I bother to check it out), then I don't have to worry about stolen mail; and if I CAN'T trust TCP to get the foreign address right, how am I justified in feeling that I'm delivering mail to the right host, even if I initiate the connection? I have an amusing anecdote from the "real world" that illustrates this point. I was in another city attending a conference a few years ago and heard this story on the local news. It seems a prankster created quite a stir by calling a television station and, posing as the police department, reported that the mayor had been assassinated. The people at the television station were no fools; they called back to the police department to verify the story before reporting it on the news. However, the initial caller was kind enough to save them the trouble of looking up the police department's phone number in the phone book. You can figure out the rest. Now it's easy to chuckle at the gullibility of that television station. However, what if the prankster were able to get into the local telephone switching station and subvert the call routing? What if they got to the printer of phone books and altered the listing for the police station? (This is beginning to sound like an episode of "Mission: Impossible".) The application of this story to the Internet should be obvious. With a sprawling, complicated network of IMPS, gateways, local nets, etc., it's very hard, even in principle, to have much confidence in the security of IP routing. When you add the complication of the domain name server system (the analogue of the phone books) things just get worse. I might know the true internet address of a bad guy, but he might convince me that the domain name mc.lcs.mit.edu is bound to that address, and steal my mail nonetheless. It doesn't matter who initiated the connection. Spoofing is possible at every level, from ARP through domain names.  Received: from SRI-IU.ARPA (TCP 1201200002) by MC.LCS.MIT.EDU 25 Feb 87 23:45:54 EST Date: Wed 25 Feb 87 20:43:45-PST From: Peter Karp Subject: TURN To: header-people@MC.LCS.MIT.EDU Message-ID: Dave Crocker: I'm no expert on TCP, but my guess is that it's a lot easier for someone on a workstation to make an outgoing SMTP connection with a forged source address than it is for them to muck around with gateways or the domain system and convince the network to route connections for a given host to their machine. Actually, one hack that occurred to me is to only accept a TURN if you had already accepted one message from the sender-SMTP. This seems like a good heuristic for distinguishing a connection from a mailer from a connection from a hacker. To me this seems like a bit of a non-issue anyway since (a) the efficiency gain from using TURN is probably not that high, and (b) it's unlikely that a hacker knows that host A has mail in its queues for host B and is thus ripe for the picking. Peter P.S. Mark, before you get on my case, I'll apologize for my mis-use of the word "hacker" above. -------  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 26 Feb 87 00:20:43 EST Received: from relay2.cs.net by RELAY.CS.NET id ae24959; 25 Feb 87 18:08 EST Received: from ub.com by RELAY.CS.NET id ab13391; 25 Feb 87 18:04 EST Date: Wed, 25 Feb 87 13:34:49 PST From: Dave Crocker To: Mark Crispin cc: loverso%buffalo.csnet@RELAY.CS.NET, jordan@UCBARPA.BERKELEY.EDU, header-people@MC.LCS.MIT.EDU Subject: Re: Pony Express implements TURN in SMTP ...? Organization: Ungermann-Bass, Inc., Santa Clara, CA This is pushing the point, a bit, but there IS a case in which the TURN command could be useful. Vint Cerf once characterized this as the Submarine Case: You may wish to think of it as the Dial-Up Host Case... A host may have relatively small windows of connectivity, due to access constraints on the data link. In this situtation, it may be useful for the host to "help" another host to know that the first host is "now" attached. Dave  Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 26 Feb 87 03:37:15 EST Date: Thu, 26 Feb 87 03:09 EST From: Barry Margolin Subject: security of SMTP TURN and your analogy To: solomon@GJETOST.WISC.EDU cc: header-people@MC.LCS.MIT.EDU Message-ID: <870226080920.663693@MIT-MULTICS.ARPA> SMTP is not used only over TCP/IP. It is often used over networks for which it is nearly impossible to determine the caller's identity. Your analogy is closer to this type of use, since the phone system is a network on which it is difficult to verify the caller's address. Let's look at your analogy some more. It is easy to call a radio station and pretend you are the police. It is relatively difficult to trick the phone network into routing calls addressed to the police to your phone. If your data is worth protecting from people with that level of determination, you should implement security at the higher levels, such as making a password necessary before the SMTP server will talk to you. However, if you merely disable TURN, you can have a reasonable amount of confidence that your mail isn't being stolen. Another real world analogy is the rule not to give your credit card number to a phone solicitor who called you, only to people you called. Of course, you are trusting that the advertisement you responded to was legit; however, faking a magazine ad takes more guts than just calling people randomly. It is also possible to check with friends, the BBB, etc. before calling someone up. barmar  Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 14 Mar 87 03:03:21 EST Date: Sat 14 Mar 87 00:58:49-MST From: Frank J. Wancho Subject: Black Art: sendmail.cf files To: TCP-IP@SRI-NIC.ARPA, HEADER-PEOPLE@MC.LCS.MIT.EDU cc: WANCHO@SIMTEL20.ARPA Message-ID: <12286252158.8.WANCHO@SIMTEL20.ARPA> It seems the root of many of the improperly formed message headers, and the reason that many hosts have had difficulty in switching to the domain format host names is poorly constructed sendmail.cf files. This problem will shortly become acute when the NIC will no longer disribute its HOSTS.TXT file containing host alias entries. Therefore, I'd like to propose that a small handful of sendmail wizards get together and produce one proven sendmail.cf file for each of the major environments: Internet only, UUCP only, a combination of the two, and whatever else they deem necessary. Then make the resulting versions available either somewhere on NIC or ucbvax or both, and advertise where they are. Of course, if this has been done already, it would pay to make that information known much more widely, particularly at this time. --Frank -------  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 MAR 87 14:48:46 EST Received: by EDDIE.MIT.EDU (5.31/4.7) id AA27949; Sat, 14 Mar 87 14:44:48 EST Received: by mit-erl id AA17228g; Sat, 14 Mar 87 14:42:16 EST Date: Sat, 14 Mar 87 14:42:16 EST From: Stephen Gildea To: WANCHO@SIMTEL20.ARPA Cc: HEADER-PEOPLE@MC.LCS.MIT.EDU In-Reply-To: Frank J. Wancho's message of Sat 14 Mar 87 00:58:49-MST Subject: Black Art: sendmail.cf files I have some sendmail.cf stuff that I'm pretty proud of (runs on UUCP only, UUCP with local ethernet, and Internet with UUCP), so I volunteer to be part of the effort to write some general purpose-config files. < Stephen  Received: from j.cc.purdue.edu (TCP 1200200045) by MC.LCS.MIT.EDU 14 Mar 87 19:30:22 EST Received: by j.cc.purdue.edu; Sat, 14 Mar 87 19:26:29 EST Date: Sat, 14 Mar 87 19:26:29 EST From: "Wombat" Message-Id: <8703150026.AA13741@j.cc.purdue.edu> To: header-people@mc.lcs.mit.edu Subject: Re: Black Art: sendmail.cf files I'd just like to point people in the general direction of "ease", which is a configuration language for writing sendmail config files. A paper on it appeared in the January '86 ;login, published by the Usenix Assoc.; the source, paper, and the whole shebang may be anonymous-ftp'ed from this machine (j.cc.purdue.edu to most, asc.cc.purdue.edu to a few)... just ftp in, and look in the directory "pub". Rich Kulawiec Purdue University Computing Center  Received: from HERMES.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 MAR 87 21:04:11 EST Received: by hermes.ai.mit.edu; Sat, 14 Mar 87 21:02:43 EST Date: Sat, 14 Mar 87 21:02:43 EST From: dms@hermes.ai.mit.edu (David M. Siegel) To: WANCHO@simtel20.arpa Cc: TCP-IP@sri-nic.arpa, HEADER-PEOPLE@mc.lcs.mit.edu, WANCHO@simtel20.arpa In-Reply-To: Frank J. Wancho's message of Sat 14 Mar 87 00:58:49-MST <12286252158.8.WANCHO@SIMTEL20.ARPA> Subject: Black Art: sendmail.cf files I have a sendmail.cf file that works fairly well. It has extra stuff in it for our local chaosnet hosts, and I think it does a few things incorrectly here and there, but it would be a good starting point for someone who might want to tune it up a bit. It uses the domain system and I've stripped out all the Berkeley specific cruft that most people have. It's much less confusing than the standard distribution file. It's in the public ftp area on hermes.ai.mit.edu.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Mar 87 14:19:33 EST Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 15 Mar 87 14:18:41 EST Received: from SEARN(MAILER) by MITVMA (Mailer X1.23) id 8715; Sun, 15 Mar 87 14:08:14 EST Received: from TQZCOM(MAILER) by SEARN (Mailer X1.23b) id 0862; Sun, 15 Mar 87 20:08:31 EDT Message-ID: <239919@QZCOM> Date: 15 Mar 87 14:21 +0100 From: "Jacob Palme QZ" Reply-To: "Jacob Palme QZ" , "External mail experience" , "Academic network cooperation group (IFIP)" To: "ARPA Internet Mail Interest List" , "External mail experience" , "Academic network cooperation group (IFIP)" , Academic_network_cooperation@WISC-RSCH.ARPA Subject: Use of a polar satelite for academic nets An earth satelite in a polar orbit has the advantage that it will not, as a geo-stationary satelite, stay over the same area of the Earth all the time. Instead, the satelite will move so that it will cover the whole Earth in a few hours. It could thus upload mail over one area, and then download mail over another area. A satelite in a polar orbit can also be made much smaller and cheaper than a geo-stationary satelite. I have talked to some people at the Swedish Space Corporation, and they say that two put up two small such satelites in orbit would cost very approximately 50 million dollars. Each ground station will cost about 15 000 dollars. The satelite will have a storage capacity of 10 Megabyte of text, and transmission to the ground is done at a speed of 64 kbit/second. The satelite will be in a place to be able to reach a certain spot on Earth for about ten minutes every two or three hours. During those ten minutes, several Earth stations may have to compete for the transmission speed to the ground of 64 kbit/second. I think it would be very interesting to compute if such a satelite would be worthwhile and suitable for the international academic mail networks. The advantage with the satelite would be higher for messages sent to many recipients (mailing lists) and for reaching recipients in developing countries, where the poor ground- based network technology may mean that a ground station for satelite communication is the best way of getting their researchers into contact with the rest of the world. --- Here is a first rough computation. We at QZ are at present downloading 33 mailing lists, coming mostly from ARPANET or BITNET. The total volume of text which we are downloading, including personal messages also, is about 200 000 bytes/day. The total volume we are sending is about 80 000 bytes/day. Assuming that the satelite would need to hold messages to/from us for an average time of 4 hours, our traffic volume would use about 50 KiloByte of the storage capacity of the satelite. A satelite with a capacity of 10 Mbyte of storage would thus be able to serve about 200 sites of our size. However, since many of the mailing-list messages are the same to several sites, the satelite might actually be able to serve about 300 sites of our size. Assuming two-year payment of the costs, we would then have to pay about 100 000 dollars/year for the service of the satelite. That seems to me to be much more than the cost of using an Earth- based network like MAILNET or CSNET over public X.25 nets. So a satelite does not seem to be cost-effective, at least not for us in the industrialized countries. But I would be very interested to hear other peoples reactions or computations on the idea.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Mar 87 15:36:05 EST Received: from USC-ECLB.ARPA (TCP 3201600101) by AI.AI.MIT.EDU 15 Mar 87 15:35:20 EST Date: Sun 15 Mar 87 12:31:14-PST From: Bob Larson Subject: Re: Use of a polar satelite for academic nets To: JPALME%QZCOM@JADE.BERKELEY.EDU, C252%QZCOM@JADE.BERKELEY.EDU, C355%QZCOM@JADE.BERKELEY.EDU cc: header-people@AI.AI.MIT.EDU, C252%QZCOM@JADE.BERKELEY.EDU, C355%QZCOM@JADE.BERKELEY.EDU, Academic_network_cooperation@RSCH.WISC.EDU In-Reply-To: <239919@QZCOM> Message-ID: <12286651276.13.BLARSON@USC-ECLB.ARPA> I don't think such a system has a chance of succeeding, especialy when compared to StarGate. StarGate, just starting in a large scale test, is a potential replacement for usenet in north america. (Usenet averages around 10 Megabytes a week of trafic, including many arpanet mailing lists.) They are renting a portion of the vertical blanking interval of a commercial station, and the cost of is around $1000 plus a cable feed of WTBS or an off the shelf home tv ground station. For details, read the usenet newsgroup news.stargate or ask someone involved. (vortex!lauren did much of the work on StarGate.) -------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Mar 87 22:19:01 EST Received: from EDDIE.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 MAR 87 22:18:09 EST Received: by EDDIE.MIT.EDU (5.31/4.7) id AA28556; Sun, 15 Mar 87 22:16:02 EST Received: by rutgers.edu; Sun, 15 Mar 87 21:57:02 EST Received: from cbpavo.MIS.OH.ATT.COM (cbpavo.ARPA) by cbosgd.MIS.OH.ATT.COM (4.12/smail2.2/01-16-87) id AA05878; Sun, 15 Mar 87 21:12:39 est Received: by cbpavo.MIS.OH.ATT.COM (3.2/3.14) id AA02552; Sun, 15 Mar 87 21:12:42 EST Date: Sun, 15 Mar 87 21:12:42 EST From: rutgers!mark@cbpavo.MIS.OH.ATT.COM (Mark Horton) Message-Id: <8703160212.AA02552@cbpavo.MIS.OH.ATT.COM> To: C252@qzcom.bitnet, C355@qzcom.bitnet, header-people@ai.ai.mit.edu Subject: Re: Use of a polar satelite for academic nets No doubt about it, satellites are expensive. But there are alternatives to buying your own satellite. You noted that you don't really need the whole satellite, and that you'd like to find 300 similar partners to share it. (Of course, you'd never find very many whose needs are very similar to yours.) If you can find someone who already has a satellite with excess capacity, you may be able to buy time on it for a fraction of the cost of your own satellite. As a principal of such a service, I can give an example. Stargate Information Services uses the vertical interval of a TV channel (Superstation WTBS) to encode data. It is fed to the satellite in Atlanta as part of the TV signal, and can be decoded with special decoder boxes from any Cable-TV service carrying WTBS, or with an inexpensive satellite dish. (Equipment costs range from $800 with a Cable-TV hookup to a few thousand dollars with a dish.) We are currently entering an experimental phase, so final subscription costs have not been set, but we are offering 6 month experimental subscriptions for $900 plus the cost of equipment. Stargate is ideal for mass mailings, such as mailing lists and discussion groups. The bulky data, which is so expensive to transmit via land lines, can be broadcast to subscribers at a fixed cost, with a very high bandwidth. Our 2400 BPS channel provides an application layer throughput of about 85 bytes/second. (Since there is no way to XOFF or NAK the satellite, a lot of redundancy is required in the transmissions.) This works out to about 300K bytes/hour. We repeat transmissions often, since we don't have enough data to fill up that capacity, and since outages in the signal can cause all the redundant information of a particular messsage to be lost. Stargate is also a useful mechanism for the distribution of large items, such as source code and connection maps. Submissions and email responses travel via ordinary land lines, but these account for a very small per-site cost relative to the bulk distributions. Our major capacity limitation turns out to be the size of the 20 MB disk on our uplink machine. The major disadvantage to Stargate in your forum is that we are limited to the areas that receive WTBS. In practice, this means the USA, although there may be hope for southern Canada. Our technology is built around the NTSC TV format, so it would have to be re-developed for Europe. However, it may be possible to use a network of such local satellites to achieve international communication at lower cost than actually buying your own satellite. The many sites in the USA could use Stargate, and similar technology might be developed for other regions. Mark Horton mark@Stargate.COM stargate!mark@a.cs.uiuc.edu  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Mar 87 17:53:55 EST Received: from mimsy.umd.edu (TCP 3200400071) by AI.AI.MIT.EDU 16 Mar 87 17:53:12 EST Received: by mimsy.umd.edu (5.9/4.7) id AA06880; Mon, 16 Mar 87 17:48:33 EST Date: Mon, 16 Mar 87 17:48:33 EST From: Michael Grant Message-Id: <8703162248.AA06880@mimsy.umd.edu> To: C252%qzcom.bitnet@umd2.umd.edu, C355%qzcom.bitnet@umd2.umd.edu, header-people@ai.ai.mit.edu, rutgers!mark@cbpavo.mis.oh.att.com Subject: Re: Use of a polar satelite for academic nets You can also buy time from a company called Equitorial Comunications. We are looking into them where I work. They appear to be quite reasonable priced. They have both one-way and two-way connections available. They just slap this 2 ft. dish someplace, and away you go. You Stargate people should look into this. As I remember, it was quite reasonably priced. They charge flat rates too! -Mike p.s. I'm in no way connected with Equitorial.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Mar 87 23:00:14 EST Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 16 Mar 87 22:58:06 EST Received: from SEARN(MAILER) by MITVMA (Mailer X1.23) id 3774; Mon, 16 Mar 87 22:52:11 EST Received: from TQZCOM(MAILER) by SEARN (Mailer X1.23b) id 5129; Tue, 17 Mar 87 04:52:37 EDT Message-ID: <240166@QZCOM> In-Reply-To: <12286651276.13.BLARSON@USC-ECLB.ARPA> Date: 16 Mar 87 21:29 +0100 From: "Tommy Ericson QZ" Reply-To: "Tommy Ericson QZ" , "Header People (mail standards) mailing lists" , "External mail experience" , "Academic network cooperation group (IFIP)" To: "Header People (mail standards) mailing lists" cc: "ARPA Internet Mail Interest List" , "External mail experience" , "Academic network cooperation group (IFIP)" Subject: Re: Use of a polar satelite for academic nets Stargate certainly sounds interesting, but will that help us here in Europe? Tommy  Received: from hplabs.HP.COM (TCP 30001235012) by MC.LCS.MIT.EDU 17 Mar 87 02:23:06 EST Received: from hplms1 by hplabs.HP.COM with TCP ; Mon, 16 Mar 87 23:17:59 pst Received: from hpldat (hpldat) by hplms1; Mon, 16 Mar 87 23:17:25 pst Return-Path: Received: by hpldat ; Mon, 16 Mar 87 23:19:46 pst From: Dave Taylor Message-Id: <8703170719.AA13138@hpldat> To: Header-People@mit-mc (The Header People Mailing List) Date: Mon, 16 Mar 87 23:19:43 PST Subject: Electronic Post Office systems... Organization: Hewlett-Packard Laboratories, Interface Technologies Group X-Mailer: Elm [version 1.5] I've been working on a system that will allow users in our heavily distributed environment to receive electronic mail on a different host computer. The setup I have currently is: As mail leaves the users computer their address is replaced by the address of their PostOffice Box. When mail arrives in the PostOffice, it is placed in their box, and an `asynchronous' notification is sent to their 'usual host' indicating that new mail has arrived. If their host is down or they have disabled the acknowledgement, it is simply ignored. If not, the default is to have the users workstation send a 'request to transfer mail' as a reply and then have the mail actually deposited in their 'real' mailbox. The advantages to this over the existing setup are mostly that it allows a central authority to have control over the system, especially with regards to backup strategies (notoriously bad in a research environment) and queueing mail for hosts that are down for a period of time is much simpler. As another added benefit, it also allows users to request their mail from *a different host* if, for example, their regular workstation is down for an extended period of time. My question for the group is simply: Has anyone else worked on a system like this? If so, please drop me a line - I have some questions about various design issues that I'd like to hear how you got around. Further information on this system will probably be forthcoming - it's "moving"right along" now... Thanks. -- Dave Taylor Hewlett-Packard Labs (415) 857-6887 PST ps: I know about POP (RFC-) and have determined that it isn't appropriate for our environment and needs.  Received: from UDEL.EDU (TCP 30001223402) by MC.LCS.MIT.EDU 17 Mar 87 15:24:16 EST Received: from localhost by Dewey.UDEL.EDU id a009504; 17 Mar 87 15:11 EST Reply-To: James M Galvin To: Dave Taylor cc: The Header People Mailing List Subject: Re: Electronic Post Office systems... In-reply-to: Your message of Mon, 16 Mar 87 23:19:43 PST. <8703170719.AA13138@hpldat> Date: Tue, 17 Mar 87 15:09:26 -0500 Message-ID: <9408.543010166@dewey> From: James M Galvin > Has anyone else worked on a system like this? How is it different from a networked file system, where all mailboxes are on the server and all machines simply mount the mailbox file system? Or isn't it supposed to be? (Conceptually, not implementation.) > ps: I know about POP (RFC-) and have determined that it isn't > appropriate for our environment and needs. Have you seen the POP that comes with MH, the Rand Message Handling System? It is quite different from the POP in RFC 937. Jim  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 17 Mar 87 16:36:59 EST Date: Tue, 17 Mar 1987 15:57 EST Message-ID: From: Rob Austein To: Dave Taylor Cc: Header-People@MC.LCS.MIT.EDU Subject: Electronic Post Office systems... In-reply-to: Msg of 17 Mar 1987 02:19-EST from Dave Taylor You might want to look at PCMail, described in RFC993. It has a central "repository", any number of "clients", a network protocol for clients to use to upload/download messages, and a lot of locking hair to handle multiple clients trying to access the same mailbox(es). --Rob  Received: from po2.andrew.cmu.edu (TCP 20000574551) by MC.LCS.MIT.EDU 18 Mar 87 17:44:38 EST Received: by po2.andrew.cmu.edu (5.54/3.15) id for header-people@mc.lcs.mit.edu; Wed, 18 Mar 87 17:43:14 EST Received: via switchmail; Wed, 18 Mar 87 17:43:12 est Received: FROM apollo.itc.cmu.edu VIA queuemail ID ; Wed, 18 Mar 87 17:40:56 est Received: FROM apollo.itc.cmu.edu VIA qmail ID ; Wed, 18 Mar 87 17:40:30 est Message-Id: X-Trace: MS Version 3.22 on ibm032 host apollo.itc.cmu.edu, by cfe (469). Date: Wed, 18 Mar 87 17:40:28 est From: cfe#@andrew.cmu.edu (Craig F. Everhart) To: James M Galvin Subject: Re: Electronic Post Office systems... Cc: header-people@mc.lcs.mit.edu In-Replyto: <9408.543010166@dewey> We on Andrew have another networked file system, and it stores *all* our personal files. The local disk has a collection of important bootstrapping and diagnostic programs, and otherwise functions as a write-through cache of the shared file system. Mailboxes are simply directories in this network file system; delivering mail to a user consists of finding the appropriate directory and inserting a file containing the mail text there. Thus, it looks to the casual user like a big timesharing system, and in many ways it is, with about 3500 users and 18 file servers. We have several post office machines, that aren't the same as file servers, but they handle all the mail going in and out of the system as a whole. Outgoing mail is just queued in one of another collection of directories in the shared file system, and is picked up by these post office machines. Incoming mail is received by daemons on these post office machines and is then injected into the delivery system, which of course may forward mail back through the outgoing queues... Craig Everhart Andrew message system  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 26 Mar 87 23:48:10 EST Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 26 Mar 87 23:44:50 EST Received: from SEARN(MAILER) by MITVMA (Mailer X1.23) id 2447; Thu, 26 Mar 87 23:37:20 EST Received: from TQZCOM(MAILER) by SEARN (Mailer X1.23b) id 1610; Fri, 27 Mar 87 05:27:27 EDT Message-ID: <242134@QZCOM> In-Reply-To: <239919@QZCOM> Date: 26 Mar 87 18:13 +0100 From: "Jacob Palme QZ" Reply-To: "Jacob Palme QZ" To: "ARPA Internet Mail Interest List" , Academic_network_cooperation@WISC-RSCH.ARPA Subject: Use of a polar satelite for academic nets Satellites for multi-national company usage ------------------------------------------- Texas Instruments has recently opened a development laboratory in India. According to TI representatives, the laboratory would never have been opened in India, unless the company could get good and reliable communications. These communications are based on a satellite ground station on the floor of the laboratory building. The satellite cost 750 000 dollars to buy. It provides a leased 64 kbit/second link to TI in London and from there to other TI establishments. The satellite can be used for electronic mail, file transfer and remote terminal usage. The total cost per year of this communication channel to the Indian laboratory is 400 000 dollars/year. This means a total cost per nominal leased capacity of about 1.6 dollars/megabyte. One can compare with the polar satellite project mailstar, which will cost somewhere around 30 dollars/megabyte nominally transferred. Alternative Texas solution Polar satellite Approximate cost per year 400 000 dollars 1 500 000 dollars Approximate nominal transfer capacity, 250 000 Mbytes/year 45 000 Mbytes/year Cost per nominal megabyte 1.6 dollars 33.3 dollars Note however that the polar satellite is to serve hundreds of small earth stations, not one single as for the TI channel. The reason TI sets up this laboratory in India is the high quality of the Indian education system, providing a good supply of good computer programmers. The Indian government also gives very favourable conditions to export-only companies like this laboratory. The advantage to India is export income and the possibillity of technology transfer.  Received: from wiscvm.wisc.edu (TCP 20032201015) by MC.LCS.MIT.EDU 3 Apr 87 18:29:22 EST Received: from CSUGREEN.BITNET by wiscvm.wisc.edu on 04/03/87 at 17:30:53 CST Message-ID: <870403094806.0000347E.GALX.AB@CSUGREEN> (UMass-Mailer 4.03) Date: Fri, 3 Apr 87 09:48:07 MST From: zbzscot%CSUGREEN.BITNET@wiscvm.wisc.edu (Scott Baily CSU Comp. Center 303-491-7655) Subject: Requiring RFC822 Style Headers To: HEADER-PEOPLE@MC.LCS.MIT.EDU We are running the UMass Mailer on our Cyber 830 and 840 machines at CSU. Although both machines are valid Bitnet nodes (CSUGOLD and CSUGREEN), only our 830 has a direct connection to NJEF, so network mail to/from the 840 must be routed through the other machine. This presented a problem when mail was sent to the 840 and the Bitnet user name was not a valid user ID. We decided to get around this by ignoring the NJF header and parsing the message header instead. We look for the user specified in the "To:" field and deliver the message to the appropriate mailbox on that machine. This works fine as long as mail is sent with an RFC822 style header on it. Unfortunately, this is not always the case, particularly from some IBM sites. I have contacted the networking staff from some of these sites, and thay tell me they have mail utilities that will put RFC822 headers on the messages, but users may select other (headerless) methods instead. I think that mail files should conform to the RFC822 and include a header. Users who cannot get headerless mail at CSU but can get it elsewhere disagree. Is it unreasonable to ask other sites to send us mail that conforms to the standard? Scott Baily Colorado State University ZBZSCOT@CSUGREEN.BITNET  Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 4 Apr 87 18:00:09 EST Date: Sat, 4 Apr 87 17:49 EST From: John C Klensin Subject: requiring RFC822 headers To: Scott Baily cc: header-people@MC.LCS.MIT.EDU Message-ID: <870404224919.376136@MIT-MULTICS.ARPA> Scott, Let them complain. There is precious little else you can do, and accomodating them only adds to the pressures on those systems and gateways for which doing what they want is impossible, rather than merely very difficult. Almost since the beginning of BITNET, there have been mail-only hosts; those hosts can't accept anything but mail (mail ::= proper headers). A reasonable response to the "headerless methods" is that, if the users involved manage to use the existing mail utilities, then they can send mail to anyone, if they insist on use of the IBM and near clone only mechanisms, then they are going to get through only to those sites that are directly RSCS connected and a small (and nearly unpredictable) subset of other sites. Bet that those folks who have to route through the intermediate machine can use SENDFILE or CP PUNCH to get files through to the 840 either -- if you can explain one, you can explain the other. john  Received: from jade.berkeley.edu (TCP 20010104011) by MC.LCS.MIT.EDU 5 Apr 87 01:46:10 EST Received: by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.12) id AA15043; Sat, 4 Apr 87 19:39:12 PST Message-Id: <8704050339.AA15043@jade.berkeley.edu> Date: Sat, 04 Apr 87 19:12 PST To: Scott Baily From: Leonard D. Woren 213 743-5391 Subject: Re: Requiring RFC822 Style Headers Cc: HEADER-PEOPLE@mc.lcs.mit.edu > ... > We decided to get around this by ignoring the NJF header and > parsing the message header instead. We look for the user specified in > the "To:" field and deliver the message to the appropriate mailbox on > that machine. Speaking from personal experience, this is risky and unreliable at best, and, depending on all the mailers involved, could be dangerous. (If something gets rejected because your mailer doesn't understand the RFC822 header completely, you could get looping error messages. Loops have been discussed at length on Header-People in the past, so let's not re-open that can of worms right now.) > This works fine as long as mail is sent with an RFC822 style > header on it. Unfortunately, this is not always the case, > particularly from some IBM sites. I have contacted the networking > staff from some of these sites, and thay tell me they have mail > utilities that will put RFC822 headers on the messages, but users may > select other (headerless) methods instead. Those users at other sites will find out that unless they use the software that generates RFC822 headers, their mail may not get delivered at all. That should be incentive enough to influence their choice away from (headerless) other methods. > I think that mail files should conform to the RFC822 and include a > header. Users who cannot get headerless mail at CSU but can get it > elsewhere disagree. Is it unreasonable to ask other sites to send us > mail that conforms to the standard? I think that mail should only be sent using mailers. That means to me RFC822 headers as a minimum, and preferably BSMTP envelopes. I (my site) had a lot of trouble receiving gatewayed mail without BSMTP. I am running the UCLA/Mail package on MVS. I think it is very good, but it is incomplete at this time. For example, it doesn't understand ReSent-xxx headers, so when someone using the Columbia mailer on VM remails something, unless I get it with BSMTP, it ends up stuck in the dump, unless/until I go manually tweak it. So, in summary, I think you should not make any attempt at all to deliver mail that doesn't have RFC822 headers, and, in addition, you should try to do all mail with BSMTP. It is my understanding that BITNET mail is RFC822 based. Making concessions to sites that can't/ won't support that bothers me. Even if BITNET mail wasn't originally specified to be RFC822, given the current facts of life with inter- connected networks, if you want to be able to communicate with people on other networks, you basically *have* to support RFC822. "Whenever you open a can of worms, you can't re-can them using the same size can." Leonard D. Woren University of Southern California LDW@USCMVSA.BITNET (preferred) LDW@Izar.USC.EDU  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Apr 87 18:08:54 EDT Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 5 Apr 87 18:07:08 EDT Received: from SEARN(MAILER) by MITVMA (Mailer X1.23) id 4051; Sun, 05 Apr 87 17:52:16 EDT Received: from TQZCOM(MAILER) by SEARN (Mailer X1.23b) id 5742; Sun, 05 Apr 87 23:54:23 EDT Message-ID: <243390@QZCOM> Date: 02 Apr 87 14:46 +0200 From: "Rolf Speth CEC COST11ter" Reply-To: "Rolf Speth CEC COST11ter" , "Jacob Palme QZ" , "AMIGO Open" , "AMIGO Group (communication)" , "MHS implementation mailing list" Resent-Reply-To: "MHS (CCITT) Standardization" To: "Jacob Palme QZ" , "AMIGO Open" , "AMIGO Group (communication)" , "MHS implementation mailing list" cc: "MHS (CCITT) Standardization" , MHS_implementation@RSCH.WISC.EDU, "ARPA Internet Mail Interest List" Subject: Message Handling conference in Munich, 27-29 April 1987. May I remind all people intending to go to this conference that late registration costs an additional amount of DM 50.-. So send in your registration as soon as possible to Message Systems '87 Mrs H.Lind Siemens D-AP 11 Otto Hahn Ring D - 8000 Muenchen 83 If someone has not received the final program (there was a COM entry by Jacob Palme nr.?) please give me your adress here in COM or write to Mrs. Lind.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Apr 87 18:09:03 EDT Received: from MIT-MULTICS.ARPA (TCP 1200000006) by AI.AI.MIT.EDU 5 Apr 87 18:07:16 EDT Received: from SEARN(MAILER) by MITVMA (Mailer X1.23) id 4054; Sun, 05 Apr 87 17:52:25 EDT Received: from TQZCOM(MAILER) by SEARN (Mailer X1.23b) id 5746; Sun, 05 Apr 87 23:54:28 EDT Message-ID: <244319@QZCOM> In-Reply-To: <243390@QZCOM> Date: 04 Apr 87 16:37 +0200 From: "Jacob Palme QZ" Reply-To: "Jacob Palme QZ" , "Rolf Speth CEC COST11ter" , "AMIGO Open" , "AMIGO Group (communication)" , "MHS implementation mailing list" , "MHS (CCITT) Standardization" To: "Rolf Speth CEC COST11ter" , "AMIGO Open" , "AMIGO Group (communication)" , "MHS implementation mailing list" cc: "MHS (CCITT) Standardization" , MHS_implementation@RSCH.WISC.EDU, "ARPA Internet Mail Interest List" Subject: Message Handling conference in Munich, 27-29 April 1987. The final program was included in a message written by Einar Stefferud on 22 Feb 87 16:31:10. That message was sent via the HEADER-PEOPLE and MHS_IMPLEMENTATION mailing lists. In QZCOM, the message can be retrieved as message no 235152.  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 7 Apr 87 20:55:51 EDT Received: from relay2.cs.net by RELAY.CS.NET id aa05314; 7 Apr 87 20:02 EDT Received: from lsu.edu by RELAY.CS.NET id aa17280; 7 Apr 87 19:57 AST Received: by lsu.edu (5.51/4.7) id AA17120; Tue, 7 Apr 87 09:40:03 CST Date: Tue, 7 Apr 87 09:40:03 CST From: Mounir Bsaibis To: header-people@MC.LCS.MIT.EDU We have a VAX 11/780 with 4.3 BSD running as the main host. Also, we have a local ethernet with several machines on. Recently, I changed our address to domain address LSU.EDU. On the mainhost machine everything seems to function smoothly. But, when I want to send a message to the outside world from one of the machines on the ethernet, reality is not so nice. The mail from a machine in our sub-domain is being sent to the main machine (VAX) and forwarded to CSNET. Unfortunately, the sendmail configuration on the VAX is omitting the site field in the FROM address. What we are after is people who have a similar configuration (as shown below). If we could obtain a few sample sendmail configurations we could then more easily determine the errors within ours. We are using a modified version of sendmail.cf which comes with pmdf stuff (it is some version of sendmail.cf from Univ. of Ill at Urbana-Champaign.) ----------------- | csnet-relay | ----------------- | | pmdf | ------------- local UUCP -------- | VAX 11/80 |---------------| | ------------- -------- ether ether | ether ---------------------------------------------------------------- | | | -------------------- -------------- ----------- | SUN work station | | IBM RT | ... | uVAXen | -------------------- -------------- ----------- Any one who has a solution, recommendation, suggestion, commentary etc... Please write to "bsaibis@lsu.edu" Thanks.  Received: from BIONET-20.ARPA (TCP 20027140005) by MC.LCS.MIT.EDU 14 May 87 21:00:05 EDT Date: Thu 14 May 87 17:56:30-PDT From: David Roode Subject: mx-existence and header etiquette] To: Header-People@MC.LCS.MIT.EDU Phone: (415) 962-7322 Message-ID: <12302428207.45.ROODE@BIONET-20.ARPA> It's been suggested that I address this message here, and hope this also routes to an equivalent on USENET. Anyone know how to reach USENET newsgroup comp.mail.misc from the Internet? --------------- Date: Tue 12 May 87 14:38:03-PDT From: David Roode To: tcp-ip@SRI-NIC.ARPA Phase-in timetables for defacto standards are generally informal. What's the feeling about the use of host names that are only valid where there is support for both a host name resolver and MX name server domain entries? It seems reasonable for forwarding hosts to show up in the From: header as a courtesy to those hosts who do not yet support MX-existence. Is this support a "required" or an "optional" part of name resolvers? At least considering that on some of the networks composing the internet name server use is optional, some period of visibilty for forwarding makes sense. Apparently RELAY.CS.NET does follow this principle, but not all the hosts relaying UUCP hosts' mail to the Internet do. ------- -------  Received: from ucbarpa.Berkeley.EDU (TCP 1200000116) by MC.LCS.MIT.EDU 15 May 87 02:24:53 EDT Received: by ucbarpa.Berkeley.EDU (5.57/1.25) id AA21107; Thu, 14 May 87 19:36:48 PDT Date: Thu, 14 May 87 19:36:48 PDT From: jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) Message-Id: <8705150236.AA21107@ucbarpa.Berkeley.EDU> To: ROODE@bionet-20.arpa Subject: Re: mx-existence and header etiquette] Cc: header-people@mc.lcs.mit.edu the problem with this [ now that i've seen the question 3 times ] is that it then becomes completely worthless to upgrade -- and it *is* an upgrade. if the % hack stays around much longer, it'll become a de facto ... MX forwarding is a *good* idea, one that vendors have been given 4 years to implement ... note: much longer than tcp/ip ... when the NCP --> TCP/IP cutover happened, those who didn't upgrade *lost* ... i think the community has been *far too kind* to those who aren't doing _the_right_thing_ with MX forwarding, and the line about "unreliability" has no water left ... if we waited for bug-free tcp implementations, we'd all be shouting through paper cups ... /jordan  Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 15 May 87 12:07:28 EDT Received: from PANDA by SUMEX-AIM.STANFORD.EDU with Cafard; Fri, 15 May 87 09:06:22 PDT Date: Fri, 15 May 87 08:50:35 PDT From: Mark Crispin Subject: Re: mx-existence and header etiquette] To: jordan@UCBARPA.BERKELEY.EDU cc: header-people@MC.LCS.MIT.EDU In-Reply-To: <8705150236.AA21107@ucbarpa.Berkeley.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12302590968.7.MRC@PANDA> Jordan - %-routing will always be with us. The domain system will never cover as much area as %-routing does. The best we can hope to do is eliminate %-routing in those places where the domain system does cover. You can't compare this with the NCP/TCP transition. -- Mark -- -------  Received: from MIT-Multics.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 30 May 87 11:13:05 EDT Received: from SEARN(MAILER) by MITVMA (Mailer X1.23) id 3846; Sat, 30 May 87 11:03:06 EDT Received: from TQZCOM(MAILER) by SEARN (Mailer X1.23b) id 6186; Sat, 30 May 87 15:42:43 EDT Message-ID: <254120@QZCOM> Date: 28 May 87 16:40 +0200 From: "Jacob Palme QZ" Reply-To: "Jacob Palme QZ" To: header-people@MC.LCS.MIT.EDU Subject: X.400/88 and failure messages A couple of years ago we had a long discussion in header-people about failure messages resulting from mailing list expansion. A consensus was reached that these failure messages should be sent to the administrator of the mailing list, not to the person who submitted the message to the list. The administrator of the list is better able to take appropriate action. It is also easier for the administrator to have automatic or semi-automatic tools to handle failing members of his list. The way to achieve this, it was agreed, was to make the administrator of the list into the SMTP-sender of messages sent out by the list expander, and having the mail system which cannot deliver a message send the failure message to the SMTP-sender. (An alternative, using an "errors-to" field in the RFC822 header, might be a better way, but few mail systems support sending failure messages to the name in the "errors-to" field. The reason I am taking up this discussion again now is that CCITT and ISO are currently working on the introduction of a distribution list facility into the X.400 messaging standard. The solution presently being discussed within ISO and CCITT will work in such a way that the delivery and non-delivery notifications will be sent either to the list administrator, or to the original sender of the message, or to both, depending on the policy of the list. The default policy will be to send to both. (There was some disagreement on this at the last meeting of the ISO group. I favored notifications going to the list administrator, because I remembered the discussion here in header-people and what we agreed on here. Other people, who were mostly interested in small closed lists, believed that in those cases notifications to the original sender was better. That is why we chose to allow either or both, depending on the type of list, with both as default.) All this is OK. The problem, however, occurs when you gateway messages from older systems (including the 1984 version of X.400) to distribution lists according to the new 1988 version of X.400. The 1988 version of X.400 will use a method somewhat similar to the "errors-to" field to ensure that notifications are sent where they should. This will not be translatable to the 1984 version of X.400, since that recommendation does not have any such envelope field. Thus, 1984/X.400 systems will send notifications to the P1.originator (=SMTP-sender). The problem is then what should a gateway from X.400/88 do to ensure that notifications are returned the way they should? The present thinking in ISO is to leave the P1.originator (=SMTP-sender) equal to the original sender. This will mean that failure messages from systems gatewayed to X.400/88 will wrongly be sent to the original sender and not to the list maintainer. If you do not like this, the right person to talk to is your national representative in the CCITT and ISO standards groups in this area, for the U.S. this would be Jim White (Telenet corp.) and Brenda Troisi (Xerox corp.) One solution, in case the gateway knows what kind of list it is, to let the gateway reset the P1.originator (=SMTP-sender) to the list administrator for those lists where notifications should be sent to the list maintainer.  Received: from BIONET-20.ARPA (TCP 20027140005) by MC.LCS.MIT.EDU 1 Jun 87 01:57:41 EDT Date: Sun 31 May 87 22:55:48-PDT From: David Roode Subject: Internet mailing list relay to BITNET To: Header-people@MC.LCS.MIT.EDU cc: Liebschutz@BIONET-20.ARPA Phone: (415) 962-7322 Message-ID: <12306939140.19.ROODE@BIONET-20.ARPA> I have some Internet mailing lists and I want to create a relay server on the BITNET side of WISCVM to avoid loading BITNET down with multiple copies of he messages sent to the list. Does anyone know how this is usually done? -------  Received: from MIT-Multics.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 1 Jun 87 13:24:35 EDT Received: from FRECP11(MAILER) by MITVMA (Mailer X1.23) id 8022; Mon, 01 Jun 87 13:12:52 EDT Received: by FRECP11 (Mailer X1.24) id 2011; Mon, 01 Jun 87 16:46:45 SET Date: Mon, 1 Jun 1987 16:45 SET From: Eric Thomas Subject: BITNET REDIST LISTS To: > > I have some Internet mailing lists and I want to create a relay server on > the BITNET side of WISCVM to avoid loading BITNET down with multiple copies > of he messages sent to the list. Does anyone know how this is usually done? > The normal procedure is to send mail to REDIST-L@UGA.BITNET@WISCVM.wisc.edu with a description of your list, of the present number of BITNET recipients and any other information you might deem useful. LISTSERV owners will then contact you if they are interested. Eric  Received: from JOVE.CAM.UNISYS.COM (TCP 20052400001) by MC.LCS.MIT.EDU 11 Jun 87 16:04:14 EDT Received: from PHOEBE.CAM.UNISYS.COM by JOVE.CAM.UNISYS.COM (sdcjove) [3.2Unisys/1.0] id AA14608; Thu, 11 Jun 87 12:58:04 PDT Received: by PHOEBE.CAM.UNISYS.COM (phoebe) [3.2Unisys/1.0] id AA18036; Thu, 11 Jun 87 12:57:31 PDT Date: Thu, 11 Jun 87 12:57:31 PDT From: jonab@CAM.UNISYS.COM (Jonathan P. Biggar) Message-Id: <8706111957.AA18036@PHOEBE.CAM.UNISYS.COM> To: header-people@mc.lcs.mit.edu Subject: RFC822 to RFC841 (FIPS 98) translator Does anyone out there have any software that can translate mail messages from RFC822 syntax to RFC841 (FIPS 98) syntax and vice versa? I would prefer source code in C, but I can live with source in any other language. Jon Biggar jonab@cam.unisys.com sdcrdcf!jonab  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 16 Jun 87 22:22:58 EDT Received: from relay2.cs.net by RELAY.CS.NET id aa19814; 16 Jun 87 21:56 EDT Received: from iowa-state by RELAY.CS.NET id ac20231; 16 Jun 87 21:48 EDT Received: by isucs1.UUCP (4.12.01/2.02) id AA09453; Tue, 16 Jun 87 20:46:57 cdt Date: Tue, 16 Jun 87 20:46:57 cdt From: Dave Shaver To: header-people.2@IOWA-STATE.CSNET Subject: UNIX <-> HP3000 This may not be the best place to direct this question, but here goes: I'm interested in *ANY* information or pointers regarding work on a mail interconnect and/or file transfers between a HP3000 running MPE V and UNIX (in our case VAX 11/780 running 4.3BSD). Has anyone tried to interface with the MPE V OS and/or mailing system at a file transfer level? Does anyone know of the existence of SMTP for the HP3000? Also, does anyone have any experience with the "import/export" facilities under the HP Desk mailing system? Thanks in advance for any responses. Cheers, /\ Dave Shaver -=*=- CS Software Support Group, Iowa State University \\ UUCP: {ihnp4!isuee1,okstate,hp-lsd,csu-cs}!isucs1!shaver \/ ARPA: shaver%iowa-state.csnet@relay.cs.net  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 17 Jun 87 09:09:07 EDT Received: from relay2.cs.net by RELAY.CS.NET id aa24178; 17 Jun 87 8:45 EDT Received: from iowa-state by RELAY.CS.NET id aa23147; 17 Jun 87 8:38 EDT Received: by isucs1.UUCP (4.12.01/2.02) id AA11836; Wed, 17 Jun 87 07:33:27 cdt Date: Wed, 17 Jun 87 07:33:27 cdt From: Dave Shaver To: header-people.mc.lcs.mit.edu@IOWA-STATE.CSNET Subject: UNIX <-> HP3000 This may not be the best place to direct this question, but here goes: I'm interested in *ANY* information or pointers regarding work on a mail interconnect and/or file transfers between a HP3000 running MPE V and UNIX (in our case VAX 11/780 running 4.3BSD). Has anyone tried to interface with the MPE V OS and/or mailing system at a file transfer level? Does anyone know of the existence of SMTP for the HP3000? Also, does anyone have any experience with the "import/export" facilities under the HP Desk mailing system? Thanks in advance for any responses. Cheers, /\ Dave Shaver -=*=- CS Software Support Group, Iowa State University \\ UUCP: {ihnp4!isuee1,okstate,hp-lsd,csu-cs}!isucs1!shaver \/ ARPA: shaver%iowa-state.csnet@relay.cs.net  Received: from hplabs.HP.COM (TCP 30001235012) by MC.LCS.MIT.EDU 18 Jun 87 11:00:11 EDT Received: from hpcea.HP.COM by hplabs.HP.COM with TCP ; Wed, 17 Jun 87 11:11:31 pdt Received: from hpcera by hpcea.HP.COM; Wed, 17 Jun 87 11:12:48 pdt Return-Path: Received: by hpcera ; Wed, 17 Jun 87 11:13:31 pdt Date: Wed, 17 Jun 87 11:13:31 pdt From: Mark Laubach Message-Id: <8706171813.AA01304@hpcera> To: nosc!shaver%iowa-state.csnet@relay.cs.net Cc: header-people@mc.lcs.mit.edu Subject: RE: HP 3000 mail connection to unix machines Dave, IOWA state is a member of CSNET. As such, you can obtain a package called HPMDF that would provide a link between the HP 3000 HPDESKMANAGER and RFC822 mail systems. It is a package based on an implementation of the MMDF/PMDF PhoneNet protocol. See the Summer 1986 CSNET NEWS newsletter article entitled "PhoneNet Software Ported to the HP 3000 Minicomputer Family" and contact CSNET as "cic@sh.cs.net" for more information. Regards, Mark Laubach Corporate Engineering Hewlett-Packard Corp.  Received: from Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 25 Jun 87 06:52:55 EDT Received: from ucl-cs-vax2 by nss.Cs.Ucl.AC.UK via Ethernet with SMTP id aa05993; 25 Jun 87 11:45 BST To: Jacob Palme QZ cc: header-people@mc.lcs.mit.edu Subject: Re: X.400/88 and failure messages Phone: +44-1-380-7294 In-reply-to: Your message of 28 May 87 16:40:00 +0200. <254120@QZCOM> Date: Thu, 25 Jun 87 11:44:38 +0100 Message-ID: <1354.551616278@UK.AC.UCL.CS> From: Steve Kille As you probaly know, I am not over enamoured with the way in which the X.400(88) crew are tackling distribution lists. Basically they are making it too complex. I feel that they shoul drop the requirement for the possibility of list errors to go back to the sender. This will then allow it to be done in two phases, and all good things happen. My experience says that list errors should NEVER go back to the sender. Locally, delivery is reliable, and no-one wants to see errors from big lists. (I think this means I agree with you). I note that Brenda Troisi is now with Tandem (not Xerox). Steve  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 25 Jun 87 17:42:36 EDT Date: Thu, 25 Jun 87 17:44:20 EDT From: David Vinayak Wallace Subject: X.400/88 and failure messages To: Steve.Kille%ucl-cs@D.ISI.EDU cc: header-people@MC.LCS.MIT.EDU In-reply-to: Msg of Thu 25 Jun 87 11:44:38 +0100 from Steve Kille Message-ID: <219682.870625.GUMBY@AI.AI.MIT.EDU> Date: Thu, 25 Jun 87 11:44:38 +0100 From: Steve Kille ... I feel that they shoul drop the requirement for the possibility of list errors to go back to the sender. ... My experience says that list errors should NEVER go back to the sender. Locally, delivery is reliable, and no-one wants to see errors from big lists. This assumes that all lists have maintainers. For the majority of lists I know about this is not so. Do you wish to force every mailing list to have a maintainer?  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 25 Jun 87 19:07:36 EDT Received: from urania.think.com (Dagda.Think.COM) by Think.COM; Thu, 25 Jun 87 19:08:32 EDT Received: by urania.think.com; Thu, 25 Jun 87 19:08:29 EDT Date: Thu, 25 Jun 87 19:08:29 EDT Message-Id: <8706252308.AA02485@urania.think.com> From: Robert L. Krawitz Sender: rlk@think.com To: GUMBY@ai.ai.mit.edu Cc: Steve.Kille%ucl-cs@d.isi.edu, header-people@mc.lcs.mit.edu In-Reply-To: David Vinayak Wallace's message of Thu, 25 Jun 87 17:44:20 EDT <219682.870625.GUMBY@AI.AI.MIT.EDU> Subject: X.400/88 and failure messages Date: Thu, 25 Jun 87 17:44:20 EDT From: David Vinayak Wallace This assumes that all lists have maintainers. For the majority of lists I know about this is not so. Do you wish to force every mailing list to have a maintainer? As the maintainer of a large list (info-nets), I do think that all significant mailing lists should have maintainers, particularly if they are public (definition of public is unclear; will "not private" have any meaning?). This includes sub-lists (redistribution lists) of other lists. If there is no maintainer for a public list, the sorts of problems that regularly occur will never get fixed. These problems include users who wish to leave and join the list (these are routine, but they are still "problems" if there's no one to fix them), dead hosts, problematic mailers, and the like. I've been on the other side, when trying to either get an address fixed or get myself removed from a list that's not being maintained, and it's a problem, too. As for subdistribution lists, they can be a real problem when an address on one of them goes bad. It's sometimes difficult, even with the help of a Received: headers, to track down a problem, especially when individual uses set up forwarding addresses that point all over known and unknown space and cause the list to assume a very weird multigraph topology rather than the ideal tree. If it were possible to bounce all failures from subdistribution lists to the maintainers of the subdistribution lists, then my job as overall list maintainer would be much easier. If all rejections from the top level list were redirected to the maintainer of the list, then my job would also be easier as I would see any problems much more quickly (and could afford to ignore them if I thought they were temporary), and the users would not be hassled. I realize I'm a little off the subject, which is whether all lists should have maintainers. I believe that they should, precisely so it could be possible to send failure notices to the maintainer rather than to the sender. As for small, private lists, what they do is up to them. If a small group of individuals who wish to communicate via mail to simulate a conference decide that they aren't going to worry about these problems, that's their business. However, I certainly think that any list on the List Of Lists that is advertised as being public (there are a few that are advertised as limited distribution, but they may not be small, so they may still fall under this category) should have owners. I think an apt analogy is that of a private meeting (i. e. a small group of people decide informally to get together for a chat) and a large, public meeting that is advertised through print or electronic media. How easily this could be formalized through SMTP/RFC821 (which RFC controls message format?) is another problem, and I suppose that any scheme of this nature will require some conditions to be met in order to work. Still, there are a few things that are moving in the right direction. Sendmail on BSD allows a name of the form owner- to specify who should get any local rejections. By checking that a list has an owner, a mailer could modify the contents of the message envelope (is that legal?) to specify MAIL From: so that any bounces get redirected. To enforce the principle of lists having owners, a mailer could refuse to accept a message with more than n recipients unless the MAIL From: was from an owner-. This has nasty compatibility problems with the current state of the world and probably has other problems that I don't see offhand (this is being consed up quickly, and I've been at work too long...). I went off on a number of tangents here, but I really find it a hassle to deal with mailing lists that don't have active maintainers. I suppose this is really a long winded way of saying "Yes, I do wish to force every mailing list to have a maintainer." Robert Krawitz info-nets-request  Received: from ucbarpa.Berkeley.EDU (TCP 1200000116) by MC.LCS.MIT.EDU 25 Jun 87 21:50:29 EDT Received: by ucbarpa.Berkeley.EDU (5.58/1.25) id AA22146; Thu, 25 Jun 87 18:05:04 PDT Date: Thu, 25 Jun 87 18:05:04 PDT From: jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) Message-Id: <8706260105.AA22146@ucbarpa.Berkeley.EDU> To: header-people@mc.lcs.mit.edu Subject: Re: X.400/88 and failure messages The problem with RLK's argument, is it's limited in scope. We're not talking here about how to do "List of Lists" mailing lists, we're talking about an international standard that's trying to define a general interface ... his comments are of great importance to list maintainers everywhere (myself included), but it's not the way to go about writing a suggestion document. Forcing all lists to have maintainers is not the answer. /jordan  Received: from jade.berkeley.edu (TCP 20010104011) by MC.LCS.MIT.EDU 26 Jun 87 04:51:24 EDT Received: by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.14QM) id AA16867; Fri, 26 Jun 87 01:49:21 PDT Message-Id: <8706260849.AA16867@jade.berkeley.edu> Date: Fri, 26 Jun 87 10:28 CET To: header-people@mc.lcs.mit.edu From: Peter Sylvester +49 228 303245 Subject: Defining RFC987 tables for X.400-internet gateways Some X.400-internet gateways use a very fixed mapping of X.400 attributes to internet domain names. This might lead to naming conflicts if the mapped addresses/OR-names are not registered in both networks (i.e the networks served by the gateway). The original tendancy to have a "gatewayed" address (% in internet) or some attributes pointing to the gateway in X.400 are more an more replaced by address mappings where the gateway does no longer occur in an address. This has obvious advantadges if used in a correct way. blabla, I guess you all know these things... I would like to know who discusses this problem in USA and whether there is already some official agreement between X.400 people an internet in USA, for example what kind of RFC987 tables should be used (if at all). Peter  Received: from NNSC.NSF.NET (TCP 20026200662) by MC.LCS.MIT.EDU 26 Jun 87 08:29:07 EDT To: header-people@mc.lcs.mit.edu Subject: Re: X.400/88 and failure messages Date: Fri, 26 Jun 87 08:26:50 -0400 From: Craig Partridge I don't see what the problem is with making every list have a maintainer. We do it here -- most bounces on most lists get returned to the postmaster, who is probably the best qualified person to figure out went wrong anyway. Craig Partridge CSNET CIC  Received: from BIONET-20.ARPA (TCP 20027140005) by MC.LCS.MIT.EDU 26 Jun 87 14:41:04 EDT Date: Fri 26 Jun 87 11:38:18-PDT From: David Roode Subject: Re: Defining RFC987 tables for X.400-internet gateways To: GRZ027%DBNGMD21.BITNET@UCBVAX.BERKELEY.EDU cc: header-people@MC.LCS.MIT.EDU In-Reply-To: <8706260849.AA16867@jade.berkeley.edu> Phone: (415) 962-7322 Message-ID: <12313631548.36.ROODE@BIONET-20.ARPA> I think there is too little discussion on this and other issues within the US and it sounds as though your question is important. If you don't get an answer, you might try sending the same message to the TCP-IP list. -------  Received: from jade.berkeley.edu (TCP 20010104011) by MC.LCS.MIT.EDU 26 Jun 87 23:42:23 EDT Received: from wcw.berkeley.edu by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.14QM) id AA16031; Fri, 26 Jun 87 17:32:40 PDT Received: by wcw.berkeley.edu (1.1/SMI-3.0DEV3.7) id AA22354; Fri, 26 Jun 87 17:36:05 PDT Date: Fri, 26 Jun 87 17:36:05 PDT From: netinfo%mica.Berkeley.EDU@BERKELEY.EDU Message-Id: <8706270036.AA22354@wcw.berkeley.edu> To: header-people@mc.lcs.mit.edu Subject: Re: X.400/88 and failure messages I do not know what kind of list the X400 list is, but I think there may be a definiition problem here. I can think of two types of lists. The ARPAnet and BITNET mailing lists are public in nature. That is to say they are conferences or bulletin boards. For these I think the error messages should go back to the mail address exploder or maintainer. Then there are private distribution lists, such as collective addresses groups that I set up in my user agent program to send to a private mail distribution list. For these I think the error message should go back to the orginator of the message. Could this difference in types of lists be the problem? I don't think one way should be used for both. Bill Wells postmaster@jade.berkeley.edu  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 27 Jun 87 23:15:22 EDT Received: from SEARN.BITNET by .MIT.EDU (Mailer X1.24) with BSMTP id 2932; Sat, 27 Jun 87 23:13:54 EDT Received: from QZCOM by SEARN.BITNET (Mailer X1.24) with BSMTP id 2500; Sun, 28 Jun 87 04:34:26 EDT Message-ID: <259768@QZCOM> In-Reply-To: <8706270036.AA22354@wcw.berkeley.edu> Date: 27 Jun 87 18:27 +0200 From: "Jacob Palme QZ" Reply-To: "Jacob Palme QZ" To: header-people@MC.LCS.MIT.EDU Subject: Re: X.400/88 and failure messages You are quite right. There are two kinds of lists. For small, local lists, it is often best to have the error messages back to the original sender. For large, public lists, it is usually best to have the error messages to the list maintainer. And the new 1988 version of X.400 will allow both alternatives. The problem is in gateways to older systems. Non-delivery notifications from recipients in older systems go to the P1.originator (which is the X.400 name for SMTP-sender). And the standard will probably not allow the list expander to change the P1.originator to the name of the list maintainer. Thus, error messages from older systems will go to the P1.originator = the original sender. Only error messages within X.400 model 1988 will understand to send these error messages to the list maintainer for those lists where this is specified. It will be interesting to see how RFC987 will be upgraded to the 1988 version of X.400!  Received: from Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 29 Jun 87 03:18:32 EDT Received: from ucl-cs-vax2 by nss.Cs.Ucl.AC.UK via Ethernet with SMTP id ab03205; 29 Jun 87 8:10 BST To: David Vinayak Wallace cc: header-people@mc.lcs.mit.edu Subject: Re: X.400/88 and failure messages Phone: +44-1-380-7294 In-reply-to: Your message of Thu, 25 Jun 87 17:44:20 -0400. <219682.870625.GUMBY@AI.AI.MIT.EDU> Date: Mon, 29 Jun 87 08:05:57 +0100 Message-ID: <572.551948757@UK.AC.UCL.CS> From: Steve Kille >From: David Vinayak Wallace >Subject: X.400/88 and failure messages >Date: Thu, 25 Jun 87 17:44:20 EDT >Do you wish to force every mailing >list to have a maintainer? Yes, absolutely - postmaster at the site concerned should be the default. Lists are tools for doing serious work - they need management. Steve  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 29 Jun 87 18:53:58 EDT Date: Mon, 29 Jun 87 18:55:38 EDT From: David Vinayak Wallace Subject: X.400/88 and failure messages To: Steve.Kille@NSS.CS.UCL.AC.UK cc: header-people@MC.LCS.MIT.EDU In-reply-to: Msg of Mon 29 Jun 87 08:05:57 +0100 from Steve Kille Message-ID: <221294.870629.GUMBY@AI.AI.MIT.EDU> Date: Mon, 29 Jun 87 08:05:57 +0100 From: Steve Kille >From: David Vinayak Wallace >Date: Thu, 25 Jun 87 17:44:20 EDT >Do you wish to force every mailing >list to have a maintainer? Yes, absolutely - postmaster at the site concerned should be the default. I agree that for large, widely-scattered lists it's essential to have list maintainers. But unless you're strictly controlling who makes lists and for what purpose, the majority will be small (fewer than 50 recipients) and amorphous. For lists like these it's often easier to let the community take responsibility. Lists are tools for doing serious work - they need management. This sort of pompous attitude is unnecessary. Why can't a group of researchers get together and make themselves a small list with which to do "serious work" without forcing the postmaster to clean up after them?  Received: from ECLA.USC.EDU (TCP 3201200101) by MC.LCS.MIT.EDU 29 Jun 87 20:51:21 EDT Date: Mon 29 Jun 87 17:45:07-PDT From: Bob Larson Subject: Re: X.400/88 and failure messages To: GUMBY@AI.AI.MIT.EDU cc: Steve.Kille@NSS.CS.UCL.AC.UK, header-people@MC.LCS.MIT.EDU In-Reply-To: <221294.870629.GUMBY@AI.AI.MIT.EDU> Message-ID: <12314484757.56.BLARSON@ECLA.USC.EDU> From: David Vinayak Wallace >Do you wish to force every mailing >list to have a maintainer? Yes, absolutely - postmaster at the site concerned should be the default. I agree that for large, widely-scattered lists it's essential to have list maintainers. But unless you're strictly controlling who makes plists and for what purpose, the majority will be small (fewer than 50 recipients) and amorphous. For lists like these it's often easier to let the community take responsibility. Have you ever tried to maintian a list with 40 members? I certainly don't find it to be a task that does itself. (I'm info-prime-request%fns1@ecla.usc.edu) Lists are tools for doing serious work - they need management. This sort of pompous attitude is unnecessary. Why can't a group of researchers get together and make themselves a small list with which to do "serious work" without forcing the postmaster to clean up after them? Maybe we just have totaly different user bases. Lists of three users can maintain themselfs -- when one drops out, the list will no longer be needed. (It may remain around, but not cause any major problem.) Bigger lists have a very small number people that do all list additions/deletions either implicitly or explicitly. I think requiring the list maintainer to be explicitly specified is a good idea. The list maintainer need not be the postmaster, and I don't think there is a need to have a default. (Make it a required field at list creation time.) -------  Received: from nic.nyser.net (TCP 20065200415) by MC.LCS.MIT.EDU 29 Jun 87 22:10:35 EDT Received: by nic.nyser.net (5.54/1.14) id AA04541; Mon, 29 Jun 87 22:07:40 EDT Date: Mon, 29 Jun 87 22:07:40 EDT From: weltyc@nic.nyser.net (Christopher A. Welty) Message-Id: <8706300207.AA04541@nic.nyser.net> To: BLARSON@ecla.usc.edu Cc: GUMBY@ai.ai.mit.edu, Steve.Kille@nss.cs.ucl.ac.uk, header-people@mc.lcs.mit.edu In-Reply-To: Bob Larson's message of Mon 29 Jun 87 17:45:07-PDT <12314484757.56.BLARSON@ECLA.USC.EDU> Subject: X.400/88 and failure messages We had a case here of a mailing list in which the "moderator" was quite different from the postmaster, and was, in fact, quite ignorant of the things that go into maintaining a distribution list, as well as the intricacies of mail itself. It was quite necessary for the postmaster (me) to handle the mail-specific side of the list, while the moderator moderated. I think that this may be the case often. There really should be no need for some specialist in one field (in this case it was VLSI) to become a specialist with mail just to organize a collaberation with other specialists. Since however, it is sometimes the case that the person already knows enough, there should be provision, at the very least, for both possibilites. This, as was mentioned by someone already, should be specified on a per-list basis. --- Christopher Welty - Asst. Director, RPI CS Labs * * * * * weltyc@cs.rpi.edu ...!seismo!rpics!weltyc \ / \ / \ / \ / \ / REX QUANDUM. REXQUE FUTURUS. -----------  Received: from Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 30 Jun 87 03:34:50 EDT Received: from ucl-cs-vax2 by nss.Cs.Ucl.AC.UK via Ethernet with SMTP id ab03571; 30 Jun 87 8:25 BST To: David Vinayak Wallace cc: header-people@mc.lcs.mit.edu Subject: Re: X.400/88 and failure messages Phone: +44-1-380-7294 In-reply-to: Your message of Mon, 29 Jun 87 18:55:38 -0400. <221294.870629.GUMBY@AI.AI.MIT.EDU> Date: Tue, 30 Jun 87 08:22:53 +0100 Message-ID: <632.552036173@UK.AC.UCL.CS> From: Steve Kille >From: David Vinayak Wallace >Subject: X.400/88 and failure messages >Date: Mon, 29 Jun 87 18:55:38 EDT >the majority will be small (fewer than 50 >recipients) and amorphous. For lists like these it's often easier to >let the community take responsibility. > Lists are tools for doing serious work - they need management. >This sort of pompous attitude is unnecessary. Why can't a group of >researchers get together and make themselves a small list with which >to do "serious work" without forcing the postmaster to clean up after them? Let me expand a little. I suspect it reflects a different attitude to exactly what consititutes management. For small lists, management can typically be lightweight. What is unacceptable (to me at least) is to send a message to a list, and not have any recognised way of fixing problems when they occur. At UCL, small lists are dealt with in two basic ways: 1) private lists, which are looked after by individuals, and are fully expanded in the header. These are clearly the concern of the individual, and are not reflected by list names in the UCL namespace. 2) lists which get an entry in the ucl namespace (e.g. staff, cine-buffs, sas, and many many others). These will always have a name "list-request" assocaited with them. For most of the "general" lists, this maps onto our postperson. For other lists, it typically maps onto the person who asked for the list in the first place. We do have lists where we allow people to add their own names, whereas others are\ restricted. We only allow valid addresses to be added. In these cases, the most usual management task is the removal of people after they leave (most people forget to remove their names). List errors will always go to the maintainer, and so the user does not get troubled by spurious errors. This system works pretty well for us. It is a vast improvement over earlier times when errors went to the sender, who often did not have a clue what to do with them. Steve  Received: from gjetost.wisc.edu (TCP 20032201041) by MC.LCS.MIT.EDU 30 Jun 87 08:28:35 EDT Date: Tue, 30 Jun 87 07:25:06 CDT From: solomon@gjetost.wisc.edu (Marvin Solomon) Message-Id: <8706301225.AA01864@gjetost.wisc.edu> Received: by gjetost.wisc.edu; Tue, 30 Jun 87 07:25:06 CDT To: Steve.Kille@cs.ucl.ac.uk Subject: Re: X.400/88 and failure messages Cc: header-people@mc.lcs.mit.edu Ok, I know I'm going to regret jumping in to this discussion, but I can't stand it anymore. It seems to me that this discussion has strayed rather far from its origins. If I remember correctly, it was started by a report that a particular standards body was discussing whether mailing list errors (specifically, when a member of a list does not designate a valid mailbox) should be returned to the sender, or forwarded to maintainer. It was reported that the standards body (in the usual manner of standards bodies) decided that you could have it either way. The original submitter then asserted that things would be much simpler if lists always had a maintainer, and asked whether there is ever a good reason NOT to have a maintainer. Please note that in the context of this discussion, a "maintainer" is simply an ORName to which non-delivery notifications should be sent. Please try to avoid flaming about law-and-order, freedom of the skies, and gun control (not you, Steve, but some other contributors to this discussion). Now my two cents: Experience with lists in the Internet seems to indicate that the best approach is to consider the list to be a re-distribution point: Errors in sending TO the list (i.e., the list is somehow "broken") are reflected to the submitter. Errors in sending FROM the list (e.g., a particular member's mailbox has been removed) are reflected to the list (i.e., its maintainer). This principle would seem to apply to any list no matter how small or informal. For small informal lists, there's no reason why the "maintainer" can't be a member of the list. If the "maintainer" knows little about electronic mail, so be it; there's no reason to assume that a random submitter to the list is going to be any more expert, so there's no advantage of reflecting errors to the submitter. All the submitter can do about the error is complain to the maintainer anyhow. The question remains: Is there EVER a case in which it is better to return errors to the submitter? On the other hand, I'm not sure the orginator of this discussion made clear what the overhead is of allowing the option. By the way, some user interfaces provide an abbreviation mechanism that expands a small mnemonic name into a long address or list of addresses ("alias" in your .mailrc, for ucbmail fans). This is NOT a mailing list in the sense we've been discussing it, since nobody but the "owner" can send to it. We can discuss user interface issues, but we must remember that they have nothing to do with mail interchange standards--indeed, there is no reason to standardize them.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 30 Jun 87 14:20:22 EDT Date: Tue, 30 Jun 87 14:06:58 EDT From: "John T. Wroclawski" Subject: Re: X.400/88 and failure messages To: solomon@GJETOST.WISC.EDU cc: header-people@MC.LCS.MIT.EDU Message-ID: <221671.870630.JTW@AI.AI.MIT.EDU> Date: Tue, 30 Jun 87 07:25:06 CDT From: solomon@gjetost.wisc.edu (Marvin Solomon) Subject: Re: X.400/88 and failure messages For small informal lists, there's no reason why the "maintainer" can't be a member of the list. If the "maintainer" knows little about electronic mail, so be it; there's no reason to assume that a random submitter to the list is going to be any more expert, so there's no advantage of reflecting errors to the submitter. All the submitter can do about the error is complain to the maintainer anyhow. The question remains: Is there EVER a case in which it is better to return errors to the submitter? Yes. At MIT there are many small lists set up to share information among groups of people who all happen to be sophisticated users and are all qualified to perform "maintainance" tasks. Whenever a member of the list submits something and gets an error, they fix it. This effectively and simply distributes the job of list maintainance among a group of people, reducing the "overhead" work for all. The situation of all members of a list being willing/able to do maintainance work may be fairly rare in most organizations. But where it exists it works well, and should not be arbitrarily prohibited by a standard formulated by people who never thought of it.  Received: from SH.CS.NET (TCP 1201600122) by MC.LCS.MIT.EDU 30 Jun 87 17:40:46 EDT To: jtw@ai.ai.mit.edu cc: header-people@mc.lcs.mit.edu Subject: re: X.400/88 and failure messages Date: Tue, 30 Jun 87 16:44:14 -0400 From: Craig Partridge > Yes. At MIT there are many small lists set up to share information among > groups of people who all happen to be sophisticated users and are all > qualified to perform "maintainance" tasks. Whenever a member of the list > submits something and gets an error, they fix it. This effectively and > simply distributes the job of list maintainance among a group of people, > reducing the "overhead" work for all. I realize this sounds imperialist, but this is usually a disasterous practice. (How many people out there have managed to break their mail systems because two or more experienced users both tweaked the system, in incompatible ways?) I have no trouble with forbidding this practice in the name of progress. Craig  Received: from WARBUCKS.AI.SRI.COM (TCP 30003002424) by MC.LCS.MIT.EDU 1 Jul 87 02:45:28 EDT Date: Tue 30 Jun 87 22:40:14-PDT From: Peter Karp Subject: list maintainers vs senders To: header-people@MC.LCS.MIT.EDU Message-ID: <552116414.0.PKARP@SRI-WARBUCKS.ARPA> Mail-System-Version: Are there any times when the list sender wants to see error messages which result from problems sending *from* a re-distribution point? Sure, what if you send an important message to a group of people and want to have some idea whether or not they've all seen it. I think the simple fact is that sometimes you want to see the error messages and sometimes you couldn't give a flying .... at a rolling doughnut. I refuse to believe either extremist position. In a similar vein, how many people out there are running software which does automatic mailing list maintenance? What OS does it run on? How does it work? Are the X.400 people considering this issue at all? Peter -------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 1 Jul 87 03:36:04 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 1 Jul 87 03:38:40 EDT Received: from SEARN.BITNET by .MIT.EDU (Mailer X1.24) with BSMTP id 5775; Wed, 01 Jul 87 03:33:50 EDT Received: from QZCOM by SEARN.BITNET (Mailer X1.24) with BSMTP id 8511; Wed, 01 Jul 87 05:04:28 EDT Message-ID: <260503@QZCOM> In-Reply-To: <8706252308.AA02485@urania.think.com> Date: 30 Jun 87 18:04 +0200 From: "Jacob Palme QZ" Reply-To: "Jacob Palme QZ" To: "ARPA Internet Mail Interest List" Subject: X.400/88 and failure messages The current ISO/CCITT thinking on distribution lists in X.400 is that non-delivery notifications should always go back to the previous sublist. The previous sublist can then set up different policies on either forwarding the notification to the list or originator it got the message from, to the maintainer of the sublist, or both. (Note that there is no problem with getting non-delivery notifications sent out to the whole list, since these notifications are a special type of object, which can be recognized as such and handled differently from ordinary messages by the list expander.)  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 2 Jul 87 02:35:11 EDT Date: Thu, 2 Jul 1987 02:34 EDT Message-ID: From: Rob Austein To: Craig Partridge Cc: header-people@MC.LCS.MIT.EDU Subject: X.400/88 and failure messages In-reply-to: Msg of Tue 30 Jun 87 16:44:14 -0400 from Craig Partridge Date: Tue, 30 Jun 87 16:44:14 -0400 From: Craig Partridge To: jtw@ai.ai.mit.edu > Yes. At MIT there are many small lists set up to share information among > groups of people who all happen to be sophisticated users and are all > qualified to perform "maintainance" tasks. Whenever a member of the list > submits something and gets an error, they fix it. This effectively and > simply distributes the job of list maintainance among a group of people, > reducing the "overhead" work for all. I realize this sounds imperialist, but this is usually a disasterous practice. (How many people out there have managed to break their mail systems because two or more experienced users both tweaked the system, in incompatible ways?) I have no trouble with forbidding this practice in the name of progress. Your site can't cope with this kind of list management, so you want a standards committee to tell us that our mail systems can't work this way either? No offense, but this sounds like sour grapes to me. John has presented a valid example of a case where errors should be returned to the message sender, not to the list maintainer (who may default to postmaster). Does that answer the original question?  Received: from NNSC.NSF.NET (TCP 20026200662) by MC.LCS.MIT.EDU 2 Jul 87 08:25:32 EDT To: sra@xx.lcs.mit.edu cc: header-people@mc.lcs.mit.edu Subject: re: X.400/88 and failure messages Date: Thu, 02 Jul 87 08:18:46 -0400 From: Craig Partridge > I realize this sounds imperialist, but this is usually a disasterous > practice. (How many people out there have managed to break their mail > systems because two or more experienced users both tweaked the system, > in incompatible ways?) I have no trouble with forbidding this practice > in the name of progress. > Your site can't cope with this kind of list management, so you want a > standards committee to tell us that our mail systems can't work this > way either? No offense, but this sounds like sour grapes to me. > John has presented a valid example of a case where errors should be > returned to the message sender, not to the list maintainer (who may > default to postmaster). Does that answer the original question? Actually I was speaking from experience as one of five maintainers of the CSNET mail hub. And the number of times we've had to clean up garbage from little private lists at other sites on the Internet is sufficiently large that I believe we really have to require people to maintain them properly. John's suggestion is an invitation to more nuisance. Craig  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 2 Jul 87 19:04:02 EDT Received: from relay2.cs.net by RELAY.CS.NET id ag03693; 2 Jul 87 13:30 EDT Received: from ubc by RELAY.CS.NET id at02734; 2 Jul 87 10:57 EDT Received: by ubc.csnet id AA01180; Thu, 2 Jul 87 07:31:04 pdt Date: 1 Jul 87 23:30 -0800 From: Ken Wallewein To: Peter Karp Cc: header-people@mc.lcs.mit.edu MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET In-Reply-To: <552116414.0.PKARP@SRI-WARBUCKS.ARPA> Message-Id: <256*kenw@noah.arc.cdn> Subject: list maintainers vs senders We use EAN. I don't believe it provides any special provision for errors involving distribution lists. Of course, with version 2.0 due to arrive next month... It has occurred to me that, since such a list must have a location, that location might be used to indicate responsibility. And what prevents the person setting up the list from indicating at that time how these errors are to be handled? I think it's apparent by this time that the choice must be made available. A second point: EAN has a 'confirm' option on sends. If I want to be sure the mail gets where I send it, I use that option. As the man said, 'it works for me'. /kenw A L B E R T A Ken Wallewein R E S E A R C H C O U N C I L  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 3 Jul 87 03:13:53 EDT Date: Fri, 3 Jul 1987 03:12 EDT Message-ID: From: Rob Austein To: Craig Partridge Cc: Header-People@MC.LCS.MIT.EDU Subject: X.400/88 and failure messages Craig, I think we are having two different conversations. I agree that mailing lists should be MAINTAINED. I disagree with your implicit assumption that in order to be maintained a list must have a designated MAINTAINER. What's wrong with allowing the members of a list to maintain the list IF THEY ARE WILLING AND ABLE TO DO SO? In particular, what about this setup is so bad that you wish to outlaw those of us who use it with a good deal of success? While I respect your experience as a maintainer of the CSNet hub, you should realize that John, David (Gumby), and I are speaking as maintainers of the MIT ITS and TOPS-20 mailers. While I have no real idea about the relative sizes of these projects, the difference is between "ridiculously huge" and "more so". We are simply asking that you not outlaw a style of management that we have been using (because it works) since before any of the current mail protocols existed. I suspect this converstion is becoming boring for the rest of the list. If you want to continue, perhaps we could do it offline and sumarize the results. --Rob  Received: from sonora.dec.com (TCP 20013200064) by MC.LCS.MIT.EDU 4 Jul 87 02:03:55 EDT Received: from armagnac.dec.com by sonora.dec.com (5.54.3/4.7.34) id AA10347; Fri, 3 Jul 87 23:00:55 PDT Received: from localhost by armagnac.DEC.COM (4.22.06/4.7.34) id AA02730; Fri, 3 Jul 87 23:00:53 pdt Message-Id: <8707040600.AA02730@armagnac.DEC.COM> To: Craig Partridge Cc: jtw@ai.ai.mit.edu, header-people@mc.lcs.mit.edu Subject: Re: X.400/88 and failure messages In-Reply-To: craig@sh.cs.net's message of Tue, 30 Jun 87 16:44:14 -0400. <8707030831.AA25922@arthur.cs.purdue.edu> Reply-To: "Christopher A. Kent" Date: Fri, 03 Jul 87 23:00:51 -0700 From: kent@decwrl.DEC.COM [MIT sez] Whenever a member of the list submits something and gets an error, they fix it. This effectively and simply distributes the job of list maintainance among a group of people, reducing the "overhead" work for all. [Craig sez] I have no trouble with forbidding this practice in the name of progress. [Chris sez] I have no trouble with allowing there to be multiple maintainers of a list. That way people who want to work in what I will call the MIT style can do so -- everyone on the list is also a maintainer, or the list is marked as "return to sender on error". However, I receive enough junk mail from broken list redistribution points that I'd want it to be extra work to set up a list to work this way. The default should be that there is a single person responsible for every list, and that person gets the error messages. Let's implement mechanism, and try to avoid (strict) policy. We can set up the defaults to push the sort of policy we'd like, though. chris ----------  Received: from SUMEX-AIM.STANFORD.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 4 Jul 87 04:31:58 EDT Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Sat, 4 Jul 87 01:26:55 PDT Date: Sat, 4 Jul 87 00:44:57 PDT From: Mark Crispin Subject: X.400/88 and failure messages To: Header-People@MC.LCS.MIT.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12315609762.8.MRC@PANDA> I consider it appalling that anyone deigns himself to be in a position to dictate to a site how they should implement a facility such as mailing lists. Fortunately, there is no way such a policy could ever be enforced, since nothing prevents a site from hiding a mailing list behind a local mailbox name (this is in fact how this is implemented in some systems). The principle problem is that everyone is thinking about a large, junk mail mailing list. This is by no means the only type of beastie prowling out there that can be called a "list." Before making policies for lists, you need to start thinking about a good definition for a list -- What *IS* a "list", anyway? In MM, a list is simply a mailbox that translates to some set of mailboxes. It is impossible to determine the difference between a list and a forwarding other than by guessing based on the number of elements. I challenge the "lists must have maintainers and the default is Postmaster" crowd to come up with a good policy statement on what the right thing to do if Postmaster itself is a list. This isn't a joke; such a situation is very real. You could also be in the position of second-guessing the sender's intentions. Goddamnit, if I carefully set up a return-path to me, then I want it respected! If I send a message to an address and give it a return-path, I want to be told if my message failed to get through, even if it *is* a list. If I didn't want the errors, I'd set a null return path. How about requiring that all email user agents have a "post junk mail" command that sets the return path null, or alternatively require the user to set his return path in his outgoing messages and default to null otherwise? It makes about as much sense as some of the other half-cocked ideas I've heard in this discussion so far. -------  Received: from thumper.bellcore.com (TCP 30001235021) by MC.LCS.MIT.EDU 6 Jul 87 15:47:56 EDT Received: by darlene.UUCP (4.12/4.7) id AA00492; Mon, 6 Jul 87 15:44:41 edt Date: Mon, 6 Jul 87 15:44:41 edt From: mcohen@darlene (Michael Cohen) Message-Id: <8707061944.AA00492@darlene.UUCP> To: header-people@mc.lcs.mit.edu Subject: non-textual glyphs Does anyone have a (pointer to a) list of e-mailable non-textual symbols, like :-) and |-; as well as non-faces. I'm doing research in translating such information between media. Tx. mcohen@thumper.bellcore.com {ihnp4,decvax,cornell}!uw-beaver!uw-june!mcohen  Received: from IU.AI.SRI.COM (TCP 1201200002) by MC.LCS.MIT.EDU 7 Jul 87 13:31:32 EDT Date: Tue 7 Jul 87 10:29:05-PDT From: Peter Karp Subject: Mailing lists To: header-people@MC.LCS.MIT.EDU Message-ID: <552677345.0.PKARP@IU.AI.SRI.COM> Mail-System-Version: I actually think there's a whole range of things that should be done with the status report messages that mailers generate. There are a total of 4 cases, for the two classes of people the messages should go to and the two classes of messages that get generated. The two classes of people are the sender of the message and the list maintainer. The two classes of messages are the "intermediate" reports (e.g., saying "your message can't be delivered but we'll keep trying for N more days), and the "final" report (which returns the original message after N days). For each possible combination of person and report, we can imagine lists for which the person does want to see the report, and lists for which they don't want to see the report. For example, I don't care to see any of the reports that this message generates. The list maintainer probably only cares to see the final reports. My point is that there should be a way to determine what reports go to whom. This could be done by the message sender on a per-message basis, and/or by the list maintainer on a per-list basis. I suppose the only want to do this in the SMTP world is through header fields. Is there any chance of establishing a standard for this? Peter -------  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Jul 87 08:45:48 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 20 Jul 87 08:46:45 EDT Received: from SEARN.BITNET by MITVMA.MIT.EDU (Mailer X1.24) with BSMTP id 7216; Mon, 20 Jul 87 08:44:15 EDT Received: from QZCOM by SEARN.BITNET (Mailer X1.24) with BSMTP id 1665; Mon, 20 Jul 87 04:37:19 EDT Message-ID: <264074@QZCOM> In-Reply-To: <552677345.0.PKARP@IU.AI.SRI.COM> Date: 19 Jul 87 19:33 +0200 From: "Jacob Palme QZ" Reply-To: "Jacob Palme QZ" To: "ARPA Internet Mail Interest List" Subject: Mailing lists X.400 does not have any support for messages like "Your message cannot be delivered for 4 days" or "Your message will not be read until the recipient gets back from holiday. I tried hard to get this into the standard at the last three standards meetings, but without success.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Jul 87 09:06:42 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 20 Jul 87 09:07:58 EDT Received: from SEARN.BITNET by MITVMA.MIT.EDU (Mailer X1.24) with BSMTP id 7335; Mon, 20 Jul 87 09:05:27 EDT Received: from QZCOM by SEARN.BITNET (Mailer X1.24) with BSMTP id 1669; Mon, 20 Jul 87 04:37:31 EDT Message-ID: <264075@QZCOM> In-Reply-To: <12315609762.8.MRC@PANDA> Date: 19 Jul 87 19:42 +0200 From: "Jacob Palme QZ" Reply-To: "Jacob Palme QZ" To: "ARPA Internet Mail Interest List" Subject: X.400/88 and failure messages > FROM: Mark Crispin > > I consider it appalling that anyone deigns himself to be in a > position to dictate to a site how they should implement a facility > such as mailing lists. I agree that local implementors should have much freedom in how to implement distribution lists. However, there is an advantage in having certain basic characteristics standardised. For example, a standard way of indicating in the mail heading the mailing-list- history, i.e. the list of successive lists which have expanded a message on the way from original submitter to recipient, is very useful in many ways: For loop control, as information to the recipient etc. and I think it is OK for the standard to define how this should work. If distribution lists never were nested, you might be right. But if several lists, maintained by different maintainers using different mail software, are to work together, some aspects should be standardised.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Jul 87 09:31:02 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 20 Jul 87 09:32:19 EDT Received: from SEARN.BITNET by MITVMA.MIT.EDU (Mailer X1.24) with BSMTP id 7465; Mon, 20 Jul 87 09:29:47 EDT Received: from QZCOM by SEARN.BITNET (Mailer X1.24) with BSMTP id 1675; Mon, 20 Jul 87 04:38:10 EDT Message-ID: <264073@QZCOM> In-Reply-To: <552116414.0.PKARP@SRI-WARBUCKS.ARPA> Date: 19 Jul 87 19:29 +0200 From: "Jacob Palme QZ" Reply-To: "Jacob Palme QZ" To: "ARPA Internet Mail Interest List" Subject: list maintainers vs senders > FROM: Peter Karp > > Are there any times when the list sender wants to see error messages > which result from problems sending *from* a re-distribution point? > Sure, what if you send an important message to a group of people and > want to have some idea whether or not they've all seen it. The way the CCITT/ISO distribution list facility in X.400 is going to work, the list maintainer decides, when setting up the list, whether delivery and/or non-delivery notifications should go to the list maintainer, the original submitter, or both. (You should thank ISO for this. If CCITT alone had decided, notifications would only and always have gone to the original sender.) So if you know, when you set up a list, that submitters have the requirement you specify, then you set the list up that way. If a list is set up so as to send delivery and non-delivery notifications only to the list maintainer, and if a submitter wants notification, s/he can ask for recieipt and non-receipt notifications. These are always sent to the original sender. (In X.400: Delivery notifications are sent at delivery to the recipient mailbox, while receipt notifications are sent when the recipient actually reads the message.) However, the handling of receipt notifications will probably not be supported by all X.400 systems, especially in the case of distribution lists, where they are rather complex to handle. The User Agent of the recipient has to check which list sent the message to the recipient, since request-for-reciept notification is a per-recipient flag.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Jul 87 18:37:16 EDT Received: from Think.COM (TCP 1201000006) by AI.AI.MIT.EDU 20 Jul 87 18:26:10 EDT Received: from dagda.think.com by Think.COM; Mon, 20 Jul 87 18:01:03 EDT Received: by dagda.think.com; Mon, 20 Jul 87 18:00:58 EDT Date: Mon, 20 Jul 87 18:00:58 EDT Message-Id: <8707202200.AA02637@dagda.think.com> From: Robert L. Krawitz Sender: rlk@think.com To: JPALME@QZCOM.BITNET Cc: header-people@ai.ai.mit.edu In-Reply-To: "Jacob Palme QZ"'s message of 19 Jul 87 19:42 +0200 <264075@QZCOM> Subject: X.400/88 and failure messages Date: 19 Jul 87 19:42 +0200 From: "Jacob Palme QZ" I agree that local implementors should have much freedom in how to implement distribution lists. However, there is an advantage in having certain basic characteristics standardised. For example, a standard way of indicating in the mail heading the mailing-list- history, i.e. the list of successive lists which have expanded a message on the way from original submitter to recipient, is very useful in many ways: For loop control, as information to the recipient etc. and I think it is OK for the standard to define how this should work. Hmm. This is an interesting idea, and a very welcome one. It's not uncommon for problems a few links down to generate bounce messages, and the Received: headers are not always sufficient to permit debugging. Unfortunately, the problems usually occur in outlying nets, which will be the last to accept new standards, so I suppose we'll all have to live with this problem for a while even if some sort of standard for history tracing is implemented. If distribution lists never were nested, you might be right. But if several lists, maintained by different maintainers using different mail software, are to work together, some aspects should be standardised. Nested distribution lists are too useful to do without (I'm not disagreeing with you, because I don't read you as being opposed to nested distribution lists). With careful maintenance, nested distribution lists provide an excellent way of balancing load over the entire network and minimizing concentrations of workload. However, they also make it difficult to track down problems. I think the real point, which Mark made in an included message that I deleted, is that different maintainers have different systems for managing their lists that work best them. I personally would like a more complete audit trail in case of problems, including returning bounce messages to the maintainer and a history expansion, as I think that this would make it easier for me to maintain my list. A lot of other people apparently disagree, and they maintain their lists just fine. I suppose it's just the Emacs mentality (feeping creaturism) taking over :-) Robert^Z  Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 24 Jul 87 12:30:40 EDT Received: from relay2.cs.net by RELAY.CS.NET id aa06946; 24 Jul 87 11:48 EDT Received: from lsu.edu by RELAY.CS.NET id am07383; 24 Jul 87 11:43 EDT Received: by lsu.edu (5.51/4.7) id AA11542; Thu, 23 Jul 87 08:51:46 CDT Date: Thu, 23 Jul 87 08:51:46 CDT From: Mounir Bsaibis To: header-people@mc.lcs.mit.edu I am looking for an LN03 printcap. The one I have does not drive the printer correctly. If you have what I need, please be kind and send a copy to the following address: unix-wizards@brl-semi.arpa unix-wizards@brl-semi.arpa  Received: from jade.berkeley.edu (TCP 20010104011) by MC.LCS.MIT.EDU 29 Jul 87 05:06:22 EDT Received: by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.15) id AA25455; Wed, 29 Jul 87 02:04:32 PDT Message-Id: <8707290904.AA25455@jade.berkeley.edu> Return-Path: EMAILDEV%UKACRL.BITNET@WISCVM.WISC.EDU Received: By UK.AC.RL.IB (MAILER) ; Wed, 29 Jul 87 09:57:49 BST Via: UK.AC.LIV.IBM; 29 JUL 87 9:57:43 BST Date: Wed, 29 Jul 87 09:52:51 BST From: Chris Wooff Subject: Help with address To: HEADER-PEOPLE@mc.lcs.mit.edu I wonder if someone in your SIG could possibly enlighten me on the address: wiley!ai-chi-request@lll-lcc.ARPA. which we have so far failed to reach. The bit I really don't understand is the 'lll-lcc' portion. (It is the name of the coordinater of a SIG which one of my colleagues would like to join). Bear in mind that I am sending from a UK (JANET) address). As I am not currently a member of Header-People please send any mail direct to me Thanks in advance for any help.  Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 5 Aug 87 02:34:20 EDT Date: Wed, 5 Aug 1987 00:31 MDT Message-ID: From: "Frank J. Wancho" To: HEADER-PEOPLE@MC.LCS.MIT.EDU cc: WANCHO@SIMTEL20.ARPA Subject: Incomplete IBM PROFS-to-DDN Header Conversions Some IBM sites on the net run a PROFS-to-DDN mail interface which, although useable, construct incomplete headers. Specifically, the "blank" line separating the header from the body is misplaced to just prior to the Subject: line, and the CC: lines are left in PROFS format at the end of the message. This causes problems with my users who expect the computer to work for them and construct replies referencing the sender's Subject: line and with Cc: lines to all the original recipients as well. Are there any PROFS people reading this message who have a "corrected" version of the interface and can point me to a contact to obtain such a version? --Frank  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 12 Sep 87 22:54:01 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 12 Sep 87 22:55:43 EDT Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/12/87 at 22:49:49 EDT Received: from SEARN.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8023; Sat, 12 Sep 87 22:49:45 EDT Received: from QZCOM by SEARN.BITNET (Mailer X1.24) with BSMTP id 2825; Sun, 13 Sep 87 04:48:39 EDT Message-ID: <276349@QZCOM> Date: 12 Sep 87 18:07 +0200 From: "Jacob Palme QZ" Reply-To: "AMIGO Advanced Group (communication)" , "RARE WG8 Management of application services" , "RARE WG4 Network Management and Operation" , "Reseaux Associes (pour la) Recherche Europeene (RARE)" , Reseaux_Associes_Recherche_Europeene@EUROKOM.UUCP To: "BITNIC MAIL-L List" , amigo_group@XPS.GMD.DBP.DE , "AMIGO Advanced Group (communication)" , "RARE WG8 Management of application services" , "RARE WG4 Network Management and Operation" , "Reseaux Associes (pour la) Recherche Europeene (RARE)" , Reseaux_Associes_Recherche_Europeene@EUROKOM.UUCP , mhsnews@VAX.RUNIT.UNIT.UNINETT , HEADER-PEOPLE@AI.AI.MIT.EDU bcc: "David Lord" , "John Ogilvie" , "Giorgio Heiman" , amiadv_emu@EMU.GIPSI.FR , "Petter Kongshaug" Subject: Remote mail directory service now available at QZCOM.BITNET A remote mail directory service is now available at QZCOM.BITNET. The service allows you to send ordinary mail messages to QZCOM.BITNET, with commands in the message text, to: > Search for the names of users and conferences (=distribution lists) in QZCOM. > Find description and other information about users and conferences. > Add and remove yourself from conferences in QZCOM. When you add yourself to a conference, messages entered into that conference will be sent by electronic mail to your mailbox. > Retrieve certain files with help information. 2. WHERE TO SEND MESSAGES Send your messages, containing directory commands, to DIRECT@QZCOM.BITNET (for the English language COM system at QZ) or to DIRECT@QZKOM.BITNET (for the Swedish language KOM system at QZ). Directory requests are normally handled at nighttime, and responses returned the next day by electronic mail to the sender of the request. 3. SEARCHING FOR NAMES OF USERS AND CONFERENCES This service allows you to search for the network mail names of users and conferences. You can input a name pattern, and all names matching the pattern will be found. Command syntax: DESCRIBE ( NAME ) where can be a name or part of a name according to the RFC822 syntax for address, for example "Jacob Palme" "Jacob Palme" SIMULA_Forum SIMULA_Forum@QZCOM.BITNET Examples: To find all QZCOM users with the name "Smith", send the command: DESCRIBE ("Smith" NAME) To find all QZCOM conferences about RARE, send the command: DESCRIBE ("RARE" NAME) To find if there is any QZCOM conference about the SIMULA programming language, send the command: DESCRIBE ("SIMULA" NAME) The difference between upper and lower case characters is not significant in directory commands. 4. FINDING OUT MORE INFORMATION ABOUT A USER OR A CONFERENCE This service allows you to find out more information about a particular user or conference. This service will only be provided if the matches one single user or conference. Command syntax: DESCRIBE ( [NAME] [DESCRIPTION] [CHARGING] [MODERATOR] ) NAME returns the full network name of the user or conference, DESCRIPTION returns a textual description, including postal address, telephone number and latest access information, CHARGING returns information about costs, MODERATOR returns the name of the person who manages the conference. Examples: To find information about the QZCOM conference "RARE Directories", which has the network name , send any of the following commands: DESCRIBE ("RARE Directories" NAME DESCRIPTION CHARGING MODERATOR) DESCRIBE (RARE_Directories NAME DESCRIPTION CHARGING MODERATOR) DESCRIBE (RAREDIR NAME DESCRIPTION CHARGING MODERATOR) DESCRIBE (RAREDIR@QZCOM.BITNET NAME DESCRIPTION CHARGING MODERATOR) To find information about the QZCOM user "Jacob Palme QZ", who has the network name , send any of the the following commands: DESCRIBE ("Jacob Palme QZ" NAME DESCRIPTION CHARGING MODERATOR) DESCRIBE (Jacob_Palme_QZ NAME DESCRIPTION CHARGING MODERATOR) DESCRIBE (JPALME NAME DESCRIPTION CHARGING MODERATOR) DESCRIBE (JPALME@QZCOM.BITNET NAME DESCRIPTION CHARGING MODERATOR) 5. ADDING AND REMOVING YOURSELF FROM A QZCOM CONFERENCE Command syntax: ADD ( * REC [] ) to add yourself to the conference, and get also the N latest previously sent messages from the conference. The number is approximate, you may get less than N messages. After ADD, all new messages in the conference will automatically be sent to your mailbox until you perform a DELETE command: DELETE ( * REC ) to delete yourself from the conference. Where the syntax for is the same as for above, and is an unsigned integer. Restrictions: You can only add yourself automatically to open (public) conferences. If you want to become member of closed conferences, write a message to INFO@QZCOM.BITNET. Examples: To add yourself to the QZCOM conference "ByteCOM news", send the command: ADD ("ByteCOM news" * REC) To add yourself to the QZCOM conference "Prolog and Logic programming", and ask for not only future messages in the conference to be sent to you, but also the 10 latest earlier messages to be sent to you, send the command: ADD ("Prolog and logic programming" * REC 10) To remove yourself from the QZCOM conference "Speakers corner", send the command: DELETE ("Speakers corner" * REC) 6. CHARGING There is a charge for subscribing to conferences in QZCOM and having them sent to you. The charge is at present (September 1987) approximately 8 SEK per 1000 characters. Universities get about 50 % reduction, and messages within the Nordic countries get about 50 % reduction on this charge. If you send a mail with the command DESCRIBE (* CHARGING) you will get more information about charging. You will also be told if you have an account, and if not, you will by electronic mail get a form, which you have to fill in, sign, and send in by postal mail to get the account. You can use the directory service, and send mail to QZCOM users and conferences, even though you do not have any account. 7. HELP If you send a mail with the command HELP The text you are reading now will be returned. You can also send the command HELP followed by a parameter on the same line, and for some parameters, HELP on that subject is returned. Examples: HELP DTEADR will return a list of the DTE addresses for some X.25 hosts, mainly in the Nordic countries, HELP PCLIB will return information about libraries of public domain personal computer software, HELP ALL will return a complete list (in Swedish) of all HELP files available in this way. If you have other questions, requiring manual response, write to INFO@QZCOM.BITNET. 8. AMIGO INFORMATION AMIGO is a joint European project to develop better methods for distributed group communication. For more information about AMIGO, write to SANTO@GUS1.GMD.DBP.DE. AMIGO has developed a standard for accessing directory systems in other systems. This standard provides a standardized format for both requests and responses, so that the responses can be handled automatically by those who so wish. The commands described above are a subset of the AMIGO directory service with a few extensions. Users on BITNET can request the full description of the AMIGO directory protocols from "Jacob Palme QZ" . Users on other networks can request the same information from "Steve Benford" .  Received: from BIONET-20.ARPA (TCP 20027140005) by MC.LCS.MIT.EDU 17 Sep 87 16:54:44 EDT Date: Thu 17 Sep 87 13:50:43-PDT From: David Roode Subject: Re: Help with address To: QQ43%UK.AC.LIVERPOOL.IBM%UKACRL%WISCVM.WISC.EDU@BIONET-20.ARPA cc: HEADER-PEOPLE@MC.LCS.MIT.EDU In-Reply-To: <8707290904.AA25455@jade.berkeley.edu> Phone: (415) 962-7322 Message-ID: <12335413607.55.ROODE@BIONET-20.ARPA> I suspect that what may be causing your problem is a possible inability of WISCVM.BITNET a.k.a. WISCVM.WISC.EDU to pass address containing bangs. Mail from JANET through the AC.UK BITNET gateway can certainly flow to WISCVM and out on the Internet in the U.S. You have an alternative route to the U.S. in the UK (2 actually). One of these is through University College of London which is a direct gateway from JANET to the Internet. If you can get permission from them, they may be better able to route your mail containing bangs in the name. Their host is UK.AC.UCL.CS as known to you I believe. A third route from the U.K. to the U.S. is the UUCP network gateway, and I don't know much about that one. It can certainly pass addresses with bangs in them, since that is or was the UUCP standard address format. -------  Received: from NSS.Cs.Ucl.AC.UK (TCP 1600000011) by MC.LCS.MIT.EDU 18 Sep 87 14:47:42 EDT Date: Fri, 18 Sep 87 15:22:58 BST From: Postie To: David Roode cc: header-people@mc.lcs.mit.edu, QQ43%ibm.liverpool.ac.uk@NSS.Cs.Ucl.AC.UK Subject: Re: Help with address Just for your info: In fact the UCL gateway between the UK and the Internet should now be called nss.cs.ucl.ac.uk (reverse order from the UK, of course). cs.ucl.ac.uk should now be used only to reach members of the department of computer science at UCL. Irene Hassell.  Received: from BIONET-20.ARPA (TCP 20027140005) by MC.LCS.MIT.EDU 18 Sep 87 16:44:49 EDT Date: Fri 18 Sep 87 13:23:30-PDT From: David Roode Subject: Re: Help with address To: irene@NSS.CS.UCL.AC.UK cc: header-people@MC.LCS.MIT.EDU, QQ43%ibm.liverpool.ac.uk@NSS.CS.UCL.AC.UK, bionet@BIONET-20.ARPA In-Reply-To: Message from "Postie " of Fri 18 Sep 87 11:43:44-PDT Phone: (415) 962-7322 Message-ID: <12335670795.38.ROODE@BIONET-20.ARPA> Thank you very much for that information. Is the gateway generally available for mail flow from Internet to UK? From UK to Internet? What are the access restrictions in general for such mail flow? -------  Received: from BIONET-20.ARPA (TCP 20027140005) by MC.LCS.MIT.EDU 21 Sep 87 13:03:10 EDT Date: Mon 21 Sep 87 09:57:21-PDT From: David Roode Subject: Re: Help with address To: irene@NSS.CS.UCL.AC.UK cc: header-people@MC.LCS.MIT.EDU, bionet@BIONET-20.ARPA In-Reply-To: Message from "Postie " of Mon 21 Sep 87 07:43:31-PDT Phone: (415) 962-7322 Message-ID: <12336419699.44.ROODE@BIONET-20.ARPA> Thanks again for the information. At BIONET, we do make sure that messages responded to by using the mail agent's REPLY command do flow back thorugh the gateway whence the query came. To make this work with the UK/EARN gateway, we have to define the host AC.UK which that gateway stamps upon all messages passing through it that we receive. As near as we can tell, this is an otherwise undefined host name on the Internet. I have tried to communicate with the UK/EARN gateway people, but they have not taken any action that I know of on the matter of using an undefined host name in the mail they pass on to BITNET for eventual delivery to the Internet. -------  Received: from NSS.Cs.Ucl.AC.UK (TCP 20012204403) by MC.LCS.MIT.EDU 21 Sep 87 13:35:18 EDT Date: Mon, 21 Sep 87 15:14:14 BST From: Postie To: David Roode cc: irene@NSS.Cs.Ucl.AC.UK, header-people@mc.lcs.mit.edu, QQ43 <@NSS.Cs.Ucl.AC.UK:QQ43@ibm.liverpool.ac.uk>, bionet@bionet-20.arpa Subject: Re: Help with address David, All traffic through the gateway is logged, and undergoes some authorisation checking. mail FROM the UK to the US is refused if it is not authorised traffic. Users authorise their mail by applying to use the Gateway ;if approved they register the mailbox addresses they send from, these addresses go into a database referred to by the authorisation control system. Access control is implemented because the UK research bodies which fund the gatewy wish to control who is using it. It costs them quite a lot of money, in IPSS bills and support of the general infrastructure. Traffic from the US to the Uk that is not associated with an authorised mailbox ius, strictly speakin, unauthorised. However, it is not currently blocked. We are aware that cases such as UK users only wishing to receive mail from US mailing lists should perhaps not have to apply for authorisation. I believe the Gateway's Governing Committee is currently formulating policy in this area. However situations where UK users are sending out of another gateway to arpanet - the UK/EARN gateway currently has not access control - but RECEIVING mail from arpanet via nss.cs.ucl.ac.uk are not looked upon favourably. If two-way traffic between UK and arpanet users is going on, then the UK user should apply for authorisation to use the UCL gateway. US arpanet users making initial contact with UK colleagues shoudl suggest the latter contact liaison@uk.ac.ucl.cs.nss if they require access to arpanet via UCL. Irene. From: David Roode Subject: Re: Help with address To: irene@uk.ac.ucl.cs.nss cc: header-people@edu.mit.lcs.mc, QQ43 , bionet@arpa.bionet-20 In-Reply-To: Message from "Postie " of Fri 18 Sep 87 11:43:44-PDT Phone: (415) 962-7322 Message-ID: <12335670795.38.ROODE@BIONET-20.ARPA> Thank you very much for that information. Is the gateway generally available for mail flow from Internet to UK? From UK to Internet? What are the access restrictions in general for such mail flow?  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 29 Oct 87 16:35:30 EST Received: from ALMSA-1 (TCP 3200200075) by AI.AI.MIT.EDU 29 Oct 87 16:35:28 EST Received: from almsal by ALMSA-1.ARPA id a000984; 29 Oct 87 15:06 CST Date: Thu, 29 Oct 87 14:49:05 CST From: Will Martin -- AMXAL-RI To: header-people@AI.AI.MIT.EDU cc: info-hams-request@SIMTEL20.ARPA Subject: Who's at fault here? Messages like the one appended have been showing up on the Info-Hams list (and, I suppose, on the USENET newsgroup to which it is gatewayed). It looks to be a reject of a bad address on a sub-distribution (so the moderator of the Info-Hams mailing list cannot fix it by changing his own mailing list entries). Anyway, it is hard to determine just who to complain to in such a situation. Who is at fault? Is the rejecting host's mail system behaving incorrectly by rejecting these back to the whole mailing list's address? Or is it behaving according to the RFC's and rejecting back to the contents of the correct field? If the latter, then, is the sub-distribution at fault for munging the header so that rejects are going to the list instead of to a local contact, or the main list moderator (the -request address)? Or was it correctly handling these messages and properly redistributing them? Or is the main mailing list at fault for not having the correct format in the messages so that rejects would go to the -request address? Or is everybody doing everything right according to the RFC's and this spew of error rejects is falling thru the cracks, finding a loophole in the rules? I suspect the redistribution point, because there is a line included that shows it replaced the -request address with the list address at some point, but I may be wrong -- maybe it was supposed to do that. I don't really know much about the mailsystem details so I can't figure this out myself, and I turn to the experts on this list to ask... Regards, Will Martin > Received: from simtel20.arpa by ALMSA-1.ARPA id a001209; 28 Oct 87 21:22 CST > Received: from VB.CC.CMU.EDU by SIMTEL20.ARPA with TCP; Wed, 28 Oct 87 19:47:41 MST > Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Wed, 28 Oct 87 20:38 EST > Date: Wed, 28 Oct 87 20:38 EDT > From: PMDF Mail Server > Subject: Undeliverable mail > To: INFO-HAMS@SIMTEL20.ARPA > > The message could not be delivered to: > > Addressee: 10217_00 > Reason: > %MAIL-E-NOSUCHUSR, no such user 10217_00 at node CISVM2 > > ---------------------------------------- > > Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Wed, 28 Oct 87 20:36 EDT > Received: From CMUCCVMA(MAILER) by PITTVMS with RSCS id 7168 for > 10217_00@PITTVMS; Wed, 28-OCT-1987 20:33 EST > Received: by CMUCCVMA (Mailer X1.25) id 7166; Wed, 28 Oct 87 20:35:09 EST > Date: 26 Oct 87 15:39:59 GMT > From: George Gorsline > Subject: Re: QSL cards > Sender: Info Hams <@vms.cis.pittsburgh.edu:DIST-HAM@UIUCVMD.BITNET> > To: Todd Paisley <10217_000544@vms.cis.pittsburgh.edu> > Reply-to: INFO-HAMS@SIMTEL20.ARPA > Comments: Warning -- original Sender: tag was > info-hams-request@simtel20.arpa > X-To: info-hams@simtel20.arpa > > [Text deleted here; not relevant]  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 30 Oct 87 03:26:02 EST Received: from oberon.USC.EDU (TCP 1200000171) by AI.AI.MIT.EDU 30 Oct 87 03:26:15 EST Received: by oberon.USC.EDU (5.51/5.5) id AA21557; Thu, 29 Oct 87 23:54:31 PST Message-Id: <8710300754.AA21557@oberon.USC.EDU> Received: from BITNET-GATEWAY by forty2.usc.edu; Thu, 29 Oct 87 23:53 PDT Date: 29 Oct 87 23:42:51 From: Leonard D Woren Subject: Re: Who's at fault here? To: header-people%ai.ai.mit.EDU@oberon.USC.EDU The way I read it, it's a PMDF problem. PMDF is a mailer for VMS, and can act as a BITNET <-> Internet gateway. /Leonard  Received: from ECLA.USC.EDU (TCP 3205200101) by MC.LCS.MIT.EDU 9 Nov 87 16:22:16 EST Received: by FNS1; Mon, 09 Nov 87 13:09:28 PST Date: Mon, 09 Nov 87 13:09:28 PST From: Bob Larson Subject: bad addresses from uucp To: header-people@MC.LCS.MIT.EDU Message-id: <7110987.15632381@FNS1> Some uucp mail sites are trying to get smarter about how to route things, and wind up messing things up. Apperently they realize that oberon.usc.edu (citvax!oberon) is willing to gateway mail to the .usc.edu domain, so they create a uucp path to forward the mail to oberon. However, many (most?) of the intermediate sites are also on the arpanet, and take @ at higher presidence than ! when routing mail. The mail gets to my site, but the address is not correct (contians multiple !) and gets rejected. The rejection message then gets rejected because it was converted to upper case (my mailer does this to host names and local addresses) and uucp is case sensitive. The mail does get to the correct place, since the rejected rejection is delivered to a human (me). (I'm postmaster and info-prime-request as well as r.larson) Is there any solution to this problem? (Fixing my mailer not to uppercase the rejection just throws it at someon else.) Here is an example header: (The @ and % are reversed in the original To: address, but I've got others without that problem.) cup.portal.com is not the only site guilty of this. Received: by FNS1; Fri, 06 Nov 87 18:56:52 PST Received: from ECLC by ECLA with DECnet; Fri 6 Nov 87 18:22:14-PST Received: from SUN.COM by ECLC.USC.EDU; Fri 6 Nov 87 18:17:13-PST Received: from sun.Sun.COM by Sun.COM (4.0/SMI-3.2) id AA19166; Fri, 6 Nov 87 18:11:46 PST Received: by sun.Sun.COM (4.0/SMI-4.0) id AA07458; Fri, 6 Nov 87 18:18:14 PST Date: Fri, 6 Nov 87 18:18:14 PST From: MAILER-DAEMON@Sun.COM (Mail Delivery Subsystem) Subject: Returned mail: Host unknown Message-Id: <8711070218.AA07458@sun.Sun.COM> To: ----- Transcript of session follows ----- bad system name: PORTAL uux failed. code 68 550 ... Host unknown ----- Unsent message follows ----- Return-Path: Received: from snail.sun.com by sun.Sun.COM (4.0/SMI-4.0) id AA07456; Fri, 6 Nov 87 18:18:14 PST Received: from Sun.COM (arpa-dev) by snail.sun.com (4.0/SMI-3.2) id AA00341; Fri, 6 Nov 87 18:14:48 PST Received: from ECLA.USC.EDU by Sun.COM (4.0/SMI-3.2) id AA19157; Fri, 6 Nov 87 18:11:27 PST Message-Id: <8711070211.AA19157@Sun.COM> Date: Fri, 06 Nov 87 17:46:48 PST From: The Mailman To: Subject: Message failure. sun!lll-lcc!rutgers!cit-vax!oberon!info-prime-request@FNS1: Unknown mailbox! ----------- Received: by FNS1; Fri, 06 Nov 87 17:46:48 PST Received: from ECLC by ECLA with DECnet; Fri 6 Nov 87 17:32:18-PST Received: from SUN.COM by ECLC.USC.EDU; Fri 6 Nov 87 17:31:36-PST Received: from sun.Sun.COM by Sun.COM (4.0/SMI-3.2) id AA17618; Fri, 6 Nov 87 17:02:23 PST Received: from portal.UUCP by sun.Sun.COM (4.0/SMI-4.0) id AA05788; Fri, 6 Nov 87 17:08:52 PST From: portal!cup.portal.com!tmanos@Sun.COM Received: from portal2.portal.com by portal.com (3.2/Portal 5.1) id AA26546; Fri, 6 Nov 87 17:04:27 PST Received: by portal2.portal.com (1.1/Portal 5.1 (sub)) id AA06198; Fri, 6 Nov 87 17:03:16 PST To: info-prime-request@fns1%ecla.usc.edu Subject: Back issues Lines: 11 Date: Fri Nov 6 17:03:13 1987 Message-Id: <8711061703.1.121@cup.portal.com> X-Origin: The Portal System (TM) X-Possible-Reply-Path: tmanos@cup.portal.com X-Possible-Reply-Path: sun!portal!cup.portal.com!tmanos  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 13 Nov 87 15:55:04 EST Received: from violet.berkeley.edu (TCP 20010104026) by AI.AI.MIT.EDU 13 Nov 87 15:52:49 EST Received: from garnet.berkeley.edu by violet.berkeley.edu (5.54 (CFC 4.22.3)/1.16.17l) id AA19684; Fri, 13 Nov 87 12:40:36 PST Received: by garnet.berkeley.edu (1.2/Ultrix2.0-CFC.8v) id AA16943; Fri, 13 Nov 87 12:40:19 pst Date: Fri, 13 Nov 87 12:40:19 pst From: netinfo%garnet.Berkeley.EDU@violet.berkeley.edu (Postmaster & BITINFO) Message-Id: <8711132040.AA16943@garnet.berkeley.edu> To: header-people@ai.ai.mit.edu, info-nets@think.com Subject: Re: Domain servers, mail exchangers, etc. I have noticed at least one mail gateway for a UUCP zone domain name that does not do domain to uucp address conversion, but expects the non-domain name address mail transport agents down the line to be able to interpret domain names. Please, if you are setting up a mail exchanger (MX) entry in an Internet domain server, remember that your mail gateway is also responsible for doing any needed address conversion. Bill Wells postmaster@jade.berkeley.edu  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 16 Nov 87 14:13:52 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Mon, 16 Nov 87 13:50:05 EST Received: from VTVM1.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4816; Mon, 16 Nov 87 13:49:50 EST Received: by VTVM1 (Mailer X1.24) id 9333; Mon, 16 Nov 87 13:40:46 EST Date: Mon, 16 Nov 87 13:16:09 EST From: John Owens Subject: Re: bad addresses from uucp To: Header-People Discussion Cc: Bob Larson In-Reply-To: Message of Mon, 09 Nov 87 13:09:28 PST from >However, many (most?) of the intermediate sites are also on >the arpanet, and take @ at higher presidence than ! when routing >mail. The mail gets to my site, but the address is not correct >(contians multiple !) and gets rejected. > . . . >Here is an example header: (The @ and % are reversed in the original >To: address, but I've got others without that problem.) The problem in this case is that while there are ways to handle @-form addresses over UUCP (mail to R.LARSON@FNS1.USC.EDU, if that were a valid address, would be sent via rmail sun!lll-lcc!rutgers!cit-vax!oberon!fns1.usc.edu!r.larson and there would be no problem with it arriving (although what the headers would look like when it got there....)), there's not yet a good way to handle mixed %-@ addresses (or route-addrs). R.LARSON%FNS1@ECLA.USC.EDU would become rmail sun!lll-lcc!rutgers!cit-vax!oberon!ecla.usc.edu!r.larson%fns1 and while there are rules about !-vs-@ (@ takes precedence), there are no rules about !-vs-%. If anyone along the way gives the % precendence, it's lost. With the @-% switch in the message you gave, it gets even worse. I can't tell whether the original user typed in like that or perhaps typed multiple @-signs or something, but since the path was still in the envelope recipient, complete with its first part, sun, we can tell that the rmail command passed from portal to sun ended in either @ecla.usc.edu or %ecla.usc.edu, causing sun to send it via SMTP, never stripping anything off of the path, *and never sending it through any intermediate sites*. (If it had, those parts of the path would have been successively stripped off of the rmail line.) The fix here would have to be in portal's handling of %'s and @'s.... -John Owens Virginia Tech Communications Network Services OWENSJ@VTVM1.BITNET owens@vtopus.cs.vt.edu +1 703 961 7827 john@xanth.UUCP  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 16 Nov 87 14:14:12 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Mon, 16 Nov 87 14:04:33 EST Received: from VTVM1.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4921; Mon, 16 Nov 87 14:04:13 EST Received: by VTVM1 (Mailer X1.24) id 5746; Mon, 16 Nov 87 13:09:03 EST Date: Mon, 16 Nov 1987 12:32:50 EST From: John Owens Subject: Re: Domain servers, mail exchangers, etc. To: Header-People Discussion , Info-Nets List Cc: Bill Wells In-Reply-To: Message of Fri, 13 Nov 87 12:40:19 pst from >I have noticed at least one mail gateway for a UUCP zone domain name that >does not do domain to uucp address conversion, but expects the non-domain >name address mail transport agents down the line to be able to interpret >domain names. Please, if you are setting up a mail exchanger (MX) entry >in an Internet domain server, remember that your mail gateway is also >responsible for doing any needed address conversion. Please be more specific about what you expect to happen, and what you're seeing. If, as I suspect, you're seeing the Internet->UUCP gateway leave the From: address in a pure domain form, then what the gateway is doing is (arguably) correct. The standard which most of the UUCP gatewaying world tried to conform to, RFC 976, specifies that the headers within the message should always remain in domain, @, form, and that only the *envelope* (the arguments to the rmail command, or the address in an SMTP RCPT TO:<...>) should be modified by the gatewaying system to adapt to network transport considerations. The receiving (UUCP) site is expected to be able to interpret domain addresses; there is widely available public domain software to do this.... There are a number of reasons that this is somewhat controversial: 1- Many mail installations set up between the advent of sendmail and the general acceptance of RFC976 would rewrite header addresses (in violation of RFC822), doing such things as prepending hostname!, creating hybrid addresses (a!b!c%d@e), etc. Many of these hosts still do so. 2- There are a large number of UUCP sites that have not installed any domain-handling software, but use programs like Berkeley Mail or System V mailx which use the From: field instead of the UUCP From_ line to reply to messages; these sites cannot reply to a pure domain address. 3- Some gateways do not agree with RFC976, preferring to use something that is more likely to work, namely rewriting addresses coming from the Internet from user@do.ma.in to gateway!do.ma.in!user, which is what you (Bill) seem to prefer. This doesn't always work, anyway, since some intermediate UUCP sites will not prepend their hostname (either they follow RFC976 or they are a truly pure UUCP site - no sendmail), and others will (sites with sendmail using the configuration file provided with the system). What I and others see as the solution is for gatewaying sites to leave addresses alone coming from the Internet to UUCP, leave addresses coming from UUCP to the Internet that are already in domain form alone, and to only change pure bang addresses coming from UUCP to the Internet, either by appending the gateway domain (host!user@gateway.org), stripping the bang path down to the last two components and turning them around to avoid hybrid addresses (user%host.UUCP@gateway.org for host!user or user%do.ma.in@gateway.org for do.ma.in!user). A variant of the latter is to turn do.ma.in!user into user@do.ma.in, and only add the gateway domain for the host!user case. All but the first of these can be dangerous, however, if the message has passed through too many gateways that have rewritten the address in too many different ways. If everyone that forwards mail via UUCP and runs sendmail, Internet gateway or not, would adopt RFC976 (and use programs like smail to help in this), we wouldn't have this mess. Since this isn't going to happen any time soon, we just have to live with it as best we can. -John Owens Virginia Tech Communications Network Services OWENSJ@VTVM1.BITNET owens@vtopus.cs.vt.edu +1 703 961 7827 john@xanth.UUCP P.S. For those of you who aren't confused enough yet :-), here's an example of the problems caused by the incompatibilities. I saw this address recently in a mailing list: From: Tom Allebrandi This originated as From: Tom Allebrandi and was sent to info-ibmpc@simtel20.arpa via UUCP: rmail unipress!rutgers!simtel20.arpa!info-ibmpc Unipress, running a vanilla 4.2BSD sendmail.cf, prepended its address, giving From: Tom Allebrandi which is already ambiguous. Rutgers, when sending it to the Internet, converted the @ to a % and added its domain, giving the address seen in the list. If USER@HOST.ARPA replied to this address, the message would go to rutgers.edu, which would most likely convert the % to an @ and give it precedence, then send to unipress!ta2 at edison.ge.com via UUCP: rmail unipress!edison!unipress!ta2 From: Joe User Unipress again prepends its address, giving rmail edison!unipress!ta2 From: Joe User Edison, since it runs smail and sees that the mail is just passing through, leaves it alone and sends it on to unipress!ta2. When unipress sees rmail ta2 the mail fails. In this example, the failure message would get back to the originator, but it is easy to find situations where it wouldn't and would end up in the mailbox of some postmaster somewhere, or, worse, in the "uucp" user's incoming mailbox on a system without an observant administator....  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 20 Jan 88 10:59:16 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Wed, 20 Jan 88 10:57:59 EST Received: from DGAIPP1S (MJL) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 1950; Wed, 20 Jan 88 10:57:50 EST Date: Thu, 14 Jan 88 09:23 MEZ From: Martin Lottermoser To: Header-People Discussion Subject: Correction to my mail of 13 Jan 88 15:45 CET My apologies! Of course, I muddled it. The rules I gave under (a) and (b) should be interchanged, i.e.: (a) From the American time zones it follows that: To obtain UTC from a with offset, one has to subtract the offset from the given time. (b) From the military time zones: If an offset is given in a , it specifies the amount one has to add to the given time to obtain UTC. Martin  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 20 Jan 88 10:59:32 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Wed, 20 Jan 88 10:58:07 EST Received: from DGAIPP1S (MJL) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 1954; Wed, 20 Jan 88 10:58:00 EST Date: Wed, 13 Jan 88 15:45 CET From: Martin Lottermoser To: Header-People Discussion Subject: Interpretation of local time offset () in RFC822 In the date field of a message, RFC822 defines a . This can take the form of +hhmm or -hhmm indicating "the amount of offset from UT" (UTC is meant, I suppose). Unfortunately, I do not have access to the ANSI standard X3.51-1975 quoted in RFC822, therefore I cannot determine the meaning directly. However, RFC822 specifies offsets for the American time zones and the military ones. But again, unfortunately, these specifications disagree: (a) Consider the American time zones. RFC822 says, e.g.: EST = -5. Now, UTC can be obtained from EST by adding 5 hours. Therefore the interpretation should be: If an offset is given in a , it specifies the amount one has to add to the given time to obtain UTC. (b) Now for the military time zones. RFC822 says, e.g.: "A:-1". But A is Central European Time, hence: To obtain UTC from a with offset, one has to subtract the offset from the given time. What is the correct interpretation? Martin  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 27 Jan 88 04:51:03 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Wed, 27 Jan 88 04:49:17 EST Received: from DGAIPP1S (MJL) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 9133; Wed, 27 Jan 88 04:46:59 EST Date: Wed, 27 Jan 88 10:44 CET From: Martin Lottermoser Reply-To: Martin Lottermoser To: Dave Taylor cc: HEADER-PEOPLE@MC.LCS.MIT.EDU In-Reply-To: <8801201803.AA22461@atom> (Your message of Wed, 20 Jan 88 10:03:19 PST) Subject: Re: Interpretation of local time offset () in RFC822 Dave, your comment is the only response I've got so far, but nevertheless I am sending a copy of this to the whole group (in the hope of stirring up more answers). The error of interpretation in my own example --------------------------------------------- You quite correctly pointed out that the rule I deduced from the American time zones is wrong. But so is the one I set up from the military ones. I recognized it on the next morning and sent a second message to correct the mistake. For reasons which would take me to long to explain, my second mail overtook the first and you should have received the correction before the original. Military time zones ------------------- What started me wondering when reading RFC822 was the fact that I recalled that CET = A (we have national service in Germany). To make sure, I asked a friend who is a communications officer in the army and he confirmed it. This is, of course, based on the assumption that "military time zones" according to RFC822 are identical with those used by NATO. But I think that this can be taken for granted. Your examples ------------- You say in your examples that "offset" for EST is -0500 and for PST -0800 (you wrote PDT), and then go on to deduce rules from your definition of "offset". But that misses answering my question, which could be phrased as: What is for EST according to RFC822? -0500 or +0500? In other words: which of the following is identical with "10:00 EST": "10:00 -0500" or "10:00 +0500" ? Martin P.S.: We don't call it "daylight savings time" in Europe, but "summer time". So it's CEST and not CDT, which is quite as well, because it prevents confusion with the American CDT zone.  Received: from OFFICE-1.ARPA (TCP 3201400200) by MC.LCS.MIT.EDU 27 Jan 88 10:12:28 EST Date: 27 Jan 88 10:05 EST From: Bill Barns Subject: Re: Interpretation of local time offset () in RFC822 To: Martin Lottermoser Cc: HEADER-PEOPLE@MC.LCS.MIT.EDU Message-ID: Others should be able to respond more authoritatively than I can, but from what you say, it sounds as if they are not doing so. I can make two relevant comments: 1. There was a discussion on the net several years ago, probably on this list, in which the question of military time zones in RFC 822 was mentioned. As I recall it, there seemed to be agreement that section 5 of RFC 822 says the opposite of what it was intended to say. In other words, CET is A as you said, and RFC 822 is not to be believed on this subject. 2. I do not have a copy of the ANSI standard to refer to, but I can tell you that every piece of software I have seen that tried to express 10:00 EST in the offset format produced the output 10:00 -0500. Bill Barns  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 29 Jan 88 19:56:52 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Fri, 29 Jan 88 19:55:33 EST Received: from STANFORD.BITNET (GA.JRG) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8624; Fri, 29 Jan 88 19:55:28 EST Date: Fri, 29 Jan 88 16:53:03 PST To: From: "June Genis" Subject: revising RFC822: heresy or possibility? Dear Header-People, The BITNET list LSTSRV-L has recently been discussing the creation of some new optional tags as a potential solution to looping problems in the LISTSERV system. Initially it was proposed that these be added as registered new optional tags as per RFC822 already allows for. It strikes me, however, that as long as conforming mailers are only required not to barf upon seeing these new headers, rather than being required to process then as defined, leaves us with a rather large hole that can not be truly plugged unless RFC 822 itself is modified (or supplanted by another RFC -- I don't really understand the procedures for this sort of thing). As concisely as I can state the problem RFC822 just doesn't allow for the degree of automation that BITNET people want to build into their systems. While 822 clearly states that the Sender: header should be used to route notification of any routing problems, it provides no alternative place to identify the sending agent when that agent is someone different that the party (human or automated) who should be notified about problems. Clearly the single Sender: header ought to be split into two separate headers. Now for the hard part, is there any reasonably friendly way to effect such a transition? Examined linguistically it would appear much better to redefine Sender: as only being the sending agent while inventing a new tag (several such as Errors-to: or Rejections-to: have been suggested) for the notification function. Unfortunately, there is already a lot of software out there designed to treat Sender: as we would like the new tag to be treated. Is it at all likely that (1) we will ever get agreement on such a change in view of the programming effort it would engender, (2) if agreement is reached (however that is determined) are we really likely to see most affected software corrected and (3) if so, what sort of mess are we likely to have during transition? My own feeling is that although I would like to see Sender: retained with a new meaning, any transition allowing it would be very messy. If two new headers (Sending-Agent: and Errors-to: perhaps?) then people wishing to follow the new rules could look for the new tags and if missing fall back on the old rules on the assumption that it was dealing with a transmission from a non-upgraded mailing agent. Other people seem to feel that a revised receiver need only look for the presence of the new (Errors-to:) header to decide if it should use the revised rules. I fear that still leaves too much room for ambiguity. Has this issue been discussed previously on this list? If so, can someone succinctly summarize the discussion do far? (BTW, please copy me directly on this right now as I've only just sent in my request to be added to HEADER-PEOPLE.) /June To: HEADER-PEOPLE@MC.LCS.MIT.EDU cc: LSTSRV-L(LSTSRV-L@POLYGRAF)  Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 30 Jan 88 01:28:20 EST Date: Fri, 29 Jan 1988 23:27 MST Message-ID: From: "Frank J. Wancho" To: June Genis Cc: , WANCHO@SIMTEL20.ARPA Subject: revising RFC822: heresy or possibility? In-reply-to: Msg of 29 Jan 1988 17:53-MST from June Genis June, The real problem on BITNET is that RFC 821 is not fully implemented. Specifically, it does not retain the envelope information such as the MAIL FROM info, which was designed exactly for this application. If that information was retained and properly used, there would be no need for any special-purpose header types and no requirement for any mail agents to be taught to parse headers. Please obtain a copy of RFC 821 and read it before replying. --Frank  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 30 Jan 88 12:45:41 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 30 Jan 88 12:45:10 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Sat, 30 Jan 88 12:43:40 EST Received: from SEARN.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0764; Sat, 30 Jan 88 12:43:17 EST Received: from QZCOM by SEARN.BITNET (Mailer X1.24) with BSMTP id 5242; Sat, 30 Jan 88 18:29:20 EDT Message-ID: <304510@QZCOM> Date: 30 Jan 88 09:44 +0100 From: "Jacob Palme QZ" Reply-To: "Jacob Palme QZ" To: "ARPA Internet Mail Interest List" , "BITNIC MAIL-L List" Subject: Receiving too much mail Many people have the problem of not having time to read all the mail they receive from various mailing lists. One way of alleviating this problem is to include the concept of *conversation* in the local mail software. By a conversation is meant a set of messages replated by In-reply-to-links. A user who does not want to read any more messages within one conversation, can give a command to this effect, and his local mail software will then skip those messages. I hope that more and more mail delivery software will have such facilities. We already have it to some extent in our COM system, and will give more support for this in the new SuperCOM system we are currently developing. The problem, however, is that this only works if all messages have Message-ID fields, and if replies use the In-reply-to field to refer to hte Message-ID of the replied-to message. I would therefore urge those of you who are developing mail software to at least include such handling of Message-ID and In-reply-to fields in your mail software.  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 30 Jan 88 14:14:42 EST Received: from IU.AI.SRI.COM (TCP 1201200002) by AI.AI.MIT.EDU 30 Jan 88 14:14:38 EST Date: Sat 30 Jan 88 11:14:09-PST From: Peter Karp Subject: Error messages To: header-people@AI.AI.MIT.EDU Cc: PKARP@IU.AI.SRI.COM Message-ID: <570568449.0.PKARP@IU.AI.SRI.COM> Mail-System-Version: As long as we're all airing out pet peeves on internet mail, here's mine. In general I've observed that the error messages most mailers generate are very confusing to users. They are confusing in that after reading error messages, users often still have little clue as to exactly why their mail failed, and thus of how to generate a new address that is likely to succeed. Here's an example. Imagine that fred@host1 sends mail to joe%host2@host3.arpa . It happens that "host3.arpa" has never heard of "host2", thus host3.arpa returns an error reply to the RCPT TO command given to it in its SMTP conversation with host1. Fred receives a rejection message from the mailer at "host1". This message says something like: joe%host2@host3.arpa: 550 unknown host Now, mail wizards that we are, we can all figure out that since this message was generated by the mailer at "host1" and contains an SMTP error code, the problem is in fact that "host3.arpa" never heard of "host2". However, Fred has no clue what's going on. He doesn't know from SMTP connections. He may not be able to figure out which host name is unknown here, and he probably doesn't know what host actually rejected the address. Thus, he forwards the error message to a mail wizard for explanation, which wastes everyone's time. These problems become much, much more tricky when much longer message routes are involved; it's very hard to figure out which host generated an error message and exactly what address it was given that caused it to barf. My suggestion is that Fred should see something that looks like: 550 HOST3.ARPA rejects address "joe%host2@host3.arpa": unknown host "host2" This has the advantages that: a) The host that rejects the address has clearly identified itself b) It tells us what address it was handed that caused it to barf c) It tells us what part of that address was problematic, and why The error messages in my VMS Pony Express mailer are of this form. I suggest that other mailer maintainers modify their error messages in this way. Peter -------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 30 Jan 88 18:37:48 EST Date: Sat, 30 Jan 1988 18:33 EST Message-ID: From: Rob Austein To: "June Genis" Cc: Header-People@MC.LCS.MIT.EDU Subject: revising RFC822: heresy or possibility? In-reply-to: Msg of 29 Jan 1988 19:53-EST from "June Genis" This is a follow-up on Frank Wancho's reply. RFC821 is the description of SMTP, a second-generation mail protocol; SMTP was designed with the shortcomings of a previous generation of mail protocols in mind. RFC822 (sic) traces its ancestory back to the earliest days of ARPANET electronic mail standards, via a series of revisions (RFCs 822, 733, 724, 680, and 561, for the curious). RFC822, by itself, is still a first-generation protocol, albeit one with provisions for encapsulation in a second-generation protocol (SMTP). Many BITNET sites have been using a modified version of SMTP called BSMTP (Batch Simple Mail Transfer Protocol) for several years with great success. The big stumbling block has been that not everybody on the BITNET implements BSMTP. Sometime in the last year or so, BSMTP was formally adopted as the official BITNET mail protocol. Unfortunately, the BITNET being the loose confederation that it is, there are STILL sites that don't use BSMTP, whether from ignorance, intransigence, or inability due to lack of vendor support. So the reason you are seeing these problems is that the BITNET community has not completely implemented the protocols that have already been designed and mandated to handle the problems. With no slight intended, the last thing the BITNET needs at this point is a change to the mail protocols, particularly if the experience with BSMTP is any guide to how such changes will be implemented. If you have some energy to invest in making BITNET mail work better, you would be better off using it to track down non-BSMTP sites and do what you can to help them to support BSMTP. I don't know how to post to LSTSRV-L, but if somebody wants to repost this message there it's ok with me. Please, no flames from people who haven't read both RFC821 and RFC822. Corrections to factual errors solicited. --Rob  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 12 Feb 88 13:16:33 EST Date: Fri, 12 Feb 1988 13:10 EST Message-ID: From: Rob Austein To: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) cc: TCP-IP@SRI-NIC.ARPA, Header-People@MC.LCS.MIT.EDU, mkg%psuvm.bitnet@CUNYVM.CUNY.EDU Subject: A plea for sanity In-reply-to: Msg of 11 Feb 1988 20:13-EST from mcc@etn-wlv.eaton.com (Merton Campbell Crockett) Date: Thursday, 11 February 1988 20:13-EST From: mcc@etn-wlv.eaton.com (Merton Campbell Crockett) [...] Perhaps its a problem with my view of electronic mail, particularly mail that is for forwarded to "tcp-ip@sri-nic.arpa"; it is irrelevant to me whether a subscriber to this service from "bangland" failed to leave his PC powered-up to receive my comment or retort of questionable significance. Why should I be inundated with "unable to deliver to xxx" messages? Its "tcp-ip" that needs the knowledge as it may signify some network problem! It does raise some questions about SMTP and its interpretation of "From:" and "Forwarded by:". The reporting of delivery errors should always be delivered to the "Forwarded by:" individual not the "From:" individual who may not have authorized the dissemination of the message. Merton, First off, TCP-IP is not really the place for this discussion (I know, you didn't start it either). If people want to continue it, please do so in private or on Header-People@MC.LCS.MIT.EDU, the list for discussion of mail protocols and lossage in the implementation of those protocols. Second, you should know that the SRI-NIC.ARPA mailer does everything in its power to keep you from ever seeing those bounce messages: specificly, it bashes the SMTP return-path of outgoing TCP-IP messages to "TCP-IP-RELAY@SRI-NIC.ARPA". Thus, anybody playing the game correctly will send any and all automatic delivery flames to the list maintainers at SRI-NIC, not to you (see RFC821 if this isn't clear). The problem is that there are an awful lot of broken mailers out there. Chief offender in recent months has been one or more BITNET mailers that discard the envelope ((B)SMTP) information and rewrite the RFC822 message headers (which they then use for mail routing) in completely bizzare ways. This is worse than just throwing all the mail on the floor, these mailers are very "smart" at figuring out who the original sender of a message was so that they can torment her with useless bug reports. It has gotten to the point where posting a dozen messages to one of the mailing lists I maintain produces over a megabyte of mis-addressed garbage; I've started getting complaints from subscribers because their (de)subscription requests are getting lost under all this junk and thus being accidently ignored. So, in closing (and as I've said on Header-People before), the problem is not deficiencies in the existing mail protocols. The problem is mailers that don't implement the existing protocols and system administrators who are unwilling/unable to install versions of the mailers that DO implement the protocols correctly. The main reason I keep bringing this up in various forums is a hope that part of the problem is ignorance on the part of the maintainers of the machines running the broken mailers. --Rob  Received: from uc.msc.umn.edu (TCP 1200400136) by MC.LCS.MIT.EDU 13 Feb 88 14:06:23 EST Received: by uc.msc.umn.edu (5.54/1.14) id AA02022; Sat, 13 Feb 88 13:05:20 CST Date: Sat, 13 Feb 88 13:05:20 CST From: "Stuart Levy" Message-Id: <8802131905.AA02022@uc.msc.umn.edu> To: SRA@xx.lcs.mit.edu, mcc@etn-wlv.eaton.com Subject: Re: A plea for sanity Cc: Header-People@mc.lcs.mit.edu, TCP-IP@sri-nic.arpa, mkg%psuvm.bitnet@cunyvm.cuny.edu (In reply to Rob Austein's message ) I don't think it's fair to call a mailer "broken" because it retains the address of the original sender for reply purposes. If mailing-list redistributions eradicated the original From: line, replacing the original sender's address with that of the redistributor, their mailing lists would be far less useful. Ditto if our mailers replied according to the SMTP envelope rather than the body of the message. Note that the envelope's format is not specified by RFC 822, only the message header is -- and messages can be delivered by other means besides SMTP. Though RFC 822 doesn't define it, I've seen some mailing lists distribute messages with an Errors-To: line. This seems to be just what's needed to separate message replies from delivery error replies. Sendmail seems to support "Errors-To"; how many other mailers do? Stuart Levy, Minn. Supercomputer Center  Received: from SUMEX-AIM.Stanford.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 13 Feb 88 16:18:53 EST Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Sat, 13 Feb 88 13:13:56 PST Date: Sat, 13 Feb 88 12:20:05 PST From: Mark Crispin Subject: Re: A plea for sanity To: slevy@uc.msc.umn.edu cc: SRA@xx.lcs.mit.edu, mcc@etn-wlv.eaton.com, Header-People@mc.lcs.mit.edu, TCP-IP@sri-nic.arpa, mkg%psuvm.bitnet@cunyvm.cuny.edu In-Reply-To: <8802131905.AA02022@uc.msc.umn.edu> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12374467486.7.MRC@PANDA.PANDA.COM> Stuart - You completely misunderstand the issue. SMTP (RFC 821) defines an address that mailer error reports (as distinguished from replies) are sent to. The BITNET mailers in question are using the reply address, ignoring the errors address, to send errors reports to. The BITNET mailers which do this are broken. Errors-To: is completely unnecessary if SMTP is correctly implemented. If you are using a non-SMTP transport, it should possess this functionality OR it should do whatever equivalent exists in that transport to pass on that address. -- Mark -- PS: I am the implementor of one of the major electronic mail packages in use on the Internet, and have been for 9 years. I know what I'm talking about. -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by MC.LCS.MIT.EDU 13 Feb 88 17:58:48 EST Received: from CCRMA-F4 by SAIL.Stanford.EDU with PUP; 13-Feb-88 14:57 PST Date: 13 Feb 88 1455 PST From: Tovar Subject: re: A plea for sanity (Errors-to:) To: Header-People@MC.LCS.MIT.EDU Errors-To: is completely unnecessary if SMTP is correctly implemented. I will disagree strongly on this point. Having seen any number of complaints about mail not going through from some individuals, i can definitely see the utility of such a field and have been tempted on at least one occasion to put a hack into our mailer to insert this sort of thing under certain circumstances. (I bet MRC might even know what/who i'm talking about). At least some naive users might be better off having errors go to someone who knows about such things (rather than just being deleted, which is what happens all too often). Where Errors-To: would be most useful is where a message leaves the SMTP world. ... useless bug reports. It has gotten to the point where posting a dozen messages to one of the mailing lists I maintain produces over a megabyte of mis-addressed garbage; I've started getting complaints from subscribers because their (de)subscription requests are getting lost under all this junk and thus being accidently ignored. I think SRA is right. There is a problem here and the wider netmail goes, the worse it's going to get until this get addresses. (Now, as i send this, i fully expect to get numerous pages of useless crud dumped into my already grossly overbloated mail file!) -- Tovar  Received: from ucbarpa.Berkeley.EDU (TCP 1200000116) by MC.LCS.MIT.EDU 13 Feb 88 21:19:48 EST Received: by ucbarpa.Berkeley.EDU (5.58/1.26) id AA28897; Sat, 13 Feb 88 18:19:46 PST Date: Sat, 13 Feb 88 18:19:46 PST From: jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) Message-Id: <8802140219.AA28897@ucbarpa.Berkeley.EDU> To: Header-People@mc.lcs.mit.edu Subject: some mailers exhibit the following behavior if (sending_host has a net-10 interface && receiving_host has a net-10 interface) use that address; even if receiving_host has more than one address. then, later in the program, we see if (can't connect to receiving_host) ignore other addresses; some mailers that do such things, *might* be running on tops-20 machines. they should be fixed. /jordan  Received: from SUMEX-AIM.Stanford.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 13 Feb 88 22:37:39 EST Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Sat, 13 Feb 88 19:35:02 PST Date: Sat, 13 Feb 88 19:22:07 PST From: Mark Crispin Subject: Re: some mailers exhibit the following behavior To: jordan@ucbarpa.Berkeley.EDU cc: Header-People@mc.lcs.mit.edu In-Reply-To: <8802140219.AA28897@ucbarpa.Berkeley.EDU> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12374544314.7.MRC@PANDA.PANDA.COM> Jordan Hayes - The algorithm you gave describes no mailer that I am aware of. What mailer that you know of has any special knowledge of net 10? -- Mark -- -------  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 14 Feb 88 15:50:59 EST Date: Sun, 14 Feb 1988 15:46 EST Message-ID: From: Rob Austein To: Mark Crispin , jordan@UCBARPA.BERKELEY.EDU Cc: Header-People@MC.LCS.MIT.EDU Subject: some mailers exhibit the following behavior Well, while Jordan's algorithm probably doesn't exactly describe any known mailer, it certainly describes a common scenario, where a mailer (TOPS-20 or otherwise) picks the "best address" of the host it wants to talk to and gives up on that host if the "best address" doesn't answer. This is obviously not entirely satisfactory, but the alternative is generally accepted as being worse; trying multiple addresses means that the mailer has wait for connection more than once before deciding to give up on a host that is probably down. For the record, some of the algorithms currently used in ITS COMSAT for delivering mail to hosts on the MIT Chaosnet require this kind of multiple wait; I can assure anyone who doubted it in the first place that this does horrible things to mailer performance. The problem is primarily one of tuning the mailer to the application. A mailer running on a personal workstation might well want to try all the addresses of a destination before giving up, while a mailer daemon running on a machine that is used primarily for relay/redistribution (ie, massive amounts of mail neither originated nor destined for the local machine) might well want to do what most mailers do now and give up on a host after the first connection failure. There is no single right answer, it depends on the mailer's owner's priorities. We (MIT-LCS) have found the distinction between endpoint and relay mailers clarifies some of the issues involved in configuring a workstation/server environment; perhaps mailsystem designers should also give some thought to the distinction and its implications. --Rob  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 14 Feb 88 19:21:25 EST Received: from Cabernet.ms by ArpaGateway.ms ; 14 FEB 88 16:18:55 PST Date: Sun, 14 Feb 88 16:18:38 PST From: JLarson.pa@Xerox.COM Subject: Xerox experience with broken mailer behaviour To: Header-People@MC.LCS.MIT.EDU, TCP-IP@SRI-NIC.ARPA Cc: SRA@XX.LCS.MIT.EDU, JLarson.pa@Xerox.COM Reply-To: JLarson.pa@Xerox.COM Message-ID: <880214-161856-1555@Xerox> We at Xerox were badly burned recently by sites which; 1) Do not use the domain name system to look up IP addresses 2) Pick the "best" address (usually net 10) from the host table, and never try any other address in the list. Our story should explain why I now consider 2) to be severely broken mailer behaviour. We installed an IP gateway at our PSN where the Xerox.Com mail gateway used to be, so the address for Xerox.Com changed from a net 10 address to a net 13 subnet address. The Xerox.Com domain name servers had the correct information, so those sites properly using the domain name system did not have a problem. But our update to the host table (to remove the net 10 address from Xerox.Com) got stalled in DDN red tape for several weeks (even though that same net net 10 address was already in the host table in the GATEWAY entry!). So, although we were allowed to place the correct net 13 subnet address as the first address in the host table, the bogus net 10 address (now the IP gateway) could not be removed from the host table for those several weeks. You guessed it; those mailers in 2) picking the "best" address from the host table were picking a BOGUS address, mail failed to go through for several weeks from these sites, and the result was irate many mail users and flurries of mail between postmasters. Note that the equivalent problem would have resulted if that net 10 interface went down for an extended period, and there were an alternate route to our net 13 subnet. (Yes folks, network interfaces do go down, sometimes even for extended periods.) There is little excuse for this broken mailer behaviour since it should be easy to fix, even for mailers which are very heavily loaded. The solution is quite simple; using that "best" address is fine for the FIRST attempt, but on later retries the BEST address to use is a DIFFERENT address in the address list. Simply rotate the previously used address to the end of the list, and use the next address in the address list on the next retry attempt. Note that you need only try one address each attempt, so there is no detrimental impact on a busy mailer. (The Xerox.com mailer implementation in fact knows how busy it is and adjusts timeout values and multiple address attempts accordingly to keep keep sick sites from affecting throughput when busy. When not busy, it tries all the addresses, and uses longer timeout values.) Hopefully this message will prompt certain mail implementers to fix their broken mailers, and prompt sites to start using the domain name system so others can avoid our painful transition experience. Cheers, John Larson Xerox PARC  Received: from SUMEX-AIM.Stanford.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 14 Feb 88 21:52:03 EST Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Sun, 14 Feb 88 18:45:21 PST Date: Sun, 14 Feb 88 18:18:09 PST From: Mark Crispin Subject: trying multiple addresses To: Header-People@MC.LCS.MIT.EDU cc: TCP-IP@SRI-NIC.ARPA Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12374794814.7.MRC@PANDA.PANDA.COM> I am sure the advocates of trying multiple mail addresses would feel quite differently if they had to pay per-packet charges for network access. Historically, only a small percentage of network connection failures -- typically less than 1% -- have been due to a dysfunctional IP address. The remaining (= overwhelming majority of) failures have been due to dysfunctional networks, dysfunctional hosts, or dysfunctional servers. It is possible that trying a different IP address may help in the dysfunctional network case, although typically the "non-best" IP addresses all involve the dysfunctional network in some way (look at some network topology maps some time). This is a relatively rare case anyway. Many times, the "non-best" IP address is substantially inferior to the point where it should not be used under ANY circumstance. No site outside of Stanford should *ever* use SAIL's, Score's, or SUMEX-AIM's net 36 IP address; the gateway between net 10 and net 36 (as well as the net 36 subnet from that gateway) is seriously overloaded. If I understand JLarson.pa correctly, he's saying that Xerox.COM will use SUMEX-AIM's net 36 address just because they couldn't connect to the net 10 address the last time. If this is common behavior it's no wonder those of us who must use the net 10/36 gateway find it so unusable. Will I have to instruct the servers on multi-homed net 10/36 hosts to refuse connections on net 36 from non-net 36 hosts to get them to stop? What about those guys multi-homed on a "free" and a pay-per-packet X.25 net? Do they appreciate this behavior? The *correct* solution to this problem is NOT kludgy algorithms in the mailer. The correct solution is multi-part, and involves: 1) complete the migration from the host table to the domain system. The NIC simply cannot keep up with the changes in network topology (as the Xerox experience showed), and, frankly, it's unreasonable for us to expect them to. 2) domain database managers need to keep their name servers updated with changes to network topology. TTL's should not be allowed to be so long that topology changes go unnoticed by resolvers for excessive periods of time. 3) better support needs to exist in the domain infrastructure for "best" IP address selection. This last point is important. Presently, it is up to the local host to decide upon a "best" IP address, based on quite incomplete information. Many hosts (all Unix hosts?) simply pick the first IP address listed in the NIC host table (or returned as A RR's from the domain system). TOPS-20 selects in priority order: (1) first IP address from a directly connected net that is "preferred" (e.g. a fast LAN), (2) first IP address from a directly connected net that is "default" (e.g. a core net such as ARPANET), (3) first IP address from any other directly connected net, (4) first IP address. "First IP address" means first from the address list from the host table (or a set of A RR's from the domain system). Note that there is nothing whatsoever to do with "net 10". Almost 100% of the time, this makes the best possible choice of an IP address. It's only in those very few cases (which come up perhaps 2 or 3 times a YEAR!!!) where an otherwise highly desirable path breaks for a long period of time that a problem comes up. I consider it highly objectionable to cycle through every other IP address (waiting a minute or more for an IP retransmission timeout if the network is courteous enough to tell me the other guy ain't there) every time I attempt to connect to a dead host. JLarson's suggestion is less objectionable, but it involves one piece of software (the mailer) telling a completely different piece of software (host table or domain resolver) that the IP address given it was sick. Nobody wants to do the work to the host table software to add such a feature. It might be doable with the domain resolver (SRA can comment on this); it certainly wouldn't be hard for the mailer to pass on the word to the domain resolver. The problem is, what does "this IP address was sick" really mean? How does "retransmission timeout" differ from "host dead" (a type 7 1822 message) differ from "host sent a reset" (refused the connection) differ from any of the other ways a connection failed? In which one(s) of these do you say try another IP address, and in which one(s) do you assume the host is really down, or really doesn't want to talk now? Again, what do you do about those cases when we really shouldn't be using a particular IP address because of charging, or other administrative issues? The domain system may be able to help; it was always my belief (I remember suggesting this at the meeting when the domain system concept was first invented) that nameservers should be allowed to tailor their responses based on who was asking the question. A domain query should be something like: "I am on net 128.43 seeking an SMTP server for FOO.BAR.COM, which is the best address for me to use?" and later on "I am on net 128.43 seeking an SMTP server for FOO.BAR.COM and I already tried 69.105.8.3, is there any other I should try?" The point is that a perfectly valid answer may be "if 69.105.8.3 ain't answering, he ain't up; try again later." This also gives the remote organization (which presumably knows the status of their hosts) control over the IP address selection criteria, based upon their knowledge instead of the local host's educated guesswork. Please, no flames. If you're going to babble on and on about how I should break my mailer to conform to your fantasy of how the world should work, send it to *NUL: or /dev/null or whatever you call it. Furthermore, I'm not interested in any comments about a host table based means of IP address selection. The systems I support do not use host tables (and, for the record, are currently the only TOPS-20's supporting MX mailing). I can't help but feel that if the problem of a sick "best" IP address happens to a domain-based mailer, that the fault is that of the management of the nameserver for that organization and not that of the mailer. If you have constructive observations, then let's talk. Remember that this is not about porting arguably "better" (or "worse") ideas from a 16-year-old operating system to a 19-year-old operating system. This is about what's going to be done in the next generation, that maybe will be ported to the 16 and 19 year-olds. I think we can do better than any of the guesswork, and we should, if the threats of pay-per-packet come to pass. -- Mark -- -------  Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 14 Feb 88 22:36:46 EST Date: Sun, 14 Feb 1988 20:35 MST Message-ID: From: "Frank J. Wancho" To: Header-People@MC.LCS.MIT.EDU, TCP-IP@SRI-NIC.ARPA Cc: WANCHO@SIMTEL20.ARPA Subject: trying multiple addresses In-reply-to: Msg of 14 Feb 1988 19:18-MST from Mark Crispin For those who may be unaware, Mark's pay-per-packet comments *will* apply to all MILNET hosts for outgoing traffic and TAC access sometime in FY 89, unless the plans have been rescinded by some miracle. And, from what I've seen of the algorithm DCA intends to impose on us, it ain't cheap! When that happens, those sites, such as this one, which support large mailing lists and anonymous ftp service may be forced to withdraw those services... (or move to ARPANET where flat fees will continue - no :). --Frank  Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 15 Feb 88 18:28:37 EST Date: Mon 15 Feb 88 17:27:07-CST From: Clive Dawson Subject: Re: trying multiple addresses To: mrc@SUMEX-AIM.STANFORD.EDU cc: Header-People@MC.LCS.MIT.EDU, TCP-IP@SRI-NIC.ARPA In-Reply-To: <12374794814.7.MRC@PANDA.PANDA.COM> Message-ID: <12375025822.40.AI.CLIVE@MCC.COM> Re: Date: Sun, 14 Feb 88 18:18:09 PST From: Mark Crispin Subject: trying multiple addresses Mark-- Your message implies that trying an alternate IP address after the best one has failed will only win 1% of the time. I disagree. As somebody who still has the job of dealing with the day-to-day hassles of "keeping the mail flowing", I cannot afford to sit back and consider what the "correct solution" will ultimately be once the whole world arrives at some standard. I will gladly accept any "kludgy algorithms" that get the job done with no adverse effects. Not counting the host-table-related problems (I know, you don't want to hear this!) such as SU's Sierra, whose 10 address still appears over a year after it died, or the more recent HI-MULTICS/CIM-VAX address problem at Honeywell, where both addresses work, but SMTP listens only on one, I have also had to deal with a multitude of other problems in just the last week which were all solved by using non-"best" IP addresses. The following scenario comes up A LOT, at least at this site: Q: Why isn't my mail getting through to host X? A: The host must be down. Q: Then why can I Telnet to it? A: Ah, your workstation is not directly connected to net 10, and is so "dumb" that it doesn't realize that net 10 is the only way out of this place anyway, so it chooses to use host X's 128 address. Meanwhile, our "smart" mail relay host (and gateway) is directly connected to net 10 and therefore insists on sticking to host X's 10 address regardless. How am I supposed to tell users that "correct failure" is better than "kludgy success"? They could care less about these details, and rightfully so. If I understand JLarson.pa correctly, he's saying that Xerox.COM will use SUMEX-AIM's net 36 address just because they couldn't connect to the net 10 address the last time. If this is common behavior it's no wonder those of us who must use the net 10/36 gateway find it so unusable. Will I have to instruct the servers on multi-homed net 10/36 hosts to refuse connections on net 36 from non-net 36 hosts to get them to stop? Mark, that's not how I understood JLarson at all. He said that this procedure was followed on RETRIES, and then ONLY at the next retry interval. This is quite different from adopting the alternative IP address "permanently" thereafter for all deliveries. It seems to me that this procedure is almost a complete win. There is no extra load on the sending mailer, and non-"best" IP addresses are used only when they have to be, on a message-by-message basis. It might possibly be improved by a heuristic which says that if, on the first retry, the second address is found to be down too, then 4 out of every 5 (say) future retries should go back to using the "best" IP address. This way, if SCORE is really down, the poor 10/36 gateway won't get so much of a pounding with doomed connection attempts from everybody. Cheers, Clive -------  Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 15 Feb 88 19:28:53 EST Date: Mon, 15 Feb 1988 17:27 MST Message-ID: From: "Frank J. Wancho" To: Header-People@MC.LCS.MIT.EDU, TCP-IP@SRI-NIC.ARPA Cc: "Frank J. Wancho" Subject: Correction on MILNET packet charges In-reply-to: Msg of 14 Feb 1988 20:35-MST from Frank J. Wancho The scheduled implementation for charge-back to directly connected MILNET hosts is FY90, not FY89. Sorry for the confusion. --Frank  Received: from SUMEX-AIM.Stanford.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 16 Feb 88 01:50:04 EST Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Mon, 15 Feb 88 22:45:18 PST Date: Mon, 15 Feb 88 22:41:10 PST From: Mark Crispin Subject: Re: trying multiple addresses To: AI.CLIVE@MCC.COM cc: Header-People@MC.LCS.MIT.EDU, TCP-IP@SRI-NIC.ARPA In-Reply-To: <12375025822.40.AI.CLIVE@MCC.COM> Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12375104837.7.MRC@PANDA.PANDA.COM> Clive - The NIC host table is a disaster, and the only way to fix the many problems associated with it is to abandon it for domains. Supported TOPS-20 domain and mail software was announced a while ago; perhaps you should consider adopting it at your site. [As a side note, the problem with Sierra's net 10 address being in the host table will go away very soon since the plug is being pulled on Sierra.] Trying every possible IP address for a host which fails to respond on its "primary" IP address is a recipe for performance disaster for any background mailer with a large workload. We're talking about thousands of messages/day, friends, not a piddly couple of hundred. Furthermore, we all can rattle off the cases where the primary IP address was wrong. We can do this because there have been so few of them! What's more, most of those few are host-table only problems. If you run obsolete software, you should expect to have to put in some maintenance on your own. -- Mark -- -------  Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 16 Feb 88 08:36:03 EST Date: Tue 16 Feb 88 07:34:17-CST From: Clive Dawson Subject: Re: trying multiple addresses To: mrc@SUMEX-AIM.STANFORD.EDU cc: Header-People@MC.LCS.MIT.EDU, TCP-IP@SRI-NIC.ARPA In-Reply-To: <12375104837.7.MRC@PANDA.PANDA.COM> Message-ID: <12375180045.70.AI.CLIVE@MCC.COM> Trying every possible IP address for a host which fails to respond on its "primary" IP address is a recipe for performance disaster for any background mailer with a large workload. We're talking about thousands of messages/day, friends, not a piddly couple of hundred. Yes, Mark, I know what large workloads are. Considering that a) this discussion deals with multi-homed hosts which comprise only about 5% of the total host population, and b) the success rate for first delivery attempts exceeds 95%, and c) once a message is in the retry queue the average number of retries is greater than 1, I would appreciate it if you would elaborate on just how this "performance disaster" you predict will come about, especially for sites using the algorithm we've discussed in the last few messages. I'm glad to see you acknowledge that only "most" of these problems are host-table related. OK, let's eliminate these from consideration. What do you propose that we do about the rest of the problems which are not host-table related? You seem to be resigned to the idea that they should just be ignored because there are so few of them. If this is true, then a solution which only affects THESE FEW can hardly cause a performance disaster. Clive -------  Received: from NNSC.NSF.NET (TCP 20026200662) by MC.LCS.MIT.EDU 16 Feb 88 11:37:35 EST To: mrc@panda.panda.com cc: header-people@mc.lcs.mit.edu Subject: Trying multiple addresses Date: Tue, 16 Feb 88 11:19:48 -0500 From: Craig Partridge Mark, The two classic cases I see which justify our use of trying multiple IP addresses is: - network interfaces which fail. So the host is up but the interface is down and people cannot or do not want to remove the old interface address from the domain system during its two or three day repair period. - transient network routing problems which people are having trouble tracking. So one address works sometimes and the other all the time. Craig  Received: from venera.isi.edu (TCP 1200200064) by MC.LCS.MIT.EDU 16 Feb 88 13:51:16 EST Received: from braden.isi.edu by venera.isi.edu (5.54/5.51) id AA15763; Tue, 16 Feb 88 10:50:18 PST Date: Tue, 16 Feb 88 10:50:11 PST From: braden@venera.isi.edu Posted-Date: Tue, 16 Feb 88 10:50:11 PST Message-Id: <8802161850.AA00307@braden.isi.edu> Received: by braden.isi.edu (5.54/5.51) id AA00307; Tue, 16 Feb 88 10:50:11 PST To: Header-People@mc.lcs.mit.edu, MRC@panda.panda.com Subject: Re: trying multiple addresses Cc: TCP-IP@sri-nic.arpa Egad! I thought this question was settled about 4 years ago! And the answer was... JLarson is entirely right, and Mark Crispin is confusing a settled issue. Bob Braden  Received: from SUMEX-AIM.Stanford.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 16 Feb 88 14:08:36 EST Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Tue, 16 Feb 88 11:03:24 PST Date: Tue, 16 Feb 88 10:31:55 PST From: Mark Crispin Subject: Re: Trying multiple addresses To: craig@NNSC.NSF.NET cc: header-people@mc.lcs.mit.edu In-Reply-To: Message from "Craig Partridge " of Tue, 16 Feb 88 08:55:39 PST Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12375234225.7.MRC@PANDA.PANDA.COM> Craig - I have never said that trying multiple IP addresses must not be done. What I did say is that such a strategy is neither required nor is it necessarily advisable. This entire discussion got started because Jordan Hayes declared that a mailer which does not try multiple IP addresses is "broken" in the sense that a mailer which tosses out the RFC821 return path information is broken. Now, nobody is going to think about fixing the BITNET mailers which lose the RFC821 return path, and those BITNET guys are going to continue to insist we should add this ridiculous "Errors-to:" header line in all our mailers to work around a deficiency in their mailer. Thank you, Jordan, for your contribution towards making electronic mail work better. -- Mark -- -------  Received: from ucbarpa.Berkeley.EDU (TCP 1200000116) by MC.LCS.MIT.EDU 16 Feb 88 16:09:50 EST Received: by ucbarpa.Berkeley.EDU (5.58/1.26) id AA29337; Tue, 16 Feb 88 11:44:00 PST Date: Tue, 16 Feb 88 11:44:00 PST From: jordan@ucbarpa.Berkeley.EDU (Jordan Hayes) Message-Id: <8802161944.AA29337@ucbarpa.Berkeley.EDU> To: Header-People@mc.lcs.mit.edu, TCP-IP@sri-nic.arpa Subject: Re: trying multiple addresses Mark talks all about "host table this" and "obsolete software this" but the problem that I had (and I think J Larson had) was that, due to NIC paperwork (i.e., changing *anything* about a host/gateway that requires an NCD), there are things that will hose you for sure. I couldn't get the host table *or the domain database* changed, so places like sushi.stanford.edu, mcc.com, a.isi.edu (a *root domain server*!!!) bounced mail headed our way for 5 weeks. I'm running all the correct software, i'm hip to the "now it's your namespace, now you have control over it" thang, but I think it's a bit naive to say that "Ah well, 1% of the time, you'll lose" ... Summary: Mark, i'd appreciate it if you'd try a bit harder not to bounce my mail. Thanks. /jordan  Received: from SUMEX-AIM.Stanford.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 16 Feb 88 16:30:48 EST Received: from PANDA.PANDA.COM by SUMEX-AIM.Stanford.EDU with Cafard; Tue, 16 Feb 88 12:09:34 PST Date: Tue, 16 Feb 88 11:59:08 PST From: Mark Crispin Subject: Braden on secondary IP addresses To: TCP-IP@SRI-NIC.ARPA, Header-People@MC.LCS.MIT.EDU Postal-Address: 1802 Hackett Ave.; Mountain View, CA 94043-4431 Phone: +1 (415) 968-1052 Message-ID: <12375250105.7.MRC@PANDA.PANDA.COM> I've been in the NWG for at least 12 years, and I remember no pronouncement that implementations *must* try all possible IP addresses. I can think of just as many cases where it is undesirable as I can of ones where it is desirable. Let's set the record straight on one thing. The mailer in question has no knowledge whatsoever of how to look up an address in a host table or from a domain server. It hasn't any notion of multi-homed hosts. It simply knows that it has to send a set of bits to a set of mailboxes at a set of hosts. The hosts are stored by name. When the mailer attempts to deliver a message, it does an operating system call which takes the host name as an argument and returns a single IP address. Any change in IP address selection would have to be done at the software at the other end of that system call. One way for be for the mailer to pass "advice" that a particular IP address has been shown to fail. Nobody is going to work on the host table software to do this. The amount of work to do such a task is much more work that it would be for Clive Dawson to upgrade his system to support domains. It would, I think, be relatively simple to put in such a function into the domain software. The only change to the mailer would be to pass "advice"; presumably a 3 or 4 line code change. I don't know what sort of effort it would take to put this in the domain software. The question then becomes, what sort of criterion should the domain software use beyond the current choice of "best" network, modified with mailer "advice"? Nobody has offered any suggestions. I again want to emphasize that the DEC-20 mailer does NOT "use the first address and ignore the rest". It has no way of knowing that any other addresses exist; it is totally dependent upon external software for any host information. Don't assume that because your mailer has internalized host table parsing routines that all mailers are written that way. I am a bit annoyed that the same people who are willing to accept BITNET mailers which toss away RFC821 return path information are quite happy to crucify software that isn't at fault. -------  Received: from IBM.COM (TCP 30001235007) by MC.LCS.MIT.EDU 16 Feb 88 17:43:07 EST Date: Tue, 16 Feb 88 13:22:52 PST From: David Alpern To: header-people@MC.LCS.MIT.EDU Subject: Re: Errors-To BITNET has been moving towards use of BSMTP, a batch form of SMTP which does carry the RFC821 envelope. The concept of Errors-To:, though, does make sense for those portions of BITNET or other networks where RFC821-like envelopes don't exist -- but it need not leave those portions to be useful. As gateways must already either get or put information into the RFC822 header, as mail leaves an RFC821 world an Errors-To line can be added (replacing any already present) to convey the current RFC821 MAIL FROM information, and upon entering an RFC821 world the Errors-To information can be removed from the header and put into the MAIL FROM. I know some out there will flame at me for suggesting that people who are on networks which "do it wrong," i.e., do not have an envelope separate from the header, should do anything to improve their situation other than add an envelope. But the same stubbornness amongst mailer-maintainers exists everywhere (I'm guilty of this too!), and a small amount (more) header munging at a gateway is frequently easier to convince someone to do than is a change to a different transport protocol. So, may I propose that no one ask Mark or others on networks which do have envelopes to change their mailers, but rather that Errors-To be looked at as an alternative means to carry the necessary information within, but only within, those portions of the networked world which do not use envelopes. - Dave p.s. I too remember this coming up many times in the past. The fact that it does keep coming up to me indicates that just saying "switch to using envelopes and the problems will go away" just doesn't solve the real-world problems involved. - These opionions are purely my own, and as usual I won't change them until after I hit 'send' :-).  Received: from venera.isi.edu (TCP 1200200064) by MC.LCS.MIT.EDU 18 Feb 88 21:54:00 EST Posted-Date: Thu, 18 Feb 88 18:49:44 PST Message-Id: <8802190249.AA20906@venera.isi.edu> Received: from LOCALHOST by venera.isi.edu (5.54/5.51) id AA20906; Thu, 18 Feb 88 18:49:47 PST To: Mark Crispin Cc: TCP-IP@sri-nic.arpa, Header-People@mc.lcs.mit.edu Subject: Re: Braden on secondary IP addresses In-Reply-To: Your message of Tue, 16 Feb 88 11:59:08 -0800. <12375250105.7.MRC@PANDA.PANDA.COM> Date: Thu, 18 Feb 88 18:49:44 PST From: Paul Mockapetris Mark, Bob, There are real issues behind this debate, and they are 1) what are the right policies with regard to hosts with multiple addresses and 2) where should the policies be implemented. It would be nice if everyone agreed what the rules are, but the waters are pretty muddy. There can be a large difference in performance depending on which address you use. My experience with domain and mail services suggests that sometimes a host offers different services on different addresses, and sometimes only a subset of the addresses are reachable due to gateway, etc factors. The bottom line is that sometimes whether you win or lose depends on the source and/or destination address you choose. There may always be a best address, but it isn't always possible to know which one it is without empirical information. I can always prefer destination addresses which share a common network, but sometimes the problem is "Given N non-local class C addresses, which one should I use?" Since the answer would seem to depend on both the identity of the source and the identity of the destination, it doesn't seem that either can solve the problem alone. Its not really just a mail issue. For example, domain resolvers and mailers have similar options. [A resolver has to decide (1) which sending address to use, (2) which name server to ask, and (3) which destination address to use when it targets a query. A mailer has to decide (1) which sending address to use (2) which MX RR (i.e. mail server) to use, and (3) which destination address to use. The parallels continue when you think about what to do in case of errors, how you tradeoff network resources vs local resources vs time to finish a request, etc. Admittedly, there are also large differences, but dealing with multiple addresses is an issue which comes up whenever you have such network services.] The domain system won't solve this problem. In fact, it will make it worse by spreading multiple addresses in more contexts. What we need is a consensus on policies regarding the use of multiple addresses and single module that can be used by all applications to implement the policies. (Maybe we have discovered one of the missing layers in the Internet 7 layer cake.) paul  Received: from bnl.ARPA (TCP 30003007401) by MC.LCS.MIT.EDU 19 Feb 88 17:38:15 EST Received: by bnl.ARPA; Fri, 19 Feb 88 15:47:08 EST Date: Fri, 19 Feb 88 15:47:08 EST From: George Rabinowitz Message-Id: <8802192047.AA06038@bnl.ARPA> To: Header-People@mc.lcs.mit.edu Subject: Mailing list request Please add me to your list George Rabinowitz gr@bnl.arpa  Received: from GUNTER-ADAM.ARPA (TCP 3200200015) by MC.LCS.MIT.EDU 20 Feb 88 16:58:13 EST Date: 20 Feb 1988 15:52:21 CST Subject: Mailing list removal From: Walt Livingston To: header-people@MC.LCS.MIT.EDU Please remove me from this mailing list....Thanks DSDC-SDT2 @ GUNTER-ADAM.ARPA Walt -------  Received: from violet.berkeley.edu (TCP 20010104026) by MC.LCS.MIT.EDU 1 Mar 88 23:00:08 EST Received: from garnet.berkeley.edu by violet.berkeley.edu (5.54 (CFC 4.22.3)/1.16.17l) id AA09064; Tue, 1 Mar 88 17:32:29 PST Received: by garnet.berkeley.edu (1.2/Ultrix2.0-CFC.8v) id AA13731; Tue, 1 Mar 88 17:32:24 pst Date: Tue, 1 Mar 88 17:32:24 pst From: netinfo%garnet.Berkeley.EDU@violet.berkeley.edu (Postmaster & BITINFO) Message-Id: <8803020132.AA13731@garnet.berkeley.edu> To: header-people@mc.lcs.mit.edu Subject: Strange Address: MAE%IME>USP%USP%USP;SPO:*EMBRA>FLOW/BR.SSANET&CI ... Cc: 8mar58@violet.berkeley.edu The following has to be the strangest address I have seen. Does anyone have any idea what this is? X400 address in an Internet message? From:MAE%IME>USP%USP%USP;SPO:*EMBRA>FLOW/BR.SSANET&CI Here is the message that the user sent me. This may be two message run together. Any ideas? ------------------------------------------------------------------------------ >From @relay.cs.net:R0ESC651@WATDCS.BITNET Fri Feb 19 10:57:14 1988 Received: by kepler.berkeley.edu (5.57/1.26) id AA17480; Fri, 19Feb 88 10:57:10 PST Received: from ernie.Berkeley.EDU by ucbvax.Berkeley.EDU (5.58/1.26) id AA00343; Fri, 19 Feb 88 11:00:19 PST Received: from CS.UCLA.EDU by ernie.Berkeley.EDU (5.58/1.26) id AA14354; Fri, 19 Feb 88 10:59:17 PST Return-Path: <@RELAY.CS.NET:R0ESC651@WATDCS.BITNET> Received: from RELAY.CS.NET by hera.cs.ucla.edu (Sendmail 5.58.2/1.15h) id AA01748; Fri, 19 Feb 88 10:43:18 PST Received: from relay2.cs.net by RELAY.CS.NET id ag26255; 19 Feb 88 11:44 EST Received: from math.waterloo.edu by RELAY.CS.NET id ag05757; 12 Feb 88 11:40 EST Received: from watdcsu by watmath; Fri, 19 Feb 88 10:59:45 EST Received: from WATDCS.UWaterloo.ca by watdcsu; Fri, 19 Feb 88 10:59:41 EST Message-Id: <8802121559.AA27370@watdcsu> Received: by WATDCS (Mailer X1.25UW) id 4397; Fri, 19 Feb 88 10:57:10 EST Date: Fri, 19 Feb 88 10:54:02 EST >>> RCPT To: <<< 550 550 alive@athena.mit.edu 43/trp/net.spi//88GATE.CLEAR Received: by kepler.berkeley.edu (5.57/1.26) id AA06376; Tue, 23 Feb 88 10:42:38 PST Date: Tue, 23 Feb 88 10:42:38 PST From:MAE%IME>USP%USP%USP;SPO:*EMBRA>FLOW/BR.SSANET&CI Message-Id: <8802231842.AA06376@kepler.berkeley.edu> To : 8mar58@violet.berkeley.edu Subject: ALO ------------------------------------------------------------------------- Bill Wells, Postmaster ------------------------------------------------------------------------ | William Wells (COML: +1 415-642-9801, ATSS: 582-9801) | | Data Communication & Network Services postmaster@jade.berkeley.edu | | University of California at Berkeley netinfo@jade.berkeley.edu | | 291 Evans Hall NETINFO at UCBGARNE (PUN/PRT) | | Berkeley, CA 94720 ucbvax!jade!postmaster | | Office Hours: Mon, Tue, Thu, and Fri: 2-4pm local Pacific time. | ------------------------------------------------------------------------  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 2 Apr 88 09:48:36 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Sat, 02 Apr 88 09:46:06 EST Received: from CARLETON.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4473; Sat, 02 Apr 88 09:45:54 EST Received: from WCSWR by CARLETON.BITNET on 02 Apr 88 10:41:26 EST X-Msg-id: <02104116_CU00> Date: 02 Apr 88 10:17:00 EDT From: Walter Roberson To: Subject: ! and @ -- which RFC ? Someone has recently asked me where the 'rule' governing the interpretation of '!' and '@', both in the same address, may be found. If you have the address , should this be interpreted as aaa!bbb!ccc or ccc!aaa!bbb ? As far as I know, the latter is correct -- but that is simply my experience, and not something I've seen documented. Could someone please point me to the appropriate RFC or other document? Thank you, Walter Roberson  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 3 Apr 88 22:47:57 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 3 Apr 88 22:49:05 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Sun, 03 Apr 88 22:44:58 EST Received: from Uofmcc.Bitnet by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 7793; Sun, 03 Apr 88 22:44:56 EST Date: Sun, 03 Apr 88 21:44 cdt From: #YEUN14%UOFMCC.BITNET@MITVMA.MIT.EDU To: franz-friends@berkeley.BITNET, header-people@ai.ai.mit.edu Subject: mailing list I want to be on your mailing list  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 4 Apr 88 00:41:20 EDT Date: Mon, 4 Apr 1988 00:39 EDT Message-ID: From: Rob Austein To: Walter Roberson Cc: header-people@MC.LCS.MIT.EDU Subject: ! and @ -- which RFC ? Date: Saturday, 2 April 1988 09:17-EST From: Walter Roberson Someone has recently asked me where the 'rule' governing the interpretation of '!' and '@', both in the same address, may be found. If you have the address , should this be interpreted as aaa!bbb!ccc or ccc!aaa!bbb ? As far as I know, the latter is correct -- but that is simply my experience, and not something I've seen documented. Could someone please point me to the appropriate RFC or other document? You lose. There's no RFC because the community that uses RFCs as their standards doesn't (formally) recognize "!" syntax. In other words, the precedence is determined by whoever wrote the mail code that you are using, and you can't count on any particular combination of "!" and "@" being universally acceptable. Now you know why even the usenet is moving away from use of "!" where possible (q.v. the "smail" mailer program). --Rob  Received: from GUNTER-ADAM.ARPA (TCP 3200200015) by MC.LCS.MIT.EDU 4 Apr 88 07:58:59 EDT Date: 4 Apr 1988 05:52:08 CST Subject: remove from mailing list From: Walt Livingston To: header-people@MC.LCS.MIT.EDU Please remove me from your mailing list (3rd request). Walt -------  Received: from NNSC.NSF.NET (TCP 20026200116) by MC.LCS.MIT.EDU 4 Apr 88 09:22:36 EDT To: wcswr%carleton.bitnet@NNSC.NSF.NET cc: header-people@mc.lcs.mit.edu Subject: re: ! and @ -- which RFC ? Date: Mon, 04 Apr 88 09:22:40 -0400 From: Craig Partridge Look at RFC 976 by Mark Horton -- which makes recommendations on this subject. Craig  Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU 4 Apr 88 13:15:44 EDT Received: from beno.CSS.GOV by seismo.CSS.GOV (5.54/1.14) id AA00865; Mon, 4 Apr 88 13:12:18 EDT Received: by beno.CSS.GOV (5.54/5.17) id AA28152; Mon, 4 Apr 88 13:12:17 EDT Date: Mon, 4 Apr 88 13:12:17 EDT From: rick@seismo.CSS.GOV (Rick Adams) Message-Id: <8804041712.AA28152@beno.CSS.GOV> To: craig@nnsc.nsf.net, wcswr%carleton.bitnet@nnsc.nsf.net Subject: re: ! and @ -- which RFC ? Cc: header-people@mc.lcs.mit.edu The defacto standard is that RFC822 rules. That means that the @ get precedence because the ! is in the "local part". Nothing should look at the local part other than the host to the right of the @. You want to avoid mixing ! and @ if at all possible (and it is almost always possible)  Received: from violet.berkeley.edu (TCP 20010104026) by MC.LCS.MIT.EDU 4 Apr 88 20:29:16 EDT Received: from garnet.berkeley.edu by violet.berkeley.edu (5.54 (CFC 4.22.3)/1.16.17l) id AA23738; Mon, 4 Apr 88 17:21:35 PDT Received: by garnet.berkeley.edu (1.2/Ultrix2.0-CFC.10) id AA28128; Mon, 4 Apr 88 17:21:17 pdt Date: Mon, 4 Apr 88 17:21:17 pdt From: netinfo%garnet.Berkeley.EDU@violet.berkeley.edu (Postmaster & BITINFO) Message-Id: <8804050021.AA28128@garnet.berkeley.edu> To: WCSWR%CARLETON.BITNET@mitvma.mit.edu Subject: Re: ! and @ -- which RFC ? Cc: header-people@mc.lcs.mit.edu, postmaster@ucbvax.Berkeley.EDU In reply to: X-Msg-Id: <02104116_CU00> Date: 02 Apr 88 10:17:00 EDT From: Walter Roberson To: Subject: ! and @ -- which RFC ? Someone has recently asked me where the 'rule' governing the interpretation of '!' and '@', both in the same address, may be found. "xxx!yyy@zzz" is interpreted differently in UUCP mail and Internet mail. In UUCP addresses the "!" takes precedence, in Internet mail addresses the "@" take precedence. This can be confusing to Internet/ UUCP hosts unless the appropriate address conversion is done going both in and out of the local mail transport system. There are also separate address conversion rules for addressees (To, Cc, etc) and originating addresses (From, Sender, etc.). And a separate sets of rules for each type of mail network address handled by the mail gateway (mail exchanger). If you have the address , should this be interpreted as aaa!bbb!ccc or ccc!aaa!bbb ? As far as I know, the latter is correct -- but that is simply my experience, and not something I've seen documented. Could someone please point me to the appropriate RFC or other document? Thank you, Walter Roberson I believe ucbvax.berkeley.edu was the first to implement the aaa!bbb@ccc.UUCP local addressing convention. You will find it documented in the mailaddr(7) section of the "Unix Programmer's Manual, 4.2 Berkeley Software Distribution, Virtual VAX-11 Version" dated August 1983 and in Unix manuals based on BSD Unix. QUOTE Compatibility. Certain old address formats are converted to the new format to provide compatibility with the previous mail system. In particular, host:user is converted to user@host to be consistent with the rcp(1c) command. Also, the syntax: host!user is converted to: user@host.UUCP This is normally converted back to the ``host!user'' form before being sent on for compatibility with older UUCP hosts. The current implementation is not able to route messages automatically through the UUCP network. Until that time you must explicitly tell mail system which hosts to send your message through to get to your final destination. UNQUOTE UUCP mail now supports "domain" instead of "host" at many sites. So this manual section is out-of-date. The new UUCP address convention is "domain!user" or "uucp-host-domain-list!domain!user". On an Internet mail host that is a UUCP gateway the local address should be converted UUCP address "ccc!aaa!bbb" for messages being send to UUCP. If going to an Internet site, that local UUCP address be converted to the Internet mail address: where "gateway-domain-name" is a valid internet domain name. Note that these rules are for addressees (To, Cc, etc.) only. Bill Wells, Postmaster ------------------------------------------------------------------------ | William Wells Telephone: COML: +1 415-642-9801, ATSS: 582-9801 | | Data Communication & Network Services postmaster@jade.berkeley.edu | | University of California at Berkeley netinfo@garnet.berkeley.edu | | 291 Evans Hall NETINFO at UCBGARNE (PUN/PRT) | | Berkeley, CA 94720 ucbvax!jade!netinfo (UUCP) | ------------------------------------------------------------------------  Received: from IU.AI.SRI.COM (TCP 1201200002) by MC.LCS.MIT.EDU 5 Apr 88 14:43:37 EDT Date: Tue 5 Apr 88 11:40:37-PST From: Peter Karp Subject: ! and @ To: header-people@MC.LCS.MIT.EDU Message-ID: <576272437.0.PKARP@IU.AI.SRI.COM> Mail-System-Version: An optimal solution may be to parse "x!y@z" both ways and determine which of the hosts z and x are known by the local host. This provides a way of disambiguating the syntax. Peter -------  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 8 Apr 88 06:36:51 EDT Received: from Burger.ms by ArpaGateway.ms ; 08 APR 88 03:33:07 PDT Sender: "Lennart_Lovstrand.EuroPARC"@Xerox.COM Date: 8 Apr 88 03:32:21 PDT (Friday) Subject: Re: ! and @ From: "Lennart_Lovstrand.EuroPARC"@Xerox.COM To: PKARP@IU.AI.SRI.COM cc: header-people@MC.LCS.MIT.EDU In-Reply-to: PKARP%IU.AI.SRI.COM's message of 6 Apr 88 05:08 Message-ID: <880408-033307-8264@Xerox> Sorry, that won't work either. Two examples: 1) Localhost is connected to two machines 'unics' and 'relayhost', but does not have access to any name server. It does, however, know that 'relayhost' can take care of most unknown addresses. In comes now the following address: unics!gobblygook@acme.com Should this be sent to the local 'unics' just because there happened to be one in the neighborhood? I say no, it is just as plausible that acme.com also has a local machine called 'unics' and that the message should be sent to 'relayhost'. 2) Localhost is both on the Internet and the UUCP network and has access to bind. In comes the following addresses: rambo.gov!gobblygook@state.edu Both rambo.gov and state.edu are on the Internet and are therefore known to localhost; to which destination should it send the message? It's not even safe to use different parsing strategies depending on from what network the message came, as UUCP more and more is adopting domain style addressing. The answer is that there is no patent proof way of disambiguating the mixed !/@ syntax. Heuristics may help, yes, but as long as these hybrid addresses are being used there will always be confusion and misunderstanding by the people and machines that have to deal with them. Only by persuading one of the communities to adopt the other's standard can we get rid of this pain -- or by scrapping them both and universally start using something like X.400. In the mean time, I think it's better to keep a firm parsing policy which favors exactly one of the above -- and if you're connected to the Internet, you know which one to choose. :-) --Lennart  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 May 88 17:45:59 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sat, 7 May 88 11:43:19 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 7 May 88 13:19:48 GMT From: osu-cis!n8emr!lwv@ohio-state.arpa (Larry W. Virden) Organization: Ham BBS, Columbus,Oh. 614-457-4227 (300/1200,8N1) Subject: Forwarded mail headers Message-Id: <544@n8emr.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 May 88 20:45:49 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sat, 7 May 88 20:34:49 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 7 May 88 23:04:25 GMT From: adm!osu-cis!n8emr!lwv%TUT.CIS.OHIO-STATE.EDU@brl-adm.arpa (Larry W. Virden) Subject: Forwarded mail headers Message-Id: <13719@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 May 88 23:15:14 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sat, 7 May 88 23:03:05 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 01:40:51 GMT From: adm!adm!osu-cis!n8emr!lwv%TUT.CIS.OHIO-STATE.EDU%brl-adm.arpa@brl-adm.arpa Subject: Forwarded mail headers Message-Id: <13734@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.  Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 7 May 88 23:32:34 EDT Received: from buita.bu.edu by bu-it.BU.EDU (4.0/4.7) id AA20881; Sat, 7 May 88 23:30:39 EDT Return-Path: Received: by buita.bu.edu (3.2/4.7) id AA15704; Sat, 7 May 88 23:30:40 EDT Date: Sat, 7 May 88 23:30:40 EDT From: jsol@bu-it.BU.EDU Message-Id: <8805080330.AA15704@buita.bu.edu> To: header-people@mc.lcs.mit.edu Subject: "forwarded mail format" I'm afraid you are out of luck. RFC822 does not describe the format of forwarded mail, nor does it require that any information at all be supplied as to the originator of mail. The only thing it requires is that the message conform to standards in the header of the mail message. It doesn't even have to be accurate!!! it just has to be there. Sorry for the disappointment, --jsol  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 02:15:16 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 02:00:51 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 05:04:51 GMT From: adm!jsol%bu-it.bu.edu@brl-adm.arpa Subject: \"forwarded mail format\" Message-Id: <13756@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I'm afraid you are out of luck. RFC822 does not describe the format of forwarded mail, nor does it require that any information at all be supplied as to the originator of mail. The only thing it requires is that the message conform to standards in the header of the mail message. It doesn't even have to be accurate!!! it just has to be there. Sorry for the disappointment, --jsol  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 02:15:42 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 02:00:05 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 05:04:25 GMT From: adm!adm!adm!osu-cis!n8emr!lwv%TUT.CIS.OHIO-STATE.EDU%brl-adm.arpa%brl-adm.arpa@brl-adm.arpa Subject: Forwarded mail headers Message-Id: <13754@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 04:15:20 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 04:10:23 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 06:45:22 GMT From: adm!adm!jsol%bu-it.bu.edu%brl-adm.arpa@brl-adm.arpa Subject: \\"forwarded mail format\\" Message-Id: <13766@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I'm afraid you are out of luck. RFC822 does not describe the format of forwarded mail, nor does it require that any information at all be supplied as to the originator of mail. The only thing it requires is that the message conform to standards in the header of the mail message. It doesn't even have to be accurate!!! it just has to be there. Sorry for the disappointment, --jsol  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 04:15:33 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 04:12:33 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 07:43:59 GMT From: adm!adm!adm!adm!osu-cis!n8emr!lwv%TUT.CIS.OHIO-STATE.EDU%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa@brl-adm.arpa Subject: Forwarded mail headers Message-Id: <13772@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 05:45:17 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 05:34:04 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 08:53:05 GMT From: adm!adm!adm!jsol%bu-it.bu.edu%brl-adm.arpa%brl-adm.arpa@brl-adm.arpa Subject: \\\"forwarded mail format\\\" Message-Id: <13779@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I'm afraid you are out of luck. RFC822 does not describe the format of forwarded mail, nor does it require that any information at all be supplied as to the originator of mail. The only thing it requires is that the message conform to standards in the header of the mail message. It doesn't even have to be accurate!!! it just has to be there. Sorry for the disappointment, --jsol  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 06:15:21 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 06:12:47 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 09:37:24 GMT From: adm!adm!adm!adm!adm!osu-cis!n8emr!lwv%TUT.CIS.OHIO-STATE.EDU%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa@brl-adm.arpa Subject: Forwarded mail headers Message-Id: <13784@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 07:45:18 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 07:35:52 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 10:46:37 GMT From: adm!adm!adm!adm!jsol%bu-it.bu.edu%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa@brl-adm.arpa Subject: \\\\"forwarded mail format\\\\" Message-Id: <13791@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I'm afraid you are out of luck. RFC822 does not describe the format of forwarded mail, nor does it require that any information at all be supplied as to the originator of mail. The only thing it requires is that the message conform to standards in the header of the mail message. It doesn't even have to be accurate!!! it just has to be there. Sorry for the disappointment, --jsol  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 08:15:18 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 08:12:21 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 11:36:53 GMT From: adm!adm!adm!adm!adm!adm!osu-cis!n8emr!lwv%TUT.CIS.OHIO-STATE.EDU%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa@brl-adm.arpa Subject: Forwarded mail headers Message-Id: <13797@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 08:45:18 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 08:33:10 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 12:21:13 GMT From: adm!adm!adm!adm!adm!jsol%bu-it.bu.edu%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa@brl-adm.arpa Subject: \\\\\"forwarded mail format\\\\\" Message-Id: <13802@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I'm afraid you are out of luck. RFC822 does not describe the format of forwarded mail, nor does it require that any information at all be supplied as to the originator of mail. The only thing it requires is that the message conform to standards in the header of the mail message. It doesn't even have to be accurate!!! it just has to be there. Sorry for the disappointment, --jsol  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 09:45:24 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 09:35:01 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 13:29:27 GMT From: adm!adm!adm!adm!adm!adm!adm!osu-cis!n8emr!lwv%TUT.CIS.OHIO-STATE.EDU%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa@brl-adm.arpa Subject: Forwarded mail headers Message-Id: <13809@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 11:30:28 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 11:20:35 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 14:47:13 GMT From: adm!adm!adm!adm!adm!adm!adm!adm!osu-cis!n8emr!lwv%TUT.CIS.OHIO-STATE.EDU%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa@brl-adm.arpa Subject: Forwarded mail headers Message-Id: <13818@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 11:30:38 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 10:32:58 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 14:03:09 GMT From: adm!adm!adm!adm!adm!adm!jsol%bu-it.bu.edu%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa@brl-adm.arpa Subject: \\\\\\"forwarded mail format\\\\\\" Message-Id: <13813@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I'm afraid you are out of luck. RFC822 does not describe the format of forwarded mail, nor does it require that any information at all be supplied as to the originator of mail. The only thing it requires is that the message conform to standards in the header of the mail message. It doesn't even have to be accurate!!! it just has to be there. Sorry for the disappointment, --jsol  Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 8 May 88 11:54:03 EDT Received: from buita.bu.edu by bu-it.BU.EDU (4.0/4.7) id AA04472; Sun, 8 May 88 11:51:54 EDT Return-Path: Received: by buita.bu.edu (3.2/4.7) id AA25302; Sun, 8 May 88 11:51:57 EDT Date: Sun, 8 May 88 11:51:57 EDT From: jsol@bu-it.BU.EDU Message-Id: <8805081551.AA25302@buita.bu.edu> To: header-people@mc.lcs.mit.edu Subject: [postmaster@utadnx.cc.utexas.edu: Mail Delivery Problem] Date: 7 May 88 23:39:05 CDT From: "SMTP MAILER" Subject: Mail Delivery Problem To: ----Reason for mail failure follows---- Sending mail to recipient(s) ilasut : Couldn't make final delivery. ----Transcript of message follows---- Received: from MC.LCS.MIT.EDU by utadnx.cc.utexas.edu with SMTP ; Sat, 7 May 88 23:19:21 CDT Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 7 May 88 23:32:34 EDT Received: from buita.bu.edu by bu-it.BU.EDU (4.0/4.7) id AA20881; Sat, 7 May 88 23:30:39 EDT Received: by buita.bu.edu (3.2/4.7) id AA15704; Sat, 7 May 88 23:30:40 EDT Date: Sat, 7 May 88 23:30:40 EDT From: jsol@bu-it.BU.EDU Message-Id: <8805080330.AA15704@buita.bu.edu> To: header-people@mc.lcs.mit.edu Subject: "forwarded mail format" I'm afraid you are out of luck. RFC822 does not describe the format of forwarded mail, nor does it require that any information at all be supplied as to the originator of mail. The only thing it requires is that the message conform to standards in the header of the mail message. It doesn't even have to be accurate!!! it just has to be there. Sorry for the disappointment, --jsol  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 13:15:24 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 13:13:03 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 16:52:06 GMT From: adm!adm!adm!adm!adm!adm!adm!jsol%bu-it.bu.edu%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa@brl-adm.arpa Subject: \\\\\\\"forwarded mail format\\\\\\\" Message-Id: <13832@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I'm afraid you are out of luck. RFC822 does not describe the format of forwarded mail, nor does it require that any information at all be supplied as to the originator of mail. The only thing it requires is that the message conform to standards in the header of the mail message. It doesn't even have to be accurate!!! it just has to be there. Sorry for the disappointment, --jsol  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 13:15:37 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 12:44:51 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 16:17:58 GMT From: adm!adm!adm!adm!adm!adm!adm!adm!adm!osu-cis!n8emr!lwv%TUT.CIS.OHIO-STATE.EDU%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa@brl-adm Subject: Forwarded mail headers Message-Id: <13827@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 14:30:25 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 14:14:38 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 17:47:12 GMT From: adm!jsol%bu-it.bu.edu@brl-adm.arpa Subject: [postmaster@utadnx.cc.utexas.edu: Mail Delivery Problem] Message-Id: <13838@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Date: 7 May 88 23:39:05 CDT From: "SMTP MAILER" Subject: Mail Delivery Problem To: ----Reason for mail failure follows---- Sending mail to recipient(s) ilasut : Couldn't make final delivery. ----Transcript of message follows---- Received: from MC.LCS.MIT.EDU by utadnx.cc.utexas.edu with SMTP ; Sat, 7 May 88 23:19:21 CDT Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 7 May 88 23:32:34 EDT Received: from buita.bu.edu by bu-it.BU.EDU (4.0/4.7) id AA20881; Sat, 7 May 88 23:30:39 EDT Received: by buita.bu.edu (3.2/4.7) id AA15704; Sat, 7 May 88 23:30:40 EDT Date: Sat, 7 May 88 23:30:40 EDT From: jsol@bu-it.BU.EDU Message-Id: <8805080330.AA15704@buita.bu.edu> To: header-people@mc.lcs.mit.edu Subject: "forwarded mail format" I'm afraid you are out of luck. RFC822 does not describe the format of forwarded mail, nor does it require that any information at all be supplied as to the originator of mail. The only thing it requires is that the message conform to standards in the header of the mail message. It doesn't even have to be accurate!!! it just has to be there. Sorry for the disappointment, --jsol  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 17:15:31 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 16:44:42 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 20:03:07 GMT From: adm!adm!adm!adm!adm!adm!adm!adm!adm!adm!osu-cis!n8emr!lwv%TUT.CIS.OHIO-STATE.EDU%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa% Subject: Forwarded mail headers Message-Id: <13853@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 17:15:41 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 16:12:44 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 18:55:32 GMT From: adm!adm!adm!adm!adm!adm!adm!adm!jsol%bu-it.bu.edu%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa@brl-adm.arpa Subject: \\\\\\\\"forwarded mail format\\\\\\\\" Message-Id: <13846@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I'm afraid you are out of luck. RFC822 does not describe the format of forwarded mail, nor does it require that any information at all be supplied as to the originator of mail. The only thing it requires is that the message conform to standards in the header of the mail message. It doesn't even have to be accurate!!! it just has to be there. Sorry for the disappointment, --jsol  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 17:30:36 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 17:13:41 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 20:36:58 GMT From: adm!adm!jsol%bu-it.bu.edu%brl-adm.arpa@brl-adm.arpa Subject: [postmaster@utadnx.cc.utexas.edu: Mail Delivery Problem] Message-Id: <13857@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Date: 7 May 88 23:39:05 CDT From: "SMTP MAILER" Subject: Mail Delivery Problem To: ----Reason for mail failure follows---- Sending mail to recipient(s) ilasut : Couldn't make final delivery. ----Transcript of message follows---- Received: from MC.LCS.MIT.EDU by utadnx.cc.utexas.edu with SMTP ; Sat, 7 May 88 23:19:21 CDT Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 7 May 88 23:32:34 EDT Received: from buita.bu.edu by bu-it.BU.EDU (4.0/4.7) id AA20881; Sat, 7 May 88 23:30:39 EDT Received: by buita.bu.edu (3.2/4.7) id AA15704; Sat, 7 May 88 23:30:40 EDT Date: Sat, 7 May 88 23:30:40 EDT From: jsol@bu-it.BU.EDU Message-Id: <8805080330.AA15704@buita.bu.edu> To: header-people@mc.lcs.mit.edu Subject: "forwarded mail format" I'm afraid you are out of luck. RFC822 does not describe the format of forwarded mail, nor does it require that any information at all be supplied as to the originator of mail. The only thing it requires is that the message conform to standards in the header of the mail message. It doesn't even have to be accurate!!! it just has to be there. Sorry for the disappointment, --jsol  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 19:00:34 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 18:19:51 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 21:55:43 GMT From: adm!adm!adm!adm!adm!adm!adm!adm!adm!adm!adm!osu-cis!n8emr!lwv%TUT.CIS.OHIO-STATE.EDU%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm. Subject: Forwarded mail headers Message-Id: <13865@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 20:15:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 20:06:22 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 8 May 88 23:41:45 GMT From: adm!adm!adm!jsol%bu-it.bu.edu%brl-adm.arpa%brl-adm.arpa@brl-adm.arpa Subject: [postmaster@utadnx.cc.utexas.edu: Mail Delivery Problem] Message-Id: <13877@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Date: 7 May 88 23:39:05 CDT From: "SMTP MAILER" Subject: Mail Delivery Problem To: ----Reason for mail failure follows---- Sending mail to recipient(s) ilasut : Couldn't make final delivery. ----Transcript of message follows---- Received: from MC.LCS.MIT.EDU by utadnx.cc.utexas.edu with SMTP ; Sat, 7 May 88 23:19:21 CDT Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 7 May 88 23:32:34 EDT Received: from buita.bu.edu by bu-it.BU.EDU (4.0/4.7) id AA20881; Sat, 7 May 88 23:30:39 EDT Received: by buita.bu.edu (3.2/4.7) id AA15704; Sat, 7 May 88 23:30:40 EDT Date: Sat, 7 May 88 23:30:40 EDT From: jsol@bu-it.BU.EDU Message-Id: <8805080330.AA15704@buita.bu.edu> To: header-people@mc.lcs.mit.edu Subject: "forwarded mail format" I'm afraid you are out of luck. RFC822 does not describe the format of forwarded mail, nor does it require that any information at all be supplied as to the originator of mail. The only thing it requires is that the message conform to standards in the header of the mail message. It doesn't even have to be accurate!!! it just has to be there. Sorry for the disappointment, --jsol  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 May 88 21:15:39 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.45/4.7 id ; Sun, 8 May 88 21:06:06 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 9 May 88 00:48:24 GMT From: adm!adm!adm!adm!adm!adm!adm!adm!adm!adm!adm!adm!osu-cis!n8emr!lwv%TUT.CIS.OHIO-STATE.EDU%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm Subject: Forwarded mail headers Message-Id: <13884@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.  Received: from OFFICE-8.ARPA (TCP 3202400200) by MC.LCS.MIT.EDU 9 May 88 11:46:32 EDT Date: 9 May 88 08:46 PDT From: William Daul / McAir / McDonnell-Douglas Corp Subject: Ah come on!!! can't someone stop this looping mail item To: header-people@mc.lcs.mit.edu Message-ID: Message: <13853@brl-adm.ARPA>!!!! enough is enough!!!  Received: from BLOOM-BEACON.MIT.EDU.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 22 May 88 14:54:40 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 22 May 88 14:37:28 EDT Received: from USENET by bloom-beacon with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 10 May 88 17:32:14 GMT From: msmith@topaz.rutgers.edu (Mark Robert Smith) Organization: M. R. Smith Consulting, Tenafly, NJ Subject: Re: Forwarded mail headers Message-Id: References: <13884@brl-adm.ARPA> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu The following message, shown in it's entirety, has arrived at this site about a dozen times, as has the followup to it. Anybody know what's up? Mark ---------------------------------------------- Path: topaz.rutgers.edu!rutgers!mit-eddie!husc6!cmcl2!brl-adm!adm!adm!adm!adm!adm!adm!adm!adm!adm!adm!adm!adm!osu-cis!n8emr!lwv%TUT.CIS.OHIO-STATE.EDU%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.@BRL.ARPA From: IO-STATE.EDU%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm.arpa%brl-adm@brl-adm.ARPA Newsgroups: comp.mail.headers Subject: Forwarded mail headers Message-ID: <13884@brl-adm.ARPA> Date: 9 May 88 00:48:24 GMT Sender: news@brl-adm.ARPA Lines: 44 I am trying to find out how forwarded mail messages are 'supposed' to look when they appear in net land. Currently, when my work mailer forwards one message to someone else, it is enveloped in a mail heading which says that the message was forwarde by me to the individual. But I am seeing recently messages from folks who claim that their mailer is rfc822 (?) compatible which does the following: Article 4143 of comp.sys.apple: Path: n8emr!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!pasteur!ucbvax!SHARK.NOSC.MIL!MEDIN-T From: MEDIN-T@SHARK.NOSC.MIL (Ted Medin) Newsgroups: comp.sys.apple Subject: Re: 2nd try Message-ID: Date: 5 May 88 23:03:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 4 I forgot whoever asked for this but here's a response I got from Ted Medin. --chris ----------------------------Original message---------------------------- The latest version of blu works on all 2's. ============================ Note that the above message was forwarded (reference to a chris and a line stating Original message) yet there is nothing in the header as it arrived here that indicates WHO originally mailed this message. This has been happening to me now for about 1-2 weeks. I know of at least one site that specifically is running this mailing pgm. They claim that their mail is fine - in fact, when messages end up on their mailing list (info- apple?) it has a Resent-By: header line. But somewhere in the translation to uucp/usenet it loses this line. This also happens when private mail crosses from the site into usenet/uucp land. Any ideas on whether there is a rogue site or if perhaps the originating sites have a problem? Thanks! -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 osu-cis!n8emr!lwv (UUCP) osu-cis!n8emr!lwv@TUT.CIS.OHIO-STATE.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children. ------------------------------------ I suspect that the problem is at brl-adm.arpa. Mark -- Mark Smith (alias Smitty) "Be careful when looking into the distance, 61 Tenafly Road that you do not miss what is right under your nose." Tenafly, NJ 07670 {backbone}!rutgers!topaz.rutgers.edu!msmith msmith@topaz.rutgers.edu Bill and Opus in '88!!!  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 23 May 88 04:37:40 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 5579; Mon, 23 May 88 03:51:46 EDT Received: from VM1.TAU.AC.IL by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 5578; Mon, 23 May 88 03:51:21 EDT Received: by TAUNIVM (Mailer X1.24) id 7140; Mon, 23 May 88 08:21:23 IST Date: Mon, 23 May 88 08:20:21 IST From: Hank Nussbacher Subject: Re: Forwarded mail headers To: header-people@mc.lcs.mit.edu, header-people-request@mc.lcs.mit.edu In-Reply-To: Message of 10 May 88 17:32:14 GMT from Since header-people-request doesn't answer for the past month, I am forced to request it this way: Plz remove me from this list. Thanks, Hank  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 Jun 88 10:32:24 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 12 Jun 88 10:24:51 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Jun 88 08:51:57 GMT From: amdahl!pyramid!prls!mips!koblas@ames.arpa (David Koblas) Organization: MIPS Computer Systems, Sunnyvale, CA Subject: Address Test List? Message-Id: <2361@wright.mips.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu [Whatever happend to lineeater fodder, now all there is is inews fodder] Mail addresses. What I'm looking for/requesting is lists of good address to pass through a mailer (sendmail) to see what come out the other side. Specifically I'm looking for not only those nice good address ("foo@mips.com", "a!b!c"), but also those one that can start FlameWars when used in the wrong context ("a!b!c@foo", or "site1!@site2.dom.main:user@site3"). And the routing that YOU the reading audiance belive to be correct. Also while I'm doing this I'm currious as to what people believe is a good rewritting scheme for a path is isn't known (i.e. recieving a path "a!b!c@d.e.f" when I talk to none of "a","b","d","d.e.f",".e.f",".f"). Thus the problem being should I try routing to "a", "d.e.f", or "c"? -- name : David Koblas place: MIPS Computers Systems phone: 408-991-0287 uucp : {ames,decwrl,pyramid,prls}!mips!koblas quote: "A day without NFS failure is like a day without sunshine" -- R.March  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 18 Jul 88 21:29:02 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 18 Jul 88 21:26:16 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 18 Jul 88 15:22:54 GMT From: uflorida!usfvax2!jc3b21!byers@gatech.edu (Jim Byers) Organization: St. Petersburg Jr. College, FL Subject: LOOKING FOR PATHS Message-Id: <435@jc3b21.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I REALLY NEED TO KNOW THE PATH TO HEWLETT PACKARD IN PALO ALTO , CA. I'M TRYING TO SEND MAIL TO A PERSON BY THE NAME OF**** BETH SCANNELL **** IF ANYONE OUT THERE HAS ANY IDEA OF HOW I CAN EMAIL SOMETHING THERE THEN I WOULD REALLY APPRECIATE IT.... **********JIM BYERS********** *****SPJC***********APJIM****  Received: from violet.berkeley.edu (TCP 20010104026) by MC.LCS.MIT.EDU 18 Jul 88 22:19:32 EDT Received: from garnet.berkeley.edu by violet.berkeley.edu (5.54 (CFC 4.22.3)/1.16.17l) id AA27950; Mon, 18 Jul 88 19:16:20 PDT Received: by garnet.berkeley.edu (1.2/Ultrix2.0-CFC.13) id AA23468; Mon, 18 Jul 88 19:16:17 pdt Date: Mon, 18 Jul 88 19:16:17 pdt From: netinfo%garnet.Berkeley.EDU@violet.berkeley.edu (Postmaster & BITINFO) Message-Id: <8807190216.AA23468@garnet.berkeley.edu> To: header-people@mc.lcs.mit.edu, uflorida!usfvax2!jc3b21!byers@gatech.edu Subject: Re: LOOKING FOR PATHS Cc: postmaster@hplabs.hp.com In reply to: Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) Date: 18 Jul 88 15:22:54 GMT From: uflorida!usfvax2!jc3b21!byers@gatech.edu (Jim Byers) Organization: St. Petersburg Jr. College, FL Subject: LOOKING FOR PATHS Message-Id: <435@jc3b21.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I REALLY NEED TO KNOW THE PATH TO HEWLETT PACKARD IN PALO ALTO, CA. I'M TRYING TO SEND MAIL TO A PERSON BY THE NAME OF**** BETH SCANNELL **** IF ANYONE OUT THERE HAS ANY IDEA OF HOW I CAN EMAIL SOMETHING THERE THEN I WOULD REALLY APPRECIATE IT.... **********JIM BYERS********** *****SPJC***********APJIM**** Jim, the correct place to ask this type of question is the site postmaster or the mailing list Info-nets@think.com on the Internet. Hewlett Parckard has several nodes listed in the UUCP map data which is available in the Usenet news system. The primary UUCP node is "hplabs" (hplabs.hp.com) on the Internet. Bill Wells, Postmaster ------------------------------------------------------------------------ | William Wells Telephone: COML: +1 415-642-9801, ATSS: 582-9801 | | Data Communication & Network Services postmaster@jade.berkeley.edu | | University of California at Berkeley netinfo@garnet.berkeley.edu | ------------------------------------------------------------------------  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Jul 88 03:59:46 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 19 Jul 88 03:51:31 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 19 Jul 88 05:51:36 GMT From: palo-alto!vixie@decwrl.dec.com (Paul Vixie) Organization: DEC Western Research Lab Subject: Re: mixed addresses Message-Id: <3503@palo-alto.DEC.COM> References: <8807142016.dusip.andrew@stl.stc.co.uk> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu (Andrew Macpherson writes:) # You have brought up a nasty. In fact you are highlighting two # of them. Firstly '%' as an address character. IT IS NOT LEGAL RFC822. # It remains around for historical compatibility (RFC7?? --- read the # first page of 822 if you really want to know which). (Rick Adams writes:) # The fact that you are mucking with the LOCAL-PART, which you are supposed # to leave totally alone, is the cause of the problem. (which I agree with, but then Rick says:) # Anyone who gives % precedence over ! should fix their mailer. # % is NOT a synonym for @. It is a valid part of the local-part # of the address and should not be interpreted my any site save # the destination machine. I agree that % is not a defined pseudonym for @ and that anyone who tries to say it is can be ignored. It is, indeed, part of the "local part", and there is no written standard that says it has to be processed one way or another. But, um, has anybody got users on their systems with "%" as part of the user identifier? Probably a few, but vastly: no. "%" _is_ intepreted by most large sites, after all standard address characters have been processed, stripped off, and yet the message is still unresolved. The usual processing of "%" is: locate the rightmost % change it to an @ go back and do what @ requires This is a _HACK_. But it's widely implemented. It has the same level of "pseudo standardization" that "!" has, though the two characters evolved on different planets. So when Rick said: # Anyone who gives % precedence over ! should fix their mailer. I say: uh-uh, nothing's wrong with my mailer. If I'm to interpret % at all, I'll be doing it mostly by the seat of my pants -- since there's no standard for it, it's in the local-part after all. It has a common meaning, which is very similar to the meaning of "@" -- the thing to the right of it is a host or domain or something, and the thing to the left of it is an address or a route or some such that the thing to the right of it can be halfway depended upon to understand. I'll say again: % is just another character if there's an @ anywhere in an address. @ is spoken of in RFC822, % is not. % should be treated like "a" or "b" or "c" if there's an @ anywhere in the address (really route-addr but you know what I mean). The UUCP "!" is in the same state -- it's just another character if there's an @ anywhere to be found. So, shall I fix my mailer to send back mail that gets here looking like "xyzzy!bar" or "bar%xyzzy" after I've stripped off the "@dec.com"? I'd rather not just bounce things, since there is something of a standard for what these LOCAL-PART characters mean. I give ! precedence over %, because I've already got a character that does what % does -- that is, @. % begins to have great value as a low-precedence @ that will be treated as an @ once all @'s and !'s have been stripped out. (Andrew Macpherson continues:) # Having got that off my chest, here is the associated nasty: mcvax # uses it as a 'local-part' operator, and hands on addresses of the form # a!b!u%l, which any Internetted (and probably any JANET) host will treat # as send to 'l' for uucp forwarding. Bleah. Seriously. If I want it to go to "l" first, I can use "@l". If I say "%l", it probably means that I want to do something that @ can't do -- namely, not be evaluated until it reaches "b". # This is not usually a problem but occasionally we recieve US mail which # has hopped to the arpanet and been strangely delt with... "Strangely"? Our conventions are different, that's true. John Diamant @HP once sent me an unfinished RFC that dealt with this issue, but like him, I could never figure out quite how to resolve everything into one neat little package. But I do think that after the one, Crocker-given symbol has been processed and we are down to our nitty-gritties trying to hand off a piece of mail based on the local-part, that ! usefully precedes % in what little decoding is possible. # Now the other point... Mixed addresses. If you live in the uucp world only # you have no trouble. If in 822 land likewise. I understand the JNETters # allow % as a source-routing so they also have a consistent rule-set. All 3 # have a route specification method, therefore there is neither need nor # justification for mixed-mode addressing. [...] The only safe and reasonable # course to take is to provide the destination address in the format required # by the network you are using. I agree completely. The rules I use for local-part precedence are worst-case, and properly generated mail messages don't get that far into the bowels of my mailers. If something comes to me over UUCP, the envelope recipients can easily be coded, each and every one, in pure !-notation. If I want to submit a message into a UUCP transport system, I can bloody well code up all the envelope recipients in pure !-notation. Likewise, if something comes in over SMTP, the envelope recips can and should be in straight route-addr notation (i.e., @a,@b,@c:u@d, and gosh that sure is ugly, Dave), and I can certainly be expected to submit things in that form. As Diamant (am I spelling that right, John?) points out, though, RFC822 and its friends imply or demand that all domains named in a route-addr be registered with the NIC. This is silly and inconvenient and everybody ignores it. But it does mean that if something comes to you over UUCP with an envelope recip of a!b!c!d and you decide to reach "a" via SMTP and you want to rewrite the envelope recip into route-addr and you rewrite it to be @a,@b:d@c and either "b" or "c" is not registered with the NIC, you've just broken another silly regulation. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Jul 88 03:59:46 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 19 Jul 88 03:51:31 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 19 Jul 88 05:51:36 GMT From: palo-alto!vixie@decwrl.dec.com (Paul Vixie) Organization: DEC Western Research Lab Subject: Re: mixed addresses Message-Id: <3503@palo-alto.DEC.COM> References: <8807142016.dusip.andrew@stl.stc.co.uk> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu (Andrew Macpherson writes:) # You have brought up a nasty. In fact you are highlighting two # of them. Firstly '%' as an address character. IT IS NOT LEGAL RFC822. # It remains around for historical compatibility (RFC7?? --- read the # first page of 822 if you really want to know which). (Rick Adams writes:) # The fact that you are mucking with the LOCAL-PART, which you are supposed # to leave totally alone, is the cause of the problem. (which I agree with, but then Rick says:) # Anyone who gives % precedence over ! should fix their mailer. # % is NOT a synonym for @. It is a valid part of the local-part # of the address and should not be interpreted my any site save # the destination machine. I agree that % is not a defined pseudonym for @ and that anyone who tries to say it is can be ignored. It is, indeed, part of the "local part", and there is no written standard that says it has to be processed one way or another. But, um, has anybody got users on their systems with "%" as part of the user identifier? Probably a few, but vastly: no. "%" _is_ intepreted by most large sites, after all standard address characters have been processed, stripped off, and yet the message is still unresolved. The usual processing of "%" is: locate the rightmost % change it to an @ go back and do what @ requires This is a _HACK_. But it's widely implemented. It has the same level of "pseudo standardization" that "!" has, though the two characters evolved on different planets. So when Rick said: # Anyone who gives % precedence over ! should fix their mailer. I say: uh-uh, nothing's wrong with my mailer. If I'm to interpret % at all, I'll be doing it mostly by the seat of my pants -- since there's no standard for it, it's in the local-part after all. It has a common meaning, which is very similar to the meaning of "@" -- the thing to the right of it is a host or domain or something, and the thing to the left of it is an address or a route or some such that the thing to the right of it can be halfway depended upon to understand. I'll say again: % is just another character if there's an @ anywhere in an address. @ is spoken of in RFC822, % is not. % should be treated like "a" or "b" or "c" if there's an @ anywhere in the address (really route-addr but you know what I mean). The UUCP "!" is in the same state -- it's just another character if there's an @ anywhere to be found. So, shall I fix my mailer to send back mail that gets here looking like "xyzzy!bar" or "bar%xyzzy" after I've stripped off the "@dec.com"? I'd rather not just bounce things, since there is something of a standard for what these LOCAL-PART characters mean. I give ! precedence over %, because I've already got a character that does what % does -- that is, @. % begins to have great value as a low-precedence @ that will be treated as an @ once all @'s and !'s have been stripped out. (Andrew Macpherson continues:) # Having got that off my chest, here is the associated nasty: mcvax # uses it as a 'local-part' operator, and hands on addresses of the form # a!b!u%l, which any Internetted (and probably any JANET) host will treat # as send to 'l' for uucp forwarding. Bleah. Seriously. If I want it to go to "l" first, I can use "@l". If I say "%l", it probably means that I want to do something that @ can't do -- namely, not be evaluated until it reaches "b". # This is not usually a problem but occasionally we recieve US mail which # has hopped to the arpanet and been strangely delt with... "Strangely"? Our conventions are different, that's true. John Diamant @HP once sent me an unfinished RFC that dealt with this issue, but like him, I could never figure out quite how to resolve everything into one neat little package. But I do think that after the one, Crocker-given symbol has been processed and we are down to our nitty-gritties trying to hand off a piece of mail based on the local-part, that ! usefully precedes % in what little decoding is possible. # Now the other point... Mixed addresses. If you live in the uucp world only # you have no trouble. If in 822 land likewise. I understand the JNETters # allow % as a source-routing so they also have a consistent rule-set. All 3 # have a route specification method, therefore there is neither need nor # justification for mixed-mode addressing. [...] The only safe and reasonable # course to take is to provide the destination address in the format required # by the network you are using. I agree completely. The rules I use for local-part precedence are worst-case, and properly generated mail messages don't get that far into the bowels of my mailers. If something comes to me over UUCP, the envelope recipients can easily be coded, each and every one, in pure !-notation. If I want to submit a message into a UUCP transport system, I can bloody well code up all the envelope recipients in pure !-notation. Likewise, if something comes in over SMTP, the envelope recips can and should be in straight route-addr notation (i.e., @a,@b,@c:u@d, and gosh that sure is ugly, Dave), and I can certainly be expected to submit things in that form. As Diamant (am I spelling that right, John?) points out, though, RFC822 and its friends imply or demand that all domains named in a route-addr be registered with the NIC. This is silly and inconvenient and everybody ignores it. But it does mean that if something comes to you over UUCP with an envelope recip of a!b!c!d and you decide to reach "a" via SMTP and you want to rewrite the envelope recip into route-addr and you rewrite it to be @a,@b:d@c and either "b" or "c" is not registered with the NIC, you've just broken another silly regulation. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Jul 88 09:43:33 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 19 Jul 88 09:34:33 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 19 Jul 88 13:09:58 GMT From: bbn.com!rsalz@bbn.com (Rich Salz) Organization: BBN Systems and Technologies, Inc. Subject: Re: mixed addresses Message-Id: <1002@fig.bbn.com> References: <8807142016.dusip.andrew@stl.stc.co.uk>, <3503@palo-alto.DEC.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu >[ Treating % as a delayed @ if there are no other meta-characters in the >address ] has the same level of "pseudo standardization" that "!" has, >though the two characters evolved on different planets. Unh, no. The "!" character for UUCP routing is documented in RFC976. I'd also claim that UUCP and ARPA aren't two different planets, but were at worst two different continents, shared by a few common passageways, navigable only by some very hardy souls. In particular, now-civilized natives of far-off UUCP backwaters fondly remember the great trappers and trackers that would hang around Old Camp Seismo. There's definitely been a shift in the plate tectonics, and these two lands are know merged into one (un)common market. With apologies to Dave Mills for the second paragraph, /rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net.  Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU 19 Jul 88 11:04:02 EDT Received: from beno.CSS.GOV by seismo.CSS.GOV (5.59/1.14) id AA09430; Tue, 19 Jul 88 11:03:24 EDT Received: by beno.CSS.GOV (5.59/5.17) id AA16812; Tue, 19 Jul 88 11:03:23 EDT Date: Tue, 19 Jul 88 11:03:23 EDT From: rick@seismo.CSS.GOV (Rick Adams) Message-Id: <8807191503.AA16812@beno.CSS.GOV> To: header-people@mc.lcs.mit.edu, palo-alto!vixie@decwrl.dec.com Subject: Re: mixed addresses If you parse site!user%site2 the same as site!user@site2 your mailer is broken and should be fixed. user%site2 is a local part of the uucp address just as much as it would be the local part of the @ style address  Received: from GUNTER-ADAM.ARPA (TCP 3200200015) by MC.LCS.MIT.EDU 19 Jul 88 11:16:46 EDT Date: 19 Jul 1988 07:01:03 CDT Subject: Mailing List maintenance From: dsdc-sdt2@GUNTER-ADAM.ARPA To: header-people-request@MC.LCS.MIT.EDU cc: header-people@MC.LCS.MIT.EDU I know I am going to get chastised for my addresses & cc's, but I have about had it. I have tried at least 7 times over the past 8 months, that's right, 8 months, to get my name off the HEADER-PEOPLE mailing list. I've tried to send to the -REQUEST address with no luck, then to the community address, equally with no luck, and had to suffer the wrath of all who read my simple request. Well, I'm going to try again, and probably have to suffer flame after flame about sending the request to the main list, but I don't really care anymore. My simple request: Remove me from the Header-People mailing list. That's all, nothing more. -------  Received: from sonora.dec.com (TCP 20013200464) by MC.LCS.MIT.EDU 19 Jul 88 16:51:44 EDT Received: from volition.dec.com by sonora.dec.com (5.54.4/4.7.34) id AA17927; Tue, 19 Jul 88 10:54:13 PDT Received: from localhost by volition.dec.com (5.54.4/4.7.34) id AA00931; Tue, 19 Jul 88 10:54:22 PDT Message-Id: <8807191754.AA00931@volition.dec.com> To: rick@seismo.css.gov (Rick Adams) Cc: header-people@mc.lcs.mit.edu Subject: Re: mixed addresses In-Reply-To: Your message of Tue, 19 Jul 88 11:03:23 -0400. <8807191503.AA16812@beno.CSS.GOV> Date: Tue, 19 Jul 88 10:54:17 PDT From: Paul A Vixie Rick Adams writes: # If you parse site!user%site2 the same as site!user@site2 your # mailer is broken and should be fixed. Agreed. But that's not what I do. % has a lower precedence than !, which has a lower precedence than @. So a!b!c = b!c@a = a!c%b = c%b@a.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Jul 88 18:33:31 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 19 Jul 88 12:26:14 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 18 Jul 88 18:30:13 GMT From: trwrb!ucla-an!stb!michael@bloom-beacon.mit.edu (Michael) Organization: STB BBS, La, Ca, Usa, +1 213 459 7231 Subject: Who is munging mailbox names with the site name? Message-Id: <10481@stb.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu This is something I've seen occasionally, and I'd really like to find out who's doing it. Notice that this started as being sent to bsu-cs!holleman, and was finally send to bsu!hollemstb. My site is stb; it seems that the last few letters were replaced by my sitename. >From hodge!uunet!iuvax!bsu-cs!MAILER-DAEMON Fri Jul 15 02:12:14 1988 remote from denwa Received: by denwa.UUCP (smail2.5) id AA02078; 15 Jul 88 02:12:14 PDT (Fri) Received: by hodge.cts.com (smail2.5) id AA02126; 15 Jul 88 00:00:59 PDT (Fri) Received: from iuvax!bsu-cs.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA03479; Fri, 15 Jul 88 02:33:51 EDT Received: by rutgers.edu (5.59/1.15) with UUCP id AA10403; Fri, 15 Jul 88 02:02:01 EDT Received: from bsu-cs by iuvax.cs.indiana.edu (5.54/1.5) with UUCP id AA18308; Thu, 14 Jul 88 03:12:14 EST Received: by bsu-cs.UUCP (5.51/UUCP-Project/rel-1.0/05-27-87) id AA21150; Thu, 14 Jul 88 01:31:43 EST Date: Thu, 14 Jul 88 01:31:43 EST From: uunet!iuvax!bsu-cs!MAILER-DAEMON (Mail Delivery Subsystem) Subject: Returned mail: User unknown Message-Id: <8807140631.AA21150@bsu-cs.UUCP> To: hodge!denwa!stb!michael ----- Transcript of session follows ----- 550 hollemstb... User unknown ----- Unsent message follows ----- Received: by bsu-cs.UUCP (5.51/UUCP-Project/rel-1.0/05-27-87) id AA21148; Thu, 14 Jul 88 01:31:45 EST Received: from uiucdcs.UUCP by uunet.UU.NET (5.59/1.14) with UUCP id AA09641; Tue, 12 Jul 88 21:04:04 EDT Received: by a.cs.uiuc.edu (UIUC-5.52/9.7) id AA04599; Tue, 12 Jul 88 13:26:27 CDT Received: from rutgers by iuvax.cs.indiana.edu (5.54/1.5) with UUCP id AA24769; Tue, 12 Jul 88 13:25:13 EST From: Received: by rutgers.edu (5.59/1.15) with UUCP id AA15113; Tue, 12 Jul 88 14:14:08 EDT Received: by sol.cs.rochester.edu (3.2/j) id AA06993; Tue, 12 Jul 88 12:15:57 EDT Received: by XN.LL.MIT.EDU; Tue, 12 Jul 88 07:19:57 EDT Posted-Date: Tue, 12 Jul 88 03:13:16 PDT Received: by oberon.USC.EDU (5.59/5.5) id AA26060; Tue, 12 Jul 88 04:13:13 PDT Received: by sdcrdcf.sm.unisys.com (smail2.5) id AA28048; 12 Jul 88 03:28:17 PDT (Tue) Received: by trwrb (5.51/1.36) id AA27510; Tue, 12 Jul 88 03:21:39 PDT Received: by ucla-an.ANES (5.51/5.17) id AA17785; Tue, 12 Jul 88 03:13:16 PDT Date: Tue, 12 Jul 88 03:13:16 PDT Message-Id: <8807121013.AA17785@ucla-an.ANES> To: bsu-cs!holleman Subject: Re: Modules #2 Date: Sat Jul 2 04:39:39 1988 To: ucla-an!trwrb!sdcrdcf!oberon!ll-xn!mit-eddie!bloom-beacon!tut.cis.ohio-state.edu!mailrus!iuvax!bsu-cs!holleman Subject: Re: Modules #2 Newsgroups: rec.games.frp In-Reply-To: <3315@bsu-cs.UUCP> Organization: STB BBS, La, Ca, Usa, +1 213 459 7231 Cc: : --- : Michael Gersten uunet.uu.net!denwa!stb!michael : sdcsvax!crash!gryphon!denwa!stb!michael : What would have happened if we had lost World War 2. Well, the west coast : would be owned by Japan, we would all be driving foreign cars, hmm...  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 20 Jul 88 16:14:04 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 20 Jul 88 16:02:04 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 20 Jul 88 19:34:36 GMT From: ukma!david@husc6.harvard.edu (David Herron -- One of the vertebrae) Organization: U of Kentucky, Mathematical Sciences Subject: Re: mixed addresses Message-Id: <10015@e.ms.uky.edu> References: <8807142016.dusip.andrew@stl.stc.co.uk>, <3503@palo-alto.DEC.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Paul, neither rfc822 nor rfc976 specify that % does what the %-hack do. In fact, both specify other methods to do routing. That means, both specs expect the local-part to only be paid attention to by the 'local' machine, not by machines along the route. In: user%a@some.dom.ain and some!long!path!with!a%percent the local part *shouldn't* be evaluated until it reaches the destination. In the '@' case, until it reaches some.dom.ain, and the '!' case until it reaches 'with'. Whatever either of those places wishes to do with a local-part like "a%b" is up to them BECAUSE IT IS NOT SPECIFIED BY EITHER SPEC! Now, I didn't read your posting very closely and it's possible that you said exactly that in your posting. But I think I caught a few statements to the otherwise. Oh, I suppose the next question is what to do with some!long!path!a%b@some.dom.ain RFC976 is the applicable spec. (according to rfc822, the "some!long!path!a%b" is *all* local part and get's evaluated according to some.dom.ain's rules for evaluating such things). The rfc recommends first that mailers not use mixed adresses internally, instead preferring something like some.dom.ain!some!long!path!a%b or some!long!path!some.dom.ain!a%b but if you must, to treat such an address as in rfc822 -- the local part is the local part and isn't evaluated until it reaches some.dom.ain (i.e. the "some.dom.ain!some!long!path!a%b" interpretation -- effectively) It's right there in the specs in black&white (or purple&brown with the right toner/paper combination ...) -- <---- David Herron -- The E-Mail guy <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- A misplaced Kansan trapped in the heart of Kentucky, <---- the state where it is now illegal to water your lawn on the wrong day.  Received: from ALMSA-1.ARPA (TCP 3200200075) by MC.LCS.MIT.EDU 22 Jul 88 11:19:54 EDT Received: from almsal by 0.ALMSA-1.ARPA id aa11863; 22 Jul 88 10:13 CDT Date: Fri, 22 Jul 88 9:40:32 CDT From: Will Martin -- AMXAL-RI To: header-people@MC.LCS.MIT.EDU Subject: Gateway info What is the "best" (most reliable, main, default, whatever) gateway to BITNET from the ARPA/MILNET? I want to be able to give generic instructions to my user community to say that, "whenever you have an address ending in 'BITNET', you will construct a reply address in this format: user%hostname.BITNET@" So far, I have some recent message traffic showing the following options for that ARPA host: CUNYVM.CUNY.EDU CORNELLC.CCS.CORNELL.EDU MITVMA.MIT.EDU I've been using the CUNYVM address; is one of the others, or another one entirely, better? Is there some place this sort of info is stored for easy retrieval, and where it is kept up-to-date when things change? Regards, Will Martin  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 22 Jul 88 14:19:28 EDT Date: Fri, 22 Jul 88 14:18:58 EDT From: "Michael A. Patton" Subject: Gateway info To: wmartin@ALMSA-1.ARPA cc: header-people@MC.LCS.MIT.EDU In-reply-to: Msg of Fri 22 Jul 88 9:40:32 CDT from Will Martin -- AMXAL-RI Message-ID: <416912.880722.MAP@AI.AI.MIT.EDU> All three of the machines you listed are real Internet/Bitnet gateways in full operation. I believe the CUNYVM.CUNY.EDU machine is supposed to be preferred, but I'm not completely sure, you might also pick the one that's closest to you by the network. If you support MX domain records in your mailer, they should (but may not always?) do some redirection, not on the .BITNET form of the name but on the real domain form of name. Perhaps you should ask the BITNET people (I'm afraid I don't have an address handy, perhaps someone else will supply it or you could ask Postmaster@BITNIC.BITNET I think, or Postmaster at one of the gateway machines).  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Jul 88 11:10:44 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 27 Jul 88 11:04:20 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 26 Jul 88 08:12:18 GMT From: mcvax!ukc!stl!scott@uunet.uu.net (Mike Scott) Organization: STL,Harlow,UK. Subject: Re: mixed addresses Message-Id: <796@acer.stl.stc.co.uk> References: <8807142016.dusip.andrew@stl.stc.co.uk>, <3503@palo-alto.DEC.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <3503@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: >But, um, has anybody got users on their systems with "%" as part of the >user identifier? Probably a few, but vastly: no. But it's not just user identifiers... consider a system where mail is being gatewayed on a VMS machine between the un*x world and the DEC foreign mail interface which uses a % character in the address to define the interface - for example, mail from PSS has the address prefix "PSI%", which can wreak some havoc when replied to by the unwary! -- Regards. Mike Scott (scott@stl.stc.co.uk ...uunet!mcvax!ukc!stl!scott) phone +44-279-29531 xtn 3133.  Received: from hplabs.HP.COM (TCP 1777610007) by MC.LCS.MIT.EDU 1 Aug 88 16:57:24 EDT Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Mon, 1 Aug 88 12:55:48 PST Received: from hplkab.HPL.HP.COM by hplms2.HP.COM; Mon, 1 Aug 88 13:55:29 pdt Received: by hplkab.HPL.HP.COM; Mon, 1 Aug 88 13:55:12 pdt Date: Mon, 1 Aug 88 13:55:12 pdt From: Karen Bradley Message-Id: <8808012055.AA10139@hplkab.HPL.HP.COM> To: header-people@mc.lcs.mit.edu, netinfo%garnet.Berkeley.EDU@violet.berkeley.edu, uflorida!usfvax2!jc3b21!byers@gatech.edu Subject: Re: LOOKING FOR PATHS Cc: postmaster@hplabs.hp.com You can send to Beth Scannell as "beth_scannell%01%hp1800@hplabs.hp.com" Sorry for the delay in replying to this message. thanks, Karen Bradley Hewlett-Packard Laboratory  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 2 Aug 88 15:40:07 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 2 Aug 88 15:26:17 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Aug 88 16:49:04 GMT From: glacier!jbn@labrea.stanford.edu (John B. Nagle) Organization: Stanford University Subject: "X-" blithering Message-Id: <17601@glacier.STANFORD.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu The X mail system (is this part of X windows?) seems to indulge in heavy self-promotion. Is all the following, taken from incoming mail, necessary? It has little value to the recipient. X-To: DYNSYS-L%UNCVM1.bitnet@jade.berkeley.edu X-Mailer: Elm [version 1.5b] X-Mailer: Elm [version 1.5d] X-Origin: The Portal System (TM) X-Possible-Reply-Path: Ed_Eric_Mitchell@cup.portal.com X-Possible-Reply-Path: mslater@cup.portal.com X-Possible-Reply-Path: sun!portal!cup.portal.com!Ed_Eric_Mitchell X-Possible-Reply-Path: sun!portal!cup.portal.com!mslater X-St-Vmsmail-To: MIPL3::ST%"jbn@glacier.stanford.edu",RGD059 X-St-Vmsmail-To: ST%"jbn@glacier.STANFORD.EDU",RGD059 X-St-Vmsmail-To: ST%"jbn@glacier.stanford.edu" X-Vms-To: IN%"jbn@glacier.STANFORD.EDU" John Nagle  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 2 Aug 88 16:19:29 EDT Return-Path: Received: from dagda.think.com by Think.COM; Tue, 2 Aug 88 16:12:07 EDT Received: by dagda.think.com; Tue, 2 Aug 88 16:14:36 EDT Date: Tue, 2 Aug 88 16:14:36 EDT Message-Id: <8808022014.AA05977@dagda.think.com> From: Robert L. Krawitz Sender: rlk@Think.COM To: glacier!jbn@labrea.stanford.edu Cc: header-people@mc.lcs.mit.edu In-Reply-To: <17601@glacier.STANFORD.EDU> Subject: "X-" blithering This has nothing to do with the X Window System, nor does it have anything to do with self-promotion. Rather, it is the standard for user-supplied headers (i. e. headers other than the standard defined headers). I believe that RFC822 specifies that these non-standard headers should be prefixed by "X-" to protect against future definition of these headers by any other RFC. When reporting bug reports in someone else's name, I frequently use an X-From: rlk field to indicate that I was the one writing the message. Of course, X-Mailer, X-Origin, etc. can be self-promotional, but the content of the field is what counds, not the name. harvard >>>>>> | Robert Krawitz bloom-beacon > |think!rlk topaz >>>>>>>> . rlk@a.HASA.disorg  Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 2 Aug 88 17:08:30 EDT Received: by INFOODS id <000001F7081@INFOODS.MIT.EDU> ; Tue, 2 Aug 88 16:57:10 EST Date: Tue, 2 Aug 88 16:53:16 EST From: John C Klensin Subject: RE: "X-" blithering To: glacier!jbn@LABREA.STANFORD.EDU X-VMS-Mail-To: EXOS%"glacier!jbn@labrea.stanford.edu" Message-ID: <880802165316.000001F7081@INFOODS.MIT.EDU> cc: header-people@MC.LCS.MIT.EDU Blithering, yes, "X" no. The X windows system, and its relatives, are not at fault. What is at fault is some severe excess on the part of a UA or user, together with a rule in RFC822 that says that, if you are going to invent headers that future versions of the standard are not going to conflict with, start them with "X-". The best way to deal with this sort of clutter is with a UA on your end that is able to censor them before you need to see them. Failing that, I'd consider unfriendly acts against the sender if that were in my power. Better, however, "X-MY-MOTHERS-NAME:" than simply "MY-MOTHERS-NAME:" if that is the choice.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 Aug 88 07:10:22 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 3 Aug 88 07:05:36 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Aug 88 10:18:16 GMT From: helios.ee.lbl.gov!lace.lbl.gov!dagg@nosc.mil (Darren Griffiths) Organization: Lawrence Berkeley Laboratory, Berkeley Subject: Re: "X-" blithering Message-Id: <601@helios.ee.lbl.gov> References: <17601@glacier.STANFORD.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <17601@glacier.STANFORD.EDU> jbn@glacier.STANFORD.EDU (John B. Nagle) writes: > > The X mail system (is this part of X windows?) seems to indulge in >heavy self-promotion. Is all the following, taken from incoming mail, >necessary? It has little value to the recipient. > Things in a mail header that have an "X-" flag are mailer independant. This means that anything that starts with "X-" was put in by some mailer somewhere, either as a comment or to pass commands specifically interpretted by that mailer, and they are ignored by all other mailers. I believe that this is the only way to add lines to the header that is supported as part of the standard, all lines that don't begin with "X-" have to do with real information that is documented in RFC822. It's a little hard to tell what everything below is doing without looking at the complete header of the message, but most of the things are comments. > X-To: DYNSYS-L%UNCVM1.bitnet@jade.berkeley.edu I'm not sure where this came from, maybe some strange IBM system on BITNET. > X-Mailer: Elm [version 1.5b] > X-Mailer: Elm [version 1.5d] Says that the mail went through the Elm mailer (twice), mainly comments. > X-Origin: The Portal System (TM) Free advertisments for the Portal System. > X-Possible-Reply-Path: Ed_Eric_Mitchell@cup.portal.com > X-Possible-Reply-Path: mslater@cup.portal.com > X-Possible-Reply-Path: sun!portal!cup.portal.com!Ed_Eric_Mitchell > X-Possible-Reply-Path: sun!portal!cup.portal.com!mslater All semi useful stuff from portal listing possible return paths. I believe this is actually put in by Elm, but it is not used any mailers I know of, it has to be interpreted by a human. There are basically two return paths listed, one via a domain-ised internet and one via uucp. I believe that the two different versions of the address are just aliases for the same person. If the entire world used the domain based systems then this would certainly be unnecessary, and even with things the way they are it shouldn't be required if all sites in the intervening path builds the return address correctly. > X-St-Vmsmail-To: MIPL3::ST%"jbn@glacier.stanford.edu",RGD059 > X-St-Vmsmail-To: ST%"jbn@glacier.STANFORD.EDU",RGD059 > X-St-Vmsmail-To: ST%"jbn@glacier.stanford.edu" These three lines come from the Software Tools Mailer (yeah!!!) running under VMS, with mail sent from VMSmail (yuch) into the Software Tools system. > X-Vms-To: IN%"jbn@glacier.STANFORD.EDU" This alse comes from VMS, someone sent the mail from VMSmail into a TCP/IP based mailer. I believe this one looks like Excelans's. --darren ------------------------------------------------------------------------------- Darren Griffiths DAGG@LBL.GOV Lawrence Berkeley Labs Information and Computing Sciences Division  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 Aug 88 11:25:29 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 3 Aug 88 11:19:52 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Aug 88 14:51:27 GMT From: ron@topaz.rutgers.edu (Ron Natalie) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: "X-" blithering Message-Id: References: <17601@glacier.STANFORD.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu You're joking, right? This has little to do with X windows. It looks like ELM turds. Remember the X- construct from RFC822.  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 3 Aug 88 12:24:02 EDT Date: Wed, 3 Aug 1988 12:17 EDT Message-ID: From: Rob Austein To: header-people@MC.LCS.MIT.EDU Subject: "X-" blithering In-reply-to: Msg of 3 Aug 1988 06:18-EDT from helios.ee.lbl.gov!lace.lbl.gov!dagg@nosc.mil (Darren Griffiths) "X-" is simply an escape sequence to allow implementers to invent their own mail headers legally, without having to get prior approval from the Header Czar. In practice X- headers tend to be used logging information generated for debugging purposes, but it doesn't have to be the mailer that's doing this. Eg, at MIT we have a replicated user database system called INQUIR, with daemons running on participating machines communicating with each other via email to well-known addresses. The TOPS-20 implementation of this system (HOLMES/WATSON) inserts a header X-Generated-By: Holmes@machine-name to make it easier to track down problems. There is nothing forbidding a user or a user's mail composition program from inserting X- headers directly, although it probably doesn't occur to most users as a useful thing to do. Agreed that mail/news reader programs should provide a facility for removing extraneous headers. TOPS-20 MM and several mail readers of the EMACS family provide this. My current list of censored headers follows this message; note how few of the headers in question follow the spec (ie, are either defined in RFC822 or use the "X-" prefix). --Rob [Address] [Acknowledge-Receipt] [Acknowledge-To] [Address] [Also-known-as] [AKA] [Approved] [Article-I.D.] [Backward-References] [BB-Posted] [BBoard-ID] [Character-Type-Mappings] [Company] [CompuServe-Address] [Delivery-By] [Distribution] [DTN] [Emacs] [Expiration-Date] [Expires] [Favorite-Beer] [Favorite-Expression] [Fonts] [Fortran] [Forum-Transaction] [Forward-References] [Full-Name] [Gateway] [Geographic-Location] [Home-Phone] [Identifier] [Home] [In-Real-Life] [In-Reply-To] [Keywords] [Length] [Lines] [Location] [Mail-From] [Mail-Stop] [May-Qotm] [MCIMail-Address] [Message-ID] [Moon] [Msg] [Network-Address(es)] [News-Category] [News-From] [News-Path] [News-Priority] [News-Source] [News-Type] [Nf-ID] [Office-Location] [Office-Phone] [Office] [Office_Phone] [Organisation] [Organization] [Origin] [Other_Electronic_Address] [Path] [Phase-Of-Moon] [Phase-Of-The-Moon] [Phone-Number] [Phone] [Ponder] [Pony_Express_Address] [Postal-Address] [Postal_Address] [Posting-Version] [Precedence] [Random-Quote] [Rank] [Rcvd-Date] [Real-Name] [Received] [References] [Regarding] [Relay-Version] [ReplyTo] [Resent-Message-Id] [Return-Path] [Song] [Source-Info] [SRI-International] [Staff] [Start-Date] [State-Of-Mind] [Status] [Summary-Line] [Summary] [Supersedes] [Telephone] [Telex] [Tel] [Title] [Transaction-Entered-By] [U.S.-Mail-Addrs] [US-Mail] [USMail [USMailAddress] [UUCP-Address] [UUCP-Path] [UUCP] [Via] [Whether] [Word-of-the-day] [Work-Phone-Number] [Work-Phone] [Work] [X-Location] [X-Mailer] [X-Phone] [X-Postal-Address] [X-VMS-To] [Xref] [Zippy-says] [Zippy]  Received: from Sun.COM (TCP 1201600002) by MC.LCS.MIT.EDU 3 Aug 88 13:07:15 EDT Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0) id AA26659; Wed, 3 Aug 88 10:04:31 PDT Received: from Ecd.Sun.COM (suneast) by snail.sun.com (4.0/SMI-4.0) id AA07703; Wed, 3 Aug 88 10:05:10 PDT Received: from hinode.ecd.sun.com by Ecd.Sun.COM (3.2/SMI-3.2) id AA15739; Wed, 3 Aug 88 13:16:32 EDT Received: by hinode.ecd.sun.com (4.0/SMI-4.0) id AA02632; Wed, 3 Aug 88 13:04:18 EDT Date: Wed, 3 Aug 88 13:04:18 EDT From: suneast!hinode!geoff@Sun.COM (Geoff Arnold @ Sun ECD - R.H. coast near the top) Message-Id: <8808031704.AA02632@hinode.ecd.sun.com> To: header-people@MC.LCS.MIT.EDU Subject: Re: "X-" blithering >From sun!@MC.LCS.MIT.EDU:SRA@XX.LCS.MIT.EDU Wed Aug 3 12:53:24 1988 >To: header-people@MC.LCS.MIT.EDU >Subject: "X-" blithering >[...] >Agreed that mail/news reader programs should provide a facility for >removing extraneous headers. TOPS-20 MM and several mail readers of >the EMACS family provide this. My current list of censored headers >follows this message; note how few of the headers in question follow >the spec (ie, are either defined in RFC822 or use the "X-" prefix). > >--Rob This is why in PC-NFS LifeLine Mail I decided to have the user specify the headers s/he DID want to see (with sensible selections available from a menu). :-) Geoff  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 Aug 88 16:40:47 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 3 Aug 88 16:23:52 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Aug 88 19:00:09 GMT From: diamond.bbn.com!mlandau@bbn.com (Matt Landau) Organization: BBN Systems and Technologies Corporation, Cambridge, MA Subject: Re: "X-" blithering Message-Id: <11387@jade.BBN.COM> References: <17601@glacier.STANFORD.EDU>, <601@helios.ee.lbl.gov>, <14977@oddjob.UChicago.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In comp.mail.headers, matt@oddjob.UChicago.EDU writes: >The point is not "What does it mean?" but rather "What the hell good >is it?" I think most of the "X-" headers ever used are useless The most useful X- header I've seen is X-Content-Type, an unofficial way of doing the Content-Type: header that Marvin Sirbu has proposed as an extension to 822 for mail systems capable of accepting and displaying different message types (text, PostScript, Andrew message format, Diamond encoded multimedia format, etc.) On the other hand, X-Zippy-Quote-of-the-Day is at least amusing once in a while, and X-Return-Path can be a useful hint to a USER saddled with a brain-dead mailer, whereas X-Mailer is just annoying.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 Aug 88 16:40:58 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 3 Aug 88 16:13:53 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Aug 88 16:19:44 GMT From: matt@oddjob.uchicago.edu (Ka Kahula) Organization: If you worked here you'd go home by now Subject: Re: "X-" blithering Message-Id: <14977@oddjob.UChicago.EDU> References: <17601@glacier.STANFORD.EDU>, <601@helios.ee.lbl.gov> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu The point is not "What does it mean?" but rather "What the hell good is it?" I think most of the "X-" headers ever used are useless and were probably inserted for someone's own fun or for, as jbn suggests, self-promotion. The "X-Mailer" headers are the ones the really get my dander up, but even worse than these are the one or two dweebs out there who insert "Precedence: special-delivery" into every message they send! They know who they are ... ________________________________________________________ Matt Crawford matt@oddjob.uchicago.edu  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 Aug 88 16:55:28 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 3 Aug 88 16:37:55 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Aug 88 17:19:34 GMT From: glacier!jbn@labrea.stanford.edu (John B. Nagle) Organization: Stanford University Subject: Re: "X-" blithering Message-Id: <17605@glacier.STANFORD.EDU> References: <17601@glacier.STANFORD.EDU>, <601@helios.ee.lbl.gov> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <601@helios.ee.lbl.gov> dagg@lbl.gov (Darren Griffiths) writes: >Things in a mail header that have an "X-" flag are mailer independant. Shouldn't this be "mailer dependent"? Incidentally, some new examples of advertising have arrived. X-Mailer: MMDF/Ream version 4.12 (The Choice for a New Generation) X-Subliminal-Message: Send me all your money My point is that this may be getting out of hand. But it will probably get worse for a while, and then some sites will start trimming headers during forwarding. John Nagle  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 Aug 88 18:40:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 3 Aug 88 18:13:26 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Aug 88 23:57:09 GMT From: munnari!ditmela!george@uunet.uu.net (George michaelson) Organization: CSIRO Division of Information Technology, Australia Subject: Re: "X-" blithering Message-Id: <1988@ditmela.oz> References: <17601@glacier.STANFORD.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu From article <17601@glacier.STANFORD.EDU>, by jbn@glacier.STANFORD.EDU (John B. Nagle): > > The X mail system (is this part of X windows?) seems to indulge in > heavy self-promotion. Is all the following, taken from incoming mail, > necessary? It has little value to the recipient. > > X-To: DYNSYS-L%UNCVM1.bitnet@jade.berkeley.edu Gentle flame. Read the standard, X- is the RFC822 extension mechanism. it allows mail systems to add fields into the message header for end-to-end (well, I suppose other people/things could use it) purposes. -value is in the eye of the beholder. your mail system (and mine) may balk a little on these fields, but it should not barf. It is in the standard to ignore them. Elm clearly offers some enhanced functionality. apologies to mail-gurus if this is wrong/to late. -george -- George Michaelson, CSIRO Division of Information Technology ACSnet: G.Michaelson@ditmela.oz Phone: +61 3 347 8644 Postal: CSIRO, 55 Barry St, Carlton, Vic 3053 Oz Fax: +61 3 347 8987  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 Aug 88 18:41:04 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 3 Aug 88 18:10:36 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Aug 88 18:15:10 GMT From: decuac!jetson!john@umd5.umd.edu (John Owens) Organization: SMART HOUSE Limited Partnership Subject: Re: "X-" blithering Message-Id: <85@jetson.UUCP> References: <17601@glacier.STANFORD.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu > The X mail system (is this part of X windows?) seems to indulge in > heavy self-promotion. Is all the following, taken from incoming mail, > necessary? It has little value to the recipient. The "X-" stuff has nothing to do with a "X mail system"; RFC822 specifies that non-standard headers should begin with an "X-" to avoid conflict with any future defined headers. The following are from a variety of mail systems: > X-To: DYNSYS-L%UNCVM1.bitnet@jade.berkeley.edu From a bitnet gateway at berkeley (UREP) > X-Mailer: Elm [version 1.5b] > X-Mailer: Elm [version 1.5d] From two different versions of Elm. > X-Origin: The Portal System (TM) > X-Possible-Reply-Path: Ed_Eric_Mitchell@cup.portal.com > X-Possible-Reply-Path: sun!portal!cup.portal.com!Ed_Eric_Mitchell From "portal", trying to let the recipient know possibile reply addresses, since addresses passing through uucp land are likely to become unrecognizable. > X-St-Vmsmail-To: MIPL3::ST%"jbn@glacier.stanford.edu",RGD059 > X-St-Vmsmail-To: ST%"jbn@glacier.STANFORD.EDU",RGD059 > X-St-Vmsmail-To: ST%"jbn@glacier.stanford.edu" One VMS mail system showing what addresses the VMS user sent mail to, before they were converted to "normal" addresses. > X-Vms-To: IN%"jbn@glacier.STANFORD.EDU" The same, from another VMS mail system. -- John Owens john@jetson.UPMA.MD.US SMART HOUSE L.P. uunet!jetson!john (old uucp) +1 301 249 6000 john%jetson.uucp@uunet.uu.net (old internet)  Received: from zooks.ads.com (TCP 20071217620) by MC.LCS.MIT.EDU 3 Aug 88 19:44:37 EDT Received: by zooks.ads.com (5.59/1.11) id AA24271; Wed, 3 Aug 88 14:55:26 PDT Date: Wed, 3 Aug 88 14:55:26 PDT From: Jordan Hayes Message-Id: <8808032155.AA24271@zooks.ads.com> To: header-people-request@mc.lcs.mit.edu Subject: PLEASE TAKE ME OFF THIS LIST!!!!! Cc: header-people@mc.lcs.mit.edu [ sorry, the list moderator has once again gone to sleep and ignored all 12 of my messages ... someone please slap him/her upside the head or put the list on a machine where the SMTP MTA allows you to do an EXPN and would allow me to call the person on the telephone ... sheesh, you would think that since this is a mailing list *about e-mail* that the *-request alias would work ... grrr ... ] Thanks. /jordan  Received: from rutgers.edu (TCP 20001412411) by MC.LCS.MIT.EDU 4 Aug 88 00:51:54 EDT Received: by rutgers.edu (5.59/1.15) with UUCP id AA01060; Wed, 3 Aug 88 22:37:40 EDT Received: by mimsy.UMD.EDU (smail2.5) id AA05944; 3 Aug 88 22:33:50 EDT (Wed) Received: by cvl.umd.edu (5.54/4.7) id AA17076; Wed, 3 Aug 88 22:10:34 EDT Received: by decuac.dec.com (1.2/smail2.2/03-11-87) id AA05189; Wed, 3 Aug 88 10:22:35 edt Received: from cube.cos.com by cos.com (3.2/smail2.2/04-17-87) id AA16820; Tue, 2 Aug 88 17:18:33 EDT Received: by cube.cos.com (3.2/smail2.2/04-17-87) id AA00871; Tue, 2 Aug 88 17:17:14 EDT Date: Tue, 2 Aug 88 17:17:14 EDT From: cvl!mgrant@mimsy.umd.edu (Michael Grant) Message-Id: <8808022117.AA00871@cube.cos.com> To: glacier!jbn@labrea.stanford.edu Cc: header-people@mc.lcs.mit.edu In-Reply-To: (John B. Nagle's message of 2 Aug 88 16:49:04 GMT <17601@glacier.STANFORD.EDU> Subject: "X-" blithering The X-stuff is used for User-Defined-Fields within an RFC822 mail header. It has nothing to do with X-windows at all. -Mike Grant  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 Aug 88 06:10:39 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 4 Aug 88 05:54:14 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Aug 88 20:34:33 GMT From: sco!stewarta@uunet.uu.net (Stewart I. Alpert) Organization: The Santa Cruz Operation, Inc. Subject: Re: "X-" blithering Message-Id: <723@viscous> References: <17601@glacier.STANFORD.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <17601@glacier.STANFORD.EDU> jbn@glacier.STANFORD.EDU (John B. Nagle) writes: > > The X mail system (is this part of X windows?) seems to indulge in >heavy self-promotion. Is all the following, taken from incoming mail, >necessary? It has little value to the recipient. > > The X-whatever headers are not from any single system. There is an RFC-822 convention that allows [programs|sites|people|etc] to add their own headers by proceeding them with 'X-'. This assures that RFC-822 compliant mailers won't confuse these with 'officially' defined headers. These headers may or may not have any value to the recipient (or sender for that matter). :-) ***************************************************************************** Internet: stewarta@sco.COM UUCP: {uunet,ucbvax!ucscc,decvax!miscosoft}!sco!stewarta  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 Aug 88 06:40:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 4 Aug 88 06:22:01 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 3 Aug 88 15:06:25 GMT From: attcan!utgpu!jarvis.csri.toronto.edu!neat.ai.toronto.edu!lamy@uunet.uu.net (Jean-Francois Lamy) Organization: Department of Computer Science, University of Toronto Subject: Re: "X-" blithering Message-Id: <88Aug3.094652edt.66@neat.ai.toronto.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Resonable mail user interfaces allow you to filter whatever you consider to be blithering. X-whatever headers are defined in RFC-822 to be extensions to the standard set. Mailers on Symbolics lisp machines, for example, use such headers to document what the control sequences in the messages mean, so that the recipient can see the italics the sender put in. Other purported uses would be documenting the encoding format of a message (e.g. uuencoded), so that a co-operative mail user agent knew how to deal with them. As to the infamous X-Mailer: ..., consider it to be gratuitous publicity, just like having your car dealer's sticker on your car. My mail set-up zonks that one into oblivion. The X-VMS-To: header is actually useful if you have to deal with the brain-dead mailer that DEC gives with VMS: the interpretation of the % sign is radically different than the usual subsitution for "@", and is a signal that you are probably asking for trouble if you trust the mailer provided return address. All in all, no, there is absolutely no link with X. Jean-Francois Lamy lamy@ai.utoronto.ca, uunet!ai.utoronto.ca!lamy AI Group, Department of Computer Science, University of Toronto, Canada M5S 1A4  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 4 Aug 88 16:40:46 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 4 Aug 88 16:33:01 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 4 Aug 88 17:08:30 GMT From: amdahl!bungia!datapg!viper!dave@ames.arpa (David Messer) Organization: Lynx Data Systems, Eagan, MN Subject: Re: "X-" blithering Message-Id: <1214@viper.Lynx.MN.Org> References: <17601@glacier.STANFORD.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <17601@glacier.STANFORD.EDU> jbn@glacier.STANFORD.EDU (John B. Nagle) writes: > > The X mail system (is this part of X windows?) seems to indulge in >heavy self-promotion. Is all the following, taken from incoming mail, >necessary? It has little value to the recipient. > > X-To: DYNSYS-L%UNCVM1.bitnet@jade.berkeley.edu ... > X-Vms-To: IN%"jbn@glacier.STANFORD.EDU" > > John Nagle Read RFC 822. Header fields beginning with "X-" are gauranteed to not conflict with the standard or future versions of the standard. (They are standard, non-standard fields ;-) -- If you can't convince | David Messer - (dave@Lynx.MN.Org) them, confuse them. | Lynx Data Systems -- Harry S Truman | | amdahl --!bungia!viper!dave | hpda / Copyright 1988 David Messer -- All Rights Reserved This work may be freely copied. Any restrictions on redistribution of this work are prohibited.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 6 Aug 88 03:26:26 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 6 Aug 88 03:21:42 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 6 Aug 88 06:13:40 GMT From: palo-alto!vixie@decwrl.dec.com (Paul Vixie) Organization: DEC Western Research Lab Subject: Real data to support my claim that '-d sun' is the way to go. Message-Id: <3703@palo-alto.DEC.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu [ By the way, I'm sure Sun is grateful for my decision. They pass an awful lot of mail for free there, and they don't need my traffic at all. ] I ran a test tonight to see how Sun.COM's MTA was behaving. The results are unsurprising. I sent three messages from my home machine, vixie.UUCP, to myself on decwrl.dec.com. I used this path in all three: pacbell!sun!decwrl!vixie. I edited the messages in the UUCP spool directory before they were sent to pacbell, so I could try several different "From:" lines. The original text of the "From:" line is duplicated in the "Subject:" line -- luckily, Sun.COM does _not_ rewrite "Subject:" lines -- yet :-). Note that in all three cases, the "Return-Path:" header has the correct contents. (For those not in the know, Return-Path: is where MH puts the UUCP From_ line.) A value of "sun!pacbell!vixie!paul" is correct because this is in fact an exact reverse of the route the message took to get here. Note also that the "To:" line is in its original form, which is correct. Many MTAs incorrectly strip their own name out of the To: header; one can probably assume that if "sun!" had been on the front of the "To:" value, it would have been stripped. Since it was hiding behind a "pacbell!", it was safe. :::::::::::::: inbox/140 :::::::::::::: Return-Path: sun!pacbell!vixie!paul Received: from SUN.COM by decwrl.dec.com (5.54.5/4.7.34) id AA17907; Fri, 5 Aug 88 20:33:51 PDT Received: from sun.Sun.COM by Sun.COM (4.0/SMI-4.0) id AA11577; Fri, 5 Aug 88 20:31:54 PDT Received: from pacbell.UUCP by sun.Sun.COM (4.0/SMI-4.0) id AA07135; Fri, 5 Aug 88 20:35:22 PDT Received: by vixie.UUCP (5.51++/smail2.3/02-18-87) id AA12696; Fri, 5 Aug 88 19:12:47 PDT Message-Id: <8808060212.AA12696@vixie.UUCP> To: pacbell!sun!decwrl!vixie Subject: test, From: line in @ notation (From: paul@vixie.uu.net) Date: Fri, 05 Aug 88 19:12:42 PDT From: Paul A Vixie --- This first one is replyable, though for a strange reason. decwrl would send it to "sun!" who would see "vixie.uu.net!" and say "ah, uunet.uu.net is the MX for *.uu.net, so I'll send it to uunet.uu.net who will deliver it further." The message didn't come through uunet to get to decwrl; why should it have to go back that way? If decwrl were running a passive router, the message would still have to go to "sun!" since passive routers (as I define the term) will only route to the first host/domain in a path. Perhaps hosts like Sun.COM are the reason why hosts like Rutgers.EDU exist? (Rutgers is an active rerouter, it will start on the right end of a path and route to the first thing it recognizes; this is evil and rude, as I explained yesterday). :::::::::::::: inbox/141 :::::::::::::: Return-Path: sun!pacbell!vixie!paul Received: from SUN.COM by decwrl.dec.com (5.54.5/4.7.34) id AA17905; Fri, 5 Aug 88 20:33:51 PDT Received: from sun.Sun.COM by Sun.COM (4.0/SMI-4.0) id AA11571; Fri, 5 Aug 88 20:31:48 PDT Received: from pacbell.UUCP by sun.Sun.COM (4.0/SMI-4.0) id AA07126; Fri, 5 Aug 88 20:35:15 PDT Received: by vixie.UUCP (5.51++/smail2.3/02-18-87) id AA12667; Fri, 5 Aug 88 19:09:42 PDT Message-Id: <8808060209.AA12667@vixie.UUCP> To: pacbell!sun!decwrl!vixie Subject: test, From: line in @ notation (From: paul@vixie.UUCP) Date: Fri, 05 Aug 88 19:09:37 PDT From: Paul A Vixie --- This message is unreplyable. This is why I have "-d sun" in my makepaths script. I can't fault Sun.COM for rewriting u@h.UUCP to h!u since they mean the same thing; adding "sun!" to the front of the result is just plain wrong and there is no modern defense for the practice. :::::::::::::: inbox/142 :::::::::::::: Return-Path: sun!pacbell!vixie!paul Received: from SUN.COM by decwrl.dec.com (5.54.5/4.7.34) id AA17906; Fri, 5 Aug 88 20:33:51 PDT Received: from sun.Sun.COM by Sun.COM (4.0/SMI-4.0) id AA11574; Fri, 5 Aug 88 20:31:52 PDT Received: from pacbell.UUCP by sun.Sun.COM (4.0/SMI-4.0) id AA07131; Fri, 5 Aug 88 20:35:19 PDT Received: by vixie.UUCP (5.51++/smail2.3/02-18-87) id AA12677; Fri, 5 Aug 88 19:10:23 PDT Message-Id: <8808060210.AA12677@vixie.UUCP> To: pacbell!sun!decwrl!vixie Subject: test, From: line in ! notation (From: vixie!paul) Date: Fri, 05 Aug 88 19:10:20 PDT From: Paul A Vixie --- See comments from #141. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 6 Aug 88 08:24:18 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 6181; Sat, 06 Aug 88 08:21:46 EDT Received: from UMass (CURRAN) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6179; Sat, 06 Aug 88 08:21:44 EDT Received: from Mars.UCC.UMass.EDU by UMass (outbound name server) with BSMTP; 6 Aug 88 08:23:35 EDT Message-ID: <8808060814322C2.AARD@Mars.UCC.UMass.EDU> (UMass-Mailer 4.04) Date: Sat, 6 Aug 88 08:20:55 EDT From: Curran%UMASS.BITNET@MITVMA.MIT.EDU (John Curran) Subject: Removal/Suppession of header fields To: header-people@mc.lcs.mit.edu As authoer of a UA, I am curious about the feature that several people have describing where the UA does not display certain fields in the header to the user. My questions are: Does this occur only on display of a message, or during delivery? If it is during delivery, what about "mailboxes" that are read by groups of people ('public mail') Send reponses directly to me; I will summarize and post if relevent. Thanks John Curran  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 Aug 88 11:56:47 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 7 Aug 88 11:42:45 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 5 Aug 88 04:14:45 GMT From: hpl-opus!hpccc!hp-sde!hpfcdc!hpfclp!diamant@hplabs.hp.com (John Diamant) Organization: HP SDE, Fort Collins, CO Subject: Re: "X-" blithering Message-Id: <7260007@hpfclp.SDE.HP.COM> References: <17601@glacier.STANFORD.EDU> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu > The X mail system (is this part of X windows?) seems to indulge in > heavy self-promotion. Is all the following, taken from incoming mail, > necessary? It has little value to the recipient. > > X-To: > X-Mailer: > X-Origin: > X-Possible-Reply-Path: > X-St-Vmsmail-To: > X-Vms-To: There is no such thing as the "X mail system." There are mailers that run under the X Window System (xmh, for instance) but they have nothing to do with these headers. The "X-" prefix is specified by the mail standards (RFC822, I think) for any header which is not official. In other words, if your mailer wants to put a header on a message that isn't a supported header, it should preceed the name by "X-." You may still choose to argue that the headers are useless, but I would disagree in at least some cases (X-Mailer, for instance). However, any mail user interface worth its salt will hide these headers unless you ask to see them, so it really is a moot point. John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 Aug 88 12:56:55 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 7 Aug 88 12:46:48 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 7 Aug 88 16:35:57 GMT From: ukma!david@gatech.edu (David Herron -- One of the vertebrae) Organization: U of Kentucky, Mathematical Sciences Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-Id: <10139@g.ms.uky.edu> References: <3703@palo-alto.DEC.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <3703@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: >I ran a test tonight to see how Sun.COM's MTA was behaving. The results >are unsurprising. Yeah, but none of the results came up with vixie!paul@sun.com like you claimed it would ... hmmm I'm not real sure how the mail got from sun to decwrl. In all the cases the Received: line has full.domain.names for both sun and decwrl, something which I assume would happen only when it's being delivered over the internet. But the From: and To: lines are in bang format, something I would expect for mail delivered over a uucp link. Perhaps sun is putting a sun.com in the From_ lines of uucp mail? Oh, MH may put uucp routes into Return-Path:. What it's *really* for is in the SMTP protocol, for recording the path the message took through the network. When a message arrives at some place with SMTP you add your own hostname to the Return-Path: line. So, in the general case, Return-Path: means the return-path in the 'envelope'. For UUCP mail the 'envelope' is the From_ line(s) and the command line given to rmail. (forward-path). >Return-Path: sun!pacbell!vixie!paul >Subject: test, From: line in @ notation (From: paul@vixie.uu.net) >From: Paul A Vixie > >--- >This first one is replyable, though for a strange reason. decwrl would send >it to "sun!" who would see "vixie.uu.net!" and say "ah, uunet.uu.net is the >MX for *.uu.net, so I'll send it to uunet.uu.net who will deliver it >further." The message didn't come through uunet to get to decwrl; why >should it have to go back that way? Why are you surprised at this? Maybe you haven't read rfc976? Though I'd be surprised if you hadn't. Anyway, this is a classic case of garbage-in garbage-out. You told it to do something (i.e. that you're part of the uu.net domain) so it's merely doing the right thing for what it knows. If you were to advertise in the uucp maps that you are the gateway for vixie.uu.net, AND your mailer is ready to accept vixie.uu.net as an alias for itself, THEN sun would know some path which merely went through the bay area and would reach you. >Return-Path: sun!pacbell!vixie!paul >Subject: test, From: line in @ notation (From: paul@vixie.UUCP) >From: Paul A Vixie > >--- >This message is unreplyable. This is why I have "-d sun" in my makepaths >script. I can't fault Sun.COM for rewriting u@h.UUCP to h!u since they >mean the same thing; adding "sun!" to the front of the result is just >plain wrong and there is no modern defense for the practice. If they are running a passive re-router then it would be replyable. I do not know what they are running, but passive re-routing (to use your terms) is simple to put up -- even under sendmail :-) -- and does wonders for the usability of the system. I agree that simply prepending sun! to a From: line is *wrong*. emory used to (still does?) get this very wrong ... They'd prepend emory! to the beginning of From: & To: lines which went out via uucp. So we'd end up with messages From: emory!speck@arizona.edu (I forget the exact address, but it was Don Speck I think ...). -- <---- David Herron -- The E-Mail guy <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- <---- Looking forward to a particularly blatant, talkative and period bikini ...  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 Aug 88 17:26:48 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 7 Aug 88 17:19:27 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 7 Aug 88 19:43:28 GMT From: killer!wisner@ames.arpa (Bill Wisner) Organization: HASA Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-Id: <5124@killer.DALLAS.TX.US> References: <3703@palo-alto.DEC.COM>, <10139@g.ms.uky.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu According to RFC822, the Return-Path header is added by the final mailer that delivers the message to its recipient. It's supposed to contain definitive information about the route back to the originator. It's not supposed to appear in a message until the very end of that message's travels. It's not supposed to be added to as a message wends its way through the network. The only MTS I know of that handles this correctly is Smail 3.1, which puts a copy of the From_ line into a Return-Path line if a message is being delivered by the "local" transport. There is a compile-time option to MH that makes it transform From_ lines into Return-Path lines.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 Aug 88 19:11:57 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 7 Aug 88 19:04:21 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 7 Aug 88 22:36:59 GMT From: palo-alto!vixie@decwrl.dec.com (Paul Vixie) Organization: DEC Western Research Lab Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-Id: <3721@palo-alto.DEC.COM> References: <3703@palo-alto.DEC.COM>, <10139@g.ms.uky.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <10139@g.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: # In article <3703@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: # >Return-Path: sun!pacbell!vixie!paul # >Subject: test, From: line in @ notation (From: paul@vixie.uu.net) # >From: Paul A Vixie # > # >--- # >This first one is replyable, though for a strange reason. decwrl would send # >it to "sun!" who would see "vixie.uu.net!" and say "ah, uunet.uu.net is the # >MX for *.uu.net, so I'll send it to uunet.uu.net who will deliver it # >further." The message didn't come through uunet to get to decwrl; why # >should it have to go back that way? # # Why are you surprised at this? Maybe you haven't read rfc976? Though # I'd be surprised if you hadn't. Anyway, this is a classic case of # garbage-in garbage-out. You told it to do something (i.e. that you're # part of the uu.net domain) so it's merely doing the right thing for # what it knows. Nope. If something comes in from the outside in user@dom.ain format, RFC82{1/2} says that the "dom.ain" part must be registered with the NIC. Therefore it makes no sense to rewrite into "sun!dom.ain!user" UNLESS THE MESSAGE IS GOING INSIDE SUN'S INTERNAL NETWORK and even then it's of questionable value. user@dom.ain is replayable on its own, I tell you! RFC82{1/2} _demands_ that it be replyable on its own. One could charitably assume that Sun.COM sees the bang-path in the "To:" or envelope recipient and decides that it is gatewaying between two different networks -- except that the message _came in_ from the same network it would be leaving on: UUCP. What's actually going on is that Sun.COM doesn't run IDA or any other variant of Sendmail that lets you rewrite the envelope differently than you rewrite the headers. They don't see this problem as important enough to justify the extra headache of not doing unto the "From:" line as they do to the "From_" line. Pfaa. I obviously disagree. I could almost make a case for them rewriting "vixie!paul" into "sun!vixie!paul" since the next site in the path might not know what "vixie!" means. But they could at least see if Sun.COM (itself!) knows what "vixie!" means, since they are _mandating_ that the reply come back through them. # >Return-Path: sun!pacbell!vixie!paul # >Subject: test, From: line in @ notation (From: paul@vixie.UUCP) # >From: Paul A Vixie # > # >--- # >This message is unreplyable. This is why I have "-d sun" in my makepaths # >script. I can't fault Sun.COM for rewriting u@h.UUCP to h!u since they # >mean the same thing; adding "sun!" to the front of the result is just # >plain wrong and there is no modern defense for the practice. # # If they are running a passive re-router then it would be replyable. # I do not know what they are running, but passive re-routing (to use # your terms) is simple to put up -- even under sendmail :-) -- and # does wonders for the usability of the system. True, _if_ they ran a passive router, the message would be replyable and I would not be bitching as loudly as I am. They don't. The message is not replyable -- "sun!" bounces it on the way back through. Note that running a passive router doesn't make it okay to rewrite headers that don't belong to you; it just makes the crime less heinous (sp?). The only time when the header sender or recipient can be correctly rewritten is when the message is crossing the boundary between one network and another -- and that is decidedly not the case here. # I agree that simply prepending sun! to a From: line is *wrong*. The implication is that rewriting into a homogenous form and adding one's host name in that form would be okay -- and it's not. That is, rewriting vixie!paul into sun!vixie!paul or paul@vixie.uucp into paul%vixie@sun.com is no better than rewriting vixie!paul into vixie!paul@sun or paul@vixie.uucp into sun!paul@vixie.uucp In _neither_ case is it okay to mess around with the header addresses AT ALL. They can do this if the message is bound for BITNET or the inside of their own network; they cannot do this when the message is passing from one Internet site to another with Sun.COM as simply an intermediary. The assumption is that if it comes in over UUCP or is going out over UUCP then it's not Internet traffic. This is false. UUCP is one of several common transport mediums over with Internet mail can flow. So by all means, do unto the envelope sender and recipient what you must do to make the message palatable to the medium it's going out over. But please leave the header sender and recipients alone! (Unless you're a gateway, as I said.) -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 Aug 88 03:42:13 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 8 Aug 88 03:30:36 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 8 Aug 88 07:03:10 GMT From: ukma!david@husc6.harvard.edu (David Herron -- One of the vertebrae) Organization: U of Kentucky, Mathematical Sciences Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-Id: <10141@g.ms.uky.edu> References: <3703@palo-alto.DEC.COM>, <10139@g.ms.uky.edu>, <3721@palo-alto.DEC.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Paul, I think we really do agree (now that we've iterated the argument a couple of times) ... Possibly there's a slight disagreement over exactly when it's kosher to rewrite things and when it's not. But then the system I oversee *is* a gateway between uucp/bitnet/internet. I view my internal network as not being part of the internet and EVERY piece of mail which comes from the outside has to be converted to proper rfc82{2,1} format. But then MMDF makes that real nice to because it does such a good job at rewriting headers and keeping envelope information seperate from header information. I am curious why nobody from Sun is here defending their honor. Yoo Hoo! Anybody home at Sun? Anybody wanna defend their sendmail configuration there? I tried a test message to you at vixie!paul@sun.com just to see what would happen. Here's the result: Oh well. I had a higher opinion of the people at sun... A place that can make a >$1 billion company off of 4.3bsd (not to mention become a major player in the computer biz) *ought* to have better talent than this in their e-mail department. ] Received: from e.ms.uky.edu by g.ms.uky.edu id ad09659; 7 Aug 88 22:16 EDT ] Received: from sun.com by g.ms.uky.edu id aa26747; 7 Aug 88 11:13 EDT ] Received: from sun.Sun.COM by Sun.COM (4.0/SMI-4.0) ] id AA21400; Sun, 7 Aug 88 09:13:59 PDT ] Received: by sun.Sun.COM (4.0/SMI-4.0) ] id AA17601; Sun, 7 Aug 88 09:17:24 PDT ] Date: Sun, 7 Aug 88 09:17:24 PDT ] From: Mail Delivery Subsystem ] Subject: Returned mail: Host unknown ] Message-Id: <8808071617.AA17601@sun.Sun.COM> ] To: david@ms.uky.edu ] MMDF-Warning: Parse error in original version of preceding line at e.ms.uky.edu ] ] ----- Transcript of session follows ----- ] bad system name: vixie ] uux failed ( 68 ) ] 550 ... Host unknown ] ] ----- Unsent message follows ----- ] Return-Path: ] Received: from Sun.COM (sun-arpa) by sun.Sun.COM (4.0/SMI-4.0) ] id AA17599; Sun, 7 Aug 88 09:17:24 PDT ] Received: from g.ms.uky.edu ([128.163.128.7]) by Sun.COM (4.0/SMI-4.0) ] id AA21397; Sun, 7 Aug 88 09:13:47 PDT ] Date: Sun, 7 Aug 88 12:13:02 EDT ] From: David Herron E-Mail Hack ] To: sun!vixie!paul@ms.uky.edu ] Subject: this is a test ] Message-Id: <8808071113.aa04242@g.g.ms.uky.edu> ] ] to see if I can send mail to a supposedly unmailable route ] -- ] <---- David Herron -- The E-Mail guy ] <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET ] <---- ] <---- Looking forward to a particularly blatant, talkative and period bikini ... -- <---- David Herron -- The E-Mail guy <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- <---- Looking forward to a particularly blatant, talkative and period bikini ...  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 Aug 88 09:57:13 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 8 Aug 88 09:43:01 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 8 Aug 88 12:14:51 GMT From: tness7!texbell!ssbn!bill@bellcore.bellcore.com (Bill Kennedy) Organization: W.L. Kennedy Jr. and Associates, Pipe Creek, TX Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-Id: <221@ssbn.WLK.COM> References: <3703@palo-alto.DEC.COM>, <10139@g.ms.uky.edu>, <5124@killer.DALLAS.TX.US> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <5124@killer.DALLAS.TX.US> wisner@killer.DALLAS.TX.US (Bill Wisner) writes: >[ explanation of Return-Path According to RFC822 ] > >The only MTS I know of that handles this correctly is Smail 3.1, >which puts a copy of the From_ line into a Return-Path line if a >message is being delivered by the "local" transport. Has anyone seen smail 3.1? I was able to find 3.0 in killer's archives but it appears not to be any substantial change over 2.5. The dates and version numbers are the same as 2.5 anyway. This Return-Path looks like a nice new wrinkle. It also looks like something worth adding into the "reply" function of something like Berkeley mail. What are the new features of smail 3.1? Where can we get it? Is it worth having smail look for "Return-Path" instead of re-routing if the last site!user is the same as the one in the From:? Don't shudder too hard on the last one, I know the snake population and depth of that pit :-) -- Bill Kennedy usenet {killer,att,rutgers,sun!daver,uunet!bigtex}!ssbn!bill internet bill@ssbn.WLK.COM  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 Aug 88 18:57:18 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 8 Aug 88 18:42:17 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 8 Aug 88 05:14:28 GMT From: attcan!lsuc!ncrcan!ontenv!soley@uunet.uu.net (Norman S. Soley) Organization: Ontario Ministry of the Environment, Toronto Subject: Re: "X-" blithering (really X-Mailer) Message-Id: <660@ontenv.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu There's been a great deal of carping about the X-Mailer header that's floating around. I'll grant that right now these things are about as useful as a Royal Commission. But in time... One of the things that X-headers can be used for is to implement special features such as confirmation of reciept, encrypted mail, various content types and so on (please don't assume that I'm suggesting that all of these things are appropriate for the net, some, like confirmation of recipt, most definitely aren't, but I needed some examples). It's a reality that some of these features are going to end up being implemented differently in different user agents, at least until the dust settles. So the only way for a recieving ua to deal with a X-feature that could have multiple interpretations is to know what ua generated the message. So presto, by combining the X-Mailer and X-feature headers you're sure to get the right interpretation. Eventually of course RFC-822 will get supercede/updated to handle new features and then we can lose the X-Mailer stuff. As for the net.bad.citizenry of Portal's X-Orgin header... Well my Mother always told me If you can't say anything nice... -- Norman Soley - Data Communications Analyst - Ontario Ministry of the Environment UUCP: utgpu!ontmoh!------------\ VOICE: +1 416 323 2623 {attcan,utzoo}!lsuc!ncrcan!ontenv!norm "witty saying not available due to writers strike"  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 Aug 88 23:12:22 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 8 Aug 88 23:05:25 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Aug 88 00:58:29 GMT From: palo-alto!vixie@decwrl.dec.com (Paul Vixie) Organization: DEC Western Research Lab Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: <3732@palo-alto.DEC.COM> References: , <3674@palo-alto.DEC.COM>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu brisco@pilot.njin.net (Thomas Paul Brisco) writes: # What I mean by "all my routing" is all my routing. I only # have to say "rutgers!foo!user" and let the rutgers mail look # up the path to site foo. So, it literally does *all my routing*. (I # don't know how else to say it). This is only a demonstration of _passive routing_, which is a Good Thing according to me and is quite different from what Rutgers actually does. If I send mail to rutgers!foobar!user, knowing full well that "foobar" is not a neighbor of Rutgers but that Rutgers will find a route, this is all very nice and very convenient and NOT what I am yelling about. What Rutgers actually does is _RErouting_. Not _passive routing_. Passive routing is where you always look for a way to send the mail to the next hop in the path as you see it -- and it means finding a route IFF that "next hop" is not a direct UUCP neighbor or an alias for a directly reachable internet site. Rutgers, on the other hand, will find a route to just about anything it can find in the path, starting from the RIGHT. From the END. Therefore if I send a piece of mail to ...!rutgers!foo!bar!baz!user, knowing full well that "foo" is a directly reachable neighbor of Rutgers, I have no guarantee at all that Rutgers will actually send to "foo". It will look first for a way to get to "baz", then to "bar", then to "foo", then finally give up if it cannot find any of the above. THIS IS WRONG. It's an option in Smail, and I wish they'd never have included it. The only possible justification is for replies along news paths, which are very long and usually circuitous. However, if you have a mailer smart enough to look something up in a routing database, you should be using the "From:" or the "Reply-To:", not the "Path:". RN and readnews both have this option available. If you have neighbors who reply using the "Path:", then you gain yourself nothing by rerouting the mail -- the message is coming through your system no matter which direction is leaves. If you want to do your neighbors a favor, tell them to make you their "smart-host" in their smail/pathalias database and reconfigure their RN or readnews software to use "From:". This way, the replies will come to your system more-or-less _asking_ you to find a route for them. I'll say it again: rerouting an explicitly routed piece of mail is rude; the practice always causes more confusion and anguish in the long run than any of its doubtful benefits ever pay anyone back for. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 Aug 88 23:27:23 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 8 Aug 88 23:09:06 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Aug 88 01:40:12 GMT From: rose!nowicki@sun.com (Bill Nowicki) Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-Id: <63372@sun.uucp> References: <10139@g.ms.uky.edu>, <3721@palo-alto.DEC.COM>, <10141@g.ms.uky.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <10141@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes: > I am curious why nobody from Sun is here defending their honor. > Yoo Hoo! Anybody home at Sun? Anybody wanna defend their sendmail > configuration there? Sure, we are home, but only have time to deal with Usenet flames about once a week. Most time is spent supporting paying customers. :-) I realize that some people will NEVER be satisfied, but please try to understand the problem from both sides. We rewrite "From: sitename!user" into "From: sitename!user@Sun.COM" because we want to comply with the Internet standards for domain names. "sitename!user" is NOT a valid domain name, nor is "user@sitename.UUCP". The primary standard that we support is the domain name system, and if you use proper domain names then the From: line should not normally be touched. However, all our internal names are converted into domain format, and we have several gateways to the outside world to hide internal complexity, so sometimes even if it LOOKS like a message is sent from UUCP to UUCP, it often gets converted into domain format and then back out again. > I tried a test message to you at vixie!paul@sun.com just to see what > would happen. It is not suprising. We run standard (now System Vr3) UUCP software, and do not do any routing of UUCP names. So any mail to site!user@Sun.COM will only work if the site is a direct UUCP neighbor. I have requested that we be taken out of the "d.Top" file as a top-level domain router, in case that will help. We already forward several thousand mail messages per day between UUCP and the Internet, so would not mind at all the reduction in traffic. Unfortunately your claim that "all rewriting of From: lines is wrong" is not correct unless EVERYONE is doing UUCP routing. For example, consider: siteA --uucp--> sun --uucp--> siteB The From: line starts out as "From: siteA!user", and we rewrite it as "From: siteA!user@Sun.COM", which then gets rewritten going out as "From: sun!siteA!user". The flamers are saying this is "RUDE". But if we did NOT do it, then when the recipient at siteB replied to the message, it would fail unless siteB were running UUCP routing software. Since the standard UUCP software from AT&T (AND BERKELEY!!) DOES NOT support UUCP routing, this is usually not the case. Thus we try to be conservative, so that the recipient can reply if they do UUCP routing or not. Since almost all of our mail is either directly to us, or relayed through one hop, or relayed from all machines that rewrite the header (i.e. standard Sun-issue software), we chose to have a policy that causes these paths to generate replyable headers. As you discovered, if you are NOT a direct UUCP neighbor of Sun, but instead relay through a site that does NOT rewrite, e.g.: siteA --uucp--> siteB --uucp--> sun --Internet--> siteC Then our scheme breaks down. My response is that "siteB" is at fault, since it did not rewrite the From: line as "siteB!siteA!user". If it did, then replies would work fine. Another solution would be for siteA to use a different path to the Internet. We could just reject mail relayed through these "non-rewriting" sites, and just do it for neighbors. Of course, we could also install the UUCP routing software, but so far nobody has had the time to test, maintain, and document it. If you can convince AT&T or Berkeley to put it in their releases, it might help the situation. Remember: just because YOU might run UUCP routing software, it does not imply that everyone else is. -- Bill Nowicki Sun Microsystems (nothing official, of course, just personal opinions)  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 9 Aug 88 01:57:21 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 9 Aug 88 01:47:43 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Aug 88 03:57:45 GMT From: mailrus!emv@ohio-state.arpa (Edward Vielmetti) Organization: University of Michigan Computing Center, Ann Arbor Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: <622@mailrus.cc.umich.edu> References: <3732@palo-alto.DEC.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <3732@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: > >This is only a demonstration of _passive routing_, which is a Good Thing >according to me and is quite different from what Rutgers actually does. I dunno, Paul. When rutgers sends me mail, I know that it's going to get to the intended site, and they're not going to give me crap that's a reply to a news path article. You know, the 25-hop monsters that start in Denver Colorado and wend their way through 10 backbone sites (including yours) on their eventual way to some poor fool in Ohio. When rutgers routes mail through mailrus, I'm almost positive it will get to its intended recipient. Hey, someone's got to keep the maps sane, right? There's much more confusion and anguish to be had by having your mail end up on someone's small private workstation in Italy that happens to have the same name as your node, let me tell you. (peter, do you want to let loose pathparse on the unsuspecting? mailrus might not be a bad candidate.) --Ed  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 9 Aug 88 10:29:43 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 0060; Tue, 09 Aug 88 10:26:54 EDT Received: from UMass (SHORES) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0059; Tue, 09 Aug 88 10:26:53 EDT Received: from Mars.UCC.UMass.EDU by UMass (outbound name server) with BSMTP; 9 Aug 88 10:21:21 EDT Message-ID: <880809101819689.AAPQ@Mars.UCC.UMass.EDU> (UMass-Mailer 4.04) Date: Tue, 9 Aug 88 10:19:05 EDT From: Shores%UMASS.BITNET@MITVMA.MIT.EDU (Ken Shores) Subject: Confirmation of Recipt To: header-people@mc.lcs.mit.edu Norman Soley (attcan!lsuc!ncrcan!ontenv!soley@uunet.uu.net) writes: >One of the things that X-headers can be used for is to implement special >features such as confirmation of reciept, encrypted mail, various content >types and so on (please don't assume that I'm suggesting that all of these >things are appropriate for the net, some, like confirmation of recipt, >most definitely aren't, but I needed some examples). One of the "features" that I have been asked to add to our mail system on several occasions is a "confirmation of recipt". I am glad to hear that at least one other person thinks this is inappropriate. However, I am curious about what the general sentiment is. Is "confirm recipt" useful? Is it a good idea? How would you implement it, if it were? (i.e. when do you send a recipt, and what field and syntax would you use to indicate that one was desired?) Ken Shores UMass  Received: from seismo.CSS.GOV (TCP 30003106431) by MC.LCS.MIT.EDU 9 Aug 88 11:35:27 EDT Received: from beno.CSS.GOV by seismo.CSS.GOV (5.59/1.14) id AA10122; Tue, 9 Aug 88 11:33:17 EDT Received: by beno.CSS.GOV (5.59/5.17) id AA21468; Tue, 9 Aug 88 11:33:30 EDT Date: Tue, 9 Aug 88 11:33:30 EDT From: rick@seismo.CSS.GOV (Rick Adams) Message-Id: <8808091533.AA21468@beno.CSS.GOV> To: header-people@mc.lcs.mit.edu, mailrus!emv@ohio-state.ARPA Subject: Re: what do _YOU_ mean by "all routing"?? I don't like rerouting. I DO like "short circuiting". It solves the problem of the 20 hop Path: replies without really surprising anyone (except those doing loop tests). The idea is that you send the mail to the rightmost site in the path that you are DIRECTLY CONNECTED TO. It works almost as well as true rerouting without the surprises. --rick  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 9 Aug 88 11:57:39 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 9 Aug 88 11:48:34 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Aug 88 15:35:01 GMT From: ukma!david@ohio-state.arpa (David Herron -- One of the vertebrae) Organization: U of Kentucky, Mathematical Sciences Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-Id: <10145@g.ms.uky.edu> References: <3721@palo-alto.DEC.COM>, <10141@g.ms.uky.edu>, <63372@sun.uucp> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <63372@sun.uucp> nowicki%rose@Sun.COM (Bill Nowicki) writes: >In article <10141@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes: >> I am curious why nobody from Sun is here defending their honor. >> Yoo Hoo! Anybody home at Sun? Anybody wanna defend their sendmail >> configuration there? >Sure, we are home, but only have time to deal with Usenet flames about >once a week. Most time is spent supporting paying customers. :-) uh, well, goshy gee whillickers. I look around the cs dept and see a *few* Sun's so we must be paying customers ... hmmm. :-) We even have at least one of them nifty keano new and improved Sun 4's! (big) :-) (Not here in CS, but there is >=1 on campus) >Unfortunately your claim that "all rewriting of From: lines is wrong" >is not correct unless EVERYONE is doing UUCP routing. For example, >consider: > > siteA --uucp--> sun --uucp--> siteB I didn't claim that. This site rewrites From: lines all the time. If anybody claimed that it was Paul. Any claim I would have made is that if you're going to rewrite From: lines then DO IT RIGHT! >The From: line starts out as "From: siteA!user", and we rewrite it >as "From: siteA!user@Sun.COM", which then gets rewritten going out >as "From: sun!siteA!user". The flamers are saying this is "RUDE". >But if we did NOT do it, then when the recipient at siteB replied >to the message, it would fail unless siteB were running UUCP routing >software. Since the standard UUCP software from AT&T (AND BERKELEY!!) >DOES NOT support UUCP routing, this is usually not the case. Thus we >try to be conservative, so that the recipient can reply if they do >UUCP routing or not. Since almost all of our mail is either directly >to us, or relayed through one hop, or relayed from all machines >that rewrite the header (i.e. standard Sun-issue software), we chose >to have a policy that causes these paths to generate replyable headers. It sounds to me as if the short version is this paragraph is We run primitive software! Nyahh! Nyahh! Look. Communications is important. One of the large reasons for the existance of the computers we have *here* (at UK) is for e-mail with colleagues. I suspect that any site which takes part in Usenet also would like to have a good e-mail system. As would most other places where you guys sell computers. Saying that standard software doesn't do good e-mail is not a good excuse. For one thing I was under the impression that you guys were going to be able to make some strong influences on the next version of the Standard Software. Tho' that was described as putting BSD features in -- like the fast file system and some other niceties... Be that as it may. How are things to improve if a major player is saying "we won't improve things"? I, a customer speaking here, would love to see you guys (not just Sun but AT&T, BSD, DEC, etc) to provide capable e-mail software with your systems. One *really* *GOOD* way of testing the e-mail software before letting your customers at it is to run it in house in a production environment for awhile. I once defended Sun's honor to a DEC salesman who was claiming that DEC had far better communications capabilities than Sun did. I knew fully well that Sun has all sorts of capabilities and that it's the equal of the capabilities in VMS. At least, give each their intended environment (DECNET || INTERNET) and they'll have equivalent capabilities. But now that I see this attitude I'm not so sure. At least with DEC's "primary" OS they deliver a mailer that can route mail world-wide ... :-) (sort of) >[Just because you're running UUCP routing software doesn't mean > everyone is ...] To which I say .... *SO*??? Now. Don't take me wrong. I'm mostly happy with the Sun equipment we have. It's good reasonable stuff. The software is a little strange sometimes, but then every company puts out strange stuff sometimes. I just want to see the world improve is all. -- <---- David Herron -- The E-Mail guy <---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <---- <---- Looking forward to a particularly blatant, talkative and period bikini ...  Received: from OFFICE-8.ARPA (TCP 3202400200) by MC.LCS.MIT.EDU 9 Aug 88 12:12:13 EDT Date: 9 Aug 88 09:04 PDT From: William Daul / McAir / McDonnell-Douglas Corp Subject: Re: Confirmation of Recipt To: Shores%UMASS.BITNET@MITVMA.MIT.EDU (Ken Shores) Cc: header-people@mc.lcs.mit.edu Message-ID: In-reply-to: <880809101819689.AAPQ@Mars.UCC.UMass.EDU> (UMass-Mailer 4.04) Acknowledge-receipt: Requested Message: Ken, Augment has two types of acknowledgments. You can ask the system to acknowledge the delivery of the message to a user's mailbox and/or you can ask the user to send you a acknowledgment of the message. Having the system confirmation only tells you it was delivered...not if it was read. And if the recipient sends you a confirmation you might suspect that it may have been read. I find a confirmation/acknowledgment assuring...it lets me know my mail was "put into a mailbox" somewhere. --Bi(( p.s. I added a Acknowledge-reciept field in this message as a example.  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 9 Aug 88 12:41:10 EDT Return-Path: Received: from dagda.think.com by Think.COM; Tue, 9 Aug 88 12:41:32 EDT Received: by dagda.think.com; Tue, 9 Aug 88 12:35:27 EDT Date: Tue, 9 Aug 88 12:35:27 EDT Message-Id: <8808091635.AA03322@dagda.think.com> From: Robert L. Krawitz Sender: rlk@Think.COM To: header-people@mc.lcs.mit.edu In-Reply-To: <880809101819689.AAPQ@Mars.UCC.UMass.EDU> (UMass-Mailer 4.04) Subject: Confirmation of Recipt Date: Tue, 9 Aug 88 10:19:05 EDT From: Shores%UMASS.BITNET@mitvma.mit.edu (Ken Shores) Norman Soley (attcan!lsuc!ncrcan!ontenv!soley@uunet.uu.net) writes: ...some, like confirmation of recipt, >most definitely aren't, but I needed some examples). One of the "features" that I have been asked to add to our mail system on several occasions is a "confirmation of recipt". I am glad to hear that at least one other person thinks this is inappropriate. However, I am curious about what the general sentiment is. Is "confirm recipt" useful? Is it a good idea? How would you implement it, if it were? I don't use this too often, but when I need it, I NEED it. Sometimes I need to make sure that a message is received by a particular individual, or I need to debug someone's mailer when it seems to be dropping things on the floor. Sendmail, at least, supports a Return-receipt-to: header. If I insert this field, sendmail will send me a bounce message with subject: return receipt. Of course :-) x-return-receipt-to: would be better... One obvious problem with this is that you can't conveniently use it to debug part of a mailing list, since you'll get return receipts for everybody on the list. Another one is that you can't ask everybody along a path for a receipt, to debug a long chain of uucp addresses. This has no (effective) parallel in the snail.usa domain because routing between physical post offices isn't something that the user ever finds out about (and in any event, USSnail postmasters are supposed to be pretty good at trying to track things down, a lot of postmasters on the network never respond to mail, and a fair number of postmaster addresses fail!) harvard >>>>>> | Robert Krawitz bloom-beacon > |think!rlk topaz >>>>>>>> . rlk@a.HASA.disorg  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 9 Aug 88 14:57:37 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 9 Aug 88 14:25:44 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Aug 88 17:44:10 GMT From: zodiac!zooks!jordan@ames.arpa (Jordan Hayes) Organization: Advanced Decision Systems, Mt. View, CA (415) 960-7300 Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-Id: <5120@zodiac.UUCP> References: <10145@g.ms.uky.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu David Herron writes: Look. Communications is important. Clearly. /jordan  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 9 Aug 88 18:13:59 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 9 Aug 88 16:58:56 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Aug 88 18:35:47 GMT From: killer!wisner@eddie.mit.edu (Bill Wisner) Organization: HASA Subject: Sun definitely doesn't know how to rewrite From: lines Message-Id: <5151@killer.DALLAS.TX.US> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I performed my own test today. My mail leaves this site with the following From line: From: Bill Wisner My first step was to find a neighbor that left my From line untouched. I addressed a message to mit-eddie!killer!wisner and it came back with the same From line it started with. OK. Good enough. I then sent mail to texsun!sun!eddie.mit.edu!killer!wisner. This path does leave two sites as possible culprits, but it's all the same company. This message arrived looking like this: From: Bill Wisner Revolting. Any self-respecting mailer will think that my account is on texsun. killer.dallas.tx.us is completely valid and has MX records (but no A record). It seems that Sun's idea of a 'valid host' is one that it can find an address for. By sending my mail through Sun I pretty much destroy any chance that I might get replies. While we're on the subject of revolting mailer behavior, might I add that texsun appends a CR to every line of every message it passes through? I think I'm going to go add "-d sun" now.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 9 Aug 88 19:57:39 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 9 Aug 88 19:19:40 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Aug 88 22:11:29 GMT From: psuhcx!wcf@psuvax1.psu.edu (Bill Fenner) Organization: Penn State University Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-Id: <327@psuhcx.psu.edu> References: <3721@palo-alto.DEC.COM>, <10141@g.ms.uky.edu>, <63372@sun.uucp> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <63372@sun.uucp> nowicki%rose@Sun.COM (Bill Nowicki) writes: |In article <10141@g.ms.uky.edu>, david@ms.uky.edu (David Herron -- One of the vertebrae) writes: |> I am curious why nobody from Sun is here defending their honor. |> Yoo Hoo! Anybody home at Sun? Anybody wanna defend their sendmail |> configuration there? | |Sure, we are home, but only have time to deal with Usenet flames about |Unfortunately your claim that "all rewriting of From: lines is wrong" |is not correct unless EVERYONE is doing UUCP routing. For example, |consider: | | siteA --uucp--> sun --uucp--> siteB | |The From: line starts out as "From: siteA!user", and we rewrite it |as "From: siteA!user@Sun.COM", which then gets rewritten going out |as "From: sun!siteA!user". The flamers are saying this is "RUDE". |But if we did NOT do it, then when the recipient at siteB replied |to the message, it would fail unless siteB were running UUCP routing |software. Since the standard UUCP software from AT&T (AND BERKELEY!!) |DOES NOT support UUCP routing, this is usually not the case. Thus we |try to be conservative, so that the recipient can reply if they do |UUCP routing or not. Since almost all of our mail is either directly |to us, or relayed through one hop, or relayed from all machines |that rewrite the header (i.e. standard Sun-issue software), we chose |to have a policy that causes these paths to generate replyable headers. The From_ line behaviour is exactly what he is describing. Unfortunately, applying From_ line behaviour to From: lines mess things up badly. | |As you discovered, if you are NOT a direct UUCP neighbor of Sun, |but instead relay through a site that does NOT rewrite, e.g.: | | siteA --uucp--> siteB --uucp--> sun --Internet--> siteC | |Then our scheme breaks down. My response is that "siteB" is at fault, |since it did not rewrite the From: line as "siteB!siteA!user". If it No, but it most likely rewrote the From_ line as siteB!siteA!user. I have yet to see a host that improperly rewrote (or didn't rewrite) the From_ line. The From_ line *should* have an accurate indication of the path the message took and how to get back where it came from, unless it goes through a host like psuvax1 which breaks the From_ line. By the From_ line I mean the line that says From wcf (date) remote from psuhcx Bill -- Bitnet: wcf@psuhcx.bitnet Bill Fenner | Internet: wcf@hcx.psu.edu | This space UUCP: {gatech,rutgers}!psuvax1!psuhcx!wcf | for rent Fido: Sysop at 263/42 |  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Aug 88 03:57:50 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 10 Aug 88 03:02:37 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 10 Aug 88 00:12:40 GMT From: cwjcc!hal!ncoast!allbery@gatech.edu (Brandon S. Allbery) Organization: Cleveland Public Access UN*X, Cleveland, Oh Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: <12134@ncoast.UUCP> References: <3732@palo-alto.DEC.COM>, <622@mailrus.cc.umich.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu As quoted from <622@mailrus.cc.umich.edu> by emv@mailrus.cc.umich.edu (Edward Vielmetti): +--------------- | In article <3732@palo-alto.DEC.COM> vixie@palo-alto.DEC.COM (Paul Vixie) writes: | >This is only a demonstration of _passive routing_, which is a Good Thing | >according to me and is quite different from what Rutgers actually does. | | Hey, someone's got to keep the maps sane, right? There's | much more confusion and anguish to be had by having your | mail end up on someone's small private workstation in Italy | that happens to have the same name as your node, let me | tell you. +--------------- I hate to say it, Ed, but you just argued against active rerouting. You see, if the little box in Italy is on the maps but yours isn't, rutgers will ignore the explicit path directing it to your system, in the name of active rerouting, and send the bugger to Italy! In a passive rerouting system, this can only happen when the path to your little box isn't specified. In active rerouting, it will *always* happen; the site in the maps gets highest priority and unregistered sites that have the same name as registered sites are unreachable even if a path is explicitly specified. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Aug 88 07:42:50 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 10 Aug 88 07:32:27 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Aug 88 16:21:23 GMT From: att!whuts!whutt!mike@bloom-beacon.mit.edu (BALDWIN) Organization: AT&T Bell Laboratories Subject: Confusion of mail "standards" Message-Id: <3735@whutt.UUCP> References: <10139@g.ms.uky.edu>, <3721@palo-alto.DEC.COM>, <63372@sun.uucp> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu > siteA --uucp--> siteB --uucp--> sun --Internet--> siteC > > Then our scheme breaks down. My response is that "siteB" is at fault, > since it did not rewrite the From: line as "siteB!siteA!user". But you say that siteB is a UUCP site. Vanilla UUCP sites do NOT rewrite From: lines. They rewrite From_ lines (only). We have (at least) two mail standards here. Vanilla UUCP has *only* From_ lines and bang syntax. No From:, no To:, no domains. The Internet has RFC-822 and domains, and no From_ and no bangs. Unfortunately, some mail software wants to treat UUCP mail as Internet mail. Berkeley mail (aka mailx), for example, puts To: and Cc: lines in mail, explicitly NOT in RFC-822 format (no commas, no @ signs). If this is dumped into a UUCP network, you reply to the author by using the From_ line, and you reply to the To: and Cc: recipients by prepending the author's path to the To: and Cc: addresses (you can reliably reduce symmetric paths). You can consider the mailx To: headers to be another kind of standard. It's not clean or pretty, but it does work. To fix it, UUCP mailers would have to rewrite all header lines AT EVERY HOP just like they rewrite From_ lines now. But they don't. Anyway, my system uses UUCP mail plus mailx with the above reply scheme. It works within our network pretty well. The problems start when I get mail from a system that rewrites headers. I can't tell, looking at the mail message, who rewrote it where. Please, when injecting mail into a network, conform to its standards. -- Michael Scott Baldwin research!mike attmail!mike mike@att.com AT&T Bell Laboratories +1 201 386 3052  Received: from MCC.COM (TCP 1200600076) by MC.LCS.MIT.EDU 10 Aug 88 20:58:18 EDT Received: from BRAHMA.ACA.MCC.COM (BRAHMA.ACA.MCC.COM.#Chaos) by MCC.#Chaos with Chaos/SMTP; Wed 10 Aug 88 19:56:21-CDT Date: Wed, 10 Aug 88 19:55 CDT From: David Vinayak Wallace Subject: "Communications is important." To: David Herron -- One of the vertebrae cc: header-people@mc.lcs.mit.edu In-Reply-To: <10145@g.ms.uky.edu> Message-ID: <880810195543.8.GUMBY@BRAHMA.ACA.MCC.COM> Date: 9 Aug 88 15:35:01 GMT From: ukma!david@ohio-state.arpa (David Herron -- One of the vertebrae) I suspect that any site which takes part in Usenet also would like to have a good e-mail system. Especially once they tried using uucp, as this much-too-long discussion shows.  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Aug 88 22:58:02 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 10 Aug 88 22:47:42 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 11 Aug 88 02:37:44 GMT From: honey@umix.cc.umich.edu (Peter Honeyman) Organization: Center for Information Technology Integration, Univ of Michigan Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: <4300@umix.cc.umich.edu> References: <3732@palo-alto.DEC.COM>, <622@mailrus.cc.umich.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Edward Vielmetti writes: >peter, do you want to let loose pathparse on the unsuspecting? ed, not really. you can take it from ~honey/down/src/pathparse on citi, but my experience with pathparse was 1) too much administrative overhead maintaining the database, and 2) i don't trust the data enough to wire pathparse into an mta in rerouting mode. (from this, you can infer my opinion of agressive routing in an mta using pathalias.) i used pathparse in my ua for a few years (motf has hooks for both pathparse and pathalias), but find that pathalias suffices and is easier to maintain. but go ahead and experiment. peter ps: made for a nice paper, though ...  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 11 Aug 88 11:58:25 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 11 Aug 88 11:49:29 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 11 Aug 88 14:17:43 GMT From: l.cc.purdue.edu!cik@k.cc.purdue.edu (Herman Rubin) Organization: Purdue University Statistics Department Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: <866@l.cc.purdue.edu> References: <676@bacchus.DEC.COM>, <881@vsi1.UUCP>, <3732@palo-alto.DEC.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <3732@palo-alto.DEC.COM>, vixie@palo-alto.DEC.COM (Paul Vixie) writes: < brisco@pilot.njin.net (Thomas Paul Brisco) writes: < # What I mean by "all my routing" is all my routing. I only < # have to say "rutgers!foo!user" and let the rutgers mail look < # up the path to site foo. So, it literally does *all my routing*. (I < # don't know how else to say it). < > This is only a demonstration of _passive routing_, which is a Good Thing > according to me and is quite different from what Rutgers actually does. > > If I send mail to rutgers!foobar!user, knowing full well that "foobar" is > not a neighbor of Rutgers but that Rutgers will find a route, this is all > very nice and very convenient and NOT what I am yelling about. > > What Rutgers actually does is _RErouting_. Not _passive routing_. > > Passive routing is where you always look for a way to send the mail to the > next hop in the path as you see it -- and it means finding a route IFF that > "next hop" is not a direct UUCP neighbor or an alias for a directly > reachable internet site. > > Rutgers, on the other hand, will find a route to just about anything it can > find in the path, starting from the RIGHT. From the END. Therefore if I > send a piece of mail to ...!rutgers!foo!bar!baz!user, knowing full well that > "foo" is a directly reachable neighbor of Rutgers, I have no guarantee at > all that Rutgers will actually send to "foo". It will look first for a way > to get to "baz", then to "bar", then to "foo", then finally give up if it > cannot find any of the above. THIS IS WRONG. > > It's an option in Smail, and I wish they'd never have included it. The only > possible justification is for replies along news paths, which are very long > and usually circuitous. However, if you have a mailer smart enough to look > something up in a routing database, you should be using the "From:" or the > "Reply-To:", not the "Path:". RN and readnews both have this option available. > > If you have neighbors who reply using the "Path:", then you gain yourself > nothing by rerouting the mail -- the message is coming through your system > no matter which direction is leaves. If you want to do your neighbors a > favor, tell them to make you their "smart-host" in their smail/pathalias > database and reconfigure their RN or readnews software to use "From:". This > way, the replies will come to your system more-or-less _asking_ you to find > a route for them. > > I'll say it again: rerouting an explicitly routed piece of mail is rude; the > practice always causes more confusion and anguish in the long run than any > of its doubtful benefits ever pay anyone back for. > -- > Paul Vixie > Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP > Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul > Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013 I use email a fair amount, both directly and in replying to news articles. Each network has its idiosyncracies, and they are incompatible. Also, I am not a systems person, and I feel I should not have to work so hard to send and receive mail. As it is, I have to edit the To: lines of most of the replies to news articles (all uucp addresses, due to a local mailing situation). Some of the time, I do not know if an address is uucp or inet; I must treat them differently. I have had quite a bit of mail bounce. Paul is absolutely right about "smart" mailers. Others posting responses to this article have complained, and rightly so, about taking a uucp ! path and affixing an inet @ site to it. Such a path cannot correctly get out of a uucp site. So what is the answer? An answer which has been proposed before is the use of parentheses, or some such equivalent. Only the site facing a ( is allowed to look into the parenthetical expression. Thus Paul could enclose the tail of his path, which he does want Rutgers to break into, in parentheses. An inet site could put the uucp ! path into parentheses, and I could use it directly for a return address without having to mung it. There was a situation in which my wife, mainly using a different machine, wished to make a direct reply. This was worked around. With parentheses, it would have been trivial. A hierarchical address scheme, with each level operating independently without any knowledge of the structure of the other levels, should be implementable and has the additional property that if someone comes up with xyznet with its peculiar addressing scheme, nothing has to be changed. One level need only get the message to the gateway to the next level; it does not have to read what goes on at the next level, and if it is supplied with the return to the previous host, so mail can be returned if necessary, it does not need to know what went before. Is there any attempt to implement something reasonable like this? -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 11 Aug 88 16:13:21 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 11 Aug 88 15:59:47 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 11 Aug 88 19:43:53 GMT From: jsol@bu-cs.bu.edu (Jon Solomon) Organization: Boston Univ. Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-Id: <24387@bu-cs.BU.EDU> References: <10141@g.ms.uky.edu>, <63372@sun.uucp>, <10145@g.ms.uky.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I just want to put my two cents worth into this discussion. In the current internet (little "i" internet means everybody, Capital "I" Internet means DARPA blessed sites), we cannot reasonably satisfy everyone's complaints about mail header munging. About the only thing that is agreed upon is that some mailers have to rewrite headers or they get into some form of trouble. The most responsible thing you can do is to minimize the trouble. A user of mine got a message from a site: texfoo.crl (I'm paraphrasing, I don't remember the exact site). Clearly the people on this site prefer to hide the domain system from their users, but they neglect to add the appropriate finishing touches (.com, tektronix.com or whatever is right -- I don't know, all I could do is give my user a guess at what I thought it was). Like Bill Nowicki, my site sends out alot of mail every day. Most of it goes to either Internet (large I Internet) or BITNET sites. We have rewriting rules which make this task easy. Also, no header rewriting needs to be done. We have sites on campus which use uucp, but they conform to the domain system addressing scheme and that makes our rewriting lives easier (we don't have to in their case). As more and more uucp sites come up, and their interdependencies with Internet sites increases, the need for a common naming scheme will be ever-increasing. BUT UNLESS WE ACTUALLY MAKE A CERTAIN NAMING SCHEME LAW WITH ITS APPROPRIATE PROTECTIONS, we have no way of truly enforcing the rules. SO, sendmail rewriters do the best they can. Without legal precidence for naming schemes, we will not be able to fully police the network. Flaming and peer pressure do help, but they are not the complete answer. Only laws and lawyers will really help this sort of thing. Personally, I think Sun is doing a great job forwarding mail. They seem to look at the world from the view that I share, which is that the Internet is the center of the world, and uucp has to eventually conform or be ousted. Think of what chaos there would be if the Internet adopted "bang-style" routing (that is ucbvax.berkeley.edu!bu-it.bu.edu!jsol). The Internet tries to make routing work through the use of domains, and not through the use of address munging. I think the powers that be on the Internet consider header munging a bad idea (I agree). On the other hand, the uucp sites would cry murder if we failed to add "buita!" before the headers we pass to them. They already face a number of problems with address resolution because they aren't a connected-all-the-time network. There is also some rule that says we can't tell others how to do their own internal routing and name resolution. We just have to be sure that they follow the protocol. Which brings up a point, is there an rfc covering how routing should be done in the UUCP world? If not then I think there should be. Flaming at Sun without an RFC to point at is like flaming at the devil. It just won't help. --jsol  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 11 Aug 88 19:20:31 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 11 Aug 88 19:08:22 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 11 Aug 88 20:57:33 GMT From: ron@topaz.rutgers.edu (Ron Natalie) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: References: <3674@palo-alto.DEC.COM>, , <3732@palo-alto.DEC.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu >Rutgers, on the other hand, will find a route to just about anything it can >find in the path, starting from the RIGHT. From the END. Therefore if I >send a piece of mail to ...!rutgers!foo!bar!baz!user, knowing full well that >"foo" is a directly reachable neighbor of Rutgers, I have no guarantee at >all that Rutgers will actually send to "foo". It will look first for a way >to get to "baz", then to "bar", then to "foo", then finally give up if it >cannot find any of the above. THIS IS WRONG. In defense of Mel Pleasant, system administrator for the machine you refer to as "Rutgers" who is out of the country right now, I feel compelled to make an answer. The machine Rutgers (Rutgers.EDU actually) handles a lot of passthrough mail as well as being a USENET backbone site and a main feed point for machines in New Jersey. We've recently upgraded this machine to a SUN 4/280. The first point that I would like to make is that as Associate Directory here responsible for the expenditures on this machine, if you don't like the way it runs, you can feel free to route your mail elsewhere. In an esoteric sense, it does seem wrong to do what Rutgers is doing. However, in an operational sense, we would not be able to run a machine long that worked that way. The machine, being much more intelligent (and closely coupled to the map database, which is maintained there as well) than your average random UUCP site, needs the facility to optimally route mail rather than constraining it to follow the news paths (which are less richly connected than the mail feeds). The alternative to doing rerouting is to drop mail transiting through Rutgers that isn't using a path that specifies the correct next hop (or giving up on forwarding mail for people entirely such as ihnp4 has done). Allowing us to reroute makes it feasible for us to provide this service at all. None of our clients (ether our UUCP/NEWS neighbors or members of the Rutgers community) have complained. -Ron  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 11 Aug 88 20:58:37 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 11 Aug 88 20:51:59 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 10 Aug 88 21:22:55 GMT From: att!whuts!homxb!genesis!andys@bloom-beacon.mit.edu (a.b.sherman) Organization: AT&T Bell Laboratories, West Long Branch, N.J. Subject: Re: re/routing (was: why you should say "-d ru) Message-Id: <469@genesis.ATT.COM> References: , <891@vsi1.UUCP>, <892@vsi1.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <892@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: >|n article <891@vsi1.UUCP> I wrote: >|= baz!bar!user foo!bar!user >|= ^ ^ >|= | | >|= +-------------------------------+ >|= >| >|The usual case here is that either foo or baz talks to a machine named bar >|which is NOT advertised in the maps. > >Upon reflection, the problem is that the "rerouters" are assuming that >baz!bar!user really means baz!bar.uucp!user. If I had specified a domain, the >rerouters would be justified (but still rude) in changing the path. In the >absence of a domain name, it is not reasonable to assume ".uucp". As I said >before, "bar" may be a machine local to "baz". How do users at baz mail to >the bar in the maps? Bar.uucp, of course! > If bar is a machine that is local to baz then it is in a sub-domain of baz's pricipal domain. If baz is in domain uucp, then bar is actually bar.baz.uucp. I am not sure, but I think that if baz is a known host in the paths file then smail will automatically resolve that address as baz!bar.baz.uucp!user. The last remaining problem is, of course, what will baz's mailer do with that bizarre address? At least your mail will get bounced by the host you wanted it to go through :-) -- andy sherman / at&t bell laboratories (medical diagnostic systems) room 2e-108 / 185 monmouth pkwy / west long branch, nj 07764-1394 (201) 870-7018 / andys@shlepper.ATT.COM ...The views and opinions are my own. Who else would want them?  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 11 Aug 88 21:13:53 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 11 Aug 88 21:01:00 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 11 Aug 88 22:59:44 GMT From: vixie@decwrl.dec.com (Paul Vixie) Organization: DEC Western Research Lab Subject: long, rambling message about parentheses in addresses Message-Id: <25@volition.dec.com> References: <881@vsi1.UUCP>, <3732@palo-alto.DEC.COM>, <866@l.cc.purdue.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <866@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: # I use email a fair amount, both directly and in replying to news articles. # Each network has its idiosyncracies, and they are incompatible. Also, I # am not a systems person, and I feel I should not have to work so hard to # send and receive mail. I quite agree - ordinary users ought not to have to deal with oddball addresses and explicit paths and whatnot. The MTA (mail transport agent) on their local machine and/or on the gateway into/out-of their local network should make this automatic and easy. "Reply" commands should usually work, instead of usually screwing up because of GIGO. My flaming and hammering is heavily accented toward making it _possible_ for local and gateway MTAs to rewrite things conveniently for the users. Most or all of my complaints are against MTAs who rewrite things in a way that cannot be automatically undone or fixed or made useful by other programs. Saying that a user can probably figure out how to generate a reply isn't good enough. # So what is the answer? An answer which has been proposed before is the use # of parentheses, or some such equivalent. Only the site facing a ( is allowed # to look into the parenthetical expression. This has been proposed from time to time in the past. Rahul Dhesi and I once had a weeks-long flame war over this issue (before discovereing, in the end, that we substantially agreed :-)). The problems with this approach are several. First, a basic ingredient in the whole situation is that you are trying to get mail into and out of different networks which have different and usually incompatible ways of expressing addresses and routes and things. If the various networks all agreed about such things, we wouldn't need parentheses; since they don't agree, they prob- ably won't agree about parentheses either! That is, even in the very unlikely event that we could get all the machines on all the networks to implement a new version of their software (this is impossible but I'll stipulate it), it is doubly unlikely that they would choose the same characters or the same semantics for the characters they _did_ choose. The real answer is more sublime than parentheses. Each network has a routing syntax known to it; gateways between networks know the routing syntax of both (all) networks they connect to. The thing to do is to rewrite the route and/ or address from the syntax it comes in with into the syntax it must go out with. (Sendmail.cf files that try to do this end up using an internal syntax that looks totally unlike anything used in any network, usually. Mine uses bang-notation, but I'm going to change that soon for various reasons.) But this causes some serious problems. There are two sets of two kinds of addresses in each message: {header,envelope} {senders,recipients}. Things which must be done to a header address are different from the things which must be done to an envelope address. Sendmail still refuses to make much distinction between header and envelope addresses, and rewrite rules that affect either must affect both. (IDA sendmail fixes this, and I not have the 5.59 IDA patches almost working well enough to post. Lennert, are you listening? Do you want to handle this latest distribution or shall I?) The actual transformations for (header|envelope)(senders|recipients) among (UUCP|SMTP|BITNET) are fairly complicated and somewhat debatable. I agree with a later article in this forum that an RFC which bespoke rules for these transformations would be a Very Good Thing, and John Diamant of HP tried to do this a while back. He got stymied on what I'm going to talk about next. There's a rule in RFC821 or 822 that says "all domains named in a route-addr must be registered with the NIC". I assert that this is foolish; if a name is registered with the NIC, why are we using a route-addr to talk about it? It should be reachable directly or with an MX. Granted, RFC82{1,2} were written before the days of MX, but that doesn't address my point: when 82{1,2} were written, everything you could register with the NIC was something you could get mail to directly, without use of route-addrs. (Everybody, please correct me if I'm wrong, I wasn't alive then :-) and I'm just going by what history I've read). What this means to my lovely transformation plan is that we cannot rewrite a UUCP path, for example, into an RFC822 path -- because one or more or several or lots of those UUCP hostnames are not going to be registered with the NIC. End of lovely plan, at least for now. Getting back to why parentheses aren't really needed, if we rewrite the route-addrs from/into the syntax used by the network the message comes in and goes out on, we will never see a mix of characters and the route-addr will always be in the notation natural to the MUA used to read the message. Thus replies should work. If replies have got to go back out through a gateway, the gateway can add itself to the front of the sender's address. (This is what Sun.COM does to UUCP->Sun->Internet traffic, but their algorythm is too simplistic and they do more harm than good, sad to say.) It can work if implemented correctly. Parentheses would be fun to write parsers for, but I can't advocate them on that basis. I think we can make what we've got work, if we can just get the gateways to agree on what gateways are supposed to be doing. We'll also have to bang on Jon Postel to get RFC822 changed, but that's actually the easier part of the task. Every gateway has a mailer guru who thinks they have the best solution, and they don't want to get stuck maintaining somebody else's idea of how things ought to work. I can't fault them for that, of course. But in spite of all that, something needs to be done aside from massive flame fests in comp.mail.headers every couple of months. Maybe some kind of interoperability conference for cross-network gateways ? (half :-)). It's worth noting, in closing, that domains will fix a lot of this. Sites whose only connection to the Internet is via UUCP can still have Internet names and use Internet route-addr syntax, thanks to the wonders of MX records. I think even BITNET sites could be convinced to formally join the Internet and register their domain names with the NIC. But we simply cannot expect the whole world to change as long as isolated segments of various networks are able to talk amongst themselves with incompatible protocols; gateways between these outlands and the rest of the world have to do something when mail comes through them from or to these swamps, and all the gateways from all the swamps of similar kinds ought to use similar rules. And that, impossible to implement though it sounds, is the easiest way we can being peace and civilization to this bizarre collection of networks. Ladies and gentlemen, thank you, and good night. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 11 Aug 88 21:28:28 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 11 Aug 88 21:11:30 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 11 Aug 88 23:35:52 GMT From: vixie@decwrl.dec.com (Paul Vixie) Organization: DEC Western Research Lab Subject: more on rutgers and rerouting Message-Id: <27@volition.dec.com> References: , <3732@palo-alto.DEC.COM>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In ron@topaz.rutgers.edu writes: # The first point that I would like to make is that as Associate Directory # here responsible for the expenditures on this machine, if you don't like the # way it runs, you can feel free to route your mail elsewhere. I'm going to assume that you havn't seen my "THANK YOU" article yet, Ron, because I agree with you completely and have already done so, netwide. # [...] The machine, being much more intelligent [...] than your average # random UUCP site, needs the facility to optimally route mail rather than # constraining it to follow the news paths [...]. I've explained several times in the last week, in these forums, that the place to avoid having mail travel over news paths is in the news user agents, not in gateway MTAs. If the mail were auto-routed at the source, or bumped up to Rutgers or another smart host for delivery, this problem would not exist. The netnews and RN installation documents explicitly recommend against hoping that a reverse news-path will get your reply delivered. I echo that recommendation. # The alternative to doing rerouting is to drop mail transiting through # Rutgers that isn't using a path that specifies the correct next hop (or # giving up on forwarding mail for people entirely such as ihnp4 has done). My complaint has nothing to do with finding a route to a next-hop that you do not directly speak to. Here, I'll say it again: Smart hosts are good things. A host that will find a route to the next hop in a path if it doesn't speak to it directly is a very nice host to have. What I object to is assuming that all hosts mentioned in the path which are also mentioned in the UUCP database are in fact hosts which are registered with the UUCP Project. This is simply not guaranteed. I object to finding a route to some host _other than_ the first one mentioned in a path, unless the first one mentioned in the path isn't reachable, in which case I can sit quietly while you search (starting from the left) for a host you _can_ reach. But stipping LHS hosts out of a path because you can find them in your UUCP database is not the right thing to do. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 11 Aug 88 21:28:39 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 11 Aug 88 21:22:20 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Aug 88 00:54:51 GMT From: caip.rutgers.edu!aramis.rutgers.edu!webber@rutgers.edu (Bob Webber) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Corrections of fact (Re: what do _YOU_ mean by "all routing"??) Message-Id: References: <676@bacchus.DEC.COM>, <881@vsi1.UUCP>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu [news posting] In article , ron@topaz.rutgers.edu (Ron Natalie) writes: > > In defense of Mel Pleasant, system administrator for the machine > you refer to as "Rutgers" who is out of the country right now, I > feel compelled to make an answer. .... Actually it doesn't matter much since Mel would not bother to publically defend these reprehensible policies anyway -- he merely implements them and leaves it up to people who don't like them to figure out some way around them. Certainly he is not unhappy about all the people who refuse to route thru rutgers because of his policies. > for the expenditures on this machine, if you don't like the way it > runs, you can feel free to route your mail elsewhere. ... An amusing notion which is very difficult to implement in practice in that there are a large number of such sites and their map entries tend not to identify them as mail manglers. Particularly from my location within the rutgers network I find avoiding routing thru rutgers to be awkward, to say the least (the best I seem to be able to do is try and find unadvertised arpa/usenet crossovers and then bounce my mail off them thru a path that doesn't cross back into the rerouting sites -- definitely awkward but sometimes easier than waiting weeks for different (sometimes feuding) sysadmins to iron out inconsistancies between their maps). > None of our clients (ether our UUCP/NEWS neighbors or members of the > Rutgers community) have complained. This is flat out wrong. As you can imagine, I have opposed such policies on a number of occasions and I am a member of the Rutgers community. Also, there have been a number of discussions of this on the internal rutgers boards over the past years and it is quite clear that the few traditional usenet users (as opposed to people who started networking on arpanet) prefer to route their own mail. Prior to the invasion of arpa into usenet, there was a net where this worked fine (people have been mangling mail addresses for a couple of years now and so it is easy to forget how well mail used to work once you figured out a reliable path to your main correspondents). Now it looks like they are going to have to build a new net because the usenet has been completely over-run by people who can't figure out how to type an exclamation mark in a mail address under csh. ------- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 Aug 88 01:44:35 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 11 Aug 88 22:39:56 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Aug 88 01:38:42 GMT From: amdcad!phil@bloom-beacon.mit.edu (Phil Ngai) Organization: Advanced Micro Devices Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: <22608@amdcad.AMD.COM> References: , <3732@palo-alto.DEC.COM>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article ron@topaz.rutgers.edu (Ron Natalie) writes: >The alternative to >doing rerouting is to drop mail transiting through Rutgers that isn't >using a path that specifies the correct next hop (or giving up on That is what I think should be done. If you get a uucp bang route and the next hop is incorrect, bounce it back. Bang routes are presumably used because the sender knew the route he wanted. If you get an @ address, then that is eligible for routing. I got the impression from Mel's article that he was using the map data for aggressive rerouting so that people would have incentive to update their map entries. Well, bouncing incorrect bang routes would have the same effect without screwing the people who do know what they are doing. I am all for convenience as long as the sophisticated user can still do what he wants. Let the novices use @ addresses and get a 98% success rate. But it's a shame if the knowledgable user can't use bang routes to get around the 2% failure rate because a "smart" host rerouted the bang route to be the same as an @ address. And let us not confuse the user interface with the router at a relay site. The user interface can accept @ addresses or incomplete bang routes and look it up for the user. That's convenient. But a relay site's router shouldn't assume it knows best. That's RUDE. I would like to see relay sites do relaying only, not rerouting. -- I speak for myself, not the company. Phil Ngai, {ucbvax,decwrl,allegra}!amdcad!phil or phil@amd.com  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 Aug 88 06:28:58 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 12 Aug 88 04:33:17 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Aug 88 07:32:09 GMT From: vsi1!lmb@ames.arpa (Larry Blair) Organization: VICOM Systems Inc., San Jose, CA Subject: Re: Corrections of fact (Re: what do _YOU_ mean by "all routing"??) Message-Id: <918@vsi1.UUCP> References: <881@vsi1.UUCP>, , Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article webber@aramis.rutgers.edu (Bob Webber) writes: > [[a lot of stuff supporting my point of view, but not important to this > posting]] Just when this discussion had reached it's apogee of pendanticism [now you know why I program instead of teaching English], who comes along to breath new life into it but Bob Webber. I take back any evil remarks I've cast your way in the past. I've always wondered what people without the ability to "-d rutgers" did to get their mail where they wanted it to go. I'd be interest in hearing more of these "war" stories. -- * * O Larry Blair ames-----\ * * O VICOM Systems Inc. pyramid---\ * * O 2520 Junction Ave. uunet!ubvax!vsi1!lmb * * O San Jose, CA 95134 sun-------/ * * O +1-408-432-8660 +1-800-538-3905  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 Aug 88 10:58:38 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 12 Aug 88 10:48:32 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Aug 88 14:20:06 GMT From: mailrus!b-tech!zeeff@ohio-state.arpa (Jon Zeeff) Organization: Branch Technology Ann Arbor, MI Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: <4695@b-tech.UUCP> References: , <3732@palo-alto.DEC.COM>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article ron@topaz.rutgers.edu (Ron Natalie) writes: >feel compelled to make an answer. The machine Rutgers (Rutgers.EDU >actually) handles a lot of passthrough mail as well as being a USENET >backbone site and a main feed point for machines in New Jersey. We've I have to agree that rutgers has been generous in providing usenet with alot of services. It is appreciated. >for the expenditures on this machine, if you don't like the way it >runs, you can feel free to route your mail elsewhere. > That's part of the problem - I can try and avoid rutgers (or any other site), but with active rerouters out there, someone may change my paths avoiding site xxx to go through xxx. Active rerouting, which rutgers does, makes it impossible to do what you suggest. >well) than your average random UUCP site, needs the facility to optimally >route mail rather than constraining it to follow the news paths (which >are less richly connected than the mail feeds). The alternative to >doing rerouting is to drop mail transiting through Rutgers that isn't >using a path that specifies the correct next hop (or giving up on Depending on what you meant by "correct next hop", I believe that you missed one alternative, the one that most sites have decided is the best one. How about only actively rerouting when the next hop is a site you don't talk to directly. If using news return paths are really the problem, you might consider some method of attempting to identify them - something like "this path is *really* bad, I'm going to reroute it" or "this looks like a news reply via the path line". >forwarding mail for people entirely such as ihnp4 has done). Allowing >us to reroute makes it feasible for us to provide this service at all. Note that running an active rerouting site may reduce traffic for some of the sites you talk to, but it does not reduce your traffic. -- Jon Zeeff Branch Technology, uunet!umix!b-tech!zeeff zeeff%b-tech.uucp@umix.cc.umich.edu  Received: from note.nsf.gov (TCP 1202200024) by MC.LCS.MIT.EDU 12 Aug 88 15:56:02 EDT Date: Fri, 12 Aug 88 15:33:16 EDT From: Stephen Wolff To: Jon Solomon cc: header-people@MC.LCS.MIT.EDU Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-ID: <8808121533.aa28552@note.note.nsf.gov> > In the current internet (little "i" internet means everybody, > Capital "I" Internet means DARPA blessed sites),... Excuse me. Capital "I" Internet means DARPA sites, BITNET 2 sites, NASA Science Net sites, NSFNET (just one of whose regional networks, for example, is larger than ARPANET was at its largest), and (soon) the IP-based Energy Sciences network, plus numerous IP sites in Mexico, Asia, and Europe. Harrumph! -s  Received: from bu-it.BU.EDU (TCP 20061201050) by MC.LCS.MIT.EDU 12 Aug 88 16:04:29 EDT Return-Path: Received: by bu-it.BU.EDU (5.58/4.7) id AA04120; Fri, 12 Aug 88 16:03:42 EDT Date: Fri, 12 Aug 88 16:03:42 EDT From: jsol@bu-it.BU.EDU (Jon Solomon) Message-Id: <8808122003.AA04120@bu-it.BU.EDU> To: steve@note.nsf.gov Cc: header-people@MC.LCS.MIT.EDU In-Reply-To: Stephen Wolff's message of Fri, 12 Aug 88 15:33:16 EDT <8808121533.aa28552@note.note.nsf.gov> Subject: Real data to support my claim that '-d sun' is the way to go. Yes, but to get an Internet connection you have to be "DARPA BLESSED", or DARPA has to say it is okay for you to connect. I believe DARPA has blessed all the sites you have said. --jsol  Received: from note.nsf.gov (TCP 1202200024) by MC.LCS.MIT.EDU 12 Aug 88 17:31:49 EDT Date: Fri, 12 Aug 88 17:12:27 EDT From: Stephen Wolff To: Jon Solomon cc: header-people@MC.LCS.MIT.EDU Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-ID: <8808121712.aa03521@note.note.nsf.gov> > Yes, but to get an Internet connection you have to be "DARPA BLESSED", > or DARPA has to say it is okay for you to connect. I believe DARPA has > blessed all the sites you have said. Nope. Each network blesses connection applicants. The interconnection of networks is a matter of agreement among the Federal agencies who sponsor them. No one "owns" the Internet. -s  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 12 Aug 88 21:27:17 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 0531; Fri, 12 Aug 88 21:05:23 EDT Received: from UCLAMVS.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0530; Fri, 12 Aug 88 21:04:50 EDT Date: Fri, 12 Aug 88 18:02 PDT To: HEADER-PEOPLE@MC.LCS.MIT.EDU From: Michael Stein Subject: Re: comment (on long, rambling conversations...) See RFC886: Proposed Standard for Message Header Munging (You've all read this?)  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 Aug 88 21:29:07 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 12 Aug 88 21:22:39 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Aug 88 11:15:16 GMT From: munnari!munnari.oz!kre@uunet.uu.net (Robert Elz) Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: <2294@munnari.oz> References: <881@vsi1.UUCP>, <3732@palo-alto.DEC.COM>, <866@l.cc.purdue.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <866@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes: > So what is the answer? An answer which has been proposed before is the use > of parentheses, or some such equivalent. That will never work .. all it could ever do is create more incompatabilities, which is what it would be nice to do away with. In any case, for the current problem it wouldn't help at all. There would be a set of sites that obey the restrictions you want the parentheses to imply (which would be much the same as the set of sites that look only at the first host in a bang path, and route to that one), and a set of sites that ignore your parentheses, look at what's inside, and "know" that they can find a better route than the one you gave. The problem that parentheses might fix (if it was rationally possible to change anything this darmatically) is the ! @ incompatability (which should be used). That's not at all relevant to the current discussion. kre  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 Aug 88 21:29:21 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 12 Aug 88 21:14:06 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Aug 88 23:33:37 GMT From: cwjcc!hal!ncoast!allbery@gatech.edu (Brandon S. Allbery) Organization: Cleveland Public Access UN*X, Cleveland, Oh Subject: Re: Real data to support my claim that '-d sun' is the way to go. Message-Id: <12209@ncoast.UUCP> References: <3721@palo-alto.DEC.COM>, <10141@g.ms.uky.edu>, <63372@sun.uucp> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu As quoted from <63372@sun.uucp> by nowicki%rose@Sun.COM (Bill Nowicki): +--------------- | understand the problem from both sides. We rewrite "From: | sitename!user" into "From: sitename!user@Sun.COM" because we want to > ... | > I tried a test message to you at vixie!paul@sun.com just to see what | > would happen. | | It is not suprising. We run standard (now System Vr3) UUCP software, | and do not do any routing of UUCP names. So any mail to | site!user@Sun.COM will only work if the site is a direct UUCP | neighbor. I have requested that we be taken out of the "d.Top" file as +--------------- By rewriting an address to stick yourself into it in such a way as to make the actual destination machine look like a neighbor of sun -- "vixie!paul@Sun.COM" -- *you* are assuming that other machines will know to reroute it properly. Most don't; I would hazard a guess that "rutgers"'s antisocial behavior is an attempt to bypass this kind of thing; and since you do not run Smail yourself your sendmail is insisting that anyone who wants to reply to UUCP mail through your site MUST run UUCP routing software. Which brings us to: +--------------- | Remember: just because YOU might run UUCP routing software, it does not | imply that everyone else is. +--------------- Then why does your sendmail configuration force everyone else to run UUCP routing software? This is even more antisocial than rutgers! It's also a prime reason why I pass as little mail through sun as possible. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 12 Aug 88 21:29:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 12 Aug 88 21:23:06 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 12 Aug 88 12:03:22 GMT From: munnari!munnari.oz!kre@uunet.uu.net (Robert Elz) Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: <2295@munnari.oz> References: <676@bacchus.DEC.COM>, <881@vsi1.UUCP>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Rutgers (and a few other hosts) policy of "active rerouting" is finally exposed as the wrong thing to do in this article from Ron Natalie ... Article , ron@topaz.rutgers.edu: > The machine, being much more intelligent > (and closely coupled to the map database, which is maintained there as > well) than your average random UUCP site, Superficially this seems to say "we have the best routing info available, so we should make use of it" and it seems to be a defence of Rutgers' policy. However, what it really says is "we have different routing info from everyone else", which in any distributed routing scheme (which is what uucp routing is in the presence of active routers) is a recipe for disaster. Eg: consider routing to the fictional site "baz", and assume that its stable routing info (from some time in the past) is ...!rutgers!a!b!c!d!baz!user Now suppose rutgers learns that there's a much better route available ... ...!rutgers!foo!bar!baz!user However, unfortunately, "foo" hasn't learned this yet, Rutgers is using its private, very recent, new map info, which will be posted sometime tonight, and actually installed in foo's pathalias database at some unknown future time. "foo" still sees the best bath to "baz" as "...!rutgers!a!b!c!d!baz!user", and also being an active rerouter, rewrites the path that way. A few iterations of this and the mail ends up being bounced... Clearly, if Rutgers is given "baz!user" it should route it via "foo!bar!baz" and "foo" should just send the mail to "bar", whatever it thinks the best route is. However, if the mail appears at Rutgers addressed to "a!b!c!d!baz!user" Rutgers *must* send it to "a" if they have any desire at all to handle uucp mail rationally. Ron goes on ... > None of our clients (ether our UUCP/NEWS neighbors or members of the > Rutgers community) have complained. Ignoring Bob Webber for the minute (which is sensible at any time), I can understand this, they aren't the people who are having problems. The problems come from sites much further away, both those whose mail is being rerouted into a black whole, and those whose routing is being ignored. Earlier Ron had said ... > I would like to make is that as Associate Directory here responsible > for the expenditures on this machine, if you don't like the way it > runs, you can feel free to route your mail elsewhere. Exactly! That's why all pathalias & map users should add "-d rutgers" to their pathalias command scripts. I've been doing that (actually I think I have -a rutgers, the effect is the same in all relevant cases to me) for at least a year now. Nb: this will remain true forever .. even if Rutgers' tactic does have the effect of getting every uucp site in the world to register with the map project, and all the data is accurate, distribution of the resulting maps will never be quick enough to allow active rerouting to be used, anywhere. kre  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 13 Aug 88 01:31:24 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 12 Aug 88 22:17:27 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Aug 88 01:09:44 GMT From: vixie@decwrl.dec.com (Paul Vixie) Organization: DEC Western Research Lab Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: <33@volition.dec.com> References: <3732@palo-alto.DEC.COM>, , <4695@b-tech.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <4695@b-tech.UUCP> zeeff@b-tech.UUCP (Jon Zeeff) writes: # [...] If using news return paths are really # the problem, you might consider some method of attempting to identify # them - something like "this path is *really* bad, I'm going to # reroute it" or "this looks like a news reply via the path line". Please don't! If you see a lot of replies using news paths, try to identify the sites which originate them and try to get them to fix their news software. NetNews and RN both suggest in their documentation that you use the "From:" line for replies rather than the "Path:" line, and sites which don't do this should be educated. NetNews (vnews/readnews) will use /usr/lib/news/mailpaths, which can be pointed at a smart host (i.e., which does routing on the next-hop if they don't speak to it directly); the generic solution is to use smail, which can also be trivially configured to use a smart-host. (RN would need smail, sadly). Smail is freely available, check the comp.unix.sources archives. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 13 Aug 88 01:31:52 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 12 Aug 88 22:18:05 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Aug 88 01:16:58 GMT From: vixie@decwrl.dec.com (Paul Vixie) Organization: DEC Western Research Lab Subject: Eliot Lear's final words aren't about this problem Message-Id: <34@volition.dec.com> References: , <22608@amdcad.AMD.COM>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu The folks at Rutgers seem intent on making us all work harder -- these obscene message-id's they generate keep making RN blow up. Yes, I know I can fix my software, but why is it always Rutgers that makes things stretch to their breaking point? Sigh. Not my topic, please ignore. In article lear@NET.BIO.NET (Eliot Lear) writes: # My final words on the subject.... # # Note: The use of source routing is discouraged. Unless the # sender has special need of path restriction, the choice # of transmission route should be left to the mail tran- # sport service. # # [RFC-822: Section 6.7.2, Page 32] Eliot, The person you need to yell at for this offense is Dave Taylor. ELM is the only user agent I know of that has an option for automatic source routing. Perhaps you can tell at Dan Heller, MUSH has everything else, it probably has this too. But you aren't addressing my complaint. My mail transport software (sendmail) is selecting a source route. Your mail transport software (who knows?) is overriding it. And note "unless the sender has special need of path restriction" -- this means that if the sender has some reason to select a certain source route, the mail transport software should respect that choice. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 13 Aug 88 01:46:36 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 12 Aug 88 22:16:40 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Aug 88 01:01:17 GMT From: vixie@decwrl.dec.com (Paul Vixie) Organization: DEC Western Research Lab Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: <32@volition.dec.com> References: <3732@palo-alto.DEC.COM>, , <22608@amdcad.AMD.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <22608@amdcad.AMD.COM> phil@amdcad.UUCP (Phil Ngai) writes: # That is what I think should be done. If you get a uucp bang route and # the next hop is incorrect, bounce it back. Bang routes are presumably # used because the sender knew the route he wanted. If you get an @ # address, then that is eligible for routing. Hmmm. I don't think that will work - it's hard to get @'s to appear in the address another site sees for forwarding. It is fairly easy to get it to see !'s, though, so mail to smarthost!someplaceelse!somebody is safer. Granted, there's no way to tell on smarthost whether the sender wants autorouting or whether they just typed the route wrong -- which is why I'm so hot on only routing to the first host in the path rather than stripping hosts off the way Rutgers does. Do the minimum, etc. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Aug 88 20:23:17 EDT Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Sat 13 Aug 88 08:32:54-EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 13 Aug 88 08:24:29 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Aug 88 05:48:16 GMT From: vixie@decwrl.dec.com (Paul Vixie) Organization: DEC Western Research Lab Subject: Re: 'pathalias -d sun' Message-Id: <40@volition.dec.com> References: <3721@palo-alto.DEC.COM>, <10141@g.ms.uky.edu>, <63372@sun.uucp> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <63372@sun.uucp> nowicki%rose@Sun.COM (Bill Nowicki) writes: # I realize that some people will NEVER be satisfied, but please try to # understand the problem from both sides. I do understand this, really. I think Dave Herron and Branden Allbery (sp) have answered this adequately, and I hope you have (and take) the time to answer them. All flames aside, I think there are some hints in all this about how this network can work a lot better. And on a personal note -- for everybody but WIN, who knows already: Bill Nowicki and I have argued this in private e-mail, on the net, in more private e-mail, back and forth, for about 18 months now. We're both pretty certain of the other's position, and neither of us thinks the other is being completely sensible anymore. We're probably both right, of course. I'm still looking for a solution that will satisfy both of us. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Aug 88 21:28:59 EDT Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Sat 13 Aug 88 12:05:03-EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 13 Aug 88 11:57:04 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 13 Aug 88 12:46:33 GMT From: l.cc.purdue.edu!cik@k.cc.purdue.edu (Herman Rubin) Organization: Purdue University Statistics Department Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: <870@l.cc.purdue.edu> References: <881@vsi1.UUCP>, <3732@palo-alto.DEC.COM>, <2294@munnari.oz> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <2294@munnari.oz>, kre@munnari.oz (Robert Elz) writes: > In article <866@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes: > > So what is the answer? An answer which has been proposed before is the use > > of parentheses, or some such equivalent. > > That will never work .. all it could ever do is create more incompatabilities, > which is what it would be nice to do away with. > > In any case, for the current problem it wouldn't help at all. There would > be a set of sites that obey the restrictions you want the parentheses to > imply (which would be much the same as the set of sites that look only at > the first host in a bang path, and route to that one), and a set of sites > that ignore your parentheses, look at what's inside, and "know" that they > can find a better route than the one you gave. Robert Elz is absolutely right that parentheses will not solve the problem if they are not obeyed. However, I find it hard to see that difficulties can arise if they are followed. The original postings on this subject concern the adverse consequences of sites ignoring ! _paths_ and inserting its own. There are advantages of smart mailers. There are also disadvantages. Maps are not always up-to-date. There was a period during which I was unable to communicate on UUCP with Ohio State because the automatic router insisted on going through ihnp4, that link having been broken, instead of cbosgd. What Paul Vixie stated in his first posting was that sites should obey routings. Parentheses could introduce a little more flexibility by stating that one does not break into a parenthetical expression to find a better way. Any particular network could establish its protocol without having to even consider what another network is doing. I am not saying that they should not try to come up with a common protocol, but if this is difficult for some reason, strictly obeyed parentheses give a simple way to proceed. It is important that the mail go through. The niceties are secondary. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Aug 88 21:58:21 EDT Date: Sat, 13 Aug 1988 11:32 EDT Message-ID: From: Rob Austein To: Header-People@MC.LCS.MIT.EDU cc: Header-People-Request@MC.LCS.MIT.EDU, Postmaster@MC.LCS.MIT.EDU Reply-To: Postmaster@MC.LCS.MIT.EDU Subject: Please take this conversation elsewhere Enough already. This conversation about whose Internet<->Usenet gateway is more anti-social has diverged a long ways from anything appropriate for HEADER-PEOPLE. I realize that many of the participants are posting their comments to a usenet newsgroup, not HEADER-PEOPLE, but the participants should realize that every one of these gems ties up MC's mailer for the better part of an hour delivering to all the non-Usenet recipients. Not to mention all the other mailers all over the Internet and the BITNET that have to pass along all this intra-usenet bickering. Comments that have some relevance to email standards are still welcome (eg, the one yesterday about RFC 886). But please take the usenet holy war elsewhere, perhaps one of the news.* newsgroups since this is really a usenet site policy issue. Our mailer will thank you. The alternative to this is that we start running the HEADER-PEOPLE distribution through a digestifier to cut down on the number of actual deliveries MC has to make. I would prefer not to do this, but if things don't quiet down we may have to. MC supports an ungodly number of mailing lists, and, while HEADER-PEOPLE is one of the ones we consider most important, we can't afford to dedicate the entire machine to it. Thanks. --Rob Austein (for Postmaster@MC.LCS.MIT.EDU) PS: Please do NOT send me flamage regarding slow response on HEADER-PEOPLE-REQUEST. The person who administers HEADER-PEOPLE is back at MIT after an extended absence and is dealing with the backlog as fast as possible. Flaming at me is more likely to get you moved to the end of the queue than the front....  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 13 Aug 88 23:42:03 EDT Received: from nrtc.nrtc.northrop.com (TCP 20030600001) by AI.AI.MIT.EDU 13 Aug 88 16:05:30 EDT Received: from nma.com by nrtc.nrtc.northrop.com id ab13466; 13 Aug 88 13:02 PDT Received: from localhost by nma.com id aa00206; 13 Aug 88 12:59 PDT To: Header-People@ai.ai.mit.edu, INFO-NETS%MIT-OZ@mc.lcs.mit.edu, MMM-PEOPLE@isi.edu From: Einar Stefferud Reply-to: ifip65@ics.uci.edu Subject: 1988 IFIP WG 6.5 INTERNATIONAL WORKING CONFERENCE Date: Sat, 13 Aug 88 12:59:34 -0700 Message-ID: <203.587505574@nma.com> Sender: stef@ics.uci.edu .PAGE ======================================================================= Please pass this annnoucement along to additional interested people. To obtain more information and a registration form, just reply to this message, or to one of the other addresses in the announcement. A list of the papers to be presented is included at the end. ======================================================================== CONFERENCE ANNOUNCEMENT 1988 IFIP WG 6.5 INTERNATIONAL WORKING CONFERENCE ON MESSAGE HANDLING SYSTEMS AND DISTRIBUTED APPLICATIONS 10 to 12 October, 1988 Sponsored by IFIP TC6 and IFIP WG 6.5 Hosted by The University of California at Irvine The Conference will be held at the Red Lion Inn, Costa Mesa, California, USA -- Near the University of California at Irvine in Southern California. Easy access from Los Angeles International Airport (LAX), Orange County Airport (SNA), and Long Beach Airport (LGB). PROGRAM: The purpose of the conference is to provide an international forum for exchange of information on the technical, economic, social, and political impacts and experiences with computer messaging and distributed application infrastructures in the automated workplace environment. The conference format will be two days of conference paper presentations combined with one day of workshops. Papers from 13 countries will be presented on the following topics: International Standards and Profiles -- 1988 Interconnection and Interworking User Agent Models and Designs Group Communication Models and Services Information Object Standards for Interchange Distribution of Services and Applications Security, Authentication, Privacy, Confidentiality Directory Services Impacts of MHS and Distributed Services Workshops will be conducted on Structured Group Communication, Multi-Media Communication, MHS Gateways, MHS Management, Directory Services, and other topics of interest to the attendees. Attendees will receive a PREPRINT of the Conference Papers and copies of Workshop Position Papers. .PAGE PROGRAM COMMITTEE: S. Bellovin, U. Beyschlag, D. Biran, B. Boutmy, E. Butrini, A. Danthine, P. Dubost, H. Forsdick, J. Granado, H.G. Hegering, C. Huitema, W.J. Jaburek, O. Jacobsen, P. Johnson, T. Kalin, F. Kamon, T. Kehres, K. Kelly, D. Khakhar, S. Kille, S.K. Lebeck, E. Lillevold, D. Long, J. McHugh, M. Medina, R. Miller, C. Moore, N. Naffah, Y. Nakagome, G. Neufeld, K. Oya, S. Rami, M.T. Rose, S. Rothwell, H. Santo, P. Schicker, T. Szentivany, E. Skovgaard, H. Smith, R. Speth, E. Stefferud, J. Sweet, F. Sztajnkrycer, L.M.R. Tarouco, R. Uhlig, J. White, P. Zupa. LIST OF AUTHORS: P. Schicker, J. Stranger, S.K. Lebeck, S.E. Kille, A. Danthine, P. Godelaine, A.M. Shivji, N.K. Koorland, K. Oya, K. Kunimasa, T. Tsukishima, D. Rotondi, G. Altomare, O. Berlen, A. Scopece, P.A. Pays, Y.Z. You, A. Lanceros, J. Saras, W. Prinz, M. Woitass, S. Wilbur, U. Pankoke-Babatz, B. Bellman, C. Partridge, M.T. Rose, G. Schurmann, K.H. Weiss, K. Tschichholz, E. Moeller, K.D. Engel, M.J.A. Wilkens, L.M.R. Tarouco, N.S. Borenstein, C.F. Everhart, J. Rosenberg, A. Stoller, T. Gyiers, F. Eliassen, I. Nordli, T. Danielson, J. Onions, G. Neufeld, E. Sadowski, M. Medina, J. Delgado, R. Cole, C. I'Anson, A. Pell, J. Galvin, S. Benford, C. Huitema, A.M. Bustos, R.J. Boaden, A.G. Lockett, A. Feenberg, H. Etzkowitz. PROGRAM CHAIRS: Peter Schicker (CH - European CoChair) Ole Jacobsen (USA - North American CoChair) ORGANIZING COMMITTEE: Einar Stefferud (USA - General Chair) James McHugh (USA - Local Arrangements Chair) Jeff Cole (USA - UCI Conference Coordinator) .PAGE CONFERENCE REGISTRATION : For information on registration fees and a registration form, please contact us via one of the netmail or postal addresses below, or by phone. Registration will be available at the Conference. Cancellation with full registration fee refund is available with written notice to UCI Conference Services, before 17 September, 1988. After 17 September, a processing fee of will be charged. No refund will be made for people who have paid but do not attend. However, the workshop postion papers and a preprint of the conference papers will be mailed to them. HOTEL INFORMATION: Red Lion Inn, 3050 Bristol Street Costa Mesa, California, USA 92626-3098 175 Rooms are reserved for attendees. (This block of rooms will be held until Sept. 17, 1988) .PAGE HOTEL RESERVATION INFORMATION: Call +1-800-547-8010 or +1-714-540-7000 and ask to reserve a room at the Costa Mesa Red Lion Inn, California, USA. Be sure to say you are attending the "IFIP 6.5 CONFERENCE" to get the Conference Rate and to credit our conference. A guarantee is required for arrival after 6PM. Travel Agents may telephone: +1-800-541-1111 Costa Mesa Red Lion Inn FAX: +1-714-540-9176 Alternate Hotel Information is Available From UCI AIRLINE SHUTTLE INFORMATION: Los Angeles International (LAX) is served by an airport shuttle with a regular stop at the Costa Mesa Red Lion Inn. Orange County Airport (SNA) and Long Beach Airport (LGB) have free transportation to the Red Lion Inn. Call the hotel from the airport for pickup. .PAGE For more Conference Information -- Send Requests to: INTERNET: IFIP65@ics.uci.edu R&D MHS: IFIP65@vax.runit.unit.uninett BITNET: IFIP65@UCI BITNET: IFIP65@CERNVAX MCIMAIL ID: 357-8979 TELEX: 650-357-8979 MCI UW Or write to: UCI Conference Services (Attn IFIP6.5) 255 Administration Building The University of California at Irvine Irvine, California, USA 92717 Or Phone UCI Conference Services: +1-714-856-6963 ADDITIONAL NETMAIL CONTACTS: Einar Stefferud INTERNET: estefferud@nrtc.northrop.com INTERNET: estefferud@ics.uci.edu BITNET: ESTEF@UCI MCIMAIL: MCI ID: 132-7425 TELEX: 650 132 7425 MCI UW Ole Jacobsen INTERNET: ole@csli.Stanford.edu Peter Schicker BITNET: SCHICKER@CERNVAX Jeff Cole BITNET: JTCOLE@UCI INTERNET: jtcole@ics.uci.edu .PAGE LIST OF PAPERS: This list is ordered according to the Topics List from the Call for Papers. The program will be organized around those topics, but not necessarily in this exact order. P. Schicker (CH) Message Handling Systems, X.400 (An Overview) J. Stranger (UK) UK GOSIP (Government Open Systems Interconnection Procurement) S. Klein Lebeck (US) Implementing MHS: 1984 versus 1988 S. E. Kille (UK) PP - A Message Transfer Agent A. Danthine (BE) MHS in a Corporate Communication Systemes P. Godelaine (BE) Offering Internet Service A. Shivji (CA) Implementing X.400 Gateways - N. K. Koorland (CA) A Comparative Analysis K. Oya (JP) The Development of a MHS Facsimile Network K. Kunimasa (JP) T. Tsukishima (JP) D. Rotondi (IT) DICOM: An Approach to the MHS UA Design G. Altomare (IT) O. Berlen (IT) A. Scopece (IT) P. A. Pays (FR) A General Multi-User Message Store Y. Z. You (FR) A. G. Lanceros (SP) Definition of Group Communication J. A. Saras (SP) Facilities in the MHS W. Prinz (DE) The Date Planning System - Example of a M. Woitass (DE) Cooperative Group Activity S. Wilbur (UK) Group Communication as a Tool for Higher-Level Applications U. Pankoke-Babatz (DE) Support for Coordinating Group Activities B. L. Bellman (US) Towards a Model for Interface and Information Server Design C. Partridge (US) A Comparison of External Data Formats M. T. Rose (US) G. Schurmann (DE) Multi.Media Document Handling Architecture K. H. Weiss (DE) in a Distributed Broadband Environment M. Tschichholz (DE) E. Moeller (DE) K. D. Engel (DE) .PAGE M. J. A. Wilkens (BR) Message System as a Communication Mean L. M. R. Tarouco (BR) among Processes N. S. Borenstein (US) Architectural Issues in the Andrew C. F. Everhart (US) Message System J. Rosenberg (US) A. Stoller (US) T. Gyires (Hungary) Distributed Problem Solving Network with Uncertainty F. Eliassen (NO) Communication via Shared Conceptual Memory I. Nordli (NO) T. Danielsen (NO) J. P. Onions (UK) The Applications Cookbook M. T. Rose (US) G. Neufeld (CA) A Store-and-Forward File Transfer System E. Sadowski (CA) M. Medina (SP) Use of Abstract Service Definition Conventions J. Delgado (SP) for Distributed Information Processing Systems Specification R. Cole (UK) Architectural Aspects of a Mobile C. l'Anson (UK) X.400 Service A. Pell (UK) J. M. Galvin (US) Privacy Without Authentication S. Benford (UK) Navigation and Knowledge Management within a Distributed Directory System C. Huitema (FR) Using a Standard Directory as a Name A. M. Bustos (FR) Server within the THORN Project R. J. Boaden (UK) A Study of Electronic Mail: Its Value, A. G. Lockett (UK) Management, and Development A. Feenberg (US) The Planetary Classroom H. Etzkowitz (US) The Electronic Focused Interview: Email as a Dialogic Interviewing Medium ===== End  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 14 Aug 88 21:43:06 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 14 Aug 88 21:32:10 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 14 Aug 88 19:08:40 GMT From: cwjcc!hal!ncoast!allbery@ohio-state.arpa (Brandon S. Allbery) Organization: Cleveland Public Access UN*X, Cleveland, OH Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: <12220@ncoast.UUCP> References: <676@bacchus.DEC.COM>, <881@vsi1.UUCP>, Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article , lear@NET.BIO.NET (Eliot Lear) writes: +--------------- | Note: The use of source routing is discouraged. Unless the | sender has special need of path restriction, the choice | of transmission route should be left to the mail tran- | sport service. | | [RFC-822: Section 6.7.2, Page 32] +--------------- Which was great, when the network(s) covered by RFC822 could propagate changes to the routing in an hour or so. With UUCP, the corresponding time can be measured in months in some cases. Quite aside from the fact that RFC822 insists that all sites named in an address be known; many small UUCP sites feel they have no need to register with the NIC. RFC822 is a bit naive. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 15 AUG 88 01:40:08 EDT Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Mon, 15 Aug 88 01:39:49 EDT Received: from ames.arc.nasa.gov by XN.LL.MIT.EDU; Mon, 15 Aug 88 01:40:32 EDT Posted-Date: Sun, 14 Aug 88 20:57 PDT Received: Sun, 14 Aug 88 22:29:25 PDT by ames.arc.nasa.gov (5.59/1.2) Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.4.1 #3.1) id ; Sun, 14 Aug 88 20:57 PDT Message-Id: Date: Sun, 14 Aug 88 20:57 PDT From: chongo@uts.amdahl.com (Landon Curt Noll) To: bill@ssbn.UUCP Subject: Re: Smail3.1 Cc: header-people@mc.lcs.mit.edu From wisner@killer.DALLAS.TX.US (Bill Wisner) >>... The only MTS I know of that handles this correctly is Smail 3.1, >>which puts a copy of the From_ line into a Return-Path line if a >>message is being delivered by the "local" transport. ... From sun!bellcore.bellcore.com!tness7!texbell!ssbn!bill (Bill Kennedy) >Has anyone seen smail 3.1? I was able to find 3.0 in killer's archives >but it appears not to be any substantial change over 2.5. ... > >What are the new features of smail 3.1? Where can we get it? Is it >worth having smail look for "Return-Path" instead of re-routing if >the last site!user is the same as the one in the From:? ... Smail3.1 is a total rewrite of the smail program which was designed by the UUCP Project (well, two functions were borrowed from an old Smail2.3, though you probably wouldn't recognize them). Before we get a flood of "I would like a copy" requests, we would like to give some background: Smail is being written by, Ronald S. Karr (tron), and Landon Noll (chongo) both presently at Amdahl Corp. Smail3.1 is the first release of the new mailer, which will be followed by a release (smail3.2) sometime in the next 6 months or so. The Smail3.2 will be distributed to anyone who asks for it. (we will post messages to the mailing list/ newsgroup when it is ready) There change between Smail3.2 and Smail3.3 will be in terms bug fixes. Smail3.3 will be posted to the 4 winds... :-) During the Smail3.2 -> Smail3.3 phase, we will be working on Smail3.4 which will hopefully include ISO X.400 support. At present we have enough Smail3.1 testers for our current needs. Even so, if someone has a reasonable amount of mailer experience and REALLY REALLY REALLY wants to be a Smail3.1 tester, we may consider it. Such requests should be sent to: info-smail-request@uts.amdahl.com. (send a description of the system(s) on which you will test Smail3.1) We have a mailing-list for Smail as well. We tend to rehash old mail-headers issues in this newsgroup. And since you likely don't have Smail3.1 source you are already reading this mailing-list/newsgroup, you might not want to be in the Smail mailing list. But if you do, send a message to info-smail-request@uts.amdahl.com. Smail3.1 eliminates the need for sendmail. The new mailer is designed to be highly extensible, in terms of the methodologies used in delivering mail, expanding aliases and mailing lists, and routing to remote hosts. The model that it uses for routing and alias expansion is an expandable database model, where queries are tried through various "drivers". Current "drivers" can query files, programs and remote YP databases, future drivers will also be able to query information available through the internet domain system. The mailer can handle SMTP, delivery through various kinds of programs, and the direct delivery to mailbox files, without going through /bin/mail, as is usually done under UN*X. It would be entirely possible to write a driver that could resolve queries using a syntax-based approach, like sendmail does, though there are currently no plans for such a thing. Smail3.1 also contains a collection of new mailer utilities such as utilities to manage a pathalias route database. For example we have replaced uuhosts with utilities that allow for finer control. From vixie@palo-alto.DEC.COM (Paul Vixie) writes: >Rutgers, on the other hand, will find a route to just about anything it can >find in the path, starting from the RIGHT. From the END. ... THIS IS WRONG. > >It's an option in Smail, and I wish they'd never have included it. ... Smail3.1 does NOT have such an option. The two routines we quasi-kept did not deal with such re-writing. :-) In fact, the Smail3.1 distribution contains the Honeyman's new pathalias. This pathalias contains some new directives (adjust and delete) that were added largely because we strongly dislike rutgers style mailers and partly because we twisted Honeyman's "Email arm" slightly. :-) No really, the new pathalias and the Smail3.1 tools work well together, for which we owe thanks to Honeyman. Last, regarding the particular question, Smail3.1 presently will add a Return-Path: header field to mail being delivered to its final destination. It does not change or remove any currently existing Return-Path: field. Though I believe sendmail is also capable of doing this, by making the addition of a Return-Path: field conditional upon the local delivery flag. chongo /\oo/\ tron |-<=>-|  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Aug 88 03:28:14 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 15 Aug 88 03:25:46 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 15 Aug 88 05:18:46 GMT From: bionet!lear@presto.ig.com (Eliot Lear) Organization: Natl Computer Resource for Mol. Biologists Subject: Re: what do _YOU_ mean by "all routing"?? Message-Id: References: <881@vsi1.UUCP>, , <12220@ncoast.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu My point was that users should leave the routing of mail to computers, like they do everything else. -- Eliot Lear [lear@net.bio.net]  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 15 Aug 88 16:28:27 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 15 Aug 88 16:26:09 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 15 Aug 88 14:15:13 GMT From: peraino@gmu90x.gmu.edu ( ) Organization: George Mason University, Fairfax, Va. Subject: OS-41 operating system for the hp41c Message-Id: <1301@gmu90x.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu I have been getting the EduCalc catalog for several years now, and have continually noticed a book called, I believe, "OS-41 an operating system for your hp41" by Beers and Beers. It looks interesting. All I know about it is that it is a collection of many useful utilities (even what they do, I'm not exactly sure). Since it carries a fairly hefty price, $41.95 I believe, I would like to know if anyone out there has this book, what they think of it, and a little info on what kind of utilities/programs it has. Thanks in advance. I believe a posting of an in-depth review to the net would help many people. peraino@gmuvax  Received: from Xerox.COM (TCP 1500006350) by MC.LCS.MIT.EDU 15 Aug 88 20:43:28 EDT Received: from Riesling.ms by ArpaGateway.ms ; 15 AUG 88 17:31:45 PDT Sender: "Lennart_Lovstrand.EuroPARC"@Xerox.COM Date: 15 Aug 88 17:29:45 PDT (Monday) Subject: The IDA Sendmail Kit for UCB sendmail 5.59 From: "Lennart_Lovstrand.EuroPARC"@Xerox.COM To: vixie@decwrl.dec.COM cc: header-people@mc.lcs.mit.EDU, Lovstrand.EuroPARC@Xerox.COM In-Reply-to: vixie@decwrl.dec.COM's message of 12 Aug 88 07:23 Message-ID: <880815-173145-1229@Xerox> Re: (IDA sendmail fixes this, and I not have the 5.59 IDA patches almost working well enough to post. Lennert, are you listening? Do you want to handle this latest distribution or shall I?) Yup, I hear you. Thanks for the offer, but I think I'd rather hang on to the Kit myself as long as I have interest in it, at least. For the rest of you: The IDA Sendmail Enhancement Kit rev 1.2 which includes modifications to BSD 4.3 sendmail 5.59 will be released shortly to comp.sources.unix. The previous release was for sendmail 5.51 and came out a bit more than a year ago; this release will mostly contain the same features as the original one, but is compatible with the MX version of sendmail and has Yellow Pages support for Suns. A couple of additional features supplied by Guy Middleton at Waterloo have also been included. From the goodies list: o Separated envelope/header rewriting rules -- to maintain/obey routes in envelope but keep headers simple o General access to dbm files -- to directly read pathalias routing tables and others o Sun yellow pages support -- to share dbm files on network o Multi-token class matches -- to match class members such as "foo" "." "bar" o Embedded ruleset calls -- to allow for expressions like "$>1$>2 foo@bar" o Batched SMTP support -- to avoid rmail's limitation on special characters in addresses o Return Path support for UUCP mailers -- to automatically construct an updated (envelope) sender route o UUCP header address relativization -- to automatically construct relative !-paths for dumb UUCP mailers Also included is the IDA Sendmail master config file with such more or less controversial features as: o "Passive rerouting" using the pathalias database. o Full support for UUCP style !-paths, domain style @-addresses with %-routing, and RFC-822 style source routes. o Total rewriting to internal format, then according to selected mailer. o Reliable host to mailer mapping (both general and individual). o Support for hiding local user/hosts under common domain name. o Support for private domain tables in addition to /etc/hosts and MX. Some of the consequences of the above are: o Sendmail.cf is rarely changed, updates go via dbm files (or YP, MX etc). o All addressing formats are treated equally, ie host!user == user@host. o Hybrid addresses (a!b@c etc) are accepted, but never produced. o Sendmail does systems routing internally; no need for smail ;-) etc, but also... o Source routes are respected if supplied. Interested? Stay tuned to this channel for more news... --Lennart Rank Xerox EuroPARC, 61 Regent Street, Cambridge CB2 1AB, England  Received: from tis.llnl.gov (TCP 30003010402) by MC.LCS.MIT.EDU 17 Aug 88 03:24:27 EDT Return-Path: Received: by tis.llnl.gov (5.51++/1.14-TIS) id AA04320; Tue, 16 Aug 88 23:52:10 PDT Message-Id: <8808170652.AA04320@tis.llnl.gov> Date: Tue, 16 Aug 88 23:52:06 -0800 From: kehres@tis.llnl.gov (Tim Kehres) Subject: Re: Confirmation of Recipt To: Shores%UMASS.BITNET@mitvma.mit.edu Cc: header-people@mc.lcs.mit.edu X-Orig-Date: Tue, 9 Aug 88 10:19:05 EDT X-Orig-From: Shores%UMASS.BITNET@MITVMA.MIT.EDU (Ken Shores) X-Orig-Message-Id: <880809101819689.AAPQ@Mars.UCC.UMass.EDU> (UMass-Mailer 4.04) In your message you write: > One of the "features" that I have been asked to add to our mail system > on several occasions is a "confirmation of recipt". I am glad to hear that > at least one other person thinks this is inappropriate. However, I am > curious about what the general sentiment is. Is "confirm recipt" useful? > Is it a good idea? How would you implement it, if it were? (i.e. when do > you send a recipt, and what field and syntax would you use to indicate that > one was desired?) > > Ken Shores Due in part to the widespread use of sendmail, the "Return-receipt-to:" field is fairly widely accepted. Although this is not officially part of RFC 822, it could probably be considered a valid user-defined-field and if RFC 822 ever gets any updated, should probably be considered for inclusion. The mailer that we have been using for the past several years has supported return receipts, and we have found that this is one of the more popular options that our mailer supports. Our UA supports the optional generation of receipts. In addition, we have our own local mail delivery program which will generate delivery notification messages when it comes across return receipt requests. We moved the delivery notification messages out of sendmail and into the local mail delivery program for two reasons. The first is that the messages produced by sendmail look more like error messages than receipts to the casual user. They are also typically quite long when only a few lines would do. The other reason is that delivery notification messasges would only be generated when mail passed through sendmail. For mailers that bypass sendmail for local delivery, delivery notifications would never get generated, producing an inconsistency in the mail service. Over the years, we have found that there is considerable demand for a receipt capability in some user communities. It seems to be one of those things that people don't think they need until they have it and use it for a while. After that, there is no way you can take it away >from them. Tim Kehres  Received: from SH.CS.NET (TCP 1201600122) by MC.LCS.MIT.EDU 17 Aug 88 21:37:57 EDT Received: by SH.CS.NET id aa00673; 17 Aug 88 21:31 EDT To: header-people@mc.lcs.mit.edu Subject: routing, 822, etc Date: Wed, 17 Aug 88 21:24:39 -0400 From: Craig Partridge It seems to me that much of this comment about Internet-UUCP gateways is simply naive. RFC 822 was written in a time of static host tables, when there was only one Internet. Now there is an interconnected mail network -- remarkably, RFC 822 stills works just fine, as long as you keep in mind that the world has changed slightly. To explain most of these{ changes RFCs-974 and 976 were written. Furthermore, there's been generally agreement among most of the major networks that we should all strive to get routing out of our headers, and simply go with addresses of users@domain (which is wonderfully user friendly). To help people get domains, the Internet NIC graciously agreed to allow anyone to register a domain name (which is extremely nice of them -- they didn't need to volunteer for that extra work). Many Internet sites will provide domain service for off-Internet organizations for free. Given this sort of free help, I'm not terribly sympathetic to USENET folks who say "I don't want a domain name" and then demand that the rest of us turn handstands to support the convoluted addresses that result. It's a free world, and you can be anti-social if you want to, but please, don't ask the rest of us to be sympathetic to the pain caused by being anti-social. Craig  Received: from gjetost.cs.wisc.edu (TCP 20032201041) by MC.LCS.MIT.EDU 18 Aug 88 08:25:29 EDT From: solomon@cs.wisc.edu (Marvin Solomon) Message-Id: <8808181222.AA22061@gjetost.cs.wisc.edu> Received: by gjetost.cs.wisc.edu; Thu, 18 Aug 88 07:22:55 CDT Subject: Re: Confirmation of Recipt To: kehres@tis.llnl.gov (Tim Kehres) Date: Thu, 18 Aug 88 7:22:51 CDT Cc: header-people@mc.lcs.mit.edu In-Reply-To: <8808170652.AA04320@tis.llnl.gov>; from "Tim Kehres" at Aug 16, 88 11:52 pm X-Mailer: Elm [version 2.0 gamma] Tim Kerhes writes: > Over the years, we have found that there is considerable demand for > a receipt capability in some user communities. It seems to be one of > those things that people don't think they need until they have it and > use it for a while. After that, there is no way you can take it away > from them. I agree. I've found this to be particularly true for users of IBM and DEC VMS systems (as Ollie North says on a new IBM commercial, "I'm sure glad I used PROFS when I told George about the Iran/Contra deal, or I'd be in jail by now." :-) However, you have to talk to them to find out what they really want. The CCITT X.400 series of recommendations make a useful distinction (it must have been an accident :-) between "Delivery" and "Receipt" notification. The former is generated by the MTA (mail transfer agent) and the latter is generated by the UA (user agent). The UA is NOT what the name implies to most people--it is not the user-interface program. Rather, the MTA/UA boundary is an authority boundary. In most UNIX systems I know of, where sendmail (or whatever) execs /bin/mail suid root (or daemon) to put the mail into /usr/spool/mail/, /bin/mail is part of the MTA, but /usr/spool/mail/ is part of the UA. Delivery notification means the message was delivered to the UA: that is, it was put into your mailbox. The semantics of receipt notification is a little less clear: It would seem to imply that you actually READ the message. I suspect people like deliverly notification because they don't really trust the mail system. It's comforting to know that the message actually got there. In fact X.400 lets you request notification on delivery, non-delivery, both, or neither. RFC 821 essentially says "non-delivery notification: always; delivery notification: never". Receipt notification raises both implementation and social problems. In the UNIX world, implementing receipt notification would mean modifying ALL the mail-reading programs (/bin/mail, /usr/ucb/mail, mh, elm, ...) to generate a return-receipt messages when the user first does a "p" command (or whatever it's called). You have to be careful to generate it only once. That means marking the message in some immediate and indelible way, even if you quit using the "forget" version ('x' in ucbmail), kill off your mail reader, or crash the system. The social issue is that many users consider it an unwarranted invasion of privacy. They find it useful to "peek" at incoming mail, but pretend not to read it until a later date. I would say that "certified mail--return receipt requested" corresponds pretty closely to deliverly notification; receipt notification is more like hiring a process-server to deliver a subpoena. Because of privacy concerns an because the generator of the return message runs (by definition) in the protection domain of the recipient, it is both tempting and easy to defeat this feature at the receiving end. For all these reasons, "receipt notification" seems not to be widely implemented in X.400 systems. In summary, most people who claim to want receipt notification would probably be quite happy with delivery notification. They may claim to be interested in knowing that you haven't read a message because you're on vacation, but there are better ways of achieving that functionality. (Now we can return to flaming about "I'm on vacation" programs. ;-) Marvin Solomon Computer Sciences Department University of Wisconsin, Madison WI solomon@cs.wisc.edu ...seismo!uwvax!solomon  Received: from SUMEX-AIM.Stanford.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 18 Aug 88 15:01:07 EDT Received: from KSL-1186-4.STANFORD.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 18 Aug 88 11:56:59 PDT Date: Thu, 18 Aug 88 11:54:06 PDT From: Mark Crispin Subject: Re: routing, 822, etc To: Craig Partridge cc: header-people@mc.lcs.mit.edu Message-ID: <617902798.A4823.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> In-Reply-To: Message from Craig Partridge of Wed, 17 Aug 88 21:24:39 -0400 As a followup on Craig Partridge's message, I've noticed a distressing tendency of certain hosts to have headers using RFC 822 routes, that is: From: Joe Blow <@foo.blohoken.edu:blow@bar.kenhobo.edu> where "foo.blohoken.edu" is known to the domain name system but "bar.kenhobo.edu" is not. Some mailers have even sent header lines such as From: <@foo.blohoken.edu:blow@bar.kenhobo.edu> or even From: @foo.blohoken.edu:blow@bar.kenhobo.edu neither of which is valid RFC 822. I hope those cretins who prattle RFC 822's misguided inclusion of the source route syntax as justification for such headers come to learn that: (1) replying to such addresses is not widely implemented by mail UA's (2) parsing such addresses in input is not widely implemented by mail UA's (3) delivering mail by source routing is not widely implemented by mailers and, most important of all (4) such addresses are among the most user-hostile mail addresses imaginable. This syntax should be kept in the dungeon of the Return-Path header line where it belongs. The so-called "%-hack" exists for a reason. You are NOT implementing domains by transforming "blow%bar.kenhobo.edu@foo.blohoken.edu" to one of the obscenities above. -- Mark --  Received: from SUMEX-AIM.Stanford.EDU (TCP 1200000070) by MC.LCS.MIT.EDU 18 Aug 88 20:55:18 EDT Received: from KSL-1186-4.STANFORD.EDU by SUMEX-AIM.Stanford.EDU with TCP; Thu, 18 Aug 88 17:51:36 PDT Date: Thu, 18 Aug 88 17:48:45 PDT From: Mark Crispin Subject: time madness To: Header-People@MC.LCS.MIT.EDU Message-ID: <617924077.A4934.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> What should you put into the time-zone field of an RFC 822 header if the machine you're using doesn't have any concept of timezone? -- Mark --  Received: from tis.llnl.gov (TCP 30003010402) by MC.LCS.MIT.EDU 19 Aug 88 00:25:54 EDT Return-Path: Received: by tis.llnl.gov (5.51++/1.14-TIS) id AA00673; Thu, 18 Aug 88 21:19:55 PDT Message-Id: <8808190419.AA00673@tis.llnl.gov> Date: Thu, 18 Aug 88 21:19:50 -0800 From: kehres@tis.llnl.gov (Tim Kehres) Subject: Re: time madness To: Crispin@sumex-aim.stanford.edu Cc: Header-People@mc.lcs.mit.edu X-Orig-Date: Thu, 18 Aug 88 17:48:45 PDT X-Orig-From: Mark Crispin X-Orig-Message-Id: <617924077.A4934.KSL-1186-4.Crispin@SUMEX-AIM.Stanford.EDU> In your message you write: > What should you put into the time-zone field of an RFC 822 header if the > machine you're using doesn't have any concept of timezone? If your machine has absolutely no idea of where it is at, you are probably out of luck. If on the other hand, it just does not know the abbreviation for the time zone (PDT, EST, etc. for example), you can use the offset (in hours) from GMT. Tim Kehres  Received: from INFOODS.MIT.EDU (TCP 2226000122) by MC.LCS.MIT.EDU 19 Aug 88 07:51:01 EDT Received: by INFOODS id <000003E1061@INFOODS.MIT.EDU> ; Fri, 19 Aug 88 07:40:15 EST Date: Fri, 19 Aug 88 07:31:45 EST From: John C Klensin Subject: RE: time madness To: Mark Crispin X-VMS-Mail-To: EXOS%"Mark Crispin " Message-ID: <880819073145.000003E1061@INFOODS.MIT.EDU> cc: header-people@MC.LCS.MIT.EDU Yes, one of the few places where 822 may ask for too much, rather than two little, relative to the capabilities of the technology. Given that, irritating as it may be, time zones typically change only a couple of times a year, putting a static zone somewhere and having the UA pick it up for each message is a typical solution. It is what most, if not all, of the VMS implementations of SMTP do, and those systems have no concept of time zone. Or am I missing something about your question? My nightmare about this has always been the van, or airplane, travelling cross-country, sending messages by mobile satellite link (a technology whose feasibility for the ARPANET was demonstrated nearly ten years ago). Now, if you want to send accurate local time and zone, the UA needs to know, dynamically, where you are. Or you have to key it in with each message, a notoriously poor and unreliable procedure. --john  Received: from Think.COM (TCP 1201000006) by MC.LCS.MIT.EDU 19 Aug 88 08:44:22 EDT Return-Path: Received: from dagda.think.com by Think.COM; Fri, 19 Aug 88 08:43:44 EDT Received: by dagda.think.com; Fri, 19 Aug 88 08:43:21 EDT Date: Fri, 19 Aug 88 08:43:21 EDT Message-Id: <8808191243.AA13361@dagda.think.com> From: Robert L. Krawitz Sender: rlk@Think.COM To: header-people@mc.lcs.mit.edu In-Reply-To: <880819073145.000003E1061@INFOODS.MIT.EDU> Subject: time madness Well, at that, if a space station ever gets built and it has a network connection via satellite (given the former, the latter seems not in the least unlikely) then what? Probably makes sense to coerce times to GMT, but that may have political repercussions... harvard >>>>>> | Robert Krawitz bloom-beacon > |think!rlk topaz >>>>>>>> . rlk@a.HASA.disorg  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 19 Aug 88 16:29:57 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 19 Aug 88 16:14:12 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 19 Aug 88 14:00:18 GMT From: peraino@gmu90x.gmu.edu ( ) Organization: George Mason University, Fairfax, Va. Subject: test posting- ignore Message-Id: <1317@gmu90x.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu This is just a test posting. I recently had trouble posting to this newsgroup. Thank you for ignoring this.  Received: from tis.llnl.gov (TCP 30003010402) by MC.LCS.MIT.EDU 20 Aug 88 01:06:12 EDT Return-Path: Received: by tis.llnl.gov (5.51++/1.14-TIS) id AA00507; Fri, 19 Aug 88 22:03:14 PDT Message-Id: <8808200503.AA00507@tis.llnl.gov> Date: Fri, 19 Aug 88 22:03:10 -0800 From: kehres@tis.llnl.gov (Tim Kehres) Subject: Re: Confirmation of Recipt To: solomon@cs.wisc.edu Cc: header-people@mc.lcs.mit.edu X-Orig-Date: Thu, 18 Aug 88 7:22:51 CDT X-Orig-From: solomon@cs.wisc.edu (Marvin Solomon) X-Orig-Message-Id: <8808181222.AA22061@gjetost.cs.wisc.edu> In your message you write: : > The CCITT X.400 series of recommendations make a useful distinction (it > must have been an accident :-) between "Delivery" and "Receipt" > notification. The former is generated by the MTA (mail transfer agent) > and the latter is generated by the UA (user agent). The UA is NOT what > the name implies to most people--it is not the user-interface program. > Rather, the MTA/UA boundary is an authority boundary. In most UNIX > systems I know of, where sendmail (or whatever) execs /bin/mail suid > root (or daemon) to put the mail into /usr/spool/mail/, /bin/mail > is part of the MTA, but /usr/spool/mail/ is part of the UA. > > Delivery notification means the message was delivered to the UA: that > is, it was put into your mailbox. For 1984 X.400 and for a 1988 X.400 UA without a Message Store (MS), this is indeed true. For 1988 UA's operating with a a MS, it is actually the MS which has the responsibility for generating the Delivery notification. I feel it is a little unfortunate that with the 1988 series of recommendations, that there is not distinction between UA's with MS (P7) and those without (P3). They are completely different beasts, since the UA with P7 does not have the nearly the same data management responsibilities as does the UA communicating via P3. BTW, an MTA is not a mail transfer agent, but rather a message transfer agent. The significance of this is that the Message Transfer System (MTS) is designed to form the foundation for many different types of store and forward communication, not just IPMS. > The semantics of receipt > notification is a little less clear: It would seem to imply that you > actually READ the message. I suspect people like deliverly > notification because they don't really trust the mail system. It's > comforting to know that the message actually got there. In fact X.400 > lets you request notification on delivery, non-delivery, both, or > neither. I believe that your interpretation is correct. The following is what the current (version 6) documents say regarding delivery notification and receipt notification (taken from X.400, Annex B): B.21 Delivery Notification MT PR This element of service enables an originating UA to request that the originating UA be explicitly notified when a submitted message has been sucessfully delivered to a recipient UA or Access Unit. The notification is related to the submitted message by means of the message identifier and includes the date and time of delivery. In the case of a multi-destination message, the originating UA can request this element of service on a per-recipient basis. When a message is delivered after distribution list expansion, then, depending on the policy of the distribution list, the notification can be sent to either the list owner, the message originator, or both. Delivery notification carries no implication that any UA or user action, such as examination of the message's content, has taken place. B.67 Receipt Notification Request Indication IPM PR This element of service allows the originator to ask that he be notified when the IP-message being sent is received. In the case of a multi-recipient message, the originator can request this element of service on a per-recipient basis. This element of service also implicitly requests Non-receipt Notification Request Indication. The originator's UA conveys his request to the recipient's UA. The recipient can instruct his UA to honour such requests, either automatically (for example, when it first renders the IP-message on the recipient's terminal) or upon his explicit command. The recipient can also instruct his UA, either in blanket fashion or case by case, to ignore such requests. What this seems to imply is that it is not correct for a UA to automatically generate (without the recipients consent) a return receipt when the recipient first scans a receipt requested message. Does this sound correct? We have changed our system to behave in this way, but I know of at least one other (non-UNIX) type mail system that generates mandatory receipts. > Receipt notification raises both > implementation and social problems. In the UNIX world, implementing > receipt notification would mean modifying ALL the mail-reading programs > (/bin/mail, /usr/ucb/mail, mh, elm, ...) to generate a return-receipt > messages when the user first does a "p" command (or whatever it's > called). There are actually two problems here. For the implementation of delivery notification, no mail-reading programs need be modified, only the program that does final delivery to a user's mailbox. For return receipt's, just the mail-reading programs need modification. One can impliment one without the other. If you take the position that return receipt generation is always optional (from the recipients point of view), then the need for ALL mail-reading programs to be modified becomes less. > The social issue is that many users > consider it an unwarranted invasion of privacy. They find it useful to > "peek" at incoming mail, but pretend not to read it until a later > date. This is precisely the problem that we had here. We had a group of users that were under the impression (an incorrect one), that when they requested a return receipt, they were guaranteed of *always* getting one back, and used this as a means to determine if the people that worked for them were being responsive. The problems with this are that there is no way for a UA to determine if a user has actually read the message and understands it without user intervention. The other issue is exactly as described above: an unwarranted invasion of privacy. I still believe that return receipts and delivery notification are extremely valuable tools, and should be retained, however improper implementation of these features can cause considerable harm. Tim Kehres  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 22 Aug 88 22:56:05 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 22 Aug 88 22:52:40 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 18 Aug 88 05:40:13 GMT From: hpda!hptsug2!taylor%hplabs.hp.com@bloom-beacon.mit.edu (Dave Taylor) Organization: Hewlett-Packard University Grants Program Subject: Re: Eliot Lear's final words aren't about this problem Message-Id: <432@hptsug2.HP.COM> References: , <34@volition.dec.com> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Paul Vixie replies to a comment of Eliot Lear with: > The person you need to yell at for this offense is Dave Taylor. ELM is the > only user agent I know of that has an option for automatic source routing. Yo! Vixie! Yer wrong, mon! The gig here is that software should be concerned with the *user* not the *specification* or the *machine*. Elm (not ELM) has the builtin hooks to pathalias and the domain rewrite database because it's something that *users need* (caveat: most sites can rephrase that as `needed' instead, but there are still leaf Unix nodes on the periphery...). I don't know, this is a pretty serious issue, actually. I guess we're just disagreeing on some fundamental issues here, that of the system modifying its behaviour to match the needs and expectations of the user, or vice versa. The counter-example, one that happens with `lower level routing', is that you send mail to a host and accidentally mistype the hostname. You have to wait for your system to choke on it and return it as a dead letter before you are notified something is wrong. That's wrong. In the same way, sendmail is *not* the right place to have personal aliases -- if I want to be able to send mail to "vixie" from my computer, I should *not* have an alias in the /usr/lib/aliases file "vixie:vixie@DEC". That's too far down, and too late for the cognitive process of composing and sending a message. I want to know IMMEDIATELY that if I type in 'vixe' instead, it's wrong. Comments? -- Dave Taylor  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 23 Aug 88 00:25:56 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 23 Aug 88 00:10:06 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 23 Aug 88 03:17:16 GMT From: vixie@decwrl.dec.com (Paul Vixie) Organization: DEC Western Research Lab Subject: Re: Eliot Lear's final words aren't about this problem Message-Id: <76@volition.dec.com> References: , <34@volition.dec.com>, <432@hptsug2.HP.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Dave Taylor felt misused when I said: # > The person you need to yell at for this offense is Dave Taylor. ELM is the # > only user agent I know of that has an option for automatic source routing. # # Yo! Vixie! Yer wrong, mon! Hey, like, you're right. I rather like ELM's source-routing and aliasing features; they're cute, harmless, and occasionally very helpful. I brought up ELM because Eliot seemed confused about what we were talking about -- if he really was upset about source routing in user agents, the thing to yell about is ELM, not Smail. I think he got the point. Sorry to rope you into this. I really don't mind this feature of ELM. But as long as we're talking about where user-name aliasing should go, I agree that there should be a way to do it in the user agent, but I like having it available in the MTA as well -- .forward files are a pain when someone leaves the host and you don't want to keep their account online. -- Paul Vixie Digital Equipment Corporation Work: vixie@dec.com Play: paul@vixie.UUCP Western Research Laboratory uunet!decwrl!vixie uunet!vixie!paul Palo Alto, California, USA +1 415 853 6600 +1 415 864 7013  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 Aug 88 05:26:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 25 Aug 88 05:22:56 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 25 Aug 88 08:03:49 GMT From: amdahl!tron@ames.arpa (Ronald S. Karr) Organization: Amdahl Coup, UTS Products Hen house Subject: Re: Eliot Lear's final words aren't about this problem Message-Id: References: , <34@volition.dec.com>, <432@hptsug2.HP.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <432@hptsug2.HP.COM> taylor@hplabs.hp.com (Dave Taylor) writes: >The gig here is that software should be concerned with the *user* >not the *specification* or the *machine*. Elm (not ELM) has the >builtin hooks to pathalias and the domain rewrite database because >it's something that *users need* (caveat: most sites can rephrase >that as `needed' instead, but there are still leaf Unix nodes on >the periphery...). >The counter-example, one that happens with `lower level >routing', is that you send mail to a host and accidentally >mistype the hostname. You have to wait for your system to >choke on it and return it as a dead letter before you are >notified something is wrong. Hey, man. Like, my Sun, it don't even have much of an alias file, or a path database. It just goes and sends everything it gets off to some other host (over UUCP). ELM aint ever going to get no verification out of that. But more seriously, the mailer we are using at amdahl has multiple path databases, an alias file, a mailing-list directory (which is not tied to the aliases file), and some other features that neither ELM nor any other UA knows about. If you want to verify addresses in the UA, why don't you just ask the MTA? This will work in sendmail. It will also work with Smail3 (still in alpha release, sorry :-). Just connect to the mailer and engage in an interactive SMTP dialog with it. The VRFY command should work nicely. If you can connect to an existing mailer process (over a socket, or over a named pipe), then the response time for requests is generally good, and you do not have to worry about which MTA is being used. Of course, if you can't query your MTA for valid addresses, there is not much you can do except emulate what the MTA will do. But them's the breaks. Some other interesting problems are that MTA's should not be designed with synchronous behavior being a requirement. If Smail3 can't route an address because a lock file is being held for an extended time period, or because a remote host with routing information is down, or whatever, it tries again later. In response to an SMTP VRFY operation, it will return a non-fatal error code indicating a temporary failure. A User Agent would have to be prepaired to handle these problems. The upshot of this is that a User Agent should be concerned with the *user* and the Mail Transfer Agent should be concerned with *mail*, and the *specification* and the *machine*. As long as there exists more than one UA on a system, or as long as alias and path information can be used by remote hosts, the system alias and routing databases should be in the MTA. It is reaonable for a UA to ask the opinion of the MTA, it is counterproductive for a UA to do the work of the MTA. -- tron |-<=>-| ARPAnet: amdahl!tron@Sun.COM tron@uts.amdahl.com UUCPnet: {decwrl,sun,uunet}!amdahl!tron [views above shouldn't be viewed as Amdahl views, or as views from Amdahl, or as Amdahl views views, or as views by Mr. Amdahl, or as views from his house]  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 31 Aug 88 21:50:57 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 31 Aug 88 21:40:52 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 31 Aug 88 17:14:24 GMT From: peraino@gmu90x.gmu.edu ( ) Organization: George Mason University, Fairfax, Va. Subject: EduCalC hp28c tradein deal Message-Id: <1360@gmu90x.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In reference to the posting recently, about the fact that EduCalc will give $55 tradein on hp28c's - this offer expired as of 08/31/88. I spoke with them on the phone. peraino@gmuvax -- ----------------------------------------------- |UUCP : uunet!pyrdc!gmu90x!peraino | |INTERNET: peraino@gmuvax.gmu.edu | |BITNET : peraino@gmuvax |  Received: from emx.utexas.edu (TCP 20024600441) by MC.LCS.MIT.EDU 1 Sep 88 17:55:37 EDT Posted-Date: Thu, 1 Sep 1988 16:53:07 CDT Received: by emx.utexas.edu (5.54/5.51) id AA27853; Thu, 1 Sep 88 16:56:08 CDT Received: by rascal.ics.utexas.edu (3.2/4.22) id AA26872; Thu, 1 Sep 88 16:53:11 CDT Date: Thu, 1 Sep 1988 16:53:07 CDT From: Werner Uhrig Reply-To: werner@rascal.ics.utexas.edu (Werner Uhrig) To: HEADER-PEOPLE@mc.lcs.mit.edu Subject: please add me to HEADER-PEOPLE distribution Message-Id: thanks --------------------------> please send REPLIES to <------------------------ INTERNET: werner@rascal.ics.utexas.edu (Internet # 128.83.144.1) or: werner%rascal.ics.utexas.edu@cs.utexas.edu UUCP: .....!cs.utexas.edu!rascal.ics.utexas.edu!werner ALTERNATIVE: werner@astro.as.utexas.edu OR werner@utastro.UUCP  Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 12 Sep 88 18:30:04 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 7158; Mon, 12 Sep 88 18:28:14 EDT Received: from MAINE.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 7157; Mon, 12 Sep 88 17:55:05 EDT Received: by MAINE (Mailer X1.25) id 6412; Mon, 12 Sep 88 17:53:13 EDT Subject: Received tag format (picking nits) To: header-people@MC.LCS.MIT.EDU From: Barry D Gates Date: Wed, 7 Sep 88 19:25:48 EDT I've been re-reading several of the mail-related RFC's lately, and I came across something in RFC822 that somewhat surprised me, because I have never, to the best of my recollection, received a piece of mail that actually conformed to this little tidbit. I was looking through the definitions of the tags, and came across the "id" parameter on the "Received" tag. It reads: ["id" msg-id] I read it once and I didn't really see what that said the first time. Then I looked a little closer, then looked at the definition of "msg-id" just to make sure that it was what I thought it was; it was. I then scanned all my folders that I had online, to see if I could find one piece of mail that had even one "Received" tag that conformed to this. I could not. Of course, I can only seem to find four different types of received tags, those generated by the Crosswell VM Mailer (Mailer X1.25), those generated by some sort of Unix mailer (sendmail?) that puts two version numbers as comments after the domain (5.57/4.1, or such), and two others that did not use the "id" parameter. My question is, should RFC 822 read that way? Or, put in a better way, what is it reasonable for a program to expect to find in that parameter field? My best guess currently is: ["id" (local-part / msg-id)] Admittedly, the subject of this message says it all (picking nits), but I'd rather not take liberties with the standards, and since I can't even remember ever seeing a piece of mail that conformed to this, I thought I'd see what's up. Comments? Conformistically yours, Barry  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 23 Sep 88 11:56:45 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 23 Sep 88 11:37:22 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 23 Sep 88 14:51:22 GMT From: spdcc!mipseast!rogerk@bloom-beacon.mit.edu (Roger B.A. Klorese) Organization: MIPS Computer Systems, Inc., Burlington, MA Subject: "Return-Receipt-To:" and Mail/mailx Message-Id: <511@mipseast.mips.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Does anyone have any suggestions for adding a "Return-Receipt-To:" header to mail generated by /usr/ucb/mail (on our BSD system) or mailx (on our SV system)? I use EMACS as my mailer, so can add it easily, but the rest of the local staff uses, and must continue to use, the basic user agents. -- Roger B.A. Klorese MIPS Computer Systems, Inc. {ames,decwrl,prls,pyramid}!mips!rogerk 25 Burlington Mall Rd, Suite 300 rogerk@mips.COM (rogerk%mips.COM@ames.arc.nasa.gov) Burlington, MA 01803 I don't think we're in toto any more, Kansas... +1 617 270-0613  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 26 Sep 88 10:49:05 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 26 Sep 88 10:44:17 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 26 Sep 88 13:55:19 GMT From: blitz!ehrlich@psuvax1.psu.edu (Dan Ehrlich) Organization: Department of Computer Science, Penn State University Subject: Re: "Return-Receipt-To:" and Mail/mailx Message-Id: <3975@psuvax1.cs.psu.edu> References: <511@mipseast.mips.COM> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <511@mipseast.mips.COM> rogerk@mips.COM (Roger B.A. Klorese) writes: > >Does anyone have any suggestions for adding a "Return-Receipt-To:" header >to mail generated by /usr/ucb/mail (on our BSD system) or mailx (on our >SV system)? I use EMACS as my mailer, so can add it easily, but the rest >of the local staff uses, and must continue to use, the basic user agents. For anybody who uses /use/ucb/mail (I am not sure about SV) one can create a file named .mailcf in one's home directory. This file can conatin any additional headers that one would like to appear in the outgoing message. Here is what I have in the one I use: HWork-Phone: +1 814 863 1142 This bit of magic was shown to me by one of the other systems programmers here. I have not delved into the source for /usr/ucb/mail to figure out what else can go in to this file or what other magic can be done. Dan Ehrlich | Disclaimer: The opinions expressed are The Pennsylvania State University | my own, and should not be attributed Department of Computer Science | to anyone else, living or dead. University Park, PA 16802 |  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 26 Sep 88 13:49:09 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 26 Sep 88 13:27:14 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 26 Sep 88 17:22:02 GMT From: triceratops.cis.ohio-state.edu!karl@ohio-state.arpa (Karl Kleinpaste) Subject: Re: "Return-Receipt-To:" and Mail/mailx Message-Id: <22535@tut.cis.ohio-state.edu> References: <511@mipseast.mips.COM>, <3975@psuvax1.cs.psu.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu ehrlich@blitz writes: For anybody who uses /use/ucb/mail (I am not sure about SV) one can create a file named .mailcf in one's home directory... ... This bit of magic was shown to me by one of the other systems programmers here. I have not delved into the source for /usr/ucb/mail to figure out what else can go in to this file or what other magic can be done. The use of the ~/.mailcf file is not a function of /usr/ucb/[Mm]ail; rather, it's a function of sendmail. [Mm]ail's (mailx') configuration is based entirely in ~/.mailrc. ~/.mailcf is in the same format (including your header example) as /usr/lib/sendmail.cf. --Karl  Received: from EDDIE.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 26 SEP 88 20:01:47 EDT Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id ; Mon, 26 Sep 88 16:10:41 EDT Received: from Think.COM by news.think.com; Mon, 26 Sep 88 16:12:34 EDT Return-Path: Received: from ames.arc.nasa.gov by Think.COM; Mon, 26 Sep 88 16:02:04 EDT Received: Mon, 26 Sep 88 13:02:16 PDT by ames.arc.nasa.gov (5.59/1.2) Received: by amdahl.uts.amdahl.com (/\=-/\ Smail3.1.6.1 #6.3) id ; Mon, 26 Sep 88 12:41 PDT Message-Id: Date: Mon, 26 Sep 88 12:41 PDT From: chongo@uts.amdahl.com (Landon Curt Noll) To: header-people@mc.lcs.mit.edu Subject: please remove - sorry about this folks... I am sorry, but after 2 months of trying to get off of this mailing list via header-people-request@mc.lcs.mit.edu, I am mailing to the full mailing list in hopes that the people who maintain the mailing list will notice and will remove me from it. I read the list via rn now. chongo /\**/\  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 26 Sep 88 23:18:21 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 26 Sep 88 22:52:45 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 27 Sep 88 00:49:00 GMT From: blitz!ehrlich@psuvax1.psu.edu (Dan Ehrlich) Organization: Department of Computer Science, Penn State University Subject: Re: "Return-Receipt-To:" and Mail/mailx Message-Id: <3977@psuvax1.cs.psu.edu> References: <511@mipseast.mips.COM>, <3975@psuvax1.cs.psu.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Ahem...(pardon me while I put on my humble hat :-). It was pointed out to me by Jordan Hayes that the feature I attributed to /usr/ucb/Mail was (note the use of the past tense) actually a feature of Sendmail that was removed in Sendmail V4.30, quite a while ago. Appearently it was hacked back into sendmail here at Penn State. Hopefully there are not a lot of folks out there trying to figure out why their copy of Mail doesn't do this. Sorry for any inconvience I may have caused. Dan Ehrlich | Disclaimer: The opinions expressed are The Pennsylvania State University | my own, and should not be attributed Department of Computer Science | to anyone else, living or dead. University Park, PA 16802 |  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 26 Sep 88 23:48:22 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 26 Sep 88 23:19:03 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 27 Sep 88 02:12:14 GMT From: cunixc!fuat@columbia.edu (Fuat C. Baran) Organization: Columbia University Center for Computing Activities Subject: Re: "Return-Receipt-To:" and Mail/mailx Message-Id: <1004@cunixc.columbia.edu> References: <511@mipseast.mips.COM>, <3975@psuvax1.cs.psu.edu>, <22535@tut.cis.ohio-state.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu In article <22535@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >The use of the ~/.mailcf file is not a function of /usr/ucb/[Mm]ail; >rather, it's a function of sendmail. [Mm]ail's (mailx') configuration >is based entirely in ~/.mailrc. ~/.mailcf is in the same format >(including your header example) as /usr/lib/sendmail.cf. I believe support for ~/.mailcf was taken out of more recent versions of sendmail. According to the Version.c file it was put in in version 3.57 and removed in version 4.30 since it was "abused". --Fuat -- ARPANET: fuat@columbia.edu U.S. MAIL: Columbia University BITNET: fuat@cunixc.cc.columbia.edu Center for Computing Activities USENET: ...!rutgers!columbia!cunixc!fuat 712 Watson Labs, 612 W115th St. PHONE: (212) 280-5128 New York, NY 10025  Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 2 Oct 88 04:39:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 2 Oct 88 02:33:27 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Oct 88 04:05:03 GMT From: chip!mparker@nosc.mil (M. D. Parker) Organization: M/A-COM Government Systems Inc., San Diego, CA Subject: Documentation on Internet/UUCP/??? possible types of mail addresses? Message-Id: <194@chip.UUCP> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Greetings... We are in the process of integrating a number of different mail systems and are hoping to write the parsers to properly interpret all the possible mail addresses out there. I do have a pretty fair idea as to the presendences and ordering of the operators and what they do, but to this point I have found no documentation on this. Many of you might point to RFC822 immediately. Unfortunately, from what I can determine RFC822 does not address the mixed UUCP/DECNET/Internet/??? formats that can exist that we all commonly use now. SOOOO...I guess what I am asking is for a pointer to a definitive document that addresses all sorts of address formats. This would make it a bit easier to write a header parser that properly routes messages. Maybe others have made a stab at this? Thanks for any and all help. Mike Parker Manager, Systems Administration  Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 2 Oct 88 23:28:48 EDT Date: Sun, 2 Oct 88 23:26:57 EDT From: "Pandora B. Berman" Subject: retransmit To: header-people@MC.LCS.MIT.EDU cc: BUG-MAIL@AI.AI.MIT.EDU Message-ID: <455322.881002.CENT@AI.AI.MIT.EDU> These two msgs from the usenet Header-People community apparently got bounced by some combination of MC's down time last week (it's been having these strange parity errors...) and the experimentally patched mailer MC has been running more recently. This situation is being watched. Header-People-Request ---------- Date: Sat 1 Oct 88 17:14:20-EDT From: The Mailer Daemon To: header-people-request@mc.lcs.mit.edu Subject: Message of 27-Sep-88 22:19:31 Message undeliverable and dequeued after 4 days: header-people@mc.lcs.mit.edu: Cannot connect to host ------------ Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Tue 27 Sep 88 22:19:31-EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 27 Sep 88 21:58:06 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 27 Sep 88 14:17:57 GMT From: clyde!watmath!egisin@bellcore.bellcore.com (Eric Gisin) Organization: U of Waterloo, Ontario Subject: Re: "Return-Receipt-To:" and Mail/mailx Message-Id: <21154@watmath.waterloo.edu> References: <511@mipseast.mips.COM>, <3975@psuvax1.cs.psu.edu>, <22535@tut.cis.ohio-state.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu The .mailcf hack was apparently removed from 4.3 bsd sendmail. If your system has exec'able shell scripts, you can create your own sendmail. This is my etc/sendmail -- #! /bin/sh (cat <<.; cat) | /usr/lib/sendmail "$@" From: (Eric Gisin) egisin @ math.Waterloo.EDU (U of Waterloo) , Then assign SENDMAIL=$HOME/etc/sendmail and export it from your .profile. -------------------- -------------------- Date: Sun 2 Oct 88 01:54:29-EDT From: The Mailer Daemon To: header-people-request@mc.lcs.mit.edu Subject: Message of 28-Sep-88 16:19:37 Message undeliverable and dequeued after 3 days: header-people@mc.lcs.mit.edu: Cannot connect to host ------------ Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 28 Sep 88 16:19:38-EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 28 Sep 88 15:54:54 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for header-people@mc.lcs.mit.edu (header-people@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 28 Sep 88 17:29:28 GMT From: dartvax!andyb%coat.uucp@bu-cs.bu.edu (Andy Behrens) Organization: Burlington Coat Factory Warehouse Subject: Re: "Return-Receipt-To:" and Mail/mailx Message-Id: <10213@dartvax.Dartmouth.EDU> References: <3975@psuvax1.cs.psu.edu>, <22535@tut.cis.ohio-state.edu>, <21154@watmath.waterloo.edu> Sender: header-people-request@mc.lcs.mit.edu To: header-people@mc.lcs.mit.edu Egisin@watmath.waterloo.edu (Eric Gisin) writes: > You can create your own sendmail. This is my etc/sendmail -- > > #! /bin/sh > (cat <<.; cat) | /usr/lib/sendmail "$@" > From: (Eric Gisin) egisin @ math.Waterloo.EDU (U of Waterloo) > . > > Then assign SENDMAIL=$HOME/etc/sendmail and export it from your .profile. In many versions of mail, the environment variable is $sendmail (lower case) rather than $SENDMAIL. Also, the existing mail delivery program may not be /usr/lib/sendmail; on my system it is "/bin/mail". It may be more convenient to put a set sendmail=$HOME/mysendmail command in your .mailrc file. If you want everyone on the system to use the local version of sendmail, put the set command in the global mail rc file. (Berkeley /usr/lib/Mail.rc, SysV /usr/lib/mailx/mailx.rc). -- "Christ died for our sins. Dare we make his martyrdom meaningless by not committing them?" Andy Behrens andyb@coat.uucp (formerly: andyb@burcoat.uucp) internet: andyb%coat@dartmouth.edu uucp: {harvard,decvax}!dartvax!coat!andyb bitnet: andyb%coat@dartcms1 RFD 1, Box 116, East Thetford, Vt. 05043 (802) 649-1258 -------