tony@ajfcal.UUCP (Tony Field) (04/24/89)
I think there is a problem in elm's resolution of paths using the pathalias
data base. For the wizzards out there, please correct (or flame) me
if my reasoning is wrong........
Both elm2.2 and smail2.5 should generate identical paths in the following:
elm -c dsinc.dsi.com!syd@rutgers.uucp
----> calgary!utai!uunet!cdin-1!bpa!dsinc!syd@rutgers.uucp
smail -A dsinc.dsi.com!syd@rutgers.uucp
----> calgary!utai!uunet!rutgers!dsinc.dsi.com!syd
My interpretation of the elm address is that rmail at "dsinc" would
attempt to foreward the mail to "syd@rutgers.uucp", however "syd" is
really at "dsinc.dsi.com".
The smail example is, in fact, correct.
For address of the form:
bangpath!user@machine
I think elm should first resolve the "machine" path, then simply
concatenate "!bangpath!user" to the resolved "machine" path.
Since "bangpath" may be a host/domain known only to "machine"
elm MUST ASSUME that "bangpath" is valid and not attempt further expansion.
^^^^^^^^^^^
The generated address should be:
expanded_machine_path!bangpath!user
If this is not done, and you are using elm with a smart r-mailer such as
smail, then the elm-generated path can be expanded again by smail to:
^^^^^
calgary!utai!uunet!rutgers!calgary!utai!uunet!cdin-1!bpa!dsinc!syd
^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^ smail generated^^ ^^elm generated^^
If my reasoning is correct, you should probably disable elm from
resolving addresses and allow smail to do all resolution.
tony...
--
+------------------------------------
| Tony Field ..uunet!utai!calgary!ajfcal!tony
| Co-Design Information Systems Ltd.
| Calgary, Alberta, Canada voice: (403) 266-3239