ml>> FDNODE.CTL is pretty static as is the inbound directory where all
 ml>> files (mail and otherwise) end up before tossing... when FD receives
 ml>> a message with a fileattach and it is set up to allow that message
 ml>> and file to travel on to another system, it knows to look in the
 ml>> inbound directory for the file to send on... this works fine if FD is
 ml>> doing all the routing handling and as long as there are no duplicate
 ml>> files received which would cause FD to adjust the extension of the


 JD> Duplicate files received.
 JD> Interesting...

 JD> I hadn't thought to try that with Squish.

yeah, here's two different but similar scenerios...

1. have a system route two messages with identicle named file attaches via
your system...

2. have a system route two carbons of a message with a file attach via your system...


in the first case, its seperate messages... the second case is carbon copies...

some mailers attempt to send a copy of the file with each message it
sends... many mailers will adjust the name of the second subsequent
files... intelligent mailers will send only one copy of the file and will
also not remove the file until all netmails that reference the file are
sent... a dumb mailer sending to another dumb mailer or to an intelligent
mailer will cause problems to one degree or another... i can see the
secondary files being orphaned on the intelligent mailer and the properly
named one traveling on as desired... dumb mailer to dumb mailer will result
in secondary files being orphaned and additional messages, other than the
first one, to leave the system without the accompanying file... intelligent
mailer to dumb mailer will work fine but the dumb mailer will mess it up by
not sending the file with the secondary messages...

head aching yet? :wink:

)\/(ark