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

[Yan Seiner <yan@cardinalengineering.com>]

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.
> 
> That's the big issue, in my mind, trust and authentication for the
> original job submitter to have continuous access to the job.
> 
> 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.
> 
> > 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.

Let me chime in here.  I think a client based setup would be a nightmare
from an admin standpoint.  Really, we should be thinking of a hylafax
proxy that would sit between the server(s) and the client, and decide
which server to route the fax to.  This would allow you to use the
existing clients, and code a competely separate app to handle security
and WAF <- New term I just made up - wide area faxing. :-)

> 
> > 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.

A proxy could be (and should be) a completely separate software
package.  The security layer should be handled by the proxy as well -
possibly running a lightweight VPN (like vtun) between servers.  The
proxy would handle user requests as well, like deleting faxes.  From the
user's standpoint, the fax is local; the proxy figures out where it sent
that fax and tells that server to delete it.

--Yan

-- 
Future fighter pilots:
Me: Akari, WHAT are you DOING?
Akari, age 3: Pushing the envelope.
spam killer code kpwq1jkcsEzdx39gnkVvgycd15ayqq
(see http://www.paganini.net/ask)

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