home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!apple!veritas!tron
- From: tron@Veritas.COM (Ronald S. Karr)
- Newsgroups: comp.mail.misc
- Subject: Re: One question about smail
- Message-ID: <1993Jan25.090201.19425@Veritas.COM>
- Date: 25 Jan 93 09:02:01 GMT
- References: <1287@kommu.UUCP>
- Organization: VERITAS Software Corp.
- Lines: 36
-
- In article <1287@kommu.UUCP> wp@orion.erls01.siemens.de writes:
- >I have one question about smail's variables
- >'version', 'compile_num' and the 'bat'.
- >
- >When I enter smail -V, I get
- >
- >/\==/\ Smail3.1.28.1 #28.1
- >
- >But looking at the mail headers created by smail, inbound and outbound ones,
- >they always looks like
- >
- >Received: from erls01.siemens.de by orion.erls01.siemens.de with smtp
- > (Smail3.1.28.1 #1) id m0nEc3o-0004oiC; Wed, 20 Jan 93 10:49 MET
- >
- >for received mail and
- >
- >Received: by orion.erls01.siemens.de (Smail3.1.28.1 #1)
- > id m0nEg6b-0004ohC; Wed, 20 Jan 93 15:08 MET
- >Message-Id: <m0nEg6b-0004ohC@orion.erls01.siemens.de>
-
- When I introduced from ... by ... with ... into the Received header,
- it became more difficult to keep the longer Smail version string in
- the Received line without going to 3 lines or stretching past 80 columns
- on a regular bassis. So, I dropped the bat and the patch number. I
- figured that the patch number was part of the version number, anyway,
- so it was redundant. The remaining #1 is the compile number in your
- compilation directory. A future version will likely restore the bat,
- since I will probably get forced into a three-line Received line,
- anyway.
-
- It is possible to get the bat and the patch number back, by setting
- your own definition for the Received field. You can set the variable
- received_field to change this.
- --
- tron |-<=>-| ARPAnet: veritas!tron@apple.com
- tron@veritas.com UUCPnet: {apple,pyramid}!veritas!tron
-