unable to write
/etc/mail/sendmail.pid on Solaris 2.x?
Kvirtuser line to sendmail.cf ?
There are a couple of ways of doing this. This describes using the "user database" code, discussed in detail at the Using UserDB to Map Full Names page. This is still experimental and was intended for a different purpose -- however, it does work with a bit of care. It does require that you have the Berkeley "db" package installed (it won't work with DBM). First, create your input file. This should have lines like:
loginname:mailname DifferentName DifferentName:maildrop loginnameInstall it in (for example) /etc/userdb. Create the database:
makemap btree /etc/userdb.db < /etc/userdbYou can then create a config file that uses this. You will have to include the following in your .mc file:
define(confUSERDB_SPEC, /etc/userdb.db) FEATURE(notsticky)
Because full names are not unique. For example, the computer community has two Andy Tannenbaums and two Peter Deutsches. At one time, Bell Labs had two Stephen R. Bournes with offices a few doors apart. You can create alternative addresses (e.g., Stephen_R_Bourne_2), but that's even worse -- which one of them has to have their name desecrated in this way? And you can bet that one of them will get most of the other person's email.
So called "full names" are just an attempt to create longer versions of unique names. Rather that lulling people into a sense of security, I'd rather that it be clear that these handles are arbitrary. People should use good user agents that have alias mappings so that they can attach arbitrary names for their personal use to those with whom they correspond (such as the MH alias file).
Even worse is fuzzy matching in email -- this can make good addresses turn bad. For example, Eric Allman is currently (to the best of our knowledge) the only ``Allman'' at Berkeley, so mail sent to <Allman@Berkeley.EDU> should get to him. But if another Allman ever appears, this address could suddenly become ambiguous. He's been the only Allman at Berkeley for over fifteen years -- to suddenly have this "good address" bounce mail because it is ambiguous would be a heinous wrong.
Directory services should be as fuzzy as possible (within reason, of course). Mail services should be unique.
The intent was to have all information for a given user (where the user is the unique login name, not an inherently non-unique full name) in one place. This would include phone numbers, addresses, and so forth. The "maildrop" feature is because Berkeley does not use a centralized mail server (there are a number of reasons for this that are mostly historic), and so we need to know where each user gets his or her mail delivered -- i.e., the mail drop.
UC Berkeley is (was) in the process of setting up their environment so that mail sent to an unqualified "name" goes to that person's preferred maildrop; mail sent to "name@host" goes to that host. The purpose of "FEATURE(notsticky)" is to cause "name@host" to be looked up in the user database for delivery to the maildrop.
The user database code is part of the Sendmail V8 distribution. However, it depends on your installing the db library from the package at http://www.sleepycat.com/packages/db.1.85.tar.gz. If you install this library, edit the Makefile to include the right option (-DNEWDB), and then make sendmail again, you get a binary which has the database features described in the book and the documentation provided in the sendmail source archive.
If you're using SGI Irix above 4.x, see Q2.16 for the patches you will need to get db 1.85 working on your machine.
The basic incompatibility with Pine and the user database option is in how Pine writes From addresses in the header. Most MUAs write the From address as "From: user", while Pine, for reasons given in its documentation, write the From address as "From: user@FQDN" (FQDN=fully qualified domain name). Using the m4 feature macro always_add_domain has the same effect. Because of this difference, the user database does not rewrite these headers.
One solution to this problem is to make the following change in the sendmail.mc file compiled by m4 into your /etc/sendmail.cf (or wherever your sendmail.cf file is located) after you have the user database option installed and working with other MUAs:
Early in the section(s) where you are setting configuration variables, add the following:
# Define our userdb file for FQDN rewrites Kuserdb btree -o /etc/userdb.dbAnd a bit later, before the "MAILER()" entries, but after other configuration options have been set:
LOCAL_RULE_1 ######################################################## ### Local Ruleset 1, rewrite sender header & envelope ## ######################################################## #Thanks to Bjart Kvarme <bjart.kvarme@usit.uio.no> S1 R$- $1 < @ $j . > user => user@localhost R$- < @ $=w . > $* $: $1 < @ $2 . > $3 ?? $1 user@localhost ? R$+ ?? $+ $: $1 ?? $(userdb $2 : mailname $: @ $) R$+ ?? @ $@ $1 Not found R$+ ?? $+ $>3 $2 Found, rewrite #NOTE ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ # Use Tab Characters Use Tab Characters in these regions # to make three columns (the line with "mailname" only has 2 columns).Now the user database should re-write messages sent with Pine or anything else that causes local users to have their address be fully qualified (both header and envelope sender will be properly re-written). If this still does not work for you, try adding the following to either the system-wide pine.conf, pine.conf.fixed, or your personal .pinerc:
user-domain=localhost
This has been known to help solve the problem for some people.
However, a more elegant (read: m4-based) solution for version 8 sendmail users has yet to be created.
There is nothing wrong. This is just a diagnosis of a condition that had not been diagnosed before. If you are getting a lot of these from a single host, there is probably some incompatibility between 8.x and that host. If you get a lot of them in general, you may have network problems that are causing connections to get reset.
Note that this problem is sometimes caused by incompatible values of the MTU (Maximum Transmission Unit) size on a SLIP or PPP connection. Be sure that your MTU size is configured to be the same value as what your ISP has configured for your connection. If you are still having problems, then have your ISP configure your MTU size for 1500 (the maximum value), and you configure your MTU size similarly.
Although it seems like a problem of this sort would affect all of your connections, that is not the case. You may encounter this problem with only a small number of sites with which you exchange mail, and it may even affect only certain size messages.
I just upgraded to version 8 sendmail and now when my users try to forward their mail to a program they get an "illegal shell" or "cannot mail to programs" message and their mail is not delivered. What's wrong?
In order for people to be able to run a program from their .forward file, version 8 sendmail insists that their shell (that is, the shell listed for that user in the passwd entry) be a "valid" shell, meaning a shell listed in /etc/shells. If /etc/shells does not exist, a default list is used, typically consisting of /bin/sh and /bin/csh.
This is to support environments that may have NFS-shared directories mounted on machines on which users do not have login permission. For example, many people make their file server inaccessible for performance or security reasons; although users have directories, their shell on the server is /usr/local/etc/nologin or some such. If you allowed them to run programs anyway you might as well let them log in.
If you are willing to let users run programs from their .forward file even though they cannot telnet or rsh in (as might be reasonable if you run smrsh to control the list of programs they can run) then add the line:
/SENDMAIL/ANY/SHELL/
to /etc/shells. This must be typed exactly as indicated, in caps, with the trailing slash.
NOTA BENE: DO NOT list /usr/local/etc/nologin in /etc/shells -- this will open up other security problems.
IBM AIX does not use /etc/shells -- a list of allowable login shells is contained, along with many other login parameters, in /etc/security/login.cfg. You can copy the information in the "shells=" stanza into a /etc/shells on your system so sendmail will have something to use. Do NOT add "/usr/lib/uucp/uucico" or any other non-login shell into /etc/shells.
Also note that there are some weird things that AFS throws into the mix, and these can keep a program from running or running correctly out of .forward files or the system-wide aliases.
See also "smrsh" in Q2.13.
I just upgraded to version 8 sendmail and suddenly connections to the SMTP port take a long time. What is going wrong?
It's probably something weird in your TCP implementation that makes the IDENT code act oddly. On most systems version 8 sendmail tries to do a ``callback'' to the connecting host to get a validated user name (see RFC 1413 for detail). If the connecting host does not support such a service it will normally fail quickly with "Connection refused", but certain kinds of packet filters and certain TCP implementations just time out.
To test this (pre-8.7.y sendmail), set the IDENT timeout to zero using:
define(`confREAD_TIMEOUT',`Ident=0')dnl
in the .mc file used by m4 to generate your sendmail.cf file. Alternatively, if you don't use m4, you can put ``OrIdent=0'' in the configuration file (we recommend the m4 solution, since that makes maintenance much easier for people who don't understand sendmail re-write rules, or after you've been away from it for a while). Either way, this will completely disable all use of the IDENT protocol.
For version 8.7.y sendmail (and above), you should instead use:
define(`confTO_IDENT',`0s')dnl
Another possible problem is that you have your name server and/or resolver configured improperly. Make sure that all "nameserver" entries in /etc/resolv.conf point to functional servers. If you are running your own server, make certain that all the servers listed in your root cache are up to date (this file is usually called something like "/var/namedb/root.cache"; see your /etc/named.boot file to get your value). Either of these can cause long delays.
I just upgraded to version 8 sendmail and suddenly I get errors such as ``unknown mailer error 5 -- mail: options MUST PRECEDE recipients.'' What is going wrong?
You need OSTYPE(systype) in your .mc file, where "systype" is set correctly for your hardware & OS combination -- otherwise the configurations use a default that probably disagrees with your local mail system. See the configuration OSTYPE page for details.
If this is on a Sun workstation, you might also want to take a look at the local mailer flags in the Sun-supplied sendmail.cf and compare them to the local mailer flags generated for your version 8 sendmail.cf. If they differ, you might try changing the V8 flags to match the Sun flags.
Sendmail 8.7.y panics SunOS 4.1.3_U1 (at least for 1 <= y <= 3) and SunOS 4.1.3, and sendmail 8.6.x seems fine on both machines (at least for 9 <= x <= 12).
The problem is that a kernel patch is missing, specifically 100584-08 (4.1.3), 102010-05 (4.1.3_U1), or 102517 (4.1.4). This should be available from your hardware vendor through your support contract or their online support facilities (including being available on the SunSolve CD).
``It's not a bug, it's a feature.'' This happens when you have an
owner-list alias and you send to list. V8 propagates
the owner information into the SMTP envelope sender field (which appears as the
Unix From line [sometimes incorrectly referred to as the From-space "header"]
on Unix mail or as the Return-Path: header) so that downstream
errors are properly returned to the mailing list owner instead of to the sender.
In order to make this appear as sensible as possible to end users, I recommend
making the owner point to a "request" address -- for example:
list: :include:/path/name/list.list owner-list: list-request list-request: ericThis will make message sent to
list come out as being
"From list-request" instead of "From eric".
Believe it or not, this is intentional. The interpretation of the standards by the version 8 sendmail development group was that this was an inappropriate rewriting, and that if the rewriting were incorrect at least the envelope would contain a valid return address.
If you're using version 8.7.y sendmail (or later), you can use
FEATURE(masquerade_envelope)in your sendmail.mc file to change this behavior. This is discussed in greater detail at the configuration Masquerading and Relaying page.
Get the reimplementation of the mail11 protocol by Keith Moore from ftp://gatekeeper.dec.com/pub/DEC/gwtools/ (with contributions from Paul Vixie).
When I look in the queue directory I see that qf* files have been renamed to Qf*, and sendmail doesn't see these. What's wrong?
If you look closely you should find that the Qf files are owned by users other than root. Since sendmail runs as root it refuses to believe information in non-root-owned qf files, and it renames them to Qf to get them out of the way and make it easy for you to find. The usual cause of this is twofold: first, you have the queue directory world writable (which is probably a mistake -- this opens up other security problems) and someone is calling sendmail with an "unsafe" flag, usually a -o flag that sets an option that could compromise security. When sendmail sees this it gives up setuid root permissions.
The usual solution is to not use the problematic flags. If you must use them, you have to write a special queue directory and have them processed by the same uid that submitted the job in the first place.
This is considered to be a MUA issue rather than an MTA issue.
Quoth Eric Allman:
The primary reason is that the information necessary to do the encoding (that is, 8->7 bit) is unknown to the MTA. In specific, the character set used to encode names in headers is _NOT_ necessarily the same as used to encode the body (which is already encoded in MIME in the charset parameter of the Content-Type: header). Furthermore, it is perfectly reasonable for, say, a Swede to be living and working in Korea, or a Russian living and working in Germany, and want their name to be encoded in their native character set; it could even be that the sender was Japanese, the recipient Russian, and the body encoded in ISO 8859-1. If all I have are 8-bit characters, I can't choose the charset properly.Similarly, when doing 7->8 bit conversions, I don't want to throw away this information, as it is necessary for proper presentation to the end user.
This is usually caused by a bug in the remote host's mail server, or Mail Transport Agent (MTA). The "EHLO" command of ESMTP causes the remote server to drop the SMTP connection. There are several MTAs that have this problem, but one of the most common server implementations can be identified by the "220 All set, fire away" greeting it gives when you telnet to its SMTP port.
To work around this problem, you can configure sendmail to use a mailertable with an entry telling sendmail to use plain SMTP when talking to that host:
name.of.remote.host smtp:name.of.remote.host
Sites which must run a host with this broken SMTP implementation should do so by having a site running sendmail or some other reliable (and reasonably modern) SMTP MTA act as an MX server for the problem host.
There is also a problem wherein some TCP/IP implementations are broken, and if any connection attempt to a remote end gets a "connection refused", then *all* connections to that site will get closed. Of course, if you try to use the IDENT protocol across a firewall (at either end), this is highly likely to result in the same apparent kind of "read error".
The fix is simple -- on those machines with broken TCP/IP implementations, do not attempt to use IDENT. When compiling newer releases of version 8 sendmail, the compiler should automatically detect whether you're on a machine that is known to have this kind of TCP/IP networking problem, and make sure that sendmail does not attempt to use IDENT. If you've since patched your machine so that it no longer has this problem, you'll need to go back in and explicitly configure sendmail for support of IDENT, if you want that feature.
When creating m4 Master Config (".mc") files for version 8 sendmail, many FEATURE() macros simply change the definition of internal variables that are referenced in the MAILER() definitions.
To make sure that everything works as desired, you need to make sure that OSTYPE() macros are put at the very beginning of the file, followed by FEATURE() and HACK() macros, local definitions, and at the very bottom, the MAILER() definitions. See the configuration Introduction and Example page for more details.
In situations where you're behind a firewall, or across a dial-up line, there are times when you need to make sure that programs (such as sendmail) do not use the DNS at all.
With version 8.8, you change the service switch file to omit "DNS" and use only NIS, files, and other map types as appropriate.
With previous releases of version 8 sendmail, you need to recompile the binary and make sure that "NAMED_BIND" is turned off in src/conf.h.
Note that you'll need to forward all your outbound mail to another machine as a "relay" (one that does use DNS, and understands how to properly use MX records, etc...), otherwise you won't be able to get mail to any site(s) other than the one(s) you configure in your /etc/hosts file (or whatever).
In the contrib directory of the sendmail distribution is a
Perl script called etrn.pl. Assuming you're running sendmail
or some other SMTP MTA on some sort of a Unix host, and your ISP uses version
8.8 sendmail and they queue all mail for your domain (as opposed to stuffing
it all in one file that you need to download via POP3 or some such), the command
etrn.pl mail.myisp.com mydomain.comwill do the trick. You can learn about Perl at the Perl Language Home Page. The O'Reilly book is also very helpful.
If you don't have Perl, something like the following script should do the trick:
#!/bin/sh telnet mail.myisp.com. 25 << __EOF__ EHLO me.mydomain.com ETRN mydomain.com QUIT __EOF__Note that this is indented for readability, and the real script would have column position #1 of the file be the first printable character in each line.
Of course, you'll have to fill in the appropriate details for "mail.myisp.com", "mydomain.com", etc....
If your ISP doesn't use version 8.8 sendmail, you may have to cobble together alternative solutions. They may have a "ppplogin" script that is executed every time your machines dials them up, and if so, you may be able to have them modified this script so as to put a "sendmail -qRmydomain.com" in it (which is effectively what the "ETRN" command does, but in a safer fashion).
Alternatively, they may have a hacked finger daemon, so that you'd put "finger mydomain.com@theirhost.theirdomain.com" in your script. Or, they may have some other solution for you. However, only they would be able to answer what solutions they have available to them.
Obviously, the easiest and most "standard" solution is to have them upgrade their system to the most recent stable release of version 8.8 sendmail.
unable to write
/etc/mail/sendmail.pid?
sendmail checks if it has write access to the directory in which it
wants to create a file without granting special privileges to 'root'.
To have sendmail run properly, the directories /etc,
/etc/mail, and/or /var/run should be owned
by root and be writable by its owner.
sendmail 8.8 only supports Berkeley DB 1.85. It will not work with newer Berkeley DB versions, even in compatibility mode
Sendmail 8.9, however, does include support for Berkeley DB 2.X, starting with 2.3.16 .
Berkeley sendmail 8.8.8 supports most known flavors of UNIX, including:
386BSD A-UX AIX Altos BSD-OS BSD43 CLIX CSOS ConvexOS Dell DomainOS Dynix EWS-UX_V FreeBSD HP-UX IRIX ISC KSR LUNA Linux Mach386 NCR.MP-RAS NEWS-OS NeXT NetBSD NonStop-UX OSF1 OpenBSD PTX Paragon PowerUX RISCos SCO SINIX SMP_DC.OSx.NILE Solaris SVR4 SunOS Titan ULTRIX UMAX UNICOS UNIX_SV.4.x.i386 UX4800 UXPDS Utah dgux maxion uts.systemV
Also, a Windows NT version is available from MetaInfo, Inc..
You need to add the fully-qualified host name and/or IP address of each
client to class R, the set of relay-allowed domains. For version 8.8.X,
this is typically defined by the file /etc/sendmail.cR ;
for 8.9.X, it is typically /etc/mail/relay-domains . Note:
if your DNS is problematic, you may need to list the IP address in
square brackets (e.g., [1.2.3.4]) to get the
${client_name} macro to work properly; in general, however,
this should not be necessary.
Once you've updated the appropriate file, SIGHUP your sendmail
daemon and you should be OK.
Further details are available on our Allowing controlled SMTP relaying in Sendmail 8.9 page.
Kvirtuser line to sendmail.cf?
Just adding the proper Kvirtuser line to sendmail.cf is not enough
to enable the virtual user table feature, a key ingredient for virtual hosting.
You need to use the m4 technique FEATURE(virtusertable);
detailed instructions are provided at our
Virtual Hosting with Sendmail page.
Stuffing multiple user's mail into a single mail box is not a good method of distributing user mail but if you must do this, the following solution should allow a tool like fetchmail to separate the messages for individual users.
FEATURE(local_procmail) in your .mc file
so procmail (which you must install separately) will deliver mail to
the mailbox.
FEATURE(virtusertable) to create a virtual user table
entry for the domain as follows:
@domain.com domuser+%1where
domuser is the username of the mailbox you will be using.
domuser's
$HOME/.procmailrc:
DOMAIN=domain.com ENV_TO=$1 :0f * ENV_TO ?? . | formail -i "X-Envelope-To: "$ENV_TO@$DOMAIN :0fE | formail -i "X-Envelope-To: UNKNOWN"This will insert an
X-Envelope-To header with the original
envelope recipient address when the message is delivered the normal way
via the virtusertable, and UNKNOWN if for some reason it was
sent directly to domuser.
If at all possible, no.
Wildcard MX records have lots of semantic "gotcha"s. For example, they will match a host "unknown.your.domain" -- if you don't explicitly test for unknown hosts in your domain, you will get "MX list for hostname points back to hostname" or "config error: mail loops back to myself".
See RFCs 1535, 1536, and 1912 (updates RFC 1537) for more detail and other related (or common) problems. See also _DNS and BIND_ by Albitz and Liu.
They can also cause your system to add your domain to outgoing FQDNs in a desperate attempt to get the mail to where it's supposed to go, but because *.your.domain is valid due to the wildcard MX, delivery to not.real.domain.your.domain will get dumped on you, and you may even find yourself in a loop as the domain keeps getting tacked on time after time after time (the "config error: mail loops back to myself" problem).
Wildcard MX records are just a bad idea, plain and simple. They don't work the way you'd expect, and virtually no one gets them right. Avoid them at all costs.
This is a local mailer issue, not a sendmail issue. Depending on what you're doing, look at procmail (see Q4.9), ftpmail, or Majordomo.
The latest version of Majordomo can be found at ftp://ftp.greatcircle.com/pub/majordomo/. It is written in Perl and requires either Perl 4.036, and appears to run with only minor tweaks under 5.001a or later. Make sure to check out the web interface for Majordomo called "Mailserv" at http://iquest.com/~fitz/www/mailserv/ or "LWGate" at http://www.netspace.org/users/dwb/lwgate.html. The latest versions of Perl (both 4.x and 5.x) can be found in http://www.metronet.com/perlinfo/src/. More information about Perl can be found at http://www.metronet.com/perlinfo/perl5.html
The latest version of ftpmail can be found at ftp://src.doc.ic.ac.uk/packages/ftpmail or any comp.sources.misc archive (volume 37).
Again, this is a local mailer issue, not a sendmail issue. Either modify your local mailer (source code will be required) or change the program called in the "local" mailer configuration description to be a new program that does this local delivery. One program that is capable of doing this is procmail (see Q4.9), although there are probably many others as well.
You might be interested in reading the paper ``HLFSD: Delivering Email to your $HOME'' available in the Proceedings of the USENIX System Administration (LISA VII) Conference (November 1993). More information is at ftp://ftp.cs.columbia.edu/pub/hlfsd/README.hlfsd, while the actual archive of the papers is at ftp://ftp.cs.columbia.edu/pub/hlfsd/hlfsd-paper.tar.gz (tar archive, gzip'ed).
Or, I'm trying to use the "don't deliver to expensive mailer" flag, and it delivers the mail interactively anyway. I can see it does it: here's the output of "sendmail -v foo@somehost" (or Mail -v or equivalent).
The -v flag to sendmail (which is implied by the -v flag to Mail and other programs in that family) tells sendmail to watch the transaction. Since you have explicitly asked to see what's going on, it assumes that you do not want to to auto-queue, and turns that feature off. Remove the -v flag and use a "tail -f" of the log instead to see what's going on.
If you are trying to use the "don't deliver to expensive mailer" flag (mailer flag "e"), be sure you also turn on global option "c" -- otherwise it ignores the mailer flag.
I'm getting these error messages:
553 MX list for domain.net points back to relay.domain.net 554 <user@domain.net>... Local configuration errorHow can I solve this problem?
You have asked mail to the domain (e.g., domain.net) to be forwarded to a specific host (in this case, relay.domain.net) by using an MX record, but the relay machine doesn't recognize itself as domain.net. Add domain.net to /etc/sendmail.cw (if you are using FEATURE(use_cw_file)) or add "Cw domain.net" to your configuration file.
IMPORTANT: When making changes to your configuration file, be sure you kill and restart the sendmail daemon (for ANY change in the configuration, not just this one):
kill `head -1 /etc/sendmail.pid` sh -c "`tail -1 /etc/sendmail.pid`"NOTA BENE: kill -1 does not work with versions prior to 8.7.y!
With version 8.8.z sendmail, if the daemon was started up with a full pathname (i.e., "/usr/lib/sendmail -bd -q13m"), then you should be able to send it a HUP signal ("kill -1", or more safely, "kill -HUP") and have it reload itself (version 8.7.y sendmail cannot do this safely, and represents a security risk if it's not replaced with version 8.8.3 or later).
I'm connected to the network via a SLIP/PPP link. Sometimes my sendmail process hangs (although it looks like part of the message has been transfered). Everything else works. What's wrong?
Most likely, the problem isn't sendmail at all, but the low level network connection. It's important that the MTU (Maximum Transfer Unit) for the SLIP connection be set properly at both ends. If they disagree, large packets will be trashed and the connection will hang.
This question is addressed on pages 445-449 of _sendmail, 2nd Ed_ (see page 319 of first edition) by Bryan Costales (see entry sendmail-faq//book/ISBN/1-56592-222-0 in Q6.1).
An updated version of this syslog-stat.pl script (so that it understands the log format used in version 8 sendmail) is at ftp://ftp.his.com/pub/brad/sendmail/syslog_stats. The updated version of ssl has been uploaded to the SMTP Resources Directory (in ftp://ftp.is.co.za/networking/mail/tools/), as well as ftp://ftp.his.com/pub/brad/sendmail/ssl. There is also another program (written by Bryan Beecher) at ftp://ftp.his.com/pub/brad/sendmail/smtpstats.
If you're interested in summarizing POP statistics, there is ftp://ftp.his.com/pub/brad/sendmail/popstats, also written by Bryan Beecher.
To see what else is available today, check the Comprehensive Perl Archive Network ftp://ftp.funet.fi/pub/languages/perl/CPAN/CPAN or ftp://ftp.cis.ufl.edu/pub/perl/CPAN/CPAN for the site nearest you. For the scripts themselves, look under CPAN/scripts/mailstuff/ at any CPAN site. For more information, see the comp.lang.perl.* FAQs at ftp://ftp.cis.ufl.edu:/pub/perl/faq/FAQ or ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/comp/lang/perl/.
There is also the "Sendmail Statistics Project" which has a web page at http://www.josnet.se/projects/ssp/. Although they have examples online of what the output might look like, it now appears that this project is either dead or at least indefinitely on hold. Still, you may be able to talk to the authors in order to get what code from them you can.
If you're interested in using these kinds of tools to help you do some near real-time monitoring of