Date: Tue, 29 Oct 1996 14:01:23 -0800 (PST) From: Kristin.Hubner@INNOSOFT.COM Subject: Re: Understanding routing > After spending a lot of time in the documentation, I have still not gotten > it clear in my mind exactly how the address mapping/routing takes place in > PMDF. Could someone give us an overview of a typical message's trip > through PMDF? In particular, exactly when are the rewrite rules applied? > Are they applied by ALL of the channel master programs every time a > message is processed? A good example might be to take an incoming > internet message on a typical system and tell what would happen to it. I > know this would be different for our various systems, but if there is a > way to keep it at a pretty high level without getting into channel > definition and rewrite rule specifics, I think it might be helpful to a > lot of us who are relatively new to PMDF. Quick description, slurring over some of the details a bit.... Each channel when it does message enqueuing (message submission) rewrites all the addresses. Each address takes its own pass through the rewrite rules: envelope to addresses first (figure out the destination channel), envelope from addresses next, and then header addresses. Note that the rewrite rules in the PMDF.CNF file serve two purposes: (1) address transformation and (2) channel matching. The right hand side of a rewrite rule specifies both a new form for the address itself, and (except for $U%domain rules) also the channel that the address matches. The channel match is either explicit via a template of a form such as $U%domain@official-channel-name, or implicit via a template of the form $U@domain, where domain is also an official-channel-name. When an envelope to address matches the local channel, that envelope to address is next looked up in the alias database and alias file. The entire process starts over if any matches are found. After the regular rewrite rule processing, a FORWARD mapping (for envelope to addresses) or REVERSE mapping (for backwards pointing addresses and optionally for forward pointing header addresses), if present, will be applied. If a FORWARD mapping entry with $D is applied, the entire process starts over. In the case of PMDF-LAN, PMDF-MR, PMDF-MB400, PMDF-X400, or PMDF-XGS channels, there is additional, subsequent address processing that is channel specific, but not done as part of the address rewriting process cycle described above. For instance, PMDF-LAN channels transform each address to a LAN mail system format, using values specified in the channel option file; PMDF-MR channels transform each address to a Message Router format using the TO_MR rules; PMDF-MB400 and PMDF-X400 transform each address to an X.400 format using the TO_X400 rules; and PMDF-XGS channels transform each address to a SNADS format. And PMDF-FAX also has its own kind of channel specific address transformations. I can try describing a fairly simple message path, but I'm not certain it will be too illuminating. Here's an overview of the address handling for a sample message addressed to First.Last@acme.com from service@innosoft.com that comes in a TCP/IP channel, goes through a directory channel, and then is delivered to a VMS MAIL account via the l channel: ---------> --------> -------> tcp_local directory l That is, I'm assuming a PMDF.CNF file that includes rewrite rules vax.acme.com $U@vax.acme.com acme.com $U%acme.com@DIRECTORY-DAEMON ! ...and in INTERNET.RULES .com $U%$H$D@TCP-DAEMON and channels l master defragment ... vax.acme.com tcp_local smtp mx ... TCP-DAEMON directory DIRECTORY-DAEMON We'll also assume that this site has a REVERSE mapping table REVERSE *@*.acme.com $Y$0@acme.com and has USE_REVERSE_DATABASE=5 in their OPTION.DAT file (meaning this reversal will be applied to forward pointing header addresses as well as all backwards pointing addresses). A remote sending system connects to the PMDF SMTP server and says it has a message addressed to First.Last@acme.com from service@innosoft.com. PMDF runs the envelope to address, First.Last@acme.com, through the rewrite rules and finds that it matches the directory channel. (If the site had a FORWARD mapping table, it would be checked after the regular rewrite rules and could possibly redirect the message.) PMDF then runs the envelope from address, service@innosoft.com, through the rewrite rules; the envelope from address would next be transformed by the REVERSE mapping table, if any entries in that table applied to service@innosoft.com, which they don't. PMDF next runs the header to and header from addresses through the rewrite rules; they stay as First.Last@acme.com and service@innosoft.com respectively. And the addresses don't match any REVERSE mapping table entry so the REVERSE mapping doesn't change them either. After any processing of the message body, PMDF writes a message file to the PMDF_QUEUE:[DIRECTORY] directory and submits a directory master job. Now the directory channel runs. The directory channel does it thing and looks up the envelope to address -- perhaps in an X.500 directory, perhaps just in a PMDF database -- and finds an entry for First.Last@acme.com that translates to user@vax.acme.com. Note that the directory channel does not look up header addresses. Then it's time for the directory channel to rewrite the addresses. PMDF runs user@vax.acme.com through the rewrite rules and finds it matches the l channel, so PMDF checks in the alias database and alias file for any entries for user -- and let's say it finds any entry for user pointing to user2. So the envelope to address is changed to user2@vax.acme.com. PMDF rewrites user@vax.acme.com and finds it matches the local channel, so checks for an alias database or alias file entry for user2 -- let's suppose there is none. As there's no FORWARD mapping, the envelope to address processing is then done. PMDF rewrites the envelope from address -- again service@innosoft.com stays as service@innosoft.com. (Again no REVERSE mapping table entry applies.) The headers are rewritten again and again remain unchanged as First.Last@acme.com and service@acme.com, and again the REVERSE mapping doesn't have any entries that match these addresses. After any processing of the message body, PMDF writes a message file to the PMDF_QUEUE:[L] directory and submits an l master job. Now the l channel runs, and delivers the message to user2, with a To: header address of First.Last@acme.com and a From: header address of service@innosoft.com. Hope that helps. Regards, Kristin Date: Tue, 29 Oct 1996 16:48:33 -0800 (PST) From: Kristin.Hubner@INNOSOFT.COM Subject: RE: Understanding routing > At what point is the conversion mapping applied to determine if > redirection through the conversion channel is appropriate? Same > question for charset conversion. The CONVERSION mapping is checked after the envelope to address is rewritten, before the envelope from address is rewritten. Now you're probably wondering, how can this happen before the envelope from address rewrite, since the CONVERSION mapping entry has to know the source channel? Well, that's one of those details I slurred over in my previous message. Before PMDF rewrites the envelope to address, it does a minimal rewrite of the source domain (based on the connection information if possible, rather than the domain in the envelope from address) to determine what the source channel should be -- and if, for instance, the switchchannel keyword is in use, switchchannel takes effect at this time, before the envelope to address is rewritten. Thus PMDF knows the source channel at the time it does the envelope to address rewrite. (In particular, rewriting envelope to addresses with source channel specific rewrite rules is possible.) And later on, PMDF knows the source channel at the time it does the CONVERSION mapping table probe. If the CONVERSION mapping table probe fails, PMDF then probes the CHARSET-CONVERSION mapping table (again, before rewriting the envelope from address). But if the CONVERSION mapping table probe succeeds, then the message goes over to the conversion channel and PMDF doesn't do a CHARSET-CONVERSION probe on this initial source channel run -- a CHARSET-CONVERSION, if any, is supposed to then occur either as part of the actual conversion performed, or after the conversion channel does its work; i.e., it should be triggered and performed with a CHARSET-CONVERSION entry having IN-CHAN=conversion;.... Regards, Kristin