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

Conference iosg::all-in-1

Title:	ALL-IN-1 (tm) Support Conference
Notice:	Please spell ALL-IN-1 correctly - all CAPITALS!
Moderator:	IOSG::PYECE

Created:	Fri Jul 01 1994
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2716
Total number of notes:	12169

2690.0. "A1 V 3.2 with P1 extensions ?" by OSITEL::rtont2.rto.dec.com::Erich (SI-Office) Wed May 21 1997 18:08

 Hi all,

 end of last year I installed XMR to exchange mails between a message router
 base and a Lotus Messaging Switch (UNIX) also called "EMX"
 I had to install a XMR patch to be able to switch off the use of P1 private 
 extensions by XMR. The EMX otherwise dropped the mails.
 (Mailbus_400 conference, notes 3079..)
 Now we plan the update to ALL-IN-1 V 3.2 and the direct connect to
 Mailbus 400 MTA (no XMR anymore).

 Question is, do the P1 extensions come back now, does ALL-IN-1 V 3.2 
 use these extensions like the XMR Gateway making it in the new 
 configuration impossible to communicate with the EMX ?

 regards, Erich

T.R	Title	User	Personal Name	Date	Lines
2690.1	Nothing wrong at our end	IOSG::MARSHALL		`Thu May 22 1997 14:56`	11
	Yes, ALL-IN-1 V3.2 does add a P1 extension. We do this to provide customer-desired functionality not available within the base X.400 standard. This is a perfectly valid X.400 construct, and there are well-defined X.400 rules for what systems that aren't interested in such extensions should do with them. If the other end's X.400 connection drops messages that contain a P1 extension then that is a very serious bug with that product, and you should pursue them for a fix. Scott
2690.2	Exchange too...	IOSG::DUTT	Nigel Dutt	`Thu May 22 1997 16:13`	5
	This was also a problem with early versions of Exchange losing messages with P1 extensions, and they fixed it pretty quickly. Simply put, receiving systems who aren't interested in the extensions should simply ignore the extensions, they shouldn't (as Scott said) ignore the message.
2690.3	Terminological Inexactitude?	IOSG::PYE	Graham - ALL-IN-1 Sorcerer's Apprentice	`Thu May 22 1997 18:14`	9
	RE .2 <<<< This was also a problem with early versions of Exchange losing <<<< messages with P1 extensions, and they fixed it pretty quickly. I guess that being an architect, the word 'quickly' means something different to you :-) Graham
2690.4	Precisely so!	IOSG::DUTT	Nigel Dutt	`Thu May 22 1997 23:05`	1
	And I guess you'd have a problem with "pretty" too, Graham :-)
2690.5	Some extra info on extensions	IOSG::MARSHALL		`Fri May 23 1997 18:58`	31
	>> receiving systems who aren't interested in the extensions should simply >> ignore the extensions Not quite so simple: the extension attributes mechanism defines a "criticality" element. It is possible to specify, for example, that a particular extension is critical for delivery. In that case, if a system doesn't know what to do with that extension, it should non-deliver the message. The extensions that ALL-IN-1 uses do not define such criticality attributes, because the data in the extension is just extra functionality useful to ALL-IN-1 (and anyone else who wants to provide a mail system as high-quality as ours :-). So in our specific case Graham is right. >> early versions of Exchange losing messages with P1 extensions Yes, I was being polite and didn't mention their bug in my first reply. But I suppose as Microsoft are considered to be Supreme Deities who can transcend mere international standards, if they feel it's worth fixing, then that probably means it is worth fixing :-) >> they shouldn't ignore the message. No mail system should ever ignore, or lose, any message, for any reason. If there is indeed something wrong with the message that is not that mail system's fault but prevents them processing it further, they should non-deliver it, or if even that isn't possible, should keep the message and ring loud alarm bells to alert the system manager to the presence of unprocessable mail. But then I'm neither pretty nor an architect, so that's just MHO :-) Scott