HylaFAX The world's
most advanced open source fax server
|
|
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
Re: [hylafax-users] Iternet-Fax WG Anyone?
>
> None of this needs T.37 - we had already decided to do it when I found
> that the device supported T.37. I had planned on using an address like
> 'f_18005551212' to send a fax. When I saw the interface on the machine
> had an "Internet Fax" option and would automatically send the TIFF-F to
> "FAX=+18005551212" when the user typed in a phone number, I thought I'd
> ask who was using it.
>
> When I looked further, I saw a TON of devices that support T.37. Many
> of them are far cheaper than the copier we're leasing. Now, we need the
> copier and the high-volume printer, so we're moving ahead. But if I get
> Hylafax to support T.37, I'll put smaller, cheaper devices around the
> office to replace those (outbound) desktop faxes.
>
> Another significant benefit would be to add a LITTLE bit of logic in the
> T.37 script to check the area code and see if another mail server in the
> company is a better choice to send the fax. We send about 5% of our
> faxes to two local areas (in TX and FL) and saving that might be worth
> looking at. In larger organiations, it could be a real boon.
>
> Anyway, given the low cost and high potential, I'll probably work on
> this shortly.
>
> Bill
>
I've started to read the RFC's, and it does seem like a good idea to
standardise the way that the information is received by the MTA. Judging
by the part that I have read so far, it probably would need very little
work to make most of the scripts written so far for email-to-fax with
HylaFax compliant with this method. But, on the downside, RFC2035 in
itself does seem to be somewhat optimistic about the actual setup.
Specifically, to quote:
The reason for developing this capability as an email profile is to
permit interworking amongst facsimile and email users. For example
it is intended that existing email users be able to send normal
messages to lists of users, including facsimile-based recipients, and
that other email recipients shall be able to reply to the original
and continue to include facsimile recipients.
This would make verification a nigh on impossible task, as the RFC
touches upon sender verification later on in the document, it is overly
simplistic, and unfeasible to introduce. The above paragraph would leave
you with two options:
1) Allow people from outside of your business/corporation to relay through
your fax service
2) Allow only your own employees/staff to use the fax service, which would
then negate the "continue to include facsimile recipients" feature.
Altering the existing, or writing a new script, to work with this range
of equipment will definitely introduce more "client" options into HylaFax,
which is, without doubt, a good move.
Sticking to the RFC's however, unless there is something later in the
documents that I haven't read yet, would be a complete and utter nightmare
with regards to MTA administration.
( I've even bored the crap out of myself with this reply :)
Matt
____________________ HylaFAX(tm) Users Mailing List _______________________
To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
*To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*