jsweet@ICS.UCI.EDU (Jerry Sweet) (02/26/91)
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?Christian.Huitema@mirsa.inria.fr (Christian Huitema) (02/26/91)
One hypothesis is extremely plausible: - 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. The concept of "ReSent-From" and "ReSent-Sender" does not exist in X.400; however, it is quite near from the "AuthorizingUser" IPM header field, which in turns gets mapped to something like "From" or "Sender" by some UAs. You could perhaps avoid the problem by one of the following actions: 1) Do not place any "ReSent-From" or "ReSent-Sender" in the header. The info is in the envelop, and that should be enough. 2) If you place a "Resent-From", then cook-up a "Reply-To" field from the original "From/Sender" field -- and do it carefully, so as to avoid multiple entries to same list... Christian Huitema
jsweet@ICS.UCI.EDU (Jerry Sweet) (02/26/91)
Christian suggests: > 1) Do not place any "ReSent-From" or "ReSent-Sender" in the header. The info > is in the envelop, and that should be enough. Ah, but the envelope is NOT what should be used if it reflects the re-sender, "mailmod". Also, there is NO way in RFC 822 to avoid ReSent-From or ReSent-Sender, although there may be tricky ways to bypass the automatic additions of these components by the posting agent -- something I'd prefer to avoid, but not completely unwilling to try if necessary. > 2) If you place a "Resent-From", then cook-up a "Reply-To" field from the > original "From/Sender" field -- and do it carefully, so as to avoid multiple > entries to same list... Cooking up a Reply-To component sounds not unreasonable. Anybody know if Reply-To (or to whatever X.400 component it gets mapped) takes precedence?