root@mjbtn.MFEE.TN.US (Mark J. Bailey) (01/01/89)
Keepers of the long anticipated (awaited) smail 3.x.... when will it be available to the general population of Usenet site administrators????? I have heard so many great and wonderous things about it for several months now, that I am getting impatient with anticipation. Any comments??? Mark. -- Mark J. Bailey "Y'all com bak naw, ya hear!" USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 ___________________________ VOICE: +1 615 893 0098 | JobSoft UUCP: ...!{ames,mit-eddie}!killer!mjbtn!mjb | Design & Development Co. DOMAIN: mjb@mjbtn.MFEE.TN.US | Murfreesboro, TN USA
wisner@killer.DALLAS.TX.US (Bill Wisner) (01/01/89)
Smail 3.1 is still in alpha test. Before it is released for beta testing the authors want to (among other things) finish writing documentation for it. [I'm *THIS* close to having Spafford put this, and the dirt on News 3.0, in the Frequently Asked Questions..]
mem@zinn.MV.COM (Mark E. Mallett) (01/04/89)
In article <6616@killer.DALLAS.TX.US> wisner@killer.Dallas.TX.US (Bill Wisner) writes: >Smail 3.1 is still in alpha test. Before it is released for beta testing >the authors want to (among other things) finish writing documentation for >it. Would it be possible to get a synopsis of important new features, in order to entertain a suggestion-and-denial period? There's a bunch of things I've been hoping for... >[I'm *THIS* close to having Spafford put this, and the dirt on News 3.0, >in the Frequently Asked Questions..] Ah... yes... but infrequently answered! :-) -mm- -- Mark E. Mallett Zinn Computer Co/ PO Box 4188/ Manchester NH/ 03103 Bus. Phone: 603 645 5069 Home: 603 424 8129 BIX: mmallett uucp: mem@zinn.MV.COM ( ...{decvax|elrond|harvard}!zinn!mem ) Northern MA and Southern NH consultants: Ask me about MV.COM
wisner@xanth.cs.odu.edu (Bill Wisner) (01/08/89)
>Would it be possible to get a synopsis of important new features, in order >to entertain a suggestion-and-denial period? There's a bunch of things I've >been hoping for... Smail 3.1 was written from scratch. The only thing it has in common with earlier versions of Smail is the name. On machines with Berkeley networking, Smail 3.1 has an SMTP listener and handles outgoing SMTP mail. It gets along fine with BIND 4.8 and obeys MX records. For UUCP sites, it supports a variant called uusmtp. Some trivial hacks described in the documentation will implement true batched SMTP over UUCP links, with many messages being transferred in one file. It knows about all the Sendmail alias file constructs, including mail piped into a program and sent to an arbitrary file name. And no, no DEBUG command in SMTP mode. It can access a paths file stored with DBM. It includes a very fun little program called mkpath that will transmogrify UUCP maps into a paths file based on the directions given in a configuration file. There is no way I could possibly extoll all the virtues of Smail from memory, particularly at this hour. Why not post your suggestions and denials? I'm sure the Smail 3.1 authors are lurking here somewhere; you might give them some ideas. Bill, the man from Xanth
mem@zinn.MV.COM (Mark E. Mallett) (01/16/89)
In article <7095@xanth.cs.odu.edu> wisner@xanth.cs.odu.edu (Bill Wisner) writes: > In some article, mm writes: >>Would it be possible to get a synopsis of important new features, in order >>to entertain a suggestion-and-denial period? There's a bunch of things I've >>been hoping for... > >There is no way I could possibly extoll all the virtues of Smail from memory, >particularly at this hour. Why not post your suggestions and denials? I'm >sure the Smail 3.1 authors are lurking here somewhere; you might give them >some ideas. Thanks. But I have no denials; I assumed those would come after I made the suggestions :-) I suspect that you've had the same (or more) wishes that I have, otherwise you wouldn't have undertaken this venture. But OK, here's a couple of things that I can recall wishing for: - smail 2.5 provides for a global smart-host. I'd like to be able to have smart-hosts that are tied to the facility provided. For instance, for my domain (MV.COM), I want member nodes, particularly gateways, to be able to identify the host that does alias translations (fullname and otherwise), but only if the local translation fails. And I'd like to have a specification of a domain-level smart-host that knows about path resolution for the domain -- not the same as alias translation, mind you. This would be a major administrative boon. I'd like to be able to specify this by domain, or by pattern (but please don't make me look at another sendmail.cf file -- it's a black hole as well as a black art). Note that I'm talking about uucp-only sites; YP is not an option. - I'd like to be able to do aliasing based on username AND/OR sitename. This has come up a number of times, for instance when registering a new domain member who's machine isn't available but who wants to start distributing the new address; mail to user@newsite should be redirected to user@oldsite for a while. For instance (this just came up again in an e-mail discussion) if a node goes down or changes name, traffic to that node should be redirected. - tee-aliasing: Many is the time that I've wanted to make an alias for a user that splits mail off to other recipients, but still delivers it to the user named in the mail. smail 2.5, with its alias grid from which "used" translations are deleted, will not do this. Example: perhaps I want to make sure I see all mail that goes to "admin", but I hardly ever check it. At the same time, I still want it to go into the admin bucket. I would make an alias: admin mem admin and it would do the right thing. You say you support sendmail's /usr/lib/aliases; it's been a few years since I did any sendmail stuff, and I've forgotten if that's supported. Thanks for your attention. Other items on my wishlist have been ionized and disolved in the back of my brain, someday they will condense and reform. What are chances of getting a test version of this software? -mm- -- Mark E. Mallett Zinn Computer Co/ PO Box 4188/ Manchester NH/ 03103 Bus. Phone: 603 645 5069 Home: 603 424 8129 BIX: mmallett uucp: mem@zinn.MV.COM ( ...{decvax|elrond|harvard}!zinn!mem ) Northern MA and Southern NH consultants: Ask me about MV.COM
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (01/17/89)
Last time I checked, smail 3.x couldn't do the following: 1) Send copies of all mail this site bounces to a specified user. Very important for catching problems. 2) Rewrite addresses in a header very well (or very flexibly) when changing from uucp format to domain format. xxx!foo.com!user was rewritten to xxx!foo.com!user@thissite.domain instead of user@foo.com. 3) Support rerouting if the specified route failed. If you mail to xxx!yyy!zzz and xxx is unavailable (or misspelled), the mail is bounced. It's my experience that it creates fewer problems to reroute it to yyy!zzz (yes, I know the arguments here). 4) Convert outgoing addresses to pure uucp form for dumb uucp only sites. (some of my neighbors don't understand user@domain). In general, I felt that smail 3.x had a bit of an attitude about how things should be done and wasn't going to give you the flexibility to do it differently. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI umix!b-tech!zeeff
wisner@killer.DALLAS.TX.US (Bill Wisner) (01/19/89)
Smail 3 currently supports a "smart-user" machine; this is a smart host used for mail with an unknown recipient (instead of an unknown machine). This can include aliasing. >- tee-aliasing: Many is the time that I've wanted to make an alias for > a user that splits mail off to other recipients, but still delivers > it to the user named in the mail. smail 2.5, with its alias grid > from which "used" translations are deleted, will not do this. > Example: perhaps I want to make sure I see all mail that goes to > "admin", but I hardly ever check it. At the same time, I still want > it to go into the admin bucket. I would make an alias: > admin mem admin > and it would do the right thing. You say you support sendmail's > /usr/lib/aliases; it's been a few years since I did any sendmail > stuff, and I've forgotten if that's supported. The proper way to do this with Smail 2.5 is: admin mem \admin The proper way to do this with Smail 3.1 is: admin: mem, real-admin Clarification: I am not one of the Smail 3.1 authors, although I believe they lurk here. I'm just alpha testing it.
henry@garp.mit.edu (Henry Mensch) (01/20/89)
wisner@killer.Dallas.TX.US (Bill Wisner) wrote: ->Smail 3 currently supports a "smart-user" machine; this is a smart host ->used for mail with an unknown recipient (instead of an unknown machine). ->This can include aliasing. -> -> . . . -> ->Clarification: I am not one of the Smail 3.1 authors, although I believe ->they lurk here. I'm just alpha testing it. well, maybe if they do lurk here they will get around to answering my response to their e-mail .... it's been more than a week, and (for folks who want alpha testers for their s/w) they don't seem very enthusiastic. # Henry Mensch / <henry@garp.mit.edu> / E40-379 MIT, Cambridge, MA # {decvax,harvard,mit-eddie}!garp!henry / <henry@uk.ac.sussex.cvaxa>
wisner@cheops.cis.ohio-state.edu (Bill Wisner) (01/21/89)
Henry Mensch: >well, maybe if they do lurk here they will get around to answering my >response to their e-mail .... it's been more than a week, and (for >folks who want alpha testers for their s/w) they don't seem very >enthusiastic. They've been busy recently. Reponses to my own mail have been sluggish. But I'm sure you know something about "Real Work".
chip@ateng.ateng.com (Chip Salzenberg) (01/21/89)
Being an Smail 3 alpha tester, I feel obligated to comment on Jon Zeeff's criticism of Smail 3's feature set. According to zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff), Smail 3 can't: >1) Send copies of all mail this site bounces to a specified user. Very >important for catching problems. No doubt a very simple patch: simply invoke the child bounce-delivery instance of Smail with "postmaster" as an additional argument. >2) Rewrite addresses in a header very well (or very flexibly) when changing >from uucp format to domain format. xxx!foo.com!user was rewritten to >xxx!foo.com!user@thissite.domain instead of user@foo.com. Smail's behavior in this respect is RFC987-conformant. It's a conservative choice, one that will seldom break things. Again, there's nothing to stop you from changing it in your copy. >3) Support rerouting if the specified route failed. This is a philosophical choice. (I happen to agree with Smail here.) >4) Convert outgoing addresses to pure uucp form for dumb uucp only sites. >(some of my neighbors don't understand user@domain). This "feature" would really be a misfeature of the worst kind. If I am mailing from a smart site, to a smart site, via a dumb site, I do NOT want to rewrite all addresses into UUCP form! The character of the next site in the bang path should *NOT* affect the message header. > In general, I felt that smail 3.x had a bit of an attitude about how >things should be done and wasn't going to give you the flexibility to >do it differently. Want something? Modify the source yourself! It's not encrypted, you know. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (01/22/89)
>>4) Convert outgoing addresses to pure uucp form for dumb uucp only sites. >>(some of my neighbors don't understand user@domain). > >This "feature" would really be a misfeature of the worst kind. If I am >mailing from a smart site, to a smart site, via a dumb site, I do NOT want >to rewrite all addresses into UUCP form! The character of the next site in >the bang path should *NOT* affect the message header. Agreed, although that's not what I said. The rmail command line addresses DO need to be rewritten or the dumb site is going to bounce it. I should say that I like 95% of smail 3.0. The authors have obviously put alot of time and thought into it. I could (and probably would) use it if it was just a little more flexible. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI mailrus!b-tech!zeeff
chip@ateng.ateng.com (Chip Salzenberg) (01/24/89)
According to zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff): >According to chip@ateng.ateng.com (Chip Salzenberg): >>This "feature" would really be a misfeature of the worst kind. If I am >>mailing from a smart site, to a smart site, via a dumb site, I do NOT want >>to rewrite all addresses into UUCP form! The character of the next site in >>the bang path should *NOT* affect the message header. > >Agreed, although that's not what I said. The rmail command line >addresses DO need to be rewritten or the dumb site is going to bounce >it. Sorry for the misunderstanding. Smail 3's behavior in this case is the more conservative one: if the originator of the message specifies a bang path, it is used without modification. This behavior never breaks correct paths. (If the maps are causing pathalias to generate incorrect paths, then fix the map entries for the dumb sites.) >I could (and probably would) use it if it was just a little more flexible. Smail 3 isn't "flexible" enough? What do you want, Pla-Do? If I had a problem, and I had a program in source form that provides 95% of a solution to that problem, I would use the program after modifying it to taste. That's what source code is for, after all. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."