Archive-Date: Thu, 5 Feb 2004 08:48:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: 8-bit MIME messages Date: Thu, 5 Feb 2004 11:47:57 -0500 Message-ID: <7d63ea7f6e8cfeb401641353329203bd402273b4@jcc.com> From: "Jeffrey S. Jalbert" Reply-To: MX-List@MadGoat.com To: Our list server has registered participants who are world wide. =20 List members occasionally receive bounce messages such as the following: Final-Recipient: rfc822;oraclerdb@mercur.jcc.com Action: failed Status: 5.6.1 Diagnostic-Code: smtp;554 5.6.1 Body type not supported by Remote Host X-Display-Name: oraclerdbmercur We believe this is due to the message body being 8-bit MIME encoded, or at least some non USASCII format. See the mail headers at the end of this message. Our mail setup goes something like this. =20 A. An external mail server (world mail) receives all external mail. =20 B. This server forwards that through our firewall (where it receives the first level of scrubbing) to an internal Exchange server where it is scrubbed again for viruses etc. =20 C. The exchange server (which is the source of the message above) forwards the message to the MX box which is a dedicated VMS system. [An ancient Jensen would you believe?] Does anybody out there have a clue what the issue can be? Software versions: VMS 7.3-1 MX V5.3 Thanks, Jeff ----------------------------------------------------------- Jeffrey S. Jalbert JCC Consulting Phone: (740)587-0157 Email: Jeff@jcc.com Fax: (740)587-0163 Web: www.jcc.com Sample Mail headers: Microsoft Mail Internet Headers Version 2.0 Received: from Arachnid.JCC.COM ([192.84.218.31]) by king.jcc.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 4 Feb 2004 19:27:04 -0500 Received: from agminet04.oracle.com (141.146.126.231) by Arachnid.JCC.COM (Worldmail 1.3.167) for oraclerdb@king.jcc.com; 4 Feb 2004 19:23:02 -0500 Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by agminet04.oracle.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i150PFmg009096 for ; Wed, 4 Feb 2004 16:25:50 -0800 Received: from rgmgw5.us.oracle.com (localhost [127.0.0.1]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i150PDM19434 for ; Wed, 4 Feb 2004 17:25:14 -0700 (MST) Received: from oracle.com (dhcp-amer-vpn-gw2-east-141-144-66-39.vpn.oracle.com [141.144.66.39]) by rgmgw5.us.oracle.com (Switch-2.1.5/Switch-2.1.0) with ESMTP id i150PCM19312 for ; Wed, 4 Feb 2004 17:25:12 -0700 (MST) Message-ID: <40218F12.D02C68B7@oracle.com> Date: Thu, 05 Feb 2004 11:32:18 +1100 From: Mark Bradley X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: oraclerdb@jcc.com Subject: Re: Triggers & upgrade issues... References: Content-Type: multipart/mixed; boundary=3D"------------DC141BAD445F607BFD8E71AA" X-Brightmail-Tracker: AAAAAQAAAAI=3D X-White-List-Member: TRUE Return-Path: mark.bradley@oracle.com X-OriginalArrivalTime: 05 Feb 2004 00:27:04.0800 (UTC) FILETIME=3D[C7DC0E00:01C3EB7E] --------------DC141BAD445F607BFD8E71AA Content-Type: text/plain; charset=3Diso-8859-1 Content-Transfer-Encoding: 8bit ================================================================================ Archive-Date: Fri, 6 Feb 2004 12:21:01 -0800 From: "Kurt A. Schumacher" Reply-To: MX-List@MadGoat.com To: Subject: Inside Networks vs. Rejman? Date: Fri, 6 Feb 2004 21:20:39 +0100 Message-ID: <001a01c3ecee$b5039bb0$10010a0a@home.schumi.ch> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Since day one of the availability we have implemented SMTP AUTH some inside networks to ensure our own systems can send out individual messages. Inside IP networks/hosts: ... 194.191.19.0 netmask 255.255.255.128 (Relay allowed) 194.191.19.129 netmask 255.255.255.128 (Relay allowed) ... 62.2.217.104 netmask 255.255.255.248 (Relay allowed) ... For example we have some appliances sending alert and log files with the same from, to and mail_to addresses (something we can't change) - but randomly we see the messages blocked by rejman - curiously just from the 194.191.19.129/255.255.255.128 network - ignoring the inside IP network definitions. No idea, since the last addition of a new rewrite rule and the associated reset MX works again as expected. -Kurt.