Exchange Gateway; MIME.822 header missing

Hello!
The MIME.822 header is stripped after passing through the GW 7.x Exchange
Gateway. As told in TID #3878409, this works 'as designed'! Unfortunately we
need the MIME.822 header information for SPAM handling and other reasons
(i.e. compliant e-mail archiving) in our local GW 7.0.2 system. Our (new)
branch offices are running MS Exchange 2003 and we wouldn't like to migrate
to Exchange. That's why we set up the GW 7.x Exchange Gateway (7.0.2) for
e-mail transfer over a central exchange server which - so far - woks fine.
The exchange server is also responsible for x-spam tagging and virus
scanning.
TID #3878409 is from June 2007 and reported to engineering. Did they solve
the 'problem'? If not, we probably have to go the hard way (to exchange)!
This couldn't be the intension of this 'feature'...
Does anybody has some information?
Thank you in advance!
Marco

There may be a hidden switch - contact Novell to find out if that's the
case.
>>> On 11/27/2007 at 12:07 PM, in message
<[email protected]>,
Marco Piesold<[email protected]> wrote:
> Hello!
>
> The MIME.822 header is stripped after passing through the GW 7.x
> Exchange
> Gateway. As told in TID #3878409, this works 'as designed'!
> Unfortunately we
> need the MIME.822 header information for SPAM handling and other reasons
> (i.e. compliant e-mail archiving) in our local GW 7.0.2 system. Our (new)
> branch offices are running MS Exchange 2003 and we wouldn't like to
> migrate
> to Exchange. That's why we set up the GW 7.x Exchange Gateway (7.0.2)
> for
> e-mail transfer over a central exchange server which - so far - woks
fine.
> The exchange server is also responsible for x-spam tagging and virus
> scanning.
>
> TID #3878409 is from June 2007 and reported to engineering. Did they
> solve
> the 'problem'? If not, we probably have to go the hard way (to
> exchange)!
> This couldn't be the intension of this 'feature'...
>
> Does anybody has some information?
> Thank you in advance!
>
> Marco

Similar Messages

Exchange users get mime.822 on all mail from outside.

We have GW 7sp3, system with gwia, dom, and po. I just put in exchange 2003 and am using the gw to exchange sp2 connection. I have only one user who does pop and smtp into exchange. All of his emails incoming from the world get mime.822's on them and looks like attachments in outlook client 2007. Is that mime.822 something that the GW Gwia puts on there.
He does not get them when the mail does not pass through the gwia. Is there any way to get rid of these showing up as attachments?

Originally Posted by Brian
We have GW 7sp3, system with gwia, dom, and po. I just put in exchange 2003 and am using the gw to exchange sp2 connection. I have only one user who does pop and smtp into exchange. All of his emails incoming from the world get mime.822's on them and looks like attachments in outlook client 2007. Is that mime.822 something that the GW Gwia puts on there.
He does not get them when the mail does not pass through the gwia. Is there any way to get rid of these showing up as attachments?
It sounds like his mail is tunneled to Exchange via the GroupWise gateway from outside. What we have done to eliminate this annoyance for Exchange users is configure all Internet mail to hit Exchange first. Then if it is destined for GroupWise from the Internet, Exchange forwards it with SMTP to GroupWise GWIA (bypassing the Exchange Gateway).
To do this you need to create the forwarding from Exchange but also you need to remove the SMTP address policy from GroupWise contacts (leaving only the GWISE address in their Recipient policy on Exchange). GroupWise needs to handle all NDRs for both sides as well..
Ryan

Header missing in SOAP message header (SAP XI Extension)

