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" <RAF%NIHCU.bitnet@jade.Berkeley.Edu>
	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 <ron@BRL.ARPA>
To:       Postmaster & BITINFO <netinfo%web.Berkeley.EDU@berkeley.EDU>
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<end || (dayno==end && hours <1)))
		{
			zone += 60*60;
		}
	}
	tval -= zone;
	return tval;

bad_date:
	return -1L;
}

static int
sunday(d, year)
{
	int i;
	int	pdays;

	for(i = 1970; i < year; i++)
		pdays += dysize(i);
	if(d >= 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 <ron@BRL.ARPA>
To:       Postmaster & BITINFO <netinfo%web.Berkeley.EDU@berkeley.EDU>
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<end || (dayno==end && hours <1)))
		{
			zone += 60*60;
		}
	}
	tval -= zone;
	return tval;

bad_date:
	return -1L;
}

static int
sunday(d, year)
{
	int i;
	int	pdays;

	for(i = 1970; i < year; i++)
		pdays += dysize(i);
	if(d >= 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 <sshurr%wellesley.edu@RELAY.CS.NET>
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 <sshurr%wellesley.edu@RELAY.CS.NET>
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 <stef@nrtc-gremlin.arpa>

------- Forwarded Message

Subject: IFIP 6.5 Conference Programme
From: Hugh Smith <hugh%computer-science.nottingham.ac.uk@cs.ucl.ac.UK>
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 <ROODE%BIONET@SUMEX-AIM.Stanford.EDU>
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 <ROODE%BIONET@SUMEX-AIM.Stanford.EDU>
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 <PKARP@SRI-IU.ARPA>
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: <VAX-MM(196)+TOPSLIB(126)+PONY(141) 24-Feb-87 19:03:45.SRI-IU.ARPA>
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 <Margolin@MIT-MULTICS.ARPA>
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 <loverso%buffalo.csnet@RELAY.CS.NET>
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 <dcrocker%engr.ub.com@RELAY.CS.NET>
To:       Jordan Hayes <jordan@UCBARPA.BERKELEY.EDU>
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 <MRC%PANDA@SUMEX-AIM.Stanford.EDU>
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 <PKARP@SRI-IU.ARPA>
Subject: TURN
To: header-people@MC.LCS.MIT.EDU
Message-ID: <VAX-MM(196)+TOPSLIB(126)+PONY(141) 25-Feb-87 20:43:45.SRI-IU.ARPA>

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 <dcrocker%engr.ub.com@RELAY.CS.NET>
To:       Mark Crispin <MRC%PANDA@SUMEX-AIM.STANFORD.EDU>
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 <Margolin@MIT-MULTICS.ARPA>
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 <WANCHO@SIMTEL20.ARPA>
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 <mit-erl!gildea@EDDIE.MIT.EDU>
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" <rsk@j.cc.purdue.edu>
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" <JPALME@QZCOM.BITNET>
Reply-To:    "Jacob Palme QZ" <JPALME@QZCOM.BITNET>,
             "External mail experience" <C252@QZCOM.BITNET>,
             "Academic network cooperation group (IFIP)"
              <C355@QZCOM.BITNET>
To:          "ARPA Internet Mail Interest List"
              <header-people@AI.AI.MIT.EDU>,
             "External mail experience" <C252@QZCOM.BITNET>,
             "Academic network cooperation group (IFIP)"
              <C355@QZCOM.BITNET>,
             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 <BLARSON@USC-ECLB.ARPA>
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 <mgrant@mimsy.umd.edu>
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" <TERICSON@QZCOM.BITNET>
Reply-To:    "Tommy Ericson QZ" <TERICSON@QZCOM.BITNET>,
             "Header People (mail standards) mailing lists"
              <HEADERP@QZCOM.BITNET>,
             "External mail experience" <C252@QZCOM.BITNET>,
             "Academic network cooperation group (IFIP)"
              <C355@QZCOM.BITNET>
To:          "Header People (mail standards) mailing lists"
              <HEADERP@QZCOM.BITNET>
cc:          "ARPA Internet Mail Interest List"
              <header-people@AI.AI.MIT.EDU>,
             "External mail experience" <C252@QZCOM.BITNET>,
             "Academic network cooperation group (IFIP)"
              <C355@QZCOM.BITNET>
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: <taylor@hpldat>
Received: by hpldat ; Mon, 16 Mar 87 23:19:46 pst
From: Dave Taylor <taylor%hpldat@hplabs.HP.COM>
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-<number>) 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 <galvin@dewey.udel.edu>
To: Dave Taylor <taylor%hpldat@hplabs.hp.com>
cc: The Header People Mailing List <Header-People@mc.lcs.mit.edu>
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 <galvin@dewey.udel.edu>

> 	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-<number>) 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: <SRA.12287180353.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   Dave Taylor <taylor%hpldat@HPLABS.HP.COM>
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 <taylor%hpldat@hplabs.HP.COM>

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 <AA01350> 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 </cmu/common/mailqs/q000/QF.apollo.itc.cmu.edu.205f2268.2cb>;
          Wed, 18 Mar 87 17:40:56 est
Received: FROM apollo.itc.cmu.edu VIA qmail
          ID </cmu/itc/cfe/.Outgoing/QF.apollo.itc.cmu.edu.205f225c.25c>;
          Wed, 18 Mar 87 17:40:30 est
