>> Â WD>> - 14 Oct 00:23:02 [4700] ZYZ Janis Kracht >> Â WD>> - 14 Oct 00:23:02 [4700] receiving zone3.287 (768 byte(s), off 0) >> >> Â AV>Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â >> ^^^^^^^^^ >> Â AV> I expected to see "rejecting" instead of this. >> >> Â Interesting, how would you arrange that at that level.
TK> In BinkD, set up a dedicated inbound dir for the node, then set up a TK> 'skip' statement including the directory name? Would that work? I TK> haven't tested.
I have though of that possibility as well. It would work, if one would only want received files from that node, that should be diverted. But I think that assumtion is not practical, where there will also be transient e-mail traffic. The latter may still exist as many used the link between Ward and Janis as a default route between Z1 and Z2. I am quite sure that Ward will now route to Nick. But there will still be systems in Z1 that route mail to Z2 via Janis. I expect that Janis will deliver such mail directly to Ward and not via Nick.
The same goes for the suggestion made by Henri. Forcing files to be received in the insecure area. That would have the result, that transient mail in both directions would be delivered to the unsecure inbound.
Having valid mail delivered to an insecure inbound or node specific directory, als requires, that such mails have to be processed by a separate routine. Not very practical, when it is only for an occasional goof on the other system.
As a last Ward uses Dbridge, I only say this as a fact, as I have nothing against it. Dbridge was built to have dynamic outboud directories and has a hook to custom binkd to support IP traffic. Binkd uses a BSO directory structure, that does not allow the dynamic handling. Nick has gone to great lengthes make the two to work together and I commend how he accoplished this.
To make this all work from within the configuration file of Binkd, a current binkd.cfg is generated for Binkd by the scheduler or whatever.
The use of mailbox directories is not foreseen in this procedure. It is also my guess, that it would be a major effort to combine mailbox support in the tosser and scheduler of Dbridge and not on Nick's priority list.
It not worth it for the problem at hand, it has been solved by "diplomacy".
Kees
--- GoldED+/LNX 1.1.5 * Origin: As for me, all I know is that, I know nothing. (2:280/5003.4)