Hi Experts,
We are implementing interface MasterDataUpdateConfirmation_Out between 2 SAP ERP systems. The middleware is SAP PI.
SAP PI team requested a change in this interface Stack - Replace Stack ABAP by Stack Java. The changes were made.
However, now we get an error in the interface in the SAP ERP sender system, but the message arrives to SAP PI where is processed without errors and also arrives to SAP ERP receive system and the message is also processes without errors.
The error we have in XML message in SAP ERP sender system is:
XML element {http://schemas.xmlsoap.org/soap/envelope/}Header missing in
SOAP message header (SAP XI Extension)
Exception of class CX_XMS_SYSERR_PARSER
Can anyone please help us? We have no ideia what to do.
Thanks in advance,
RS

Hi again,
I don't know if it is important, but the communication is asynchronous and the sender system is SAP ECC 6.0.
Thanks!

Can't install Exchange Gateway

I'm trying to install the Exchange gateway on an Echange 2003 system. Have installed C1 with snapins and created a secondary GW domain for the gateway on the Exchange server. The secondary domain starts up OK.
However, when I try and install the gateway on the Exchange server, it fails wi the error 'Unable to get Exchange Server Sites for the server servername and the organization orgname'. If I OK that message, it takes me to the dialog to select the server site, etc, but there is nothing to select, so I have to cancel out of the install.
Any ideas?
Rob.

The best approch at installing this gateway is to follow the TID on how to install it.
How to Install the GroupWise Gateway for Microsoft Exchange
TID #7001367
Environment
Novell GroupWise Gateway - 7.x Gateway for MS Exchange
Novell GroupWise 7
Situation
GroupWise Gateway for Microsoft Exchange Install fails to result in working Gateway
GroupWise Gateway for Microsoft Exchange Service will not start
ERROR: "1503: The Service did not respond or the start or control request in a timely fashion."
ERROR: "ERROR (E01) 010012: Unable to get configuration information from the MAPI Session"
ERROR: "ERROR (E01) 010012 MAPI code: 11D"
ERROR: "ERROR (E01) 0323004 - Unable to bind to the Gateway Object"
Resolution
This document is designed to aid in a successful install of the GroupWise Gateway for Microsoft Exchange in regards to "How to Set Rights for Windows users to install and run the Gateway."
The install and configure documentation should be followed in addition to this TID. GroupWise GateWay Documentation Novell Doc: GroupWise Migration Utilities - Table of Contents
The document does not include installation of the Free busy search components. At the time of writting the GroupWise Gateway for Microsoft Exchange is not intended to be used with Exchange 2007. Installing the Gateway on a Exchange 2003 server in an Exchange 2007 environment appears to be a valid work-around for using the gateway in an Exchange 2007 environment.
Install the latest version of the Gateway software. The latest version can be obtained by calling support. The files can be obtained by opening a service request with support. If no additional support is required the service request may be closed at no additional charge.
Assumptions about the server where the Gateway will be installed:
Novell Client is installed
Authenticated to Edirectory as Admin
ConsoleOne is installed
Active directory Users and Computers in installed
Exchange system manager is installed
AdsiEdit is installed (possibly not needed)
The install / running of the GroupWise gateway for Microsoft Exchange has been complicated and usually requires additional attention to rights as a result of change made in Exchange
More information about this change can be noted at “Send As” permission behavior change in Exchange 2003 “Send As” permission behavior change in Exchange 2003.
Preliminary Step to take to insure success before installing the Gateway:
Check for the existance of Gwise address space on current policy and remove. Find Policy in Exchange system manager | go to properties | remove any old Gwise address space and apply the policy to remove address space from invidual users. Check individual users that the Gwise address space was remove.
Find and remove all Gwproxy.dll on all Exchange servers. Delete gwproxy.dll from Program Files\Exchsrvr\address\gwise\i386 directory on ALL Exchange servers. If the file will not delete you may have to stop Exchange services.
Enable the hidden security tab at the top of the Exchange Org to assist in checking for proper rights needed to run the gateway. The following document will assist in enabling the security tab: XADM: Security Tab Not Available on All Objects in System Manager
Create a user to run the Gateway service and remove his membership to groups not needed. IE: remove membership to "users group" as well as any other groups that are not needed. To remove and add membership to a user go to Active directory Users and Computers | properties of the user | membership tab.
Add group membership for user used to install the gateway as well as the user used to run the gateway rights to the following groups: Domain admins, Schema admins, Enterprise admins, Exchange Domain Servers
Use the hidden security tab to verify that the Installer user and the Service Runner user do not have deny rights set to the "send as" and "receive as" attributes. Go to Exchange system manager at the top of the Org | right click and see the new security tab we enabled in Step 3. Check each group the installer and runner are a members of and remove deny attributes from the "send as and receive as" check boxes. If the groups are not visible in the Top portion of the properties page use the ADD button to add the group | highlight the user and check the "send as" and "receive as" rights.
Follow the Install and configure documentation for the GateWay Novell Doc: GroupWise Migration Utilities - Table of Contents
Run the Install for the Gateway.
If the gateway fails to start it is usually an issue with "send as" and "receive as" set to deny. Use ADSIedit.mcs to find a possible deny that is not visible in Step 6. To launch ADSIedit go to Start | run | type ADSIeit.msc (If needed you can install ADSEedit using the following URL suggestions Adsiedit Overview: Active Directory )
NOTE: Use ADSIedit carefully. The goal is to check and set a deny / allow right for the above groups and users. Contact Microsoft support for information regarding the use of this tool.
Using ADSIedit to find Denys to the Mail Store that are not allowing the user to run the gateway:
Set all "Send as and Receive as" rights for the above users and groups to allow. There cannot be any deny on the "Send as and Receive as" for the above groups or users. Not even if the deny is inherited (greyed out.)
Go into ADSIedit by going to Start | run | type ADSIeit.msc
Expand the Configuration Container
Drill down to Configuration/Services/Microsoft Exchange/First Organization/Administrative Groups/First Administrative Group/Servers/Exchange/information Store/First Storage Group/ and not the mail store.
Right click the mail store object in the right hand window of Adsiedit and go to security tab.
Check "Send as and Receive as" and change any Deny to an allow right for the above users and groups.
A Grey check mark set to Deny indicates the right is inherited from above the current container.
Walk up the Tree of containers checking at each section to insure the "Send as and Recieve as" is set to allow for the users and groups noted above.
NOTE: The most common hidden deny that needs to be removed is found for the Exchange Domains Servers Group and at the Servers Container.
Once all Denys for "Send As and Receive As" have been removed allow some time for replication. Server Restart have also shown to be helpful when rights are set correctly but service still behaves as if it is lacking the "Send As and Receive As" allow rights.
Additional Information
What we need to know:
The Gateway needs to login to the Exchange mail store on the local Exchange Server and create a mailbox for the user that is specified to run this gateway. This users rights to the mail store are needed or the gateway will fail to run.
Additional Trouble shooting aids:
Check the Windows Event logs for error when starting the gateway
Set the Gateway in Consoleone to log at verbose logging level
Try starting the gateway as an application during trouble shooting process as it may allow errors to be see that are not logged. To Start the Gateway as an application when installed as a service Go to / GroupWise domain directory / wpgate/ Exchange / Exegate.exe right click and select open to launch.

"Mail" creating odd Mime-Version Header

Hi all,
occasionally, I get complaints by recipients of my e-mail messages stating they cannot see any content in my message. This has also happened with high-volume support sites who should actually be computer savvy and technically well-equipped enough not to just mess up their e-mail systems. That makes me think there may be an issue with the way apple Mail composes messages.
When I look at a plain text message source code created in Apple Mail on Mavericks, the "Mime-Version:" header field strikes me as weird.
It looks something like this:
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
--Apple-Mail=_8E5E6054-0586-4DE3-B102-381F84B5E9AD
You may have noticed the two linefeeds in it. What are they for? Can this be a reason for recipient user agents to break header parsing at, because the SMTP header block is defined to be terminated by a <cr><lf> sequence? What if a user agent just interprets "newlines" as termination of the header block, not explicitly the <CR><LF> sequence?
Mirko

Do you mean they get sent as headers, or are they part of the message body when they arrive? It will append whatever headers are currently displayed.
Also, it's not a good idea to post your email on a public bulletin board like this unless you enjoy getting a lot of spam.

Groupwise 7 Exchange Gateway

I have and exchange system with 130K users and GW system with 50K users connected together via Exchange Gateway 7 SP2.
Is there a maximum in the number of contacts in either direction?
What is the maximum number of Post Offices on GW side supported by the gateway? There is a error stating maximum open POs but no number is given.
Is there any way to cause a full sync only on the weekends while allowing delta exchange at all times? I was considering a script file to delete the flag files in the DX directories. I think this is an ungraceful method to a simple problem.
I was told about GW7 SP3 coming out before GW8. How can I get a beta copy of the newer exchange gateway.

I have and exchange system with 130K users and GW system
with 50K users connected together via Exchange Gateway 7 SP2.
Q.- Is there a maximum in the number of contacts in either direction?
A.- None that I'm aware of. As long as your HW is fast enough for all them it should be fine.
Q.- What is the maximum number of Post Offices on GW side supported by the gateway?
A.- Same as before.
Q.- There is a error stating maximum open POs but no number is given.
A.- Could you provide more details about it?
Q.- Is there any way to cause a full sync only on the weekends while allowing delta exchange at all times? I was considering a script file to delete the flag files in the DX directories. I think this is an ungraceful method to a simple problem.
A.- I don't think it's supported by the product but you can always try.
Q.- I was told about GW7 SP3 coming out before GW8.
A.- GW 7.0.3 is expected between the second and third week of March. Of course this is not fixed and subject to change.
Bonsai is expected for 10/2008, again, not fixed and subject to change.
Q.- How can I get a beta copy of the newer exchange gateway.
A.- You need to subscribe to the beta program to have access to it or wait for the beta public release.
Hope it helps.
Roberto Helering.

MIME.822 attachments (Xperia M2)

Hi,
I can't be certain about the timing around when this issue started, but my users seem to think it coincides with the last lot of maintenance we carried out on our GW mobility server.
We patched the BASH vulnerability and upgraded our server to SLES11 SP3 at the same time. Since then (they tell me!), when they get an external email with an attachment(s) (note internal mails are OK - makes sense), the device shows the email up but the attachments are all shown as MIME.822. You cannot obviously open these, nor do you get a clue as to what file type they should be.
I've now upgraded the GWMS in an attempt to resolve this, which did nothing (Version: 2.0.1 Build: 53). I've also applied a patch relating to an issue with Xperia handsets - http://www.novell.com/support/kb/doc.php?id=7014337. This didn't solve the problem either.
We have iPhone/iPad users and a couple of users with Galaxy S4's, none of which have this issue. The M2 phones are now Android 4.4.2, which is a reasonably recent update, but they still tell me it's me that broke it during my last lot of maintenance on the server.
I guess it's an issue with the handsets primarily, but I have over 40 of these in circulation, so I do need a solution
Any ideas anyone please? Many thanks, Alan

OK, in case anybody finds this post in future, I can confirm this problem is not consistent. Some external emails come in fine from some people, some have this MIME.822 issue.
The user who had this problem with every external email (he claimed), I've deleted his user from the GMS, left it to settle, then re-added him. I removed the account from his phone at the same time, and re-added that. When I tested from my personal Hotmail, it was fine. When he tested from his home email, it was fine. But there are still some emails with this issue on his phone. Another user, same phone, same firmware and android system revision, no problem.
In short, I think I have a user (or 2) with issues, and not a GMS server...

Exchange Gateway or API Gateway

We're running GroupWise 7.02HP1a on both NetWare and Linux. We're looking to cooperate with an Exchange 2003 system (maybe 2007 with a 2003 intermediary).
Not sure whether to use the Microsoft Gateway with API Gateway on the Novell side, or the Novell Exchange Gateway. Does anyone have experience with both that can comment on which one seems to function better? Is it a toss up and just a matter of preference?
Thanks for any feedback,
Ryan

Originally Posted by ukdtom
Use the Novell Exch. Gateway....
The API one was before html was invented, so I doubt it supports html based mails
Also...The Novell Exch. gateway is under constant development, where the API one hasn't been developed
since GW4
Ahh ok :) Thanks for the response... I'll push for the Novell Exch. Gateway.