Message-Id: <wULm9Qy00VsLBL8238@andrew.cmu.edu>
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 <galvin@dewey.udel.edu>
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" <JPALME@QZCOM.BITNET>
Reply-To:    "Jacob Palme QZ" <JPALME@QZCOM.BITNET>
To:          "ARPA Internet Mail Interest List"
              <header-people@AI.AI.MIT.EDU>,
             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 <Klensin@MIT-MULTICS.ARPA>
Subject:  requiring RFC822 headers
To:  Scott Baily <ZBZSCOT@CSUGREEN.BITNET>
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                           <zbzscot@CSUGREEN.BITNET>
From: Leonard D. Woren 213 743-5391               <LDW%USCMVSA.bitnet@BERKELEY.EDU>
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" <P136@QZCOM.BITNET>
Reply-To:    "Rolf Speth CEC COST11ter" <P136@QZCOM.BITNET>,
             "Jacob Palme QZ" <JPALME@QZCOM.BITNET>,
             "AMIGO Open" <AMIGOOPE@QZCOM.BITNET>,
             "AMIGO Group (communication)" <AMIGOGRO@QZCOM.BITNET>,
             "MHS implementation mailing list" <MHSIMP@QZCOM.BITNET>
Resent-Reply-To:
             "MHS (CCITT) Standardization" <C333@QZCOM.BITNET>
To:          "Jacob Palme QZ" <JPALME@QZCOM.BITNET>,
             "AMIGO Open" <AMIGOOPE@QZCOM.BITNET>,
             "AMIGO Group (communication)" <AMIGOGRO@QZCOM.BITNET>,
             "MHS implementation mailing list" <MHSIMP@QZCOM.BITNET>
cc:          "MHS (CCITT) Standardization" <C333@QZCOM.BITNET>,
             MHS_implementation@RSCH.WISC.EDU,
             "ARPA Internet Mail Interest List"
              <header-people@AI.AI.MIT.EDU>
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" <JPALME@QZCOM.BITNET>
Reply-To:    "Jacob Palme QZ" <JPALME@QZCOM.BITNET>,
             "Rolf Speth CEC COST11ter" <P136@QZCOM.BITNET>,
             "AMIGO Open" <AMIGOOPE@QZCOM.BITNET>,
             "AMIGO Group (communication)" <AMIGOGRO@QZCOM.BITNET>,
             "MHS implementation mailing list" <MHSIMP@QZCOM.BITNET>,
             "MHS (CCITT) Standardization" <C333@QZCOM.BITNET>
To:          "Rolf Speth CEC COST11ter" <P136@QZCOM.BITNET>,
             "AMIGO Open" <AMIGOOPE@QZCOM.BITNET>,
             "AMIGO Group (communication)" <AMIGOGRO@QZCOM.BITNET>,
             "MHS implementation mailing list" <MHSIMP@QZCOM.BITNET>
cc:          "MHS (CCITT) Standardization" <C333@QZCOM.BITNET>,
             MHS_implementation@RSCH.WISC.EDU,
             "ARPA Internet Mail Interest List"
              <header-people@AI.AI.MIT.EDU>
Subject:     Message Handling conference in Munich, 27-29 April 1987.

The final program was included in a message written by
Einar Stefferud <stef@NRTC-GREMLIN.ARPA> 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 <bsaibis%lsu.edu@RELAY.CS.NET>
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 <ROODE@BIONET-20.ARPA>
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 <ROODE@BIONET-20.ARPA>
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 <MRC%PANDA@SUMEX-AIM.Stanford.EDU>
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" <JPALME@QZCOM.BITNET>
Reply-To:    "Jacob Palme QZ" <JPALME@QZCOM.BITNET>
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 <ROODE@BIONET-20.ARPA>
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 <ERIC@FRECP11>
Subject:      BITNET REDIST LISTS
To:           <Header-people@MC.LCS.MIT.EDU>

>
> 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 <shaver%iowa-state.csnet@RELAY.CS.NET>
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 <shaver%iowa-state.csnet@RELAY.CS.NET>
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: <laubach@hpcera>
Received: by hpcera ; Wed, 17 Jun 87 11:13:31 pdt
Date: Wed, 17 Jun 87 11:13:31 pdt
From: Mark Laubach <laubach%hpcera@hplabs.HP.COM>
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 <JPALME%bitnet.qzcom@Cs.Ucl.AC.UK>
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 <Steve.Kille@Cs.Ucl.AC.UK>

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 <GUMBY@AI.AI.MIT.EDU>
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 <Steve.Kille at Cs.Ucl.AC.UK>
Message-ID: <219682.870625.GUMBY@AI.AI.MIT.EDU>

    Date: Thu, 25 Jun 87 11:44:38 +0100
    From: Steve Kille <Steve.Kille at Cs.Ucl.AC.UK>

    ... 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 <rlk@Think.COM>
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 <GUMBY@ai.ai.mit.edu>

   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-<list_name> 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: <owner>
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-<list>.
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             <GRZ027%DBNGMD21.BITNET@BERKELEY.EDU>
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 <craig@NNSC.NSF.NET>


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 <ROODE@BIONET-20.ARPA>
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" <JPALME@QZCOM.BITNET>
Reply-To:    "Jacob Palme QZ" <JPALME@QZCOM.BITNET>
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 <GUMBY@ai.ai.mit.edu>
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 <Steve.Kille@Cs.Ucl.AC.UK>



 >From:  David Vinayak Wallace <GUMBY@edu.mit.ai.ai>
 >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 <GUMBY@AI.AI.MIT.EDU>
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 <Steve.Kille at Cs.Ucl.AC.UK>
Message-ID: <221294.870629.GUMBY@AI.AI.MIT.EDU>

    Date: Mon, 29 Jun 87 08:05:57 +0100
    From: Steve Kille <Steve.Kille at Cs.Ucl.AC.UK>

     >From:  David Vinayak Wallace <GUMBY@edu.mit.ai.ai>
     >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 <BLARSON@ECLA.USC.EDU>
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 <GUMBY@edu.mit.ai.ai>
     >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 <GUMBY@ai.ai.mit.edu>
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 <Steve.Kille@Cs.Ucl.AC.UK>



 >From:  David Vinayak Wallace <GUMBY@edu.mit.ai.ai>
 >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" <JTW@AI.AI.MIT.EDU>
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 <craig@SH.CS.NET>


