__ __ __ __ | | | | _ _ _ _ | _ _ _ | | | _ _ _ _ _ _ _ | | | | | | | |_) |_| | |/ | | | |_| |\| |_| | _ |_| | _ |_ |_) | | | | | | | | \ | | |_ |\ | | | | | | | | | |_| | | |_| |_ | \ Version 1.4 Đ 1996 by Sebastian Bleikamp All rights reserved. ------------------------------------------------------------------------------- 1.1 Introduction: ------------- Well, what is it ? I think it is a new message tracker for MM. But who knows, perhaps it is just a new bug bomb for MM ... ??? The idea for this program came me when I tried MM_StarTrack. I thought this program were great, but for me it had a major disadvantage: It dosnīt recognize/checks for e-mail addresses. And about 80% of my mails are e-mails. So I decided to write my own tracker. While doing this, I added some other features, too. So are the domains and all other addresses configured by standard AmigaDOS patterns, e.g. (#?):(#?)/(#?).(#?)@(#?). This is what came out. A fast scanning, fully configurable message tracker with multi-language support. I hope you have fun with it. 1.2 Copyright: ---------- This program is copyrighted by Sebastian Bleikamp. It is MAILWARE or POSTCARDWARE, which means the following: THE ARCHIVE MAY BE DISTIBUTED FREELY AS LONG AS ITSELF OR ITS CONTENTS ARE NOT MODIFIED IN ANY WAY. USE IT AT YOUR OWN RISC ! THE AUTHOR IS NOT RESPONSIBLE FOR ANY DAMAGE THE PROGRAM MAKES. WHO USES THIS PROGRAM REGULARLY HAS TO WRITE THE AUTHOR A POSTCARD OR A MAIL. Pirates, listen ! Who uses this program without writnig me a mail will be punished (if caught ..) by two or more harddisk crashs and seven GURUs a day. :-) A registration mail is included in this package. So if you are too lazy to write me a mail, use it ! 2.1 Installation: ------------- Software installation is quite simple. Just copy the files to the directories to which they belong: MM:Rexx/ MM_TrackManager.rexx MM:Config/ MM_TrackManager.cfg Copy the other files where you want to have them (e.g. MM:Config/MM_TrackManager/ ). If you use this program regularly, you should change the textfiles because they are only examples. The areas which should be scanned have to have the flag "TwoPassImport" set ! 2.2 Configuration: -------------- The configuration is done by the configuration file "MM:Config/MM_TrackManager" and the textfiles used in the config. After the configfile has been written, it has to be compiled. Therefor call MM_TrackManager with the arguments "CPLCFG " e.g.: 1. MM:Rexx/> rx MM_TrackManager.rexx CPLCFG MM:Config/MM_TrackManager.cfg MM:Rexx/MM_TrackManager.rexx NOTE: 1. The config will be parsed and added to the source code. So you have to add the . Donīt worry, backup will be made. 2. MM_TrackManager will check the configfile for modifications every time when it is started, and if the configfile was changed, it will inform you. 2.2.0 The configfile "MM:Config/MM_TrackManager.cfg": -------------- This configfile exists out of command lines, each beginning with a keyword. Empty lines and lines beginning with an ";" will be skipped. Address Patterns are standard AmigaDOS patterns. Here are some examples: (#?):(#?)/(#?).(#?)@(internet) - everything from the domain internet. (#?):(#?)/(#?).(#?)@(internet|fidonet) - everything from the domains internet and fidonet ((#?):(#?)/(#?).(#?)@(internet)|(2):(24#?)/(#?).(#?)@(fido)) - everything from the domain internet and all addresses beginning with 2:24... from fidonet. The same is meant for the email addresses , eg: ((dummy_a@localhost)|(dummy_b@#?)) - everything to dummy_b and everything to dummy_a@localhost By the way, I get the from-email address out of the replyaddr kludge and the to-email address from the first line in the message body ("To: ..."). Please report bugs to me immediately ! Look into the example config file for more infos ! 2.2.1 General Settings: ----------------- MM_TrackManager has an own logfile. Only important things like the startup/shutdown/moved mails/errors are logged in the MM logfile. Here are the different loglevels: -1 - nothing will be logged. 0 - only Hard Errors will be logged, like a missing file aso. 1 - startup/shutdown will be logged. 2 - moving messages will be logged. 3 - moving/remapping messages will be logged. 4 - other message functions (RRR, copy) will be logged. 5 - message info will be logged. Keyword: Function: ------------------------------------------------------------------------------- #SYSOPNAME - This defines the sysops name. It will be used for the replace patterns. #SYSOPADDR - The sysopīs fido addresses. You can give several ones here, they will be only used for the replace patterns. #SYSOPEMAIL - The sysopīs email address. Again only for the replace patterns. #TEMPFILE - MM_TrackManager needs a file for temporary storages. "T:MM_TrackManager.tmp" would be a good one. #BADAREA - If MM_TrackManager finds messages to be bounced etc., the messages wonīt be deleted. They will be moved to this area. You can use your badarea here. #STDFLAGS - These are the flags an outgoing message will have, e.g. "PVT KILL". #LOGCLEVEL - The loglevel for the stdio. #LOGLLEVEL - The loglevel for the logfile. #LOGFILE - The logfile AmigaDOS path, e.g. "RAM:MM_TrackManager.log". 2.2.2 Language settings: ------------------ MM_TrackManager supports different languages. Therefore several settings must be made. Every language has a number. Language number 0 is the standard language, it is allways used if no other setting is made. (e.g. a msg file is not given for the specified language.) The different languages are defined by address patterns. Keyword: Function: ------------------------------------------------------------------------------- #LANGUAGE - = language number, = string. This defines language number . The language is called . e.g: #LANGUAGE 0 English #LANGPAT - = language number, = address pattern, = email pattern This means, that every message send to an address that fits to the patterns will be written in language number . e.g.: #LANGPAT 0 (#?):(#?)/(#?).(#?)@internet #? for every message in the domain "internet" will be used language number 0 (here English). 2.2.3 Standard message files: ----------------------- Here the textfiles and subjects for non-routable messages are configured. NOTE: In this chapter I also explain how different language textfiles and subjects work. From now on I will not explain every time how to include different languages. I will use several shortcuts in the following text: - this will mean a language number. - a textfile, including the path ! - a subject, replace patterns (see below) can be used. Different language support is done as follows: For each textfile and subject, a standard setting is made. For this standard setting, language number 0 (std. language, normally English) is used. Then other textfiles / subjects with other language numbers can be added. If a textfile/subject in a language is not specified ("", empty string), the standard language will be used. So the standard language (0) HAS to be defined ! Example: #UDFTEXT 0 MM:Track/ENG.UnknownFrom - language 0, textfile "MM:Track/ENG.U..." #UDFTEXT 1 MM:TRack/GER.UnknownFrom - language 1, textfile ... #UDFTEXT 2 - language 2, no textfile specified ! A message shall be written in language number ... ... 0 : Textfile is present, okay. ... 1 : Oh, an own textfile exists ! It will be used. ... 2 : Mhh .. no textfile specified. The standard (no 0) textfile will be used. ... 3 : ??? Nothing there. I will use textfile number 0, the standard textfile. The same it works withe subjects. You got it now ? NO ??? Then read this chapter again, but please: carefully ... Keyword: Function: ------------------------------------------------------------------------------- #UDTTEXT - textfile for a bounced message, which goes to an unknown domain, which means no routing is present. #UDTSUBJ - the subject for the above textfile. #UDFTEXT - textfile sent to the receiver of a message whose sender comes form an unknown domain. That means that replies canīt be routed. #UDFSUBJ - the subject to this textfile. 2.2.4 Domain configuration: --------------------- This is the domain configuration part. Each domain is identified by an address pattern. For each domain, other check functions can be selected. There are: RRR - Send a receive receipt if requested. CROSSNET - Check for mails addressed to a different domain. KILLEMPTY - Kill messages with a completely empty body. CHECKNLR - Check the nodelist(s) for the receiverīs system/boss. If not found, send a messsage and/or kill the message. I think only useful for fidonet. CHECKNLS - Like CHECKNLR, but the sender will be checked. Keyword: Function: ------------------------------------------------------------------------------- #DOMAIN - from here on all settings belong to a new domain named . The name will be used by the replace patterns. #DPATTERN - the address pattern for this domain. #DCHECK - what to check: RRR, CROSSNET, KILLEMPTY #DRRRTEXT - receive receipt textfile for language . #DRRRSUBJ - subject for language . #DCNSTEXT - text for crossnet answers to the sender. #DCNSSUBJ - ^ subject #DCNRTEXT - text for crossnet answers to receiver. #DCNRSUBJ - ^ subject #DTODONLR [STOP] - Boolean switches: Stop if node wasnīt found in the #DTODONLS [STOP] nodelist(s) ? #DNLRTEXT - send to the sender if receiver wasnīt found in the nl. #DNLRSUBJ - ^subject. #DNLSTEXT - send a warning msg to the receiver if sender wasnīt found. #DNLSSUBJ - ^subject. 2.2.5 Bouncing: --------- Ah, now it becomes interesting: How can I bounce messages ? You have to define a new bounce "structure" like a domain: Keyword: Function: ------------------------------------------------------------------------------- #BOUNCE - begin new bounce structure .. If these patterns fit, then bounce (use #? for everything, speeds up checking): #BFROMNAME - senderīs name #BFROMADDR - his fido address #BFROMEMAIL - his e-mail address #BTONAME - receiverīs name #BTOADDR - his fido address #BTOEMAIL - his e-mail address #BSUBJECT - the message subject #BTEXT - text in the message body. (be careful, slows down checking !) Information message to the sender. If NO files are given, no message will be sent. #BINFTEXT - the bounce file ( = language) #BINFSUBJ - the subject. 2.2.6 Remaping messages: ------------------ Remapping messages is like bouncing messages. Keyword: Function: ------------------------------------------------------------------------------- #REMAP - begin new remap structure ... Input patterns: If they fit, the message will be remapped. #RINNAME - receiverīs name #RINADDR - his fido address #RINEMAIL - his email address To these values the message will be remapped. If you leave something empty, the old value will be used: #ROUTNAME - name #ROUTADDR - fido address #ROUTEMAIL - email address I think you donīt have to set these values, but you should: #ROUTTEXT - new message body (for the remapped message). #ROUTTEXT - new subject. #RINFTEXT - information text send to the sender. #RINFSUBJ - subject. 2.2.7 Copying messages: ----------------- Copying messages is like remapping messages. The only difference is that there are some more input fields (look at bounce, too !) and that ONLY ONE FILE AND SUBJECT CAN BE given !!! Keyword: Function: ------------------------------------------------------------------------------- #COPY - begin new copy section. #CINFNAME - senderīs name #CINFADDR - his fido address #CINFEMAIL - his email address #CINTNAME - the receiverīs name #CINTADDR - his fido address #CINTEMAIL - his email address #CINSUBJ - the subject #CINTEXT - some text in the message body. #COUTNAME - the copy shall be send to: ... name #COUTADDR - ... fido address #COUTEMAIL - ... email address #COUTTEXT - ... the textfile #COUTSUBJ - ... the subject 2.2.8 The ToDo function: ------------------ Another nice function is the ToDo function. If a message matches to several patterns, a specified action will be done. This can be done for each message (e.g. if an uuencoded file was found then decrypt it) (f: ToDoEach) or once after everything other is done (e.g. if a message to AreaFix was found, run an AreaFix program) (f: ToDoOnce) Keyword: Function: (ToDoEach:) (ToDoOnce:) ------------------------------------------------------------------------------- #TODOEACH #TODOONCE - begin new Todo section. #TDEFNAME #TDOFNAME - senderīs name. #TDEFADDR #TDOFADDR - fido address. #TDEFEMAIL #TDOFEMAIL - email address. #TDETNAME #TDOTNAME - receiverīs name. #TDETADDR #TDOTADDR - fido address. #TDETEMAIL #TDOTEMAIL - email address. #TDESUBJ #TDOSUBJ - subject of the message. #TDETEXT #TDOTEXT - text in the body. #TDECOM #TDOCOM - command executed when a message is found. ToDoEach only: Replace patterns can be used ! 2.2.9 The Move function: ------------------ With the move function, messages can be moved from one area to another. You just have to specify which messages shall be moved. Useful when you have several users at one system, and you want to keep different user mail-folders. Keyword: Function: ------------------------------------------------------------------------------- #MOVE - begin new MOVE section. #MOVEFNAME - senderīs name. #MOVEFADDR - fido address. #MOVEFEMAIL - email address. #MOVETNAME - receiverīs name. #MOVETADDR - fido address. #MOVETEMAIL - email address. #MOVESUBJ - subject of the message. #MOVETEXT - text in the body. #MOVEAREA - the area the message shall be moved to. 2.3 The replace patterns: --------------------- In all the textfiles and the subjects can the replace patterns be used. They are simple keywords which are replaced by special values. Here they are (ta taa taa taaaa !): Text related patterns: {TEXT} [lines] - This pattern has to be an single line. This line will be replaced by the message body. [lines] is the number of lines inserted. If [lines] is not present, the whole message body will be inserted. Sysop related patterns: {SYSOP_NAME} - the sysopīs name. {SYSOP_ADDR} - his address(es). {SYSOP_EMAIL} - his email address. Program related patterns: {PRG_NAME} - the program name. (MM_TrackManager) {PRG_VER} - the version. {PRG_ID} - the name and version. {PRG_SYS} - this systemīs address. Message related patterns: {MSG_NUMBER} - number of the current message. {MSG_AREA} - area of the current message. {MSG_FROM} - name of the sender. {MSG_FROMADDR} - his fido address. {MSG_FROMEMAIL} - his email address. {MSG_FROMWHOM} - his name & address in style "XY (0:0/0.0@?)" (Fido) or "xy@ab.cd.ef (X Y)" (Internet). {MSG_FROMNICK} - the first name of the sender. {MSG_FROMDOMAIN} - the name of the domain the message comes from. (If unknown, ??????) {MSG_FROMLANGUAGE} - the name of the language used by TrackManager. {MSG_TO} - name of the receiver. {MSG_TOADDR} - his fido address. {MSG_TOEMAIL} - his email address. {MSG_TOWHOM} - the same as {MSG_FROMWHOM} {MSG_TONICK} - the first name of the receiver. {MSG_TODOMAIN} - the name of the domain the message is addressed to. (If unknown, ??????) {MSG_TOLANGUAGE} - the name of the language used by TrackManager. {MSG_SUBJECT} - the subject of the message. {MSG_DATE} - the date of the message. {MSG_FLAGS} - the flags of the message. Extra patterns (function depending): 1. Remap & Copy: {EXTRA1} - the original receiver. {EXTRA2} - the original receiverīs address. {EXTRA3} - the original receiverīs email address. {EXTRA4} - the original subject. 2.4 Usage: ------ Once the config is compiled, you can start MM_TrackManager without any arguments. It begins to scan for new messages (flag !SENT) first, then for messages to remap. If you forget how to compile a config etc., use: rx MM_TrackManager HELP and you will get a nice (???) help. 3.1 Known Bugs: ----------- - none. 3.2 How to contact the author: -------------------------- Where to send the flowers and flames ? Here, to me: Suggestions and comments are welcome, because MM_TrackManager is still under developement. Sebastian Bleikamp Lothringer Weg 37a D-45481 Mülheim GERMANY Fido: 2:2448/10.131@fidonet EMail (preferred): bleikamp@mail.rhein-ruhr.de WWW: http://www.rhein-ruhr.de/~bleikamp/ This is the support page for MM_PGPManager, MM_FbMRM and MM_TrackManager ! 3.3 Credits: -------- I want to thank these peoples .... Pino Aliberti, ... for his great MailManager, Siggi Weisner, ... for the MM support in Germany, my Cat, ... for playing with me in times when I was bored. And ??? Are there no betatesters who want to be called here ?? I need some. 3.4 Future: ------- The Future is up to YOU !!!!! Tell me your suggestions and I will implement them ! This is not monarchy, not Micr*s*ft, not PC !! This is AMIGA !! 3.5 History: -------- since 0.0: - MM_TrackManager was born ! since 1.0: - added a copy/forward function. - added e-mail support for language detection. - added own logfile. - many bugs removed. since 1.1: - fixed a bug - bounce looked for wrong values ! - added ToDoOnce & ToDoEach. since 1.2: - minor improvements. - addded nodelist check for sender & receiver. since 1.3(a,b): - added move function.