Re: [hylafax-users] Routing faxes to other fax servers based on phone number

["Jay R. Ashworth" <jra@baylink.com>]

On Thu, Mar 21, 2002 at 09:18:08PM -0800, Lee Howard wrote:
> On 2002.03.21 18:46 Joe Phillips wrote:
> > There would be a trust and authentication problem.  I've been thinking
> > about this for a while.  Basically, if we have servers forwarding
> > fax jobs around you get something like the email model.  We all know
> > how broken that is.
> 
> Yep.
> 
> I've been thinking at this off-and-on for a year or so, since I'm setting 
> up a "network" of HylaFAX servers nationwide, and it would help reduce 
> long-distance charges for my client.
> 
> There's a HUGE issue with this regarding trust and authentication.
> 
> I think that the best (rather, the least bad) option would be to build 
> something into DestControls that would redirect the fax (like 
> RejectNotice, but different).  Calling "faxalter -h" doesn't redirect the 
> fax - it specifies the server on which we are altering the job - so we'd 
> need to send it back through sendfax unless we integrated a simple client 
> program into faxq.  The remote system would need to authenticate us on IP, 
> since we're running non-interactively (and maybe this opens security 
> concerns), but there would be no way for the original job submitter to 
> alter or cancel the job once it reached the remote server.

My thought on this is that perhaps the best solution to it is to jack
up hfaxd and stick a new routing engine in under it: something that
checks the destination address, and then forwards it to its idea of
the "right" other machine... and when a machine decides that the job is
local, it hands it off to a "real" hfaxd, listening on a different
port.

The only problem will be status tracking...

> The e-mail models which allow the submitting client to define the job 
> owner are all broken, as you've said, because they open the door wide-open 
> for abuse of that capability, such that the system superuser must delete 
> the actual queue files unless he has an unrequired admin account.  For 
> those who develop web faxing or email-to-fax mechanisms we've suggested 
> building forward and reverse authentication into the client application.  
> Again, I tend to think that this networked-HylaFAX-server scenario is 
> something that is the client's responsibility again.

Hmmm...  See the Quake open-source fiasco; *never* trust the client
side.

> > In a closed, single admin group it could work.  Otherwise you're trusting
> > the admin of the forwarding server to have properly configured (secured)
> > his machine or the whole network suffers.
> 
> Indeed.  The whole function works better, IMHO, if the client, rather than 
> the server, is configured to direct jobs to multiple servers based on 
> destination number.

See above.

> > You'd definitely want this stuff disabled in the default install.
> 
> Yeah, and considering the mess, maybe not integrate it into the codebase 
> at all.

Which my idea might not require, perhaps at only the cost of modifying
the status clients a bit.. and maybe not even that.

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink                             RFC 2100
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 647 1274

   "If you don't have a dream; how're you gonna have a dream come true?"
     -- Captain Sensible, The Damned (from South Pacific's "Happy Talk")

____________________ HylaFAX(tm) Users Mailing List _______________________
 To unsub: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null