[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference abbott::teamlinks_windows

Title:TeamLinks for Windows
Notice:Kit and ECO locations: See replies to note 8.o note 8.
Moderator:ORION::chayna.zko.dec.com::tamara::eppesAN
Created:Mon Aug 28 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2238
Total number of notes:9650

2212.0. "Routing address missing after decoding a message" by BACHUS::bro-ws-1565.bro.dec.com::brssws::VANDENBOSSCH () Wed May 21 1997 11:33

Hi,

We are experiencing the next problem at a customer site :

After decoding (File - Decode Message) an incoming message, the routing address from the sender is missing in the "Show Full 
Header" information of the result message.

This means that a "Reply" to this message is not possible anymore.

Any idea how to get the routing address back ?

Many thanks,
Christel (MCS - Brussels)

T.RTitleUserPersonal
Name
DateLines
2212.1please provide undecoded message contentsTAMARA::qwert.zko.dec.com::TLEXCH::John McClungJohn McClung, 381-2774Wed May 21 1997 13:595
Could you provide us with the contents of the message before it is decoded?
Read the message, copy the entire contents, and paste it in here a reply.

Thanks,
John
2212.2Requested infoBACHUS::bro-ws-1565.bro.dec.com::brssws::VANDENBOSSCHWed May 21 1997 14:2147
Hallo, thanks for your quick response.
As you asked, please find hereafter the contents of the
incoming message (before doing the decode).  Since the attachment
is very large, I could not paste the complete encoded info.
I suppose you need the header information :

----------------------------------------------------

Subject: From TL to TL with mime attachm.
To: Christel Van Den Bossche             ( VANDENBOSSCH )
From: Christel Van Den Bossche
Importance: normal
Sensitivity: Company-Confidential
Priority: normal
Content-Return: prohibited
Content-Type: multipart/mixed;
	boundary="mw00000001l00000000l00000046l00000000l00003A2Blmw"
X-Mailer: TeamLinks V2.7
MIME-Version: 1.0

--mw00000001l00000000l00000046l00000000l00003A2Blmw
Content-Type: text/plain; charset=ISO-8859-1; Type=Text
Content-Transfer-Encoding: 7bit
X-TLformat: TEXT

With mime attachm.

--mw00000001l00000000l00000046l00000000l00003A2Blmw
Content-Type: application/msword; name="TL.doc"; Type=MS-Word-6
Content-Description: D:\MYFILE~1\LOCATI~1.DOC
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="TL.DOC"
X-TLformat: WINWORD6

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAIwAAAAAA
AAAAEAAAJQAAAAEAAAD+////AAAAACIAAAD/////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
///////////////////////////////////spcEARwAJBAAAABK/AAAAAAAAEAAAAAAABAAA
uAUAAA4AYmpiao7ZjtkAAAAAAAAAAAAAAAAAAAAAAAAJBBYAJRIAAOyzAQDsswEAuAEAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A

2212.3restriction when MIME encoding using MailWorks or ALL-IN-1TAMARA::qwert.zko.dec.com::TLEXCH::John McClungJohn McClung, 381-2774Wed May 21 1997 19:0632
Christel,

Was the message being decoded by the customer sent using TeamLinks, with 
MailWorks or ALL-IN-1 primary? I'll assume it was - the example you provided in 
.2 was sent by TeamLinks. Note that if you've got PMDF or another MIME aware 
gateway on your server, you should not have TeamLinks do the MIME encoding. 
What is the customer's environment? Do they have PMDF or an equivalent MIME
gateway on the server? 

The problem you mention occurs when using TeamLinks to send MIME using MailWorks 
or ALL-IN-1 as your primary file cabinet. The MIME From: field that gets created
only contains the sender's name - not their mail address.

The problem is that TeamLinks MIME encodes the message *before* it is sent, but 
the mail address of the sender is not set until *after* it is sent, by the 
server, not TeamLinks. Thus, when TeamLinks MIME encodes the message before 
sending it, it doesn't know the mail address of the sender, so just the personal
name is put into the MIME From: field. In your case:

    From: Christel Van Den Bossche

Thus, when the user decodes the received message, all that is available
to display for the sender is what's in the From: field. That makes it necessary
for the user to modify the To: field when they reply.

This is a restriction of using TeamLinks to MIME encode and decode messages
with ALL-IN-1 or MailWorks. There's no practical way to fix this I'm aware of. 
We'd have to know in advance what the mail address of the sender is, but this
information is not available to us at MIME encode time.

John

2212.4XANADU::cascobay.zko.dec.com::TAMARA::STJEANBob St.JeanWed May 21 1997 21:439
Would it be possible to someday add this Sender address into TeamLinks,
maybe into a local profile, so this kind of MIME encode could work?  We 
sort of do this for internet mail.

Of course we would be taking a chance that the address wouldn't be 
valid or wouldn't match what ALL-IN-1 would have generated.

Bob

2212.5a possible workaroundTAMARA::qwert.zko.dec.com::XANADU::MCCLUNGJohn McClung, 381-2774Thu May 22 1997 15:1529
First, an assumption. The only time it makes sense to select the MIME button 
in the TeamLinks Send Options dialog is when:

    - You are using TeamLinks with ALL-IN-1 or MailWorks primary AND
    - The intended recipient is an Internet mail user (not ALL-IN-1 or 
    MailWorks) AND
    - Your server does not have PMDF (or the equivalent) running

If the recipient is an ALL-IN-1 or MailWorks user, MIME is not needed.
If your server does have PMDF (with MIME options enabled appropriately), then 
MIMEing outgoing Internet messages will be handled automatically.

Assuming the 3 conditions above, the problem in .0 exists, because the sent 
message will only contain the user's personal name in the From field, which 
cannot be replied to:
    From: John McClung

A workaround to this would be to change your ALL-IN-1 or MailWorks personal name 
field (see TLSETUP Mail Profile User Info) to contain the Internet Mail address 
that you can be replied to by Internet Mail recipients. For example, if I set my 
personal name to:
    John McClung <mcclung@am.xanadu.zko.mts.dec.com>
and I then send to an internet mail address, the MIME From field will be:
    From: John McClung <mcclung@am.xanadu.zko.mts.dec.com>
When decoded, a reply would properly go to my MailWorks account (via the 
Internet mail address).

John

2212.6Instant work-around!XANADU::cascobay.zko.dec.com::TAMARA::STJEANBob St.JeanThu May 22 1997 21:517
RE: .5

Sounds like a good workaround to me!

Thanks, John.

Bob
2212.7I will suggest this to customerBACHUS::COLLARTLi p'ti fouineu - Dtn 856-8796Fri May 23 1997 07:5416
		Hello,



	Yes, it looks fine, I will suggest this to customer.

	For .5, customer is using MailWorks Vms to send to internet user
	without PMDF gateway, that's why it uses Teamlinks manual
	encoding.


					Thanks for help

					Eric Collart
					MCS Brussels