naftoli@aecom.yu.edu (Robert N. Berlinger) (05/23/89)
There seems to be a bug in mush regarding the From: line.
Mush is not supposed to generate a From: line if PICKY_MAILER
is defined but it does if you *don't have edit_hdrs set*.
In mail.c/add_headers() line 1697, right before:
if(!got_from)
I inserted the following:
#ifdef PICKY_MAILER
if(i > 0)
#endif /* PICKY_MAILER */
This is my unofficial fix after about 10 minutes of looking at
the code, so wait for the mush gurus to have a chance to verify
the bug and fix before applying. Nevertheless, it fixed the
problem for me :-).
In general, it seems to me like mush should not be messing around
with the From: and leave it to the MTA's who really know how
to deal with it (yeah right). And if it is going to create one
(sometimes it must, for instance the record file), it should tack
on the complete domain name (at least optionally). As it stands,
I don't think there's any way to get mush to know the local
domain name; it seems to rely on hostname only.
Also, I think smail2.5 is broken in this regard -- it seems be happy
to allow an incorrect user-specified From: to go out to the
world without as much as a warning. So it's PICKY_MAILER for smail2.5
all the way.
--
Robert N. Berlinger |Domain: naftoli@aecom.yu.edu
Supervisor of Systems Support |UUCP: {uunet}!aecom!naftoli
Scientific Computing Center |CompuServe: 73047,741 GEnie: R.Berlinger
Albert Einstein College of Medicine |Pan: berlinger AppleLink: U0995schaefer@ogccse.ogc.edu (Barton E. Schaefer) (05/23/89)
In article <2260@aecom.yu.edu> naftoli@aecom.yu.edu (Robert N. Berlinger) writes: } Mush is not supposed to generate a From: line if PICKY_MAILER } is defined but it does if you *don't have edit_hdrs set*. Hmm ... seems somebody missed something there ... I hope it wasn't me. :-) } In mail.c/add_headers() line 1697, [...] I inserted the following: } } #ifdef PICKY_MAILER } if(i > 0) } #endif /* PICKY_MAILER */ That does indeed appear to be the correct thing to do. Thank you. } In general, it seems to me like mush should not be messing around } with the From: and leave it to the MTA's who really know how } to deal with it (yeah right). And if it is going to create one } (sometimes it must, for instance the record file), it should tack } on the complete domain name (at least optionally). As it stands, } I don't think there's any way to get mush to know the local } domain name; it seems to rely on hostname only. If you know of a completely portable way (system call or whatever) to find out what the domain name *is*, please, please tell us. I can't find a single call (or even a process I could run) that will actually tell me what my system's domain name is. (There's one that is supposed to, but it requires YP which we aren't running, and it doesn't exist on non-NFS systems anyway.) Mush relies on the hostname because that's the best it can do by itself (at the moment, anyway). If you tell it your domain name (via "set hostname"), it'll use it. -- Bart Schaefer "And if you believe that, you'll believe anything." -- DangerMouse CSNET / Internet schaefer@cse.ogc.edu UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer
naftoli@aecom.yu.edu (Robert N. Berlinger) (05/24/89)
In article <2857@ogccse.ogc.edu>, schaefer@ogccse.ogc.edu (Barton E. Schaefer) writes: > If you know of a completely portable way (system call or whatever) to > find out what the domain name *is*, please, please tell us. I can't > find a single call (or even a process I could run) that will actually > tell me what my system's domain name is. (There's one that is > supposed to, but it requires YP which we aren't running, and it > doesn't exist on non-NFS systems anyway.) Well I don't know of any portable call, but I don't think a "set domain = ..." call wouldn't be too bad (with .UUCP disallowed :-)). Then hostname could be prepended (which you already have), making it less of a job for the system administrator (only different domains would have to have different setups). Just a thought. > > Mush relies on the hostname because that's the best it can do by > itself (at the moment, anyway). If you tell it your domain name (via > "set hostname"), it'll use it. I tried this and came up with some related funniness. If I set my hostname to, for example, aecom.yu.edu, and I send a message to a local user, my autosign2 won't be used even though I have @aecom.yu.edu in autosign2. I think it's because the signing code uses the external "ourname" instead of the value of the hostname variable. Maybe when hostname is set ourname should be set too? Otherwise, this does seem to do the trick. -- Robert N. Berlinger |Domain: naftoli@aecom.yu.edu Supervisor of Systems Support |UUCP: {uunet}!aecom!naftoli Scientific Computing Center |CompuServe: 73047,741 GEnie: R.Berlinger Albert Einstein College of Medicine |Pan: berlinger AppleLink: U0995
naftoli@aecom.yu.edu (Robert N. Berlinger) (05/24/89)
In article <2263@aecom.yu.edu>, naftoli@aecom.yu.edu (Robert N. Berlinger) writes: > Well I don't know of any portable call, but I don't think a "set ^^^^^ delete this word. Oops. -- Robert N. Berlinger |Domain: naftoli@aecom.yu.edu Supervisor of Systems Support |UUCP: {uunet}!aecom!naftoli Scientific Computing Center |CompuServe: 73047,741 GEnie: R.Berlinger Albert Einstein College of Medicine |Pan: berlinger AppleLink: U0995
schaefer@ogccse.ogc.edu (Barton E. Schaefer) (05/24/89)
In article <2263@aecom.yu.edu> naftoli@aecom.yu.edu (Robert N. Berlinger) writes: } In article <2857@ogccse.ogc.edu>, schaefer@ogccse.ogc.edu (Barton E. Schaefer) writes: } > If you know of a completely portable way (system call or whatever) to } > find out what the domain name *is*, please, please tell us. } } Well I don't know of any portable call, but I don't think a "set } domain = ..." call wouldn't be too bad (with .UUCP disallowed :-)). } Then hostname could be prepended (which you already have), } making it less of a job for the system administrator (only } different domains would have to have different setups). Just a } thought. Not good enough. It might be feasible to add a $domain variable, but it would have to be the ENTIRE domain, not just the .organization.type part. The official domain name of the host named "ogccse" is "cse.ogc.edu" -- it just happens that our MX record server (thank you, csnet) recognizes "ogccse.ogc.edu" as an equivalent. The upshot is that it may not be sufficient to append .something.other to the hostname. } > Mush relies on the hostname because that's the best it can do by } > itself (at the moment, anyway). If you tell it your domain name (via } > "set hostname"), it'll use it. } } I tried this and came up with some related funniness. If I set } my hostname to, for example, aecom.yu.edu, and I send a message } to a local user, my autosign2 won't be used even though I have } @aecom.yu.edu in autosign2. I think it's because the signing } code uses the external "ourname" instead of the value of the } hostname variable. Maybe when hostname is set ourname should be } set too? Otherwise, this does seem to do the trick. Try using "!aecom.yu.edu" as well. Ourname does get set when hostname changes. That's actually part of the problem you are having -- the rest of your list of local identities gets tossed out when you change $hostname. You can salvage part of it by using set hostname="aecom.yu.edu $hostname" which at the moment shifts ourname[0] to ourname[1], throws out ourname[2] through ourname[N] (whatever N is), and sets ourname[0] to "aecom.yu.edu". Perhaps a "hostname" command could be added, that works like "ignore" -- that is, it adds the new host to ourname[] without scrapping the rest. -- Bart Schaefer "And if you believe that, you'll believe anything." -- DangerMouse CSNET / Internet schaefer@cse.ogc.edu UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer
naftoli@aecom.yu.edu (Robert N. Berlinger) (05/24/89)
You're right about hostname.domain not necessarily being a host's
domain address (not enough sleep). I think your idea of a
command that allows you to add hostname aliases would be a good
compromise (one of the aliases can be given a "preferred" status,
i.e., the one that goes on the From: line). It would be ideal
for systems that are known not only by more than one hostname but
for systems that are known by more than one domain name (e.g., a
mail gateway).
Thanks.
--
Robert N. Berlinger |Domain: naftoli@aecom.yu.edu
Supervisor of Systems Support |UUCP: {uunet}!aecom!naftoli
Scientific Computing Center |CompuServe: 73047,741 GEnie: R.Berlinger
Albert Einstein College of Medicine |Pan: berlinger AppleLink: U0995