> 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 <PKARP@SRI-WARBUCKS.ARPA>
Subject: list maintainers vs senders
To: header-people@MC.LCS.MIT.EDU
Message-ID: <552116414.0.PKARP@SRI-WARBUCKS.ARPA>
Mail-System-Version: <VAX-MM(215)+TOPSLIB(126)+PONY(165)@SRI-WARBUCKS.ARPA>

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" <JPALME@QZCOM.BITNET>
Reply-To:    "Jacob Palme QZ" <JPALME@QZCOM.BITNET>
To:          "ARPA Internet Mail Interest List"
              <header-people@AI.AI.MIT.EDU>
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: <SRA.12315072603.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   Craig Partridge <craig@SH.CS.NET>
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 <craig@SH.CS.NET>

    Date: Tue, 30 Jun 87 16:44:14 -0400
    From: Craig Partridge <craig@SH.CS.NET>
    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 <craig@NNSC.NSF.NET>


>        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 <kenw%noah.arc.cdn%ubc.csnet@RELAY.CS.NET>
To: Peter Karp <PKARP@WARBUCKS.AI.SRI.COM>
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: <SRA.12315341765.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   Craig Partridge <Craig@NNSC.NSF.NET>
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 <craig@SH.CS.NET>
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" <kent@sonora.dec.com>
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 <MRC%PANDA.COM@SUMEX-AIM.Stanford.EDU>
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 <PKARP@IU.AI.SRI.COM>
Subject: Mailing lists
To: header-people@MC.LCS.MIT.EDU
Message-ID: <552677345.0.PKARP@IU.AI.SRI.COM>
Mail-System-Version: <VAX-MM(215)+TOPSLIB(126)+PONY(165)@IU.AI.SRI.COM>

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" <JPALME@QZCOM.BITNET>
Reply-To:    "Jacob Palme QZ" <JPALME@QZCOM.BITNET>
To:          "ARPA Internet Mail Interest List"
              <header-people@AI.AI.MIT.EDU>
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" <JPALME@QZCOM.BITNET>
Reply-To:    "Jacob Palme QZ" <JPALME@QZCOM.BITNET>
To:          "ARPA Internet Mail Interest List"
              <header-people@AI.AI.MIT.EDU>
Subject:     X.400/88 and failure messages

> FROM: Mark Crispin <MRC%PANDA.COM@SUMEX-AIM.Stanford.EDU>
>
>      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" <JPALME@QZCOM.BITNET>
Reply-To:    "Jacob Palme QZ" <JPALME@QZCOM.BITNET>
To:          "ARPA Internet Mail Interest List"
              <header-people@AI.AI.MIT.EDU>
Subject:     list maintainers vs senders

> FROM: Peter Karp <PKARP@SRI-WARBUCKS.ARPA>
>
> 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 <rlk@Think.COM>
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" <JPALME@QZCOM.BITNET>

   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 <bsaibis%lsu.edu@RELAY.CS.NET>
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: <bsaibis@lsu.edu>
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 <QQ43%UK.AC.LIVERPOOL.IBM@ac.uk>
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: <WANCHO.12323984933.BABYL@SIMTEL20.ARPA>
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
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"  <JPALME%QZCOM.BITNET@MITVMA.MIT.EDU>
Reply-To: "AMIGO Advanced Group (communication)"
  <AMIGOADV%QZCOM.BITNET@MITVMA.MIT.EDU> ,
   "RARE WG8 Management of application services"
  <C477%QZCOM.BITNET@MITVMA.MIT.EDU> ,
   "RARE WG4 Network Management and Operation"
  <C394%QZCOM.BITNET@MITVMA.MIT.EDU> ,
   "Reseaux Associes (pour la) Recherche Europeene (RARE)"
  <RAREOPEN%QZCOM.BITNET@MITVMA.MIT.EDU> ,
    Reseaux_Associes_Recherche_Europeene@EUROKOM.UUCP
To: "BITNIC MAIL-L List" <MAIL-L%BITNIC.BITNET@MITVMA.MIT.EDU> ,
    amigo_group@XPS.GMD.DBP.DE ,
   "AMIGO Advanced Group (communication)"
  <AMIGOADV%QZCOM.BITNET@MITVMA.MIT.EDU> ,
   "RARE WG8 Management of application services"
  <C477%QZCOM.BITNET@MITVMA.MIT.EDU> ,
   "RARE WG4 Network Management and Operation"
  <C394%QZCOM.BITNET@MITVMA.MIT.EDU> ,
   "Reseaux Associes (pour la) Recherche Europeene (RARE)"
  <RAREOPEN%QZCOM.BITNET@MITVMA.MIT.EDU> ,
    Reseaux_Associes_Recherche_Europeene@EUROKOM.UUCP ,
    mhsnews@VAX.RUNIT.UNIT.UNINETT ,
    HEADER-PEOPLE@AI.AI.MIT.EDU
