Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!mp.cs.niu.edu!rickert From: rickert@mp.cs.niu.edu (Neil Rickert) Newsgroups: mail.uk-sendmail-workers,comp.mail.sendmail Subject: Re: Full name expansion in From: header Message-ID: <1990Nov10.003601.27771@mp.cs.niu.edu> Date: 10 Nov 90 00:36:01 GMT References: <22619.9011091840@derek.cs.kl.ac.uk> Organization: Northern Illinois University Lines: 73 In article <22619.9011091840@derek.cs.kl.ac.uk> jonathan@cs.kl.ac.uk (Jonathan Knight) writes: >I have been driven nuts trying to make sendmail put my full >name on the From: header line. > >The problem I see is that any email which originates locally and is >delivered locally appears with a from line with the full email >address and full name on. Any email sent to another host is >delivered without the full name. It appears that sendmail has >declared that the 'x' macro is undefined in these circumstances. > >If you want the config file, it's below. This topic was just discussed recently. To recap, it is because your mail is configured to send mail for local users to your file server for delivery. This is the procedure that 'sendmail' uses for assigning a value to the '$x' macro. If the 'From: ' header already exists, no additional $x is added, even if the sender name is absent from the existing header. In other words, for 'sendmail' to add the sender name, there must be no 'From: ' header when the mail arrives. As stated in 'sendmail' operations guide, the value of $x is determined from the 'Full-name:' header if present, then from the 'From:' header if present. Apparently these statement apply even if the value so determined is null. Now, given that there is no 'From:' line, the next step is for 'sendmail' to determine whether the sender is local. If not, there is no attempt to assign a value to $x. The determination of whether the sender is local is handled as follows: A simulated attempt is made to send mail to the sender. That is, the sender address is parsed by rulesets 3,0. If this results in selecting the local mailer, the user is local, and the operand to $: in the mailer selection rewrite rule is the local user name. In the case of the 'sendmail.cf' enclosed by Jonathan Knight, there was no rule which selected the local mailer. Therefore no user will ever be recognized as local. I presume that Sun introduced the 'OR' definition into its 'sendmail.cf' for exactly this reason. It allowed the local mailer to be selected, but the local mail to still be forwarded by SMTP to a server. My friends who deal a lot with Sun systems tell me that 'OR' causes problems, and they would just as soon not use it. For another approach, you might want to pick up the sendmail-5.65+IDA package from uxc.cso.uiuc.edu. In the latest config package (1.4.1) I have an option for sending local mail to a server, yet still correctly evaluating $x. To achieve this, it parses a local user so that it selects the LOCAL mailer when a sender address is being parsed, but so that it selects the TCP mailer when actual mail is being processed. However this can only be done because of the code enhancements in the IDA package. The same approach would not work on an unmodified 'sendmail'. To be more specific, it requires the $&X option for runtime evaluation of $X. Another method that has been suggested is to set the mailer flags so that when local mail is sent to the local server, no 'From: ' header is generated. Then the header can be generated on the server machine. Of course this presumes the sender has an entry in the passwd file on the server machine, and will be satisfied with that information for the value of $x. Of course this means you can not set $x with the 'NAME' environment variable, or, worse still, if NAME was defined when the daemon was started on the server, that may become every user's name. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940