XFERFAXLOG(5F)

💖 XFERFAXLOG — aka xferfaxlog, section 5F, bestie 💖

okay so this is the HylaFAX activity log page and honestly? it's the receipts page. every fax that goes out, every fax that comes in, it's all getting written down. let's get into it 🫶

---

✨ NAME ✨

xferfaxlog — the HylaFAX activity log, fr fr

---

🌸 DESCRIPTION 🌸

so the file etc/xferfaxlog is where all the tea gets spilled about inbound and outbound activities. it holds one line per inbound facsimile document or outbound job. it ALSO holds one line per expired job, and one line per job submitted. and if the modem config setting LogCalls is set to true, then you also get one line per received call, no cap.

the lines are fixed-format, tab-separated ASCII strings. literally, that's the whole vibe.

each record of a facsimile transmission goes like this:

date SEND commid modem jobid jobtag sender ``dest-number'' ``CSI'' params #pages jobtime conntime ``reason'' ``faxname'' ``faxnumber'' <null> ``owner'' ``dcs'' jobinfo

a facsimile document reception record goes like this:

date RECV commid modem qfile <null> fax ``local-number'' ``TSI'' params #pages jobtime conntime ``reason'' ``CIDName'' ``CIDNumber'' ``callid'' <null> ``dcs'' <null>

call records go like this:

date CALL commid modem <null> <null> fax ``local-number'' ``<null>'' 0 0 jobtime conntime ``<null>'' ``CIDName'' ``CIDNumber'' ``callid'' ....

each facsimile document retrieved by polling gets a record like this:

date POLL commid modem jobid jobtag sender ``dest-number'' ``TSI'' params #pages jobtime conntime ``reason'' ``faxname'' ``faxnumber'' <null>

an alphanumeric pager request gets a record like this:

date PAGE commid modem jobid jobtag sender ``dest-number'' ``<null>'' 0 0 jobtime conntime ``reason'' <null> <null> ``owner'' <null> jobinfo

expired job records go like this:

date UNSENT ``<null>'' ``<null>'' jobid ....

and job submission records go like this:

date SUBMIT ``<null>'' ``<null>'' jobid ....

---

🎀 the fields, explained 🎀

okay now the part where we decode all of that, because yes there are a LOT of fields. slay, let's go one by one:

• date — the date and time of the transaction, formatted like MM/DD/YY HH:MM. so MM is the numeric month, DD is the numeric day, YY is the last two digits of the year, and HH:MM is the time in 24-hour format. iconic.
• commid — the communication identifier for the call.
• modem — the device identifier for the modem that was used to do the send or receive.
• jobid — the job number for outbound calls.
• jobtag — the client-specified job tag for outbound calls.
• qfile — the associated queue file for the event.
• sender — the sender/receiver's electronic mailing address. and bestie, heads up: facsimile receptions are always attributed to the fax user.
• dest-number — the phone number dialed for outgoing calls.
• TSI — the Transmitter Subscriber Identification string (as received) for incoming calls.
• CSI — the Caller Subscriber Identification string of the remote machine (as reported) for outgoing calls.
• local-number — the local phone number on which the data was received.
• params — the negotiated facsimile session parameters used for transferring data, encoded as described below.
• #pages — the total number of pages transferred.
• jobtime — the duration of the session, in the format HH:MM:SS. this time includes setup overhead AND any time spent cleaning up after a call. it's giving "we count everything" energy.
• conntime — the time spent on the phone, in the format HH:MM:SS. this should be the time used by the PTT to calculate usage charges. 💸
• reason — a string that indicates if any problem occurred during the session.
• CIDName — the received CIDName value for the session.
• CIDNumber — the received CIDNumber value for the session.
• owner — the login name of the job owner.
• callid — the CallID values other than CIDName and CIDNumber, formatted by :: delimiters.
• dcs — the T.30 DCS string that was used in the facsimile communication.
• jobinfo — other formatted information about the job: totpages, ntries, ndials, totdials, maxdials, tottries, and maxtries, separated by slashes (/).

ngl, note that fields may have embedded blanks. do with that what you will.

session parameters are encoded as a decimal number that contains a packed set of Class 2 session parameter values. the format lives in the source code in the Class2Params::decode function. the page counts are always integral numbers, and partial pages that are to be retransmitted are not included in the page count. periodt.

the whole simple ASCII format was designed to be easy to process with programs like awk(1). so cute, so practical. 🦋

and now the fun part: if an executable named /var/spool/hylafax/etc/FaxAccounting exists, then it will be executed every time a record is written to etc/xferfaxlog. the record fields will each serve as separate command arguments. this is designed to allow attachment to external databases and other accounting mechanisms. and in earlier versions of HylaFAX, FaxAccounting would block the HylaFAX process invoking it — but bestie, that is no longer the case. glow up achieved. ✨

---

💅 NOTES 💅

the sender field does not necessarily represent the submitter's actual identity. for example, it reflects the value given by the sendfax(8C) -f option. so be cautious — do not use this field for auditing if the fax user base is not trusted. use owner instead, if possible. iykyk, this is important. 👑

---

💀 BUGS 💀

okay so the date format will "break" in the year 2000. 😭 and information should be recorded on a per-page basis for facsimile communications.

---

🌈 SEE ALSO 🌈

faxq(8C) faxsend(8C) faxgetty(8C)

---

and that's the whole page, bestie! 🫶 this one's from June 5, 1996, and it's the XFERFAXLOG(5F) page — go forth and read your logs like the main character you are. 💖✨🎀