azar@morpho.UUCP (Jim Van Horn) (03/20/91)
I've recently noticed that my machine doesn't leave an audit-trail header on mail that passes through it. (I'm sure that's not what it's called. I'm referring to the "Received:" by/from lines at the top of all mail files.) I tried to RTFM, and found that mail(1) mentions the "UNIX PC Electronic Mail User's Guide", which I don't seem to have. Is it common to replace the mail handler on a 3b1? If so, what are the choices? The Stats: 3b1, 3.51m, HDB uucp form osu-cis STORE, mail reader is mush. KOSONOM SZEPEN (thank you) -- -=- =-= -=- =-= -=- =-= -=- -Jim Van Horn uunet!amc-gw!morpho!azar "Where it falls mandrakes grow. That's why they shriek when you pull them up"
dt@yenta.alb.nm.us (David B. Thomas) (03/24/91)
azar@morpho.UUCP (Jim Van Horn) writes: >I've recently noticed that my machine doesn't leave an audit-trail >Is it common to replace the mail handler on a 3b1? If so, what are >the choices? >The Stats: 3b1, 3.51m, HDB uucp form osu-cis STORE, mail reader is mush. I heartily recommend smail. It's small, simple, understands internet addressing well, and does add a "Received" line to the headers. It also does some nice things like forwarding and aliasing, without suffering from "feeping creaturitis" :-) smail is available from uunet and elsewhere. It was posted some time back to comp.sources.something. Anybody having a better idea where it is is encouraged to post. Actually, it's rather small, so I could easily mail it to anybody wanting it. It comes with a complete set of man pages. Smail is a "mail transfer agent", and is linked to rmail, so it is called first for incoming mail via uucp. It does not run setuid, but passes the message on to your original stock mailer (renamed to /bin/lmail), which does have the privs necessary to deliver the message locally, if it was destined for your machine. I used mush for a long time as a mail reader, but I tried elm and now I like that better, especially since I have novice users on my system. But don't get the idea from that comment that it's wimpy -- it's just intuitive, where mush is not. I'm a hacker and all that, but I don't like having to hack my way through things that ought to be intuitive like reading mail. That's why I prefer elm to mush, and nn to rn for news. Anyway, to quit rambling, I use smail, elm, Cnews and nn, and they seem like good choices for the 3b1. little david -- Bottom of stack = 0x40000 Stack pointer = 0x3fffe Don't push it!
clewis@ferret.ocunix.on.ca (Chris Lewis) (03/25/91)
In article <526@morpho.UUCP> azar@morpho.UUCP (James W. Van Horn) writes: >I've recently noticed that my machine doesn't leave an audit-trail >header on mail that passes through it. (I'm sure that's not what >it's called. I'm referring to the "Received:" by/from lines at the >top of all mail files.) Stock (aka dumb) System V mail transfer agents don't do "Received:" (In System V the User Agent (MUA) and Transport Agent (MTA) are the same thing. You've added mush as another "user agent". Good.) Bare System V mail doesn't support anything much. >I tried to RTFM, and found that mail(1) mentions the >"UNIX PC Electronic Mail User's Guide", which I don't seem to have. Won't help. >Is it common to replace the mail handler on a 3b1? If so, what are >the choices? Yes. One solution is smail 2.5 which partially replaces your "mail" and "rmail" programs. It supports "Received:", internet style addressing (eg: clewis@ferret.ocunix.on.ca), and mail routing lookup if you want to run pathalias. I'm running smail 2.5 on a 3b1, 386, and have even replaced sendmail (another MTA) on an RS/6000 with it. The biggest advantage is that smail 2.5 is small and pretty reliable. (There are fixes available for some of the problems, though, you'r not likely to ever encounter them - I've not applied the fixes, and I've never hit them myself). Other alternatives are Smail 3.1 (large, but more capable - eg: multiple gateways), sendmail (capable, but worthy of a Phd if you successfully manage to reconfigure it), and deliver (of which I've heard good things, but have no real detailed knowledge). Smail 2.5 and deliver can be found in comp.sources.unix or .misc archives. I'm not really sure where you'd find a copy of sendmail source (but I wouldn't recommend it anyhow) or smail 3.1. I do lots of mail, two mailing lists and other stuff, and smail 2.5 is perfectly adequate for me. My mail system consists of: 3b1 mail, mush 7.2.2, smail 2.5 (vanilla), Jon Zeeff's lmail (to do "mail-to-pipe" and "mail-to- file", needed extensive bug fixing), pathalias (to produce routing tables from comp.mail.maps postings), and unpackmaps (a program I wrote to unpack the comp.mail.maps postings and run pathalias). All of these (aside from 3b1 "mail") are available thru comp.sources.unix or .misc. -- Chris Lewis, clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada) **** somebody's mailer is appending .bitnet to my From: address. If you see this, please use the address in the signature, and send me a copy of the headers of the mail message with the .bitnet return address. Thanks!
bruce@balilly (Bruce Lilly) (03/27/91)
In article <1991Mar25.035039.14319@ferret.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes: > > The biggest >advantage is that smail 2.5 is small and pretty reliable. (There are >fixes available for some of the problems, though, you'r not likely >to ever encounter them - I've not applied the fixes, and I've never >hit them myself). Other alternatives are Smail 3.1 (large, but more >capable - eg: multiple gateways), sendmail (capable, but worthy of a >Phd if you successfully manage to reconfigure it), and deliver (of which >I've heard good things, but have no real detailed knowledge). Both versions of smail fail to handle the "%-hack" (See RFC1123), and smail 2.5 doesn't handle smtp at all, and is therefore useless for sending mail over an Ethernet link (since uucp over Ethernet is not supported on the 3b1). Sendmail does the job admirably, and frankly isn't as difficult to configure as some people think. >Smail 2.5 and deliver can be found in comp.sources.unix or .misc archives. >I'm not really sure where you'd find a copy of sendmail source (but I wouldn't >recommend it anyhow) or smail 3.1. Sendmail source is available on osu-cis in ~/sendmail (I recommend the version with IDA enhancements, which compiles cleanly on the 3b1). -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
john@chance.UUCP (John R. MacMillan) (03/27/91)
|I've recently noticed that my machine doesn't leave an audit-trail |header on mail that passes through it. (I'm sure that's not what |it's called. I'm referring to the "Received:" by/from lines at the |top of all mail files.) Adding Received: headers is the job of the Mail Transfer Agent (or MTA in mailspeak), and the quick answer is that what acts as an MTA on the 3B1 (mail/rmail) doesn't. If you want this functionality (and other stuff, like adding other required headers, understanding user@site.dom addresses, etc.) you'll have to put a new MTA on the machine. Other MTAs available include: smail2.5 - A very small, simple MTA, does the basic stuff and nothing fancy. Quite probably all you need if you're happy with everything except the Received: headers now. smail3.1 - Unrelated to the above except in name. This is intended to be a drop in replacement for sendmail (below) but is much easy to configure, and more flexible. It's much bigger than smail2.5. Incidentally, it's what's I run on chance. sendmail - The defacto standard in the BSD world, it's as easy to operate and as painless as using manually powered dental tools on yourself. I had to understand .cf files at one time, and I still haven't quite recovered. MMDF - Not a huge following, but expect that to change somewhat as SCO is shipping MMDF as its default MTA. It has a lot going for it, but also has some ugly bits. It's very gentle on system resources. PP - A fairly new MTA, a descendant of MMDF by some of the MMDF developers. Your only real option if you want X.400 compatibility.
john@chance.UUCP (John R. MacMillan) (03/27/91)
|... and deliver (of which |I've heard good things, but have no real detailed knowledge). Deliver is pretty neat, but it's not really an MTA. It's a local delivery agent, to be used by an MTA. If you want very powerful mail filtering capabilities, I'd recommend it. It can be made to work with smail2.5, anything that supports .forward files, and MMDF.
john@chance.UUCP (John R. MacMillan) (03/27/91)
I wrote: |MMDF - Not a huge following, but expect that to change somewhat as SCO |is shipping MMDF as its default MTA. It has a lot going for it, but |also has some ugly bits. It's very gentle on system resources. One word of warning I should have mentioned: if you get a release of MMDF up to and including release 43 that supports .forward files via the DOTFORWARD configuration DO NOT use this feature, as it opens a major security hole. This problem does not occur in SCO's current MMDF or the release 43 that they will be shipping. Hopefully, releases after 43 will fix this (the fix is non-trivial; the easiest solution is to remove the option).
john@chance.UUCP (John R. MacMillan) (03/28/91)
|Both versions of smail fail to handle the "%-hack" (See RFC1123), and I'm running smail3.1.18.1, and it most certainly does handle the percent hack. |... Sendmail does the job admirably, and frankly isn't as difficult |to configure as some people think. Is that why there's a package available (EASE) that attempts to make it easier? (1/2 :-) ) I found it not difficult to get sendmail to pass mail, I had enormous difficulty trying to keep it from molesting the headers.
rjg@sialis.mn.org (Robert J. Granvin) (03/29/91)
||... Sendmail does the job admirably, and frankly isn't as difficult ||to configure as some people think. | |Is that why there's a package available (EASE) that attempts to make |it easier? (1/2 :-) ) I found it not difficult to get sendmail to |pass mail, I had enormous difficulty trying to keep it from molesting |the headers. Sendmail is quite easy to set up when someone gives you a sendmail.cf that is already functional. :-) (I've yet to meet anyone (myself included) who didn't find sendmail to be as difficult as they believed... Maybe not as difficult as was _feared_, but I doubt it has ever actually "surprised" anyone...) -- Robert J. Granvin \\\\\\\\ rjg@sialis.com : INTERNET University of Minnesota \\\ ...uunet!rosevax!sialis!rjg : UUCP School of Statistics \\\\\\\ rjg%sialis.com@uunet.uu.net : BITNET Cleared by Network Censors
bruce@balilly (Bruce Lilly) (03/29/91)
In article <1991Mar28.150925.703@chance.UUCP> john@chance.UUCP (John R. MacMillan) writes: [ I wrote: ] >|Both versions of smail fail to handle the "%-hack" (See RFC1123), and > >I'm running smail3.1.18.1, and it most certainly does handle the >percent hack. Depending on "attributes", I've seen smail 3.1 turn a perfectly fine (envelope address) "foo%bar@fribble.com" (the names have been changed to protect the innocent) into garbage like "fribble.com!foo%bar". That's (1) not a valid RFC822 address because it does not contain an '@', and (2) if one interprets the '%' as a low-priority '@' (in accordance with RFC1123), mail gets delivered to the wrong machine. This has happened recently, and of course people started pointing fingers at sendmail, saying things like "sendmail is munging addresses". Well, the problem was clearly demonstrated to be an smail problem -- sendmail was and is working just fine. >|... Sendmail does the job admirably, and frankly isn't as difficult >|to configure as some people think. > >Is that why there's a package available (EASE) that attempts to make >it easier? (1/2 :-) ) I found it not difficult to get sendmail to >pass mail, I had enormous difficulty trying to keep it from molesting >the headers. I've never found it necessary to use "ease". And sendmail with IDA enhancements has separate rewriting rules for headers and envelope, so it's trivial to *entirely avoid* rewriting headers. There's no "trick" to configuring sendmail -- simply (1) read TFM and the applicable RFC's, then (2) figure out what it is that you're trying to do (e.g. UUCP<->Internet gateway?, mail delivery via SMTP?, UUCP?) *before* you start hacking away at sendmail.cf. And use sendmail's built-in regression testing capability to verify that it's working properly before pressing a new sendmail.cf into service. That's simply common sense. -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
john@chance.UUCP (John R. MacMillan) (04/02/91)
|Depending on "attributes", I've seen smail 3.1 turn a perfectly fine |(envelope address) "foo%bar@fribble.com" (the names have been changed |to protect the innocent) into garbage like "fribble.com!foo%bar". Any MTA that's misconfigured can munge addresses. Smail was designed specifically to be easier to configure than sendmail, and having used both, I simply think they succeeded. |This has happened recently, and of course people started pointing fingers |at sendmail, saying things like "sendmail is munging addresses". Well, the |problem was clearly demonstrated to be an smail problem -- sendmail was |and is working just fine. Don't you suppose there was a reason that everyone was quick to blame sendmail? |I've never found it necessary to use "ease". And sendmail with IDA |enhancements has separate rewriting rules for headers and envelope, so |it's trivial to *entirely avoid* rewriting headers. I'm glad you have it figured out, but obviously plenty of people don't, or there never would have been a need for ease, and sendmail would not have achieved its near-legendary notoriety (although some of the bugs in earlier versions certainly helped with that). Sounds like the IDA enhancements certainly would help. |There's no "trick" to configuring sendmail -- simply (1) read TFM and the |applicable RFC's Also sounds like TFM has improved, because what the vendor-supplied version I had to use came with was next to useless. I don't want this to degenerate into an MTA flamefest, so this is it for me on the subject. Closing arguments: I've used smail, MMDF, and sendmail, as well as looked over or worked on the code for all three, and IMHO, sendmail is the most difficult to configure.
bruce@balilly (Bruce Lilly) (04/04/91)
In article <1991Apr2.151024.19209@chance.UUCP> john@chance.UUCP (John R. MacMillan) writes: >Any MTA that's misconfigured can munge addresses. Smail was designed >specifically to be easier to configure than sendmail, and having used >both, I simply think they succeeded. 1) Being "easy to configure" is no benefit if the program doesn't do the job. 2) given an address "foo%bar@fribble.com", and *after* smail has had the "attributes" fixed, it sends to the host for fribble.com a pseudo-address which looks like "foo%bar" which is NG. Ergo, smail (3.1.18.1) still doesn't properly handle the RFC1123 "%-hack". >Don't you suppose there was a reason that everyone was quick to blame >sendmail? Ignorance and malice are responsible for many of the world's problems (N.B. no smiley). >Also sounds like TFM has improved, because what the vendor-supplied >version I had to use came with was next to useless. The same Fine Manual, written by Eric Allman, which has accompanied the sendmail source distribution for ages. If your vendor of binaries hasn't included documentation, complain about your vendor, not about sendmail. Better yet, get the source distribution and compile it yourself. >I don't want this to degenerate into an MTA flamefest, so this is it >for me on the subject. Closing arguments: I've used smail, MMDF, and >sendmail, as well as looked over or worked on the code for all three, >and IMHO, sendmail is the most difficult to configure. Flexibility (i.e. the ability to do the job right) does not come without a price. I've no experience with MMDF, but configuring smail, if your criteria for configuration includes that the result must work properly, is far more difficult with smail than with sendmail. To properly configure smail, one must rewrite much of the code, which is rather buggy (see examples above). And yes, I have worked on smail as well as sendmail. If you're happy with smail, fine -- I much prefer sendmail. I gues we can agree to disagree. -- Bruce Lilly blilly!balilly!bruce@sonyd1.Broadcast.Sony.COM
clewis@ferret.ocunix.on.ca (Chris Lewis) (04/05/91)
In article <1991Mar29.105053.20573@blilly.UUCP> bruce@balilly (Bruce Lilly) writes: >Depending on "attributes", I've seen smail 3.1 turn a perfectly fine >(envelope address) "foo%bar@fribble.com" (the names have been changed >to protect the innocent) into garbage like "fribble.com!foo%bar". >That's (1) not a valid RFC822 address because it does not contain an >'@', and (2) if one interprets the '%' as a low-priority '@' (in >accordance with RFC1123), mail gets delivered to the wrong machine. Actually, it looks right to me. Especially if it reroutes fribble.com. Ie: foo%bar@fribble.com -> fribble.com!foo%bar -reroute-> path-to-fribble.com!foo%bar. Then, at fribble.com, the % is changed to a "@", and voila - send to user "foo" on "bar". That's what was intended right? I guess it depends on what your connection to fribble.com is. -- Chris Lewis, clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada) **** somebody's mailer is appending .bitnet to my From: address. If you see this, please use the address in the signature, and send me a copy of the headers of the mail message with the .bitnet return address. Thanks!