openldap/clients/fax500
2001-06-11 21:08:49 +00:00
..
fax500.h Add OpenLDAP RCSid to *.[ch] in clients, libraries, and servers. 1999-09-08 19:06:24 +00:00
faxtotpc.c Add OpenLDAP RCSid to *.[ch] in clients, libraries, and servers. 1999-09-08 19:06:24 +00:00
main.c objectclass=* -> NULL 2000-04-12 01:00:48 +00:00
Makefile.in Strip installed executables 2000-05-30 18:23:56 +00:00
README Initial revision 1998-08-09 00:43:13 +00:00
rp500.c unifdef -ULDAP_UFN 2001-06-11 21:08:49 +00:00
xrpcomp merged with autoconf branch 1998-10-25 01:41:42 +00:00

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