mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-27 03:20:22 +08:00
.. | ||
fax500.h | ||
faxtotpc.c | ||
main.c | ||
Makefile.in | ||
README | ||
rp500.c | ||
Version.c | ||
Versionrp.c | ||
xrpcomp |
README file for fax500 xrpcomp ------- This directory contains a modified version of the rpcomp program, used with the Internet remote-printing experiment. More info on the experiment can be found in /mrose/tpc on ftp.ics.uci.edu. The xrpcomp program (it's a shell script) is like rpcomp, except that it will look in X.500 if no fax recipients are found in the .rpdb file. It still uses .rpdb to extract the originator information. There are a couple of things in rp500.c you will want to tailor to use xrpcomp at your site: DAPUSER This is the user the rp500 program, called from xrpcomp will bind to the directory as. It can be set to NULL. DEFAULT_BASE This is the search base rp500 will use when looking in the directory for fax recipients. DEFAULT_FILTERCONF Where to find the ldapfilter.conf file. Should make setting this automatic, but for now... PHONE_PREFIX The prefix of phones in your local area. If rp500 finds a fax number in the directory that is not fully qualified, it will append as many of these digits as necessary to make it fully qualified. NB it assumes US-format numbers. DEFAULT_LDAPHOST The host running the default ldap server to contact. Things to note: The rp500 program knows a little about the US phone number format, in an attempt to deal with (evil) people who have not put fully qualified international format (e.g. +1 ... ) phone numbers in their entry. If your users do not have US-format phone numbers, you'll need to take a look at the fax2email() routine in rp500.c and change it around a bit. 7/30/93 -- Tim fax500 ------ This directory also contains the fax500 program. fax500 is just like mail500, except that it looks up the facsimileTelephoneNumber attribute, constructs an appropriate "remote-printer@blah.tpc.int" address, and send the mail there. For example, the facsimile number "+1 313 555 1212" corresponds to the address "remote-printer@2.1.2.1.5.5.5.3.1.3.1.tpc.int." For a complete explanation of the Internet remote-printing experiment, look in /mrose/tpc on ftp.ics.uci.edu, or send mail to tpc-faq@town.hall.org. The general idea is that you can set things up so that mail sent to "user@fax.domain" will get printed on the user's fax machine, if they've entered a fax number in their X.500 entry. NOTE: you will need to modify faxtotpc.c if you have any "abbreviated" phone number capabilities. For example, our telephone switches allow you to dial only the last 5 digits of campus telephone numbers. People, therefore, tend to list the last 5 digits of their fax numbers. The routine "munge_phone()" takes care of fixing up abbreviated phone numbers. You may need to write your own code. fax500 is not yet complete. In particular, the following work still needs to be done: - If the group entry itself has a fax number, don't send to all the members' individual fax numbers. Instead, just send to the group's fax number. - The -h flag for fax500 defines both the host name and the search base. This causes problems because the host name we want is "fax.umich.edu" but we need to search "umich.edu." The workaround is to add an Associated Domain corresponding to the domain you want for your fax service to each X.500 group which is to be accessible. - We're working toward mail500 and fax500 being the same binary. Depending on what argv[0] is, you'll get different behavior. Although this binary should work just like mail500 if you name it "mail500" it's not yet been tested. - fax500 currently assumes that incoming messages are plain text, and therefore constructs a destination address like "remote-printer.user_name@2.1.2.1.5.5.5.3.1.3.1.tpc.int". If the message is already MIME-compliant with an "application/remote-printing" content type, we lose, since the remote-printing software assumes that anything other than "remote-printer" on ther lhs of the address means the message is plain text. Not sure about the solution to this. - Regarding group support - typically, when we collect all the fax numbers for a group, we'll end up either with (a) people who haven't registered fax numbers, or (b) "email-only" group members who do not have entries in X.500 (they only have an email address associated with the group). The question is: what do you do with faxes for these folks? You could (1) bounce to the sender (current behavior) or you could (2) send email to the members with no fax numbers, informing them that someone tried to send them a fax. I tend to prefer solution (2) for case (a), and solution (1) for case (b). - A configuration file-driven "munge_phone()" would be nice. 8/23/93 - Gordon