MIME header missing "filename=" results in BAD messages

I've been trying to track down several issues involving what appear to
be MIME handling issues. We are running GroupWise v7.01 (we have not
installed the "interim release" yet), and all components on the server
are at that release level (MTA, POA, GWIA, WebAccess).
One of the issues I am currently working on involves problems receiving
attachments from an outside sender. Their attachments are readable if
sent to an outside test account (i.e. - we've tested it with Yahoo
web-based mail, and a RoadRunner POP3 account using Outlook as the client).
The problem is that these e-mails either get dumped by the GWIA to the
GWPROB directory, or the e-mails go through, but the attachments are
corrupted (they do show up as attachments to the e-mail, but are
unreadable).
I haven't looked at why some e-mails go through and some don't, but I
did find out why the attachments are unreadable on the delivered
e-mails, and why the rest are just undeliverable. For whatever reason,
the sender's mail server (or AV gateway or whatever else had a chance to
touch the e-mail) is either not inserting, or is stripping out the
"filename=" from the MIME header just before the encoded attachment.
Adding this back into the message (by editing the original e-mail
w/header, and dropping the modified message into the GWIA "RECEIVE"
directory) fixes the attachment AND makes the e-mail deliverable.
Below I have an example of a bad e-mail which was originally sent to our
GWPROB directory, but was successfully delivered with a readable
attachment through a separate POP3 account (RoadRunner). Following this
"bad" e-mail example is the "fixed" version of that same e-mail, which
was delivered successfully to our user, with the attachment also being
readable.
*************** This is the original "BAD" e-mail ***************
MAIL From:<[email protected]> SIZE=73686
RCPT To:<[email protected]>
Received: from test.rr.com ([65.xx.xx.xx])
by smtp.ourhost.com with ESMTP; Wed, 21 Feb 2007 15:28:27 -0500
Received: from local.com (rrcs-24-xx-xx-xx.central.biz.rr.com [24.xx.xx.xx])
by test.rr.com (8.13.6/8.13.6) with ESMTP id l1LKSFTm009106
for <[email protected]>; Wed, 21 Feb 2007 15:28:24 -0500 (EST)
Message-Id: <[email protected]>
From: [email protected]
To: [email protected]
Date: Wed, 21 Feb 2007 15:25:54 -0500
MIME-Version: 1.0
X-Mailer: Telexis Gateway
Content-Type: multipart/mixed;
boundary="Mark=Num1_Lev1_2007221202554265_Tlx"
X-Virus-Scanned: Symantec AntiVirus Scan Engine
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: text/plain
Content-Transfer-Encoding: Quoted-Printable
This is a test
-Test Sender
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: application/vnd.ms-excel;
name="1st Q 2007 Income to Budget.xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
"1st Q 2007 Income to Budget.xls"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAZgAAAAAAAAAA
EAAA/v///wAAAAD+////AAAAAGUAAAD/////////////////////////////////////////////
--Mark=Num1_Lev1_2007221202554265_Tlx--
************** END OF BAD E-MAIL **************
*************** This is the "fixed" e-mail ***************
MAIL From:<[email protected]> SIZE=73686
RCPT To:<[email protected]>
Received: from test.rr.com ([65.xx.xx.xx])
by smtp.ourhost.com with ESMTP; Wed, 21 Feb 2007 15:28:27 -0500
Received: from local.com (rrcs-24-xx-xx-xx.central.biz.rr.com [24.xx.xx.xx])
by test.rr.com (8.13.6/8.13.6) with ESMTP id l1LKSFTm009106
for <[email protected]>; Wed, 21 Feb 2007 15:28:24 -0500 (EST)
Message-Id: <[email protected]>
From: [email protected]
To: [email protected]
Date: Wed, 21 Feb 2007 15:25:54 -0500
MIME-Version: 1.0
X-Mailer: Telexis Gateway
Content-Type: multipart/mixed;
boundary="Mark=Num1_Lev1_2007221202554265_Tlx"
X-Virus-Scanned: Symantec AntiVirus Scan Engine
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: text/plain
Content-Transfer-Encoding: Quoted-Printable
This is a test
-Test Sender
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: application/vnd.ms-excel;
name="1st Q 2007 Income to Budget.xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="1st Q 2007 Income to Budget.xls"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAZgAAAAAAAAAA
EAAA/v///wAAAAD+////AAAAAGUAAAD/////////////////////////////////////////////
--Mark=Num1_Lev1_2007221202554265_Tlx--
************** END OF "FIXED" E-MAIL **************
The only change I made, which both allowed the above e-mail to be
delivered and made the attachment readable, was the addition of the
"filename=" just before the file name on the line after the
"Content-Disposition: attachment;".
I did the same test with an e-mail that had the same "filename="
missing, but somehow was successfully delivered to our user (again, the
attachment was unreadable). Adding the "filename=" into the resent
message did make the attachment readable.
I haven't looked to see if the sender's system is actually non-compliant
for excluding the "filename=" (I will be doing that later this evening),
or whether this is a GWIA problem for not being able to handle this. I
just wanted to throw this out there to see if anyone else has seen this.
Does the "interim release" update by chance fix this?
Thanks,
Greg Niese

