Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!uwm.edu!linac!mp.cs.niu.edu!rickert From: rickert@mp.cs.niu.edu (Neil Rickert) Newsgroups: comp.mail.sendmail Subject: Re: SunOS4.1.1 sendmail.mx's actual ruleset sequence Message-ID: <1991May12.025950.28737@mp.cs.niu.edu> Date: 12 May 91 02:59:50 GMT References: <1991May8.231130.25587@csl.dl.nec.com> <1991May9.005329.17471@mp.cs.niu.edu> <1991May9.221508.13637@csl.dl.nec.com> Organization: Northern Illinois University Lines: 89 In article <1991May9.221508.13637@csl.dl.nec.com> ylee@csl.dl.nec.com (Ying-Da Lee) writes: >In article <1991May9.005329.17471@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >> I posted a fairly complete rundown on the sequence of rules used approx. > >That was a fine article, Neil, but I am afraid the part discussing >address reprocessing must have skated right by me. Would you mind >writing another article concentrating on that issue? That was also a long article. I don't intend rewriting it all. I believe a number of ftp sites may have made a copy available. There is a file called something like 'sendmail.rules' with the appropriate date at uxc.cso.uiuc.edu >> Now why don't you create an alias for that final recipient address so it >>won't bounce, and run your test again to see if you can confirm my >>description of the header rewriting sequence (the 'To:' and 'From:' headers). > >Well, I created an account for the peculiar address (I had to, > > From 4.12.1.3.4.1.3.ylee Thu May 9 15:50:42 1991 >... > From: 4.12.1.3.4.12.1.3.4.1.3.ylee > To: 4.22.2.3.ylee@csl.dl.nec.com > >The corresponding log entries are: > >May 9 15:50:42 texas sendmail[12687]: AA12684: to=<4.22.2.3.4.22.2.0.3.ylee@csl.dl.nec.com>, delay=00:00:01, stat=Sent A few more comments. Firstly, this corresponds exactly with my lengthy article on the subject. The envelope sender (on 'From '): There is an initial processing of the incoming sender by rules 3,1,4. The result is saved as $f. This is done in setsender() in envelope.c . The comments there do not fully explain the purpose, but on use seems to be to convert local names of the form 'user@your.domain' to just a canonical 'user' to store in $f. When a mailer is selected, the address in $f is processed to put it in the form for the outgoing mailer. This is done with a call to remotename(), and involves using rulesets 3,1,mailer-specific,4. The result is assigned to $g. The 'From:' header is usually built from the value of $g. A typical 'sendmail.cf' may define $q with something like: Dq$x <$g> (Note the above is deliberately simplified from what you perhaps have). Then the 'From:' header is defined in terms of $q H?F?From: $q All of this means that the sender address, which has already been processed twice, is taken from $g to store in the 'From:' header, and then header processing will reprocess it once more. On mail with an incoming 'From:' header this will not happen unless the contents of the incoming 'From:' header is completely identical (except for white space) to the incoming envelope sender. Otherwise only a single processing of the existing header is performed. In the current IDA rulesets, we are defining $q in terms of $f (rather than $g) to eliminate one of these steps. Note that this is not for efficiency, but because the IDA versions are capable of processing header addresses differently from envelope addresses. This capability is used in the IDA rulesets. The reprocessing of the recipient envelope address only happens for SMTP mailers. The IDA versions do not do this. The Berkeley versions do, as pointed out a few weeks ago by kyle@uunet.uu.net. It is done in usersmtp.c with a call to remotename() just before sending the RCPT-To: command. In my opinion that additional processing is wrong, and some of the potential problems were mentioned by kyle. What your tests did not show is the additional step that occurs for some messages when the value of $f contains an '@' but the header address does not. In that case, if there is no '@' by the end of ruleset 3, and if the 'C' flag is set in the 'receiving mailer' the '@domain' from $f is appended to the address and it is processed once more by ruleset 3. (See my earlier article for more details). -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940