bcc: "David Lord" <PFKDN%CERNVM.BITNET@MITVMA.MIT.EDU> ,
   "John Ogilvie" <ogilvie@VXGIFT.CERN> ,
   "Giorgio Heiman" <heiman@VXGIFT.CERN> ,
    amiadv_emu@EMU.GIPSI.FR ,
   "Petter Kongshaug" <kongshaug@VAX.RUNIT.UNIT.UNINETT>
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 pattern> NAME )

   where <name pattern> can be a name or part of a name according to
   the RFC822 syntax for address, for example
   "Jacob Palme"
   "Jacob Palme" <JPALME@QZCOM.BITNET>
   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 <name pattern> matches one single user or conference.

   Command syntax:

     DESCRIBE ( <name pattern> [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 <RAREDIR@QZCOM.BITNET>, 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 <JPALME@QZCOM.BITNET>, 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 (<conference name> * REC [<N>] )

   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 (<conference name> * REC )

   to delete yourself from the conference.

   Where the syntax for <conference name> is the same as for <name pattern>
   above, and <N> 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" <JPALME@QZCOM.BITNET>.

   Users on other networks can request the same information from
   "Steve Benford" <sdb@cs.nott.ac.uk>.



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 <ROODE@BIONET-20.ARPA>
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 <irene@NSS.Cs.Ucl.AC.UK>
To:       David Roode <ROODE@bionet-20.arpa>
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 <ROODE@BIONET-20.ARPA>
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 <irene@NSS.Cs.Ucl.AC.UK>" 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 <ROODE@BIONET-20.ARPA>
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 <irene@NSS.Cs.Ucl.AC.UK>" 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 <irene@NSS.Cs.Ucl.AC.UK>
To:       David Roode <ROODE@bionet-20.arpa>
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 <ROODE@arpa.bionet-20>
Subject: Re:  Help with address
To: irene@uk.ac.ucl.cs.nss
cc: header-people@edu.mit.lcs.mc,
    QQ43 <QQ43%uk.ac.liverpool.ibm@uk.ac.ucl.cs.nss>, bionet@arpa.bionet-20
In-Reply-To: Message from "Postie <irene@NSS.Cs.Ucl.AC.UK>" 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 <wmartin@ALMSA-1.ARPA>
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 <Postmaster%vms.CIS.PITTSBURGH.EDU@VB.CC.CMU.EDU>
> 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 <mnetor!genat!george@uunet.uu.NET>
> 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 <LDW@USCMVSA>
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 <R.LARSON%FNS1@ECLA.USC.EDU>
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: <MAILMAN%FNS1.#USCnet@ECLA.USC.EDU>

   ----- Transcript of session follows -----
bad system name: PORTAL
uux failed. code 68
550 <PORTAL!CUP.PORTAL.COM!TMANOS>... Host unknown

   ----- Unsent message follows -----
Return-Path: <MAILMAN%FNS1.#USCnet@ECLA.USC.EDU>
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 <Mailman%FNS1@ECLA.USC.EDU>
To: <PORTAL!CUP.PORTAL.COM!TMANOS%SUN.COM@ECLA.USC.EDU>
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 <OWENSJ%VTVM1.BITNET@MITVMA.MIT.EDU>
Subject:      Re: bad addresses from uucp
To:           Header-People Discussion <HEADER-PEOPLE@MC.LCS.MIT.EDU>
Cc:           Bob Larson <R.LARSON%FNS1@ECLA.USC.EDU>
In-Reply-To:  Message of Mon, 09 Nov 87 13:09:28 PST from
 <R.LARSON%FNS1@ECLA.USC.EDU>

>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 <OWENSJ%VTVM1.BITNET@MITVMA.MIT.EDU>
Subject:      Re:  Domain servers, mail exchangers, etc.
To:           Header-People Discussion <HEADER-PEOPLE@MC.LCS.MIT.EDU>,
              Info-Nets List <Info-Nets@Think.COM>
Cc:           Bill Wells <Postmaster@jade.Berkeley.EDU>
In-Reply-To:  Message of Fri, 13 Nov 87 12:40:19 pst from
 <netinfo%garnet.Berkeley.EDU@violet.berkeley.edu>

>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 <unipress!ta2%edison.ge.com@rutgers.edu>
This originated as
        From: Tom Allebrandi <ta2@edison.GE.COM>
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 <unipress!ta2@edison.ge.com>
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 <USER@HOST.ARPA>
Unipress again prepends its address, giving
        rmail edison!unipress!ta2
        From: Joe User <unipress!USER@HOST.ARPA>
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 <MJL%DGAIPP1S.BITNET@MITVMA.MIT.EDU>
To:      Header-People Discussion <HEADER-PEOPLE@MC.LCS.MIT.EDU>
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 <date-time> 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 <date-time>, 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 <MJL%DGAIPP1S.BITNET@MITVMA.MIT.EDU>
To:      Header-People Discussion <HEADER-PEOPLE@MC.LCS.MIT.EDU>
Subject: Interpretation of local time offset (<zone>) in RFC822

In the date field of a message, RFC822 defines a <zone>. 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 <date-time>, 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 <date-time> 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 <MJL%DGAIPP1S.BITNET@MITVMA.MIT.EDU>
Reply-To:    Martin Lottermoser <MJL%DGAIPP1S.BITNET@MITVMA.MIT.EDU>
To:          Dave Taylor <taylor%atom@hplabs.HP.COM>
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 (<zone>) 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 <offset> 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  <WWB.TYM@OFFICE-1.ARPA>
Subject: Re: Interpretation of local time offset (<zone>) in RFC822
To: Martin Lottermoser <MJL%DGAIPP1S.BITNET@MITVMA.MIT.EDU>
Cc: HEADER-PEOPLE@MC.LCS.MIT.EDU
Message-ID: <TYM-WWB-D10AB@OFFICE-1>

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   <WWB.TYM@OFFICE-1.ARPA>


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:        <header-people@mc.lcs.mit.edu>
From:      "June Genis" <GA.JRG%STANFORD.BITNET@MITVMA.MIT.EDU>
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: <WANCHO.12370645951.BABYL@SIMTEL20.ARPA>
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
To:   June Genis <GA.JRG%STANFORD.BITNET@MITVMA.MIT.EDU>
Cc:   <header-people@MC.LCS.MIT.EDU>, WANCHO@SIMTEL20.ARPA
Subject: revising RFC822: heresy or possibility?
In-reply-to: Msg of 29 Jan 1988  17:53-MST from June Genis <GA.JRG%STANFORD.BITNET at MITVMA.MIT.EDU>

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" <JPALME%QZCOM.BITNET@MITVMA.MIT.EDU>
Reply-To:    "Jacob Palme QZ" <JPALME%QZCOM.BITNET@MITVMA.MIT.EDU>
To:          "ARPA Internet Mail Interest List"
              <header-people@AI.AI.MIT.EDU>,
             "BITNIC MAIL-L List" <MAIL-L@BITNIC>
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 <PKARP@IU.AI.SRI.COM>
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: <VAX-MM(215)+TOPSLIB(126)+PONY(205)@IU.AI.SRI.COM>

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: <SRA.12370832658.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   "June Genis" <GA.JRG%STANFORD.BITNET@MITVMA.MIT.EDU>
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" <GA.JRG%STANFORD.BITNET@MITVMA.MIT.EDU>

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: <SRA.12374181810.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
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" <slevy@uc.msc.umn.edu>
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 <SRA.12374181810.BABYL@XX.LCS.MIT.EDU>)

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 <MRC@PANDA.PANDA.COM>
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 <TVR%CCRMA-F4@SAIL.Stanford.EDU>
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 <MRC@PANDA.PANDA.COM>
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: <SRA.12374734480.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   Mark Crispin <MRC@PANDA.PANDA.COM>, 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 <MRC@PANDA.PANDA.COM>
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: <WANCHO.12374808909.BABYL@SIMTEL20.ARPA>
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
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 <MRC at PANDA.PANDA.COM>

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 <AI.CLIVE@MCC.COM>
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 <MRC@PANDA.PANDA.COM>
	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: <WANCHO.12375036842.BABYL@SIMTEL20.ARPA>
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
To:   Header-People@MC.LCS.MIT.EDU, TCP-IP@SRI-NIC.ARPA
Cc:   "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
Subject: Correction on MILNET packet charges
In-reply-to: Msg of 14 Feb 1988  20:35-MST from Frank J. Wancho <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 <MRC@PANDA.PANDA.COM>
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 <AI.CLIVE@MCC.COM>
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 <craig@NNSC.NSF.NET>


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 <MRC@PANDA.PANDA.COM>
Subject: Re: Trying multiple addresses
To: craig@NNSC.NSF.NET
cc: header-people@mc.lcs.mit.edu
In-Reply-To: Message from "Craig Partridge <craig@NNSC.NSF.NET>" 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 <MRC@PANDA.PANDA.COM>
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 <Alpern@IBM.COM>
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 <MRC@panda.panda.com>
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 <pvm@venera.isi.edu>

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 <gr@bnl.arpa>
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 <DSDC-SDT2@GUNTER-ADAM.ARPA>
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
   <Cienes/Valpa; 88GATE.CLEAR>

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:<xabne@athena.mit.edu>
<<< 550 <alive@athena.mit.edu>
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
<Cienes/Valpa; 88GATE.CLEAR>
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 <WCSWR%CARLETON.BITNET@MITVMA.MIT.EDU>
To:       <header-people@mc.lcs.mit.EDU>
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 <aaa!bbb@ccc.uucp>, 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 <WCSWR@CARLETON.BITNET>

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: <SRA.12387665661.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To:   Walter Roberson <WCSWR%CARLETON.BITNET@MITVMA.MIT.EDU>
Cc:   header-people@MC.LCS.MIT.EDU
Subject: ! and @ -- which RFC ?

    Date: Saturday, 2 April 1988  09:17-EST
    From: Walter Roberson <WCSWR%CARLETON.BITNET@MITVMA.MIT.EDU>

    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 <aaa!bbb@ccc.uucp>, 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 <DSDC-SDT2@GUNTER-ADAM.ARPA>
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 <craig@NNSC.NSF.NET>


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 <WCSWR%CARLETON.BITNET@mitvma.mit.edu>
	To: <header-people@mc.lcs.mit.edu>
	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 <aaa!bbb@ccc.uucp>, 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 <WCSWR@CARLETON.BITNET>
	
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
<aaa!bbb@ccc.uucp> 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:
<ccc!aaa!bbb@gateway-domain-name> 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 <PKARP@IU.AI.SRI.COM>
Subject: ! and @
To: header-people@MC.LCS.MIT.EDU
Message-ID: <576272437.0.PKARP@IU.AI.SRI.COM>
Mail-System-Version: <VAX-MM(215)+TOPSLIB(126)+PONY(205)@IU.AI.SRI.COM>

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 <AA02470@BLOOM-BEACON.MIT.EDU>; 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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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 <AA12914@BLOOM-BEACON.MIT.EDU>; 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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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 <AA15304@BLOOM-BEACON.MIT.EDU>; 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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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: <jsol@bu-it.bu.edu>
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 <AA17543@BLOOM-BEACON.MIT.EDU>; 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 <AA17512@BLOOM-BEACON.MIT.EDU>; 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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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 <AA18949@BLOOM-BEACON.MIT.EDU>; 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 <AA19018@BLOOM-BEACON.MIT.EDU>; 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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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 <AA20047@BLOOM-BEACON.MIT.EDU>; 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 <AA20449@BLOOM-BEACON.MIT.EDU>; 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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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 <AA21278@BLOOM-BEACON.MIT.EDU>; 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 <AA21718@BLOOM-BEACON.MIT.EDU>; 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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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 <AA21931@BLOOM-BEACON.MIT.EDU>; 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 <AA23099@BLOOM-BEACON.MIT.EDU>; 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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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 <AA25367@BLOOM-BEACON.MIT.EDU>; 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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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 <AA24284@BLOOM-BEACON.MIT.EDU>; 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: <jsol@bu-it.bu.edu>
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" <postmaster@utadnx.cc.utexas.edu>
Subject: Mail Delivery Problem
To: <jsol%bu-it.bu.edu@mc.lcs.mit.edu>

 ----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 <AA27586@BLOOM-BEACON.MIT.EDU>; 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 <AA27070@BLOOM-BEACON.MIT.EDU>; 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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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 <AA28609@BLOOM-BEACON.MIT.EDU>; 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" <postmaster@utadnx.cc.utexas.edu>
Subject: Mail Delivery Problem
To: <jsol%bu-it.bu.edu@mc.lcs.mit.edu>

 ----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 <AA01905@BLOOM-BEACON.MIT.EDU>; 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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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 <AA01234@BLOOM-BEACON.MIT.EDU>; 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 <AA02388@BLOOM-BEACON.MIT.EDU>; 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" <postmaster@utadnx.cc.utexas.edu>
Subject: Mail Delivery Problem
To: <jsol%bu-it.bu.edu@mc.lcs.mit.edu>

 ----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 <AA03446@BLOOM-BEACON.MIT.EDU>; 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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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 <AA06223@BLOOM-BEACON.MIT.EDU>; 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" <postmaster@utadnx.cc.utexas.edu>
Subject: Mail Delivery Problem
To: <jsol%bu-it.bu.edu@mc.lcs.mit.edu>

 ----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 <AA07557@BLOOM-BEACON.MIT.EDU>; 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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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  <WBD.MDC@OFFICE-8.ARPA>
Subject: Ah come on!!! can't someone stop this looping mail item
To: header-people@mc.lcs.mit.edu
Message-ID: <MDC-WBD-DN98L@OFFICE-8>
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 <AA14248@BLOOM-BEACON.MIT.EDU>; 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: <May.10.13.32.12.1988.20376@topaz.rutgers.edu>
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: <M1988$004590.MEDIN-T.MEDIN-T@SHARK.NOSC.MIL>
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 <HANK%TAUNIVM.BITNET@MITVMA.MIT.EDU>
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 <msmith@topaz.rutgers.edu>

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 <AA21524@BLOOM-BEACON.MIT.EDU>; 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 <AA02545@BLOOM-BEACON.MIT.EDU>; 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 <AA07979@BLOOM-BEACON.MIT.EDU>; 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 <AA07979@BLOOM-BEACON.MIT.EDU>; 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 <AA12562@BLOOM-BEACON.MIT.EDU>; 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 <vixie@decwrl.dec.com>

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 <AA16623@BLOOM-BEACON.MIT.EDU>; 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: <uunet!hodge!denwa!stb!michael>
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 <AA18269@BLOOM-BEACON.MIT.EDU>; 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                         <david@ms.uky.edu>
<---- 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 <wmartin@ALMSA-1.ARPA>
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@<some ARPA host here>"

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" <MAP@AI.AI.MIT.EDU>
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 <wmartin at ALMSA-1.ARPA>
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 <AA26945@BLOOM-BEACON.MIT.EDU>; 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 <or> ...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 <bradley%hplkab@hplabs.HP.COM>
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 <AA28059@BLOOM-BEACON.MIT.EDU>; 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: <rlk@Think.COM>
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 <rlk@Think.COM>
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 <rlk@think.com>
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 <KLENSIN@INFOODS.MIT.EDU>
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 <AA13896@BLOOM-BEACON.MIT.EDU>; 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 <AA18196@BLOOM-BEACON.MIT.EDU>; 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: <Aug.3.10.51.26.1988.2622@topaz.rutgers.edu>
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: <SRA.12419512003.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
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

<Begin censored header list>
       [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]
<End censored header list>

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 <AA23756@BLOOM-BEACON.MIT.EDU>; 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 <AA23493@BLOOM-BEACON.MIT.EDU>; 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 <AA24153@BLOOM-BEACON.MIT.EDU>; 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 <AA26602@BLOOM-BEACON.MIT.EDU>; 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-<field> 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 <AA26529@BLOOM-BEACON.MIT.EDU>; 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 <jordan@ads.com>
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 <AA07816@BLOOM-BEACON.MIT.EDU>; 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 <AA08260@BLOOM-BEACON.MIT.EDU>; 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 <AA19270@BLOOM-BEACON.MIT.EDU>; 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 <AA26084@BLOOM-BEACON.MIT.EDU>; 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 <sun!vixie.uu.net!paul>

---
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 <sun!vixie!paul>

---
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 <sun!vixie!paul>

---
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 <AA23565@BLOOM-BEACON.MIT.EDU>; 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 <AA24480@BLOOM-BEACON.MIT.EDU>; 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 <sun!vixie.uu.net!paul>
>
>---
>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 <sun!vixie!paul>
>
>---
>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                         <david@ms.uky.edu>
<---- 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 <AA29112@BLOOM-BEACON.MIT.EDU>; 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 <AA00882@BLOOM-BEACON.MIT.EDU>; 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 <sun!vixie.uu.net!paul>
# >
# >---
# >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 <sun!vixie!paul>
# >
# >---
# >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 <AA08568@BLOOM-BEACON.MIT.EDU>; 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 <MAILER-DAEMON@SUN.COM>
] 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 <vixie!paul>... Host unknown
] 
]    ----- Unsent message follows -----
] Return-Path: <david@ms.uky.edu>
] 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 <david@ms.uky.edu>
] 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                         <david@ms.uky.edu>
] <---- 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                         <david@ms.uky.edu>
<---- 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 <AA13419@BLOOM-BEACON.MIT.EDU>; 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 <AA24170@BLOOM-BEACON.MIT.EDU>; 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 <AA28869@BLOOM-BEACON.MIT.EDU>; 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: <Aug.4.13.20.49.1988.373@pilot.njin.net>, <3674@palo-alto.DEC.COM>, <Aug.5.11.45.54.1988.16554@pilot.njin.net>
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 <AA28912@BLOOM-BEACON.MIT.EDU>; 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 <AA01700@BLOOM-BEACON.MIT.EDU>; 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 <AA19567@BLOOM-BEACON.MIT.EDU>; 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                         <david@ms.uky.edu>
<---- 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  <WBD.MDC@OFFICE-8.ARPA>
Subject: Re: Confirmation of Recipt
To: Shores%UMASS.BITNET@MITVMA.MIT.EDU (Ken Shores)
Cc: header-people@mc.lcs.mit.edu
Message-ID: <MDC-WBD-E83PJ@OFFICE-8>
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: <rlk@Think.COM>
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 <rlk@Think.COM>
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 <rlk@think.com>
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 <AA23083@BLOOM-BEACON.MIT.EDU>; 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 <david@ms.uky.edu> 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 <AA25841@BLOOM-BEACON.MIT.EDU>; 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 <wisner@killer.dallas.tx.us>

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 <texsun!wisner%killer.dallas.tx.us@Sun.COM>

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 <AA28525@BLOOM-BEACON.MIT.EDU>; 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 <AA07302@BLOOM-BEACON.MIT.EDU>; 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 <AA11508@BLOOM-BEACON.MIT.EDU>; 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 <Gumby@MCC.COM>
Subject: "Communications is important."
To: David Herron -- One of the vertebrae <david@g.ms.uky.edu>
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 <AA29616@BLOOM-BEACON.MIT.EDU>; 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 <AA12998@BLOOM-BEACON.MIT.EDU>; 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 <AA17957@BLOOM-BEACON.MIT.EDU>; 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 <AA21616@BLOOM-BEACON.MIT.EDU>; 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: <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu>
References: <3674@palo-alto.DEC.COM>, <Aug.5.11.45.54.1988.16554@pilot.njin.net>, <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 <AA24058@BLOOM-BEACON.MIT.EDU>; 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: <Aug.5.11.45.54.1988.16554@pilot.njin.net>, <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 <AA24236@BLOOM-BEACON.MIT.EDU>; 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 <AA24545@BLOOM-BEACON.MIT.EDU>; 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: <Aug.5.11.45.54.1988.16554@pilot.njin.net>, <3732@palo-alto.DEC.COM>, <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu> 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 <AA24828@BLOOM-BEACON.MIT.EDU>; 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: <Aug.11.20.54.50.1988.29090@aramis.rutgers.edu>
References: <676@bacchus.DEC.COM>, <881@vsi1.UUCP>, <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