Does this email come in directly to GWIA (or do you have a relay host in
between)? I must say I've never experienced this problem on any of the GW
systems I administer. Could you tell us what domain this is coming from?
Ted Kumsher
>>> On 2/23/2007 at 8:21 AM, in message
<[email protected]>, Greg
Niese<[email protected]> wrote:
> I agree that this shouldn't be accepted as a valid "filename parameter"
> line. There are two ways to "not accept" this invalid parameter: "stop
> processing" the e-mail because of the problem (discard the e-mail), or
> discard the bad parameter and continue processing the rest of the e-mail
> (this could only work when the parameter is optional, as in this case).
> The GWIA seems to take the route of "stop processing", and then moving
>
> the resultant "bad" e-mail to the GWPROB directory.
>
> I say "seems" because in many cases where this occurs the e-mail doesn't
> get sent to the GWPROB directory, but instead still gets through the
> GWIA to the user. The attachments are corrupted, but still show up
> correctly in the attachment window, so everything seems OK with the
> e-mail & attachment - until you try to open the attachment.
>
> If there is a semi-colon after the "Content-disposition" type, the GWIA
> should see a valid disposition parameter following. But if it sees an
> invalid parameter, as in this case, what is the GWIA doing? It must
> either be discarding the invalid parameter, or "uses" it by either
> incorrectly parsing it as part of the header, or lumping it in as part
> of the attachment. If it "uses" in any way the invalid line of data -
> that sounds like the definition of "accepting" it, isn't it?
>
> To test whether the GWIA is actually using, and therefore "accepting",
> this bad parameter, I simply removed the malformed parameter (having the
>
> line in or out shouldn't matter if the GWIA's not using it), and I tried
>
> this both with the semi-colon removed from the end of the
> "content-disposition" type, and with that semi-colon left in place. In
> both cases the GWIA properly processed the e-mail and the attachment was
> readable! What does that mean? If the GWIA was truely NOT
> using/accepting that invalid header parameter (i.e. - the GWIA discards
> it), then the e-mail and attachment should go through OK. Since this
> isn't what happens when the bad line is left in place (the attachments
> DO NOT come through OK, but the e-mail often does get to the user's
> mailbox), then the GWIA must be accepting that bad parameter as either a
>
> part of the header, or a part of the attachment.
>
> I suspect that in those cases that these e-mails are sent to the problem
> directory, instead of being delivered with a corrupt attachment, the
> GWIA isn't really recognizing that the optional disposition parameter is
>
> "bad". The reason for the e-mail going to the problem directory is
> probably due to an error while trying to decode the attachment if the
> bad parameter is treated as part of the attachment, or if part of the
> attachment is being lumped in with the malformed parameter as it is
> parsed.
>
> I agree that how the GWIA should go about "not accepting" bad header
> parameters may be debatable (assuming that the GWIA were actually
> halting processing of the e-mail when this type of problem is found, and
> then sending the e-mail to the problem directory every time). But in
> cases such as this, since the parameter itself is optional, it would
> seem that the better route would be for the GWIA to discard the
> parameter and continue processing, instead of "discarding" the whole
> e-mail (to the problem directory). "Discarding the bad parameter" seems
> to be what is being done by at least a few other competing SMTP agents,
> since the other mail systems I tested with did get the e-mail through
> without corrupting the attachment.
>
> I may suggest that the sender's company fix whatever is going on at
> their server, but it probably won't do any good (I've already been told
> that they don't experience this problem with anyone else). In the
> meantime, my user (yes...he is the CEO), will have to continue to have
> some important e-mails sent to one of his personal accounts, because
> those e-mail systems receive these e-mails fine, but our GroupWise
> system can't.
>
> :-(
>
> -Greg
>
>
>
> Michael Bell wrote:
>> No it shouldn't, IMO.
>>
>> It's a matter of interpretation, of course. But GWIA is 100% right in
> not
>> accepting this as vaid (that part is beyond any debate - it's in the
> RFC).
>>
>> The only part that can be debated is "should GWIA then pass the buck"?.
> In
>> olden days, many would have said yes.
>>
>> But In general, no. Moving away from Postel's law, which was formulated
> in a
>> pre-malware age, is pretty much needed. Tight specifications and
> pickiness
>> is good. Collateral damage is unfortunate, and of course one needs to be
>
>> flexible if this is a widespread issue (which frankly, it is not in this
>
>> case), but otherwise it is up to to sender to fix their issue.
>>
>> 90% of viruses and malware in the last 6 years (and I'm well aware of
> them,
>> working in the email security field) are from MALFORMED e-mail, that the
>> gateway and client misinterpreted. Many of these were MS issues, but
> that's
>> another point. Point is you have to be STRICT.
>>
>> In this case this violates the generic MIME RFCs which state that if you
> do
>> have parameters, they all gotta be separated with semicolons (PASS), and
>
>> have to be name=value pairs (FAIL).
>>
>>
>> "Greg Niese" <[email protected]> wrote in message
>> news:[email protected]...
>>> Well, according to RFC 2183, the "filename=" string has to be present if
>
>>> the Filename parameter is going to be used. So the sending host seems
> to
>>> be "broken" in that regard.
>>>
>>> My next question then is: Should the GWIA ignore the "stray" file name
> in
>>> these e-mail headers, instead of allowing it to be lumped in with the
>>> attachment (I'm assuming that's why the attachment is trashed)? It
>>> appears that other systems are able to do this.
>>>
>>> -Greg
>>>
>>> Greg Niese wrote:
>>>> I haven't looked to see if the sender's system is actually
non-compliant
>>>> for excluding the "filename=" (I will be doing that later this
evening),
>
>>>> or whether this is a GWIA problem for not being able to handle this. I
>>>> just wanted to throw this out there to see if anyone else has seen
this.
>>>>
>>>> Does the "interim release" update by chance fix this?
>>>>
>>>> Thanks,
>>>>
>>>> Greg Niese
>>>>
>>
>>

MSPT/MACM status at network header - Missing Parts

I have a query with regards to how the MSPT(missing parts) status is set/unset at the network header level.
My question is why is the Missing Part status set to INACTIVE at the Network Header level when several components have the Missing Part indicator set.
The MACM status is set as ACTIVE instead at the network header level.

Dear Chandra shekar,
check for the production order type and plant combination in OPJK for business function 1 - material availability check during order
creation for the check box - check material availability during order creation and likewise for business function 2 - material
availability during order release and the setting for release material .
Kindly make the required setting after discussing with your PP consultant and go ahead.
Regards
Mangalraj.S

Symantec Mail Security with Exchange 2007 (Emails with Attachment missing)

HI, i need help here
I have Win 2008 with Exchange 2007 and Symantec Mail Security. Symantec was working fine until the license expired but it was still fine until yesterday, we realize that we cannot receive email with attachment. after stopping the symantec services, mail
flow went back to normal. We then remove the program from the control panel.
Then i found that i cant retrieve or find those emails that was sent to us during a period of ard 6 hours. i tried looking the the Symantec quarantine folder but it is not there.
Can someone point to me where should i look for the missing mails? When i do a mail flow troubleshoot i can see the logs that it is sent to the mailbox, but from users's outlook inbox, there is no email ??
Much Appreciated

Symantec's support group should be able to tell you what happened.
--- Rich Matheisen MCSE&I, Exchange MVP

ODI Web Service Soap Header Missing Error

I am trying to invoke oracle crm ondemand web service using ODIInvokeWebService tool by providing the below parameters
Url
Port Type
Operation
XML Request
HTTP User
HTTP Password
I am getting the below error during the execution of the step.
javax.xml.ws.soap.SOAPFaultException: Invalid Soap Request : Soap Header is missing
     at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:189)
     at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:122)
     at com.sun.xml.ws.client.dispatch.DispatchImpl.doInvoke(DispatchImpl.java:187)
