dheller@cory.Berkeley.EDU.UUCP (07/13/88)
I just heard some very disturbing news about Mail on sunos 4.0. Apparently, messages no longer have the string: From <path> <date-recieved> at the beginning of each message. Instead, the string looks like: From <your-login-name> I see some major problems with this new format. 1) It's incompatible with any other mailer to date so now all mail user agents will no longer work until they are fixed. This includes MH, gnuemacs, elm, mush, and, of course, the old version of Mail. 2) The "path" that was there, was always correct -- you could always use that to get the return path easily if it was incorrect in unavailable in other headers. 3) The date that came after the path was the date that you received the message. This is rarely the same as the date the message was sent (via the Date: header). This isn't as important as the previous two reasons, but it's a shame that such information is now lost. I, personally, consider this unforunate because in my mailer (Mush), you can sort messages by date sent or date recieved as well as doing other neat things with the date of a message. The question is obvious: why?! Well, clearly, someone at sun was thinking, "well, we have this problem which can easily be solved by making the header look like _this_!" Obviously, this person didn't really think about the impact of 1 and 2 mentioned above. I would still like to know what the motivating reason was to change this format. Of course, I don't know all the facts here -- maybe they compensated for the change by adding new headers into the list of headers which contain the real return path and the date received. More importantly, can this "feature" be _disabled_? Is it a function of sendmail? binmail, or something even newer? Can I configure out this feature using my sendmail.cf? Does anyone in the know offer more information on this? I'm happy to carry on religious arguments about Mail folder formats as well. :-) Dan Heller <island!argv@sun.com>
mlandau@bbn.com (Matt Landau) (07/13/88)
In comp.mail.misc (<4442@pasteur.Berkeley.Edu>), dheller@cory.Berkeley.EDU (Dan Heller) writes: >I just heard some very disturbing news about Mail on sunos 4.0. >Apparently, messages no longer have the string: > From <path> <date-recieved> >at the beginning of each message. Instead, the string looks like: > From <your-login-name> I don't know where you heard this, but I just tested mail between 4.0FCS on a Sun-386i and 3.4 on a Sun-3, and your news appears to be wrong. I sent all possible combinations of local and remote mail in both directions, and the Unix-style "From " lines appear to be correct everywhere. -- Matt Landau The happiest cold and lonely guy mlandau@bbn.com stuck in the Yukon without a dog.
dheller@cory.Berkeley.EDU (Dan Heller) (07/14/88)
In article <11232@jade.BBN.COM> mlandau@bbn.com (Matt Landau) writes: > I (Dan Heller) wrote: >I just heard some very disturbing news about Mail on sunos 4.0. >Apparently, messages no longer have the string: > From <path> <date-recieved> >at the beginning of each message. Instead, the string looks like: > From <your-login-name> I don't know where you heard this, but I just tested mail between 4.0FCS on a Sun-386i and 3.4 on a Sun-3, and your news appears to be wrong. It appears I was rather premature in my posting. The news I heard was just as I reported it, but it was reported incorrectly. Sorry if I alarmed anyone... Anyway, the latest info is that internet mail appears ok, and uucp mail appears ok, but sometimes a mixture will result in the From line looking like "From <your login> <date>". The "date" always appears. More data needs to be gotten before I can remove my foot from my mouth. Dan Heller <island!argv@sun.com>
simmons@applga.uucp (Steve Simmons) (07/14/88)
In article <4442@pasteur.Berkeley.Edu> dheller@cory.Berkeley.EDU (Dan Heller) writes: >I just heard some very disturbing news about Mail on sunos 4.0. >[goes on to detail the problems] >I see some major problems with this new format. > 1) It's incompatible with any other mailer to date so > now all mail user agents will no longer work until > they are fixed. This includes MH, gnuemacs, elm, mush, > and, of course, the old version of Mail. I can't speak for gnuemacs or MH, but elm and mush are working just fine under 4.0. > 2) The "path" that was there, was always correct -- you > could always use that to get the return path easily > if it was incorrect in unavailable in other headers. Disagree. The 4.0 sendmail.cf does considerable fewer stupid things about reformatting mail. It has thus far proven more reliable, not less. > 3) The date that came after the path was the date that > you received the message. This is rarely the same as > the date the message was sent (via the Date: header). > I, personally, consider this unforunate because in my > mailer (Mush), you can sort messages by date sent or > date recieved as well as doing other neat things with > the date of a message. True. I'd occasionally like this feature as well. But it's no major loss. Looking at the sendmail.cf it appears a minor hack would bring back the date as you describe it. >The question is obvious: why?! [[goes on to make a point about > backwards compatibility]] My impression of the 4.0 sendmail/sendmail.cf/local mailer is that it is improved. Some of those improvements involved changing the From field, some involved making it assume the sender knew what they wanted (how...novel), and some were irrelevant (your point 3, for example). *On the whole* it's an improvement over 3.X. But much of your arguement seems to relate to backwards compatibility for 3rd party mail interfaces. If I were Sun and had to choose between backwards compatibility for freeware vs. improving my own service, it'd be a real simple choice. Now, let's get into those religious wars over mailbox formats! -- Steve Simmons Secretary, Michigan USENIX Chapter scs@lokkur.uucp
akkana@brain.ucsd.edu (Akkana) (07/15/88)
In article <4460@pasteur.Berkeley.Edu> dheller@cory.Berkeley.EDU.UUCP (Dan Heller) writes: >In article <11232@jade.BBN.COM> mlandau@bbn.com (Matt Landau) writes: > > I (Dan Heller) wrote: > >I just heard some very disturbing news about Mail on sunos 4.0. > >Apparently, messages no longer have the string: > > From <path> <date-recieved> > >at the beginning of each message. Instead, the string looks like: > > From <your-login-name> > > I don't know where you heard this, but I just tested mail between > 4.0FCS on a Sun-386i and 3.4 on a Sun-3, and your news appears to > be wrong. > >Anyway, the latest info is that internet mail appears ok, and uucp >mail appears ok, but sometimes a mixture will result in the From line >looking like "From <your login> <date>". The "date" always appears. Well, I guess I'd better interject something here, since I was the one who sent the flame to Dan which caused him to post in the first place. The story so far: I just upgraded my Sun network to 4.0, putting /usr/spool/mail on an NFS partition (*) and installing the old sendmail.cf /* (*) This used to require root-over-the-net privs on the client, but with 4.0 it no longer does. So maybe sendmail is setuid()ing to the owner of the /usr/spool file in order to deliver the mail, and somehow the From line gets changed in the process? (Please, no flames about /usr/spool being NFS; users don't like rsh'ing all over the net just to read their mail, and I don't blame them.) */ from 3.4 (it's a .cf which is being used by many Unix machines around here with no problems I'm aware of). Under 4.0, mail sent to the server (akkana@heart.ucsd.edu) works fine, but mail sent to my client (akkana@brain.ucsd.edu) often has an incorrect From line -- a typical set of headers might look something like: From akkana Tue Jul 12 17:22:16 1988 Date: Tue, 12 Jul 88 18:20:49 MDT From: foo@bar.gov (Foo Bar) To: akkana%brain@ucsd.edu This happens on most internet mail, but usually not on mail which has been routed through UUCP (i.e. mail from paths with '!'s in them usually have the correct From line) or mail from users on the local network. The From: line (with a colon) always seems to be correct. I haven't figured out yet why this is happening. It has something to do with the .cf I'm using, because it doesn't happen with the Sun- distributed sendmail.main.cf, but it also has something to do with NFS and 4.0 sendmail, because it happens on the client but not on the server (it also doesn't happen when I put a .forward on the client forwarding to the server.) I called Sun about the problem and asked whether they knew anything, and was told "That's not a bug, it's a feature" and that it had something to do with bounced mail being returned to the right place. The Sun rep. wasn't able to tell me the exact nature of this "feature", though (i.e. what changed, what good is it and how do I disable it?). (It was after getting off the phone with Sun that I flamed to to Dan about the problem. :-) Anyway, Dan's flame was premature, since it's still not clear what's causing this, so you can all go back to your regularly scheduled smail installations, unless you know something about this 4.0 sendmail "feature", in which case I'd appreciate hearing from you ... -- ...Akkana LaboratoryForBiologicalDynamicsAndTheoreticalMedicine, UCSD akkana%brain@ucsd.edu sun!brain.ucsd.edu!akkana "What we're dealing with here is a complete lack of respect for the law." -- Smokey and the Bandit
nowicki%rose@Sun.COM (Bill Nowicki) (07/16/88)
In article <1029@ucsd.EDU>, akkana@brain.ucsd.edu (Akkana) writes: > The story so far: I just upgraded my Sun network to 4.0, putting > /usr/spool/mail on an NFS partition (*) and installing the old sendmail.cf > from 3.4 (it's a .cf which is being used by many Unix machines around > here with no problems I'm aware of). If you use NFS to mount the mailbox directory in SunOS 4.0, then you should put the line "OR" in your sendmail.cf file. This causes the server to send outgoing mail through the server, so the sender lines are correct. There is such a line in the sendmail.cf files on the 4.0 release, and this option is described on page 483, Chapter 18 - Sendmail Installation and Operation, in the System and Network Administration manual. -- Bill Nowicki Sun Microsystems