>> Colin Campbell wrote:
>> >I have done a bit of research into this problem at present including the
>> >use of the TIS plug-gw between cooperating MTAs (doesn't work BTW).
>>
>> Could you be more specific about why a plug-gw on port 102 (for RFC 1006
>> connections) won't work between MTAs? We're about to test this solution
>> and would like to leverage any info you have. It seems too simple to be
>> wrong :-) Thanks in advance for your help.
> It did to me too. I set it up. The "experts" in the X.400 ways tested it.
> What they saw was mail being rejected by the receiving MTA because the
> sender's (plug-gw host) IP address at the (I guess) RFC 1006 level in the
> OSI stack did not match the sender's (originating MTA) IP address,
> buried at higher levels in the OSI stack.
hum ... lemme see ...
If at rfc1006 level your configurations are correct (ie MTA1 connects to
plug-gw host, and not directly to MTA2), it's definatly possible.
At a stack level (rfc1006 or OSI), you don't have any kind of check inside
the messages. If both MTAs know that they're gonna connect to plug-gw,
everything will be fine at lower levels.
But, there are identifications needed at x.400 level. You have identity check
between two MTAs, when they need to connect to each other (passwds, etc ...).
If the check is done against #IP of the MTA, it will fail for sure. But
the check can be done against something called MTAname, which is a fairly
long stream/string, and can be the hostname for example.
Then, it depends of the implementation of x.400, and what products are used.
Some MTAs can check #IP, or MTAname, or both. Some probably check both,
without giving any option to change that.
(also, it can be requested by some context, some corporate requirements or
stuff like that, to have #IP check.)
> They decided this problem was
> insurmountable and that was that.
It's definatly not insurmountable.
Arnaud.
--
Arnaud Girsch -+- agirsch @
marben .
com -+- Marben Products, Inc. - San Jose, CA
\- OSI Networking Products -----------
References:
|
|