The code which is getting executed is
OdiInvokeWebService "-URL=http://slc402454.us.oracle.com:30090/Services/cte/FieldManagementService?wsdl" "-PORT_TYPE=FieldManagementService" "-OPERATION=FieldManagementRead" "-HTTP_USER=Upgrade_all/sales" "-HTTP_PASS=aYyHL7THHZYEdPNTd.1ugy"
<?xml version = '1.0' encoding = 'UTF8'?>
<WL5G3N1:FieldManagementRead_Input xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:WL5G3N1="urn:crmondemand/ws/odesabs/fieldmanagement/">
<apQuery:FieldSet xmlns:apQuery="urn:/crmondemand/xml/fieldmanagement/query">
<apQuery:ObjectName>Account</apQuery:ObjectName>
<apQuery:IncludeAll>true</apQuery:IncludeAll>
</apQuery:FieldSet>
</WL5G3N1:FieldManagementRead_Input>
With SOAPUI , I am able to get the response.

After mentioning the SOAP header and response file as XML with other properties , I am able to successfully retrieve the SOAP response.

OSB - Content length http header missing from business service out message

Hi all,
I am having some diffuclty with a business service in OSB. I created the business service from the wsdl and created a regular proxy service that just routes to the business service. When i run the test console i get the below fault.
<faultcode>soapenv:Server</faultcode>
<faultstring>BEA-380000: Length Required</faultstring>
<detail>
After some debugging i find that the content length http header is missing from the outbound message the business process creates and sends to the acutal web service which sends back the http 411 fault.
Does anyone know how to configure the message flow of my proxy service to ensure that the outbound message sent from the business service contains that content length http header or any suggestions on how to fix this issue will be appreciated.
Thanks

