Q: Why would I want to install an email autoresponder? A: Because your boss forced you to do so ;-). Anyway, even though I wrote it, I wouldn't really recommend using it, having your mail auto replied to is much like leaving a "gone fishing, nobody at home" note on your front door. A perfect way to attract the attention of people, whose attention you probably don't want to attract. ----- Q: Does gnarwl need root access? A: No, gnarwl does not require any extended priveleges at all, but of course it needs access to it's own files and should therefore be installed under it's own UID. Keep in mind, that gnarwl.cfg as well as gnarwl's homedirectory (may) contain sensible data. So care should be taken concerning file owner- ship and permission. ----- Q: What is this blacklist stuff good for? A: The whole point of employing LDAP for data storage instead of flat text files, is to keep all datarecords, belonging to a single user in a single place. Unfortunatly this proves to be futile for gnarwl, as soon as users either begin to share emailaddresses, or - even worse - get systemmail (e.g. root, webmaster, postmaster, etc.). You certainly don't want to generate automatic replies, stating that "sales@bigbiz.com" is currently gone fishing. On the other hand, you can't dissallow the user in question to use the autoresponder either. And thats what that blacklist is good for: An address listed in this database will never produce an automatic reply, even if the LDAP data says otherwise. ----- Q: What is this badheaders and blockfile stuff good for? A: They are used to prevent mail bouncing happily back and forth between gnarwl and another automated MUA (which can really generate a lot of network traffic and fill disks very fast). With the blockfiles, gnarwl keeps track on who already got an automatic reply, and makes sure s/he doesn't get another one too soon. The badheaders may be used to prevent gnarwl from replying to a mailing list. ----- Q: Someone mailed me back an emailbounce, saying gnarwl failed. A: This happens whenever gnarwl exits with EXIT_FAILURE. Normally this should not happen, or better said: A user is not able to provoke this him-/herself by simply sending a (garbled) mail, so you should check your maillog. Probable causes: Gnarwl could not ... - access lock or configfile - contact the LDAP server - invoke your MTA If none of this is the case you probably discovered a bug ;-). ----- Q: The header of the mail, gnarwl sent out seems to be somehow garbled. A: Gnarwl won't generate a mailheader itself, you have to provide one yourself. You have the choice of either putting a complete mail (header and body) in the field, refered to by "result", or you can force a unified standard header upon your users, by putting it in the file refered to by forceheader (NOTE: header and body must be separated by a single empty line, so don't forget to put such a line at the end of this file, if you forget to do so, it is assumed, that the user may continue the header and will supply the empty line him/herself). ----- Q: Wouldn't it be nice if a user only had to supply a vacationStart and a vactionEnd date and gnarwl would automatically de/activate itself in this period? A: Sure, that would be nice, but it won't be included in gnarwl for a simple reason: What format would that date be? - 13.01.01 - 01.13.01 - 01.13.2002 - 26.25.1234 - 01/01/03 - 14. Jun, 2004 - July the 14th - Montag - Tomorow - Christmas Just to name a few variants. As you see, there are numerous ways to (mis)spell a date, bring in a locale or make unprecise (even wrong) statements. Trying to deal with these would open a can of worms regarding syntax and semantic check. It would also remove a great deal of gnarwls flexibility. Therefore I'm afraid you have to either provide this feature by using add-on software (some script, that runs from CRON and toggle "vactionActive), or adapt the search filter in some way. ----- Q: Does gnarwl expand macros inside of macros? It seems to do so only sometimes? A: Gnarwl expands macros in the same order, they are declared in the configfile. So the earlier ones may contain all the later ones, but not vice versa. Let's regard this to be a feature ;-). ----- Q: I mapped $somemacro to someattribute, using the map_field directive. This ldapattribute now contains more than one value, but gnarwl only sees the first one, how do I refer to the second, third,... A: You don't gnarwl is not able to deal with multivalued attributes, so it always picks the first one it gets. ----- Q: Which conditions must be fullfilled, in order for gnarwl to send out an autoreply? 1. The incomming mail must not contain a headerline, matching a line in the badheaders database. 2. The mailheader must specify a sender and at least one recepient (naturally). 3. The header must not contain more than "maxheader" lines. 4. The mail may not specify more then "maxreceivers" addresses in the according header(s). 5. Last action for a sender/recepient pair was at least "expire" hours ago. 6. The receiving emailaddress must not be in the blacklist database. Points one to four refer the complete mail, that is, if one condition is not met, the complete mail is ignored. Points five and six refer to a single receiving address specified in the mail, that is, if one condition is not met, only this emailaddress is ignored, if the mail specified multiple recepients, they'll all get their chance. ----- Q: Is it save to delete files in blockdir? A: Yes, it is as long as gnarwl is not accessing them. Gnarwl simply creates a new lockfile if the old one is missing (of course, the old content is lost, so deleting a blockfile "resets" the according emailaddress). ----- Q: I plan to migrate the mailsystem to a different architecture, can I simply copy gnarwl's database files? A: No, this cannot be done. Gnarwl stores values of type time_t in those files. They cannot be recognized on architectures with a different endianess or sizeof(time_t). You have to employ the damnit program for doing so. ----- Q: It seems that gnarwl processes some mails over and over again?! A: This happens whenever an email specifies more than one recepient local to your site and your mailsystem is configured to pipe any received email through gnarwl, using the .forward mechanism. In this case, the mail in question is naturally processed (local recepient)^2 times. If this is a performance issue to your site, you could try to configure gnarwl and your mailsystem to make use of the "Delivered-To:" header. ----- Q: Will gnarwl answer to a BCC (blind carbon copy) mail? A: Not in the default configuration, as it is difficult to extract information that does not exist from the mail in question ;-). If you want to be able to answer to BCC's, you could try going for the "Delivered-To:" header. ----- Q: I wrote this little perl (bash,python,...) script as an add-on for gnarwl. It is quite handy, but I don't feel like maintaining my own downloadsite. Would it be possible to bundle it with gnarwl? A: Yes, it is possible. That's, what the contrib/ branch is good for. But please keep in mind: You program must be properly coded (no backdoors, obvious security holes, etc.), well documented and of course not be specific to your site. ----- Q: The email, gnarwl sent out contains strange glyphs everywhere. A: This happens wherever the mail contains non ASCII characters (german umlaute for example), as these are stored unicode encoded within LDAP. You have two choices here: 1. Make sure, any non ASCII character is MIME encoded. This is the proper way to do it, but may require some user discipline. 2. Use the "charset" configdirective, to translate unicode into your locale. Conversion is done using the iconv(3) routine, and therefore limited, to the encodings, it knows about. NOTE: iconv may not be available on every platform, in this case, the "charset" directive simply does nothing. In both cases you should adjust the header.txt file accordingly. ----- Q: What does "DEBUG/MAIL Code: MessageID: " in the maillog main? A: This line is produced by the mailparser and gives status information on every processed mail. "MessageID" is - of course - the content of the "Message-ID:" header, while code results from ORing the MAIL_* macros in mailhandler.h in the mail_status bitfield. ----- Q: Hey, what happened to the "uninstall:" target in the Makefile? A: It got deleted, because it is a) obsolete and b) a hassle to maintain. If you wish to be able to uninstall gnarwl again, then you should not install it from source, but build a package from it. After all, that is what the whole package manager biz is all about, isn't it ;-)? Anyway if this is not an option for you, there is a little trick to get the filelist: Just do a: configure --prefix=/tmp/gnarwl make make install cd /tmp/gnarwl find . NOTE: Of course, you still have to delete the systemaacount yourself. ----- Q: I run a heavy loaded Mailserver. Any tips on tuning gnarwl? A: Several: - Strip down your configfile. Comments and empty lines are waste, as well as config directives specifying default values. - Set the loglevel low, once your setup works. - Creating blockfiles takes gnarwl a considerable amount of IO resources. You might want to pre-create them using damnit. - Make sure, to index all the attributes from the querystring in your LDAP database. Otherwise lookups may by very slow. Use anonymous binding and don't set the protocol to autodetect. Keep your entire database in RAM if possible. - Compile gnarwl with a smaller line input buffer (--with-maxline=NUMBER). The default is set very high (2.1kb), to make sure, no lines are truncated. Unless someone sends mail using a really broken MUA, 256 bytes should still do the trick. - Try to avoid retrieving emailaddresses from "To:" and "Cc:" headers (even though it is the default), as these headers may contain more than one entry. This results in a number of useless and/or redundant database queries. ------ Q: There are some persons, I don't want to sent automatic replies to, how do I do that? A: This may be a bit tricky/messy, as you have to find an attribute for storing the unwelcome remote address first. In case you don't feel like extending LDAP schema (and updating all objects in the database), I suggest, you simply (ab)use the vacationForward attribute for this. Then adapt the queryfilter to something like: "( &(&(mail=$receiver)(vacationActive=TRUE))(!(vacationForward=$sender)) )" ------ Q: Gnarwl may produce quite a lot of LDAP queries, wouldn't it be better to cache them in order to gain more performance? A: Nope. The problem is simply, that gnarwl does not run as a daemon, but is invoked once per mail, so there is no way to provide a in-memory cache, while a on-disk cache would probably have the opposite effect. ------ Q: There are two versions of the ISPEnv.schema, which one should I take? A: The old version is included for legacy reasons only and should not be used for new installations, as it will not work with recent openLDAP servers. Beware if you plan to upgrade your schema, the two versions are slightly incompatible.