[news posting]

In article <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu>, 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 <AA26241@BLOOM-BEACON.MIT.EDU>; 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: <Aug.5.11.45.54.1988.16554@pilot.njin.net>, <3732@palo-alto.DEC.COM>, <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu> 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 <AA02314@BLOOM-BEACON.MIT.EDU>; 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>, <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu>, <Aug.11.20.54.50.1988.29090@aramis.rutgers.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <Aug.11.20.54.50.1988.29090@aramis.rutgers.edu> 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 <AA08873@BLOOM-BEACON.MIT.EDU>; 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: <Aug.5.11.45.54.1988.16554@pilot.njin.net>, <3732@palo-alto.DEC.COM>, <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu> 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 <steve@note.nsf.gov>
To:       Jon Solomon <jsol@BU-CS.BU.EDU>
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: <jsol>
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 <steve@note.nsf.gov>
To:       Jon Solomon <jsol@BU-IT.BU.EDU>
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                        <CSYSMAS%OAC.UCLA.EDU@MITVMA.MIT.EDU>
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 <AA22786@BLOOM-BEACON.MIT.EDU>; 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 <AA22636@BLOOM-BEACON.MIT.EDU>; 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 <AA22803@BLOOM-BEACON.MIT.EDU>; 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>, <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu>
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 <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu>, 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 <AA23721@BLOOM-BEACON.MIT.EDU>; 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>, <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu>, <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 <AA23729@BLOOM-BEACON.MIT.EDU>; 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: <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu>, <22608@amdcad.AMD.COM>, <Aug.11.20.43.05.1988.26993@NET.BIO.NET>
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 <Aug.11.20.43.05.1988.26993@NET.BIO.NET>
					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 <AA23714@BLOOM-BEACON.MIT.EDU>; 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>, <Aug.11.16.57.31.1988.21678@topaz.rutgers.edu>, <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 <AA00828@BLOOM-BEACON.MIT.EDU>; 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 <AA04943@BLOOM-BEACON.MIT.EDU>; 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: <SRA.12422125273.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
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 <stef@ics.uci.edu>
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 <AA07055@BLOOM-BEACON.MIT.EDU>; 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>, <Aug.11.20.43.05.1988.26993@NET.BIO.NET>
Sender: header-people-request@mc.lcs.mit.edu
To: header-people@mc.lcs.mit.edu

