![]() |
> > 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*