Path: utzoo!utgpu!watserv1!watmath!att!linac!uwm.edu!zaphod.mps.ohio-state.edu!usc!orion.oac.uci.edu!ucivax!gateway
From: jsweet@ICS.UCI.EDU (Jerry Sweet)
Newsgroups: comp.protocols.iso.x400.gateway
Subject: RFC-822 envelopes and X.400
Message-ID: <11477.667556523@ics.uci.edu>
Date: 26 Feb 91 08:23:49 GMT
Lines: 43
Approved: usenet@ICS.UCI.EDU


I've been seing a problem wherein mail re-sent by "mailmod@ics.uci.edu"
to MHSNews or to IFIP-Gtwy appears to confuse some X.400 UAs about to
whom to reply.  Specifically, reply mail is sent not to the originator
of the message, but back to "mailmod".  This is not the desired
result, and I want to know what, if anything, can be done about it.

("Mailmod" is secretly the user behind the North American
mhsnews-request and ifip-gtwy-request addresses.  The "mailmod" user
forwards messages received from the moderated USENET groups
comp.protocols.iso.x400 and comp.protocols.iso.x400.gateway, among
other tasks.  A group of us is responsible for handling mail arriving
for "mailmod".)

Mail re-sent by "mailmod" leaves the original RFC 822 "From" header
component intact, but unavoidably adds RFC 822 "ReSent-From" and
"ReSent-Sender" components.  Presumably, the envelope of the re-sent
message indicates that "mailmod" is the re-sender.

One or more of the following problems are probably occurring:

  - The envelope information is being retained in some form that
	leads X.400 UAs to believe that the originator of the
	message is "mailmod", rather than the address recorded
	in the RFC-822 "From" component.
  or

  - Some unfortunate header mapping is occuring that leads some X.400
	UAs to use the contents of the ReSent-From or ReSent-Sender
	components instead of the "From" component.
  or

  - I'm seeing the results of "pilot error"; X.400 UA users are simply
	replying to the wrong addresses for reasons known only to them.

The end result is that mail in reply to re-sent messages often winds up
going to "mailmod" instead of to the mailing lists or to the originators
of the messages.  This is bad.  I don't want this to happen.  It makes
me toss and turn at night.  ;-)

Is the problem I've described a known behavior of RFC 822/X.400
gateways?  Perhaps it results from some misguided requirements for
address authentication?