In article <Aug.11.20.43.05.1988.26993@NET.BIO.NET>, 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 <AA28035@EDDIE.MIT.EDU>; 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 <m0dlay2-00000CC@amdahl.uts.amdahl.com>; Sun, 14 Aug 88 20:57 PDT
Message-Id: <m0dlay2-00000CC@amdahl.uts.amdahl.com>
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 <Send smail related Email to smail-info-request@uts.amdahl.com> /\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 <AA11597@BLOOM-BEACON.MIT.EDU>; 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: <Aug.14.22.18.45.1988.9347@NET.BIO.NET>
References: <881@vsi1.UUCP>, <Aug.11.20.43.05.1988.26993@NET.BIO.NET>, <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 <AA28338@BLOOM-BEACON.MIT.EDU>; 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 <Lovstrand.EuroPARC@Xerox.COM>
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: <kehres>
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 <craig@SH.CS.NET>


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/<user>, /bin/mail
is part of the MTA, but /usr/spool/mail/<user> 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 <Crispin@SUMEX-AIM.Stanford.EDU>
Subject: Re: routing, 822, etc
To: Craig Partridge <craig@SH.CS.NET>
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 <craig@SH.CS.NET> 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 <Crispin@SUMEX-AIM.Stanford.EDU>
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: <kehres>
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 <Crispin@SUMEX-AIM.Stanford.EDU>
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 <KLENSIN@INFOODS.MIT.EDU>
Subject: RE:  time madness
To: Mark Crispin <Crispin@SUMEX-AIM.STANFORD.EDU>
X-VMS-Mail-To: EXOS%"Mark Crispin <Crispin@SUMEX-AIM.Stanford.EDU>"
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: <rlk@Think.COM>
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 <rlk@Think.COM>
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 <rlk@think.com>
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 <AA17316@BLOOM-BEACON.MIT.EDU>; 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: <kehres>
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/<user>, /bin/mail
> is part of the MTA, but /usr/spool/mail/<user> 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 <AA29018@BLOOM-BEACON.MIT.EDU>; 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: <Aug.11.20.43.05.1988.26993@NET.BIO.NET>, <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 <AA00384@BLOOM-BEACON.MIT.EDU>; 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: <Aug.11.20.43.05.1988.26993@NET.BIO.NET>, <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 <AA00778@BLOOM-BEACON.MIT.EDU>; 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: <aazHKe6cUJ1010w5/fM@amdahl.uts.amdahl.com>
References: <Aug.11.20.43.05.1988.26993@NET.BIO.NET>, <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 <AA07829@BLOOM-BEACON.MIT.EDU>; 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 <werner@rascal.ics.utexas.edu>
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: <CMM.0.88.589153987.werner@rascal.ics.utexas.edu>

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 <Athena%MAINE.BITNET@MITVMA.MIT.EDU>
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 <AA24070@BLOOM-BEACON.MIT.EDU>; 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 <AA22317@BLOOM-BEACON.MIT.EDU>; 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 <ehrlich@blitz.cs.psu.edu> | 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 <AA25416@BLOOM-BEACON.MIT.EDU>; 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 <AA02627@EDDIE.MIT.EDU>; 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: <amdahl!chongo@ames.UUCP>
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 <m0e13im-0000A7C@amdahl.uts.amdahl.com>; Mon, 26 Sep 88 12:41 PDT
Message-Id: <m0e13im-0000A7C@amdahl.uts.amdahl.com>
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 <sorry for the bother> /\**/\

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 <AA06361@BLOOM-BEACON.MIT.EDU>; 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 <jordan@ads.com> 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 <ehrlich@blitz.cs.psu.edu> | 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 <AA06728@BLOOM-BEACON.MIT.EDU>; 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 <AA10323@BLOOM-BEACON.MIT.EDU>; 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" <CENT@AI.AI.MIT.EDU>
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 <Mailer@XX.LCS.MIT.EDU>
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 <AA01547@BLOOM-BEACON.MIT.EDU>; 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 <Mailer@XX.LCS.MIT.EDU>
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 <AA20236@BLOOM-BEACON.MIT.EDU>; 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
-------