Disable the "Use Chunked Streaming Mode" property in HTTP Transport Configuration of your business service. By default it remains enabled.
Regards,
Anuj

XML Gateway / OXTA message header

How do we tell XML Gateway not to put the hub username/password in the transaction header?

Thanks for the advice. I checked the Workflow Status monitor I did get an error...
Internal Name          ECXERROR
Description          XML Gateway Error Processing
Message Direction          O
Error Name          1
ECX Error Type          20
ECX Return Code          1
ECX Error Message          Attribute 'xmlns' used but not declared.
This seems to be an xml namespace error. Can anyone tell me how to solve this problem?
Thanks,
-Jason

GroupWise 7 Exchange Gateway "Bad GroupWise proxy"

I am testing the GW7 Gateway on a GW702(NW) and Exchange 2003SP2 installation. I have it basically running, but there are 2 issues that I cannot seem to fix.
as part of my learning, I have determined that I must run the Gateway as an Application, due to the windows Service being unable to run from a NetWare UNC, and I also determined that the Gateway name must be 8 chars. This all works.
At this point, if I initiate a Directory Synchronization, it creates contacts for every GroupWise user in the AD import container, and contacts in GroupWise for any existing Exchange users.
My first issue is that it ONLY creates contacts. It does not seem to be able to "mail enable" existing AD accounts event though they match. It is ignoring the settings in the properties of the gateway-> Import Container "When replicating a mailbox whose primary account does not exist in the domain" if I set it to create a Windows Account. Is this normal?
Second issue is: if I migrate a user from GroupWise to Exchange using the Microsoft Exchange 2003 sp2 Migration wizard, it correctly removes the Contact, and mail enables the AD User account, but the new Exchange account will not synchronize.
The problem is that the directory sync gives errors on every user account that was migrated, and does not create a new contact in GroupWise. Any new user created manually in Exchange does sync and is ok. The verbose log in the Gateway says "DXIN: Ignored: Adding User GW701DO.GW701PO.Bob Brown: Reason-Bad GroupWise proxy".
Taking this message at it's word, I have ensured that the account running the Gateway has full AD and NDS rights, and is explicitly assigned full GroupWise proxy rights.
What does this error message really mean?

There is something else going on with the migrated user account. I have deleted the NDS account, leaving only the AD/Exchange user, but it still does not populate the gateway domain with a contact. It still says "Bad GroupWise Proxy".
I will test if I can export, delete, and then import this user so that I can reproduce the content of the AD account. Perhaps there is something in the attributes that is causing the gateway to fail to do it's creation.
Originally Posted by durrand
I've previously tried (and failed) to get the gateway to create windows user accounts - maybe a call to NTS is require to get newer code(?)
On the second issue, are you trying to import/export to/from the same conatner in AD and DOMAIN in GroupWise? Is it possible that the create fails because it clashes with the old account?
If you're only testing the gateway my suggestion would be to create a separate External Domain and use this in the Exchange GWISE addressing scheme (which, in turn, will ensure that any sync'd accounts are created in the new domain).

Exchange Gateway; MIME.822 header missing

Similar Messages

Maybe you are looking for