jbayer@ispi.UUCP (Jonathan Bayer) (12/29/88)
Hello there. I have just finished installing smail on this system. Now that I am done I have a question. Since it is apparent that smail is able to do smart routing, what else does sendmail do that smail does not? Thank you Jonathan Bayer ------------------------------------ Intelligent Software Products, Inc. "The time has come," the Walrus said... 19 Virginia Ave. ------------------------------------ Rockville Centre, NY 11570 (516) 766-2867
akay@cadsqa.intel.com (Allen Kay) (12/31/88)
In article <378@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: >Hello there. > > I have just finished installing smail on this system. Now that >I am done I have a question. Since it is apparent that smail is able to >do smart routing, what else does sendmail do that smail does not? > From what I have heard, smail doesn't work well with DECnet mail. -------- Internet: akay@cadev4.intel.com
wisner@killer.DALLAS.TX.US (Bill Wisner) (01/01/89)
Smail (or, at least, pre-3.0 versions thereof) is a UUCP router that makes a UUCP site RFC822 conformant. It also makes them look like Sendmail sites (they even ripped off the Sendmail format for Message-Ids). It is usually quite sufficient for a UUCP machine. Sendmail is an inter-network mail handler. It is particularly handy on the Internet since it has built-in the SMTP routines used on the Internet to move mail around. (Silence, please, from the MMDF disciples in the back row.) On a more pragmatic level it has some very nifty aliasing features (like piping mail to a program or saving it in an arbitrarily named file) that are glaringly absent from Smail. Many sites will never need those features, but then, some will. [In this article "Smail" refers to any version that predates 3.0. Version 3.0, which was written from scratch by a couple of masochists at Amdahl, resembles Sendmail more than it does earlier Smail. It's also not yet publically available.]
skl@van-bc.UUCP (Samuel Lam) (01/01/89)
In article <3401@mipos3.intel.com>, akay@cadsqa.UUCP (Allen Kay) wrote: >In article <378@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: >>I have just finished installing smail on this system. Now that >>I am done I have a question. Since it is apparent that smail is able to >>do smart routing, what else does sendmail do that smail does not? > >From what I have heard, smail doesn't work well with DECnet mail. smail (at least up to 2.5) also doesn't exchange mail using SMTP (RFC821). That at least means you can't use it (alone) to accept mail on TCP port 25 or send mail over TCP/IP. -- Samuel Lam {alberta,watmath,uw-beaver,cs.ubc.ca}!ubc-cs!van-bc!skl
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (01/02/89)
In article <6618@killer.DALLAS.TX.US> wisner@killer.Dallas.TX.US (Bill Wisner) writes about sendmail: >back row.) On a more pragmatic level it has some very nifty aliasing >features (like piping mail to a program or saving it in an arbitrarily >named file) that are glaringly absent from Smail. Many sites will never If anyone wants piping to files/programs, I have a local mail delivery program "lmail" that allows smail sites to do this. It is available from comp.sources.misc or directly from me. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Support ISO 8859/1 zeeff%b-tech.uucp@umix.cc.umich.edu Ann Arbor, MI umix!b-tech!zeeff
friedl@vsi.COM (Stephen J. Friedl) (01/02/89)
In article <5029@b-tech.ann-arbor.mi.us>, zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > If anyone wants piping to files/programs, I have a local mail delivery > program "lmail" that allows smail sites to do this. It is available > from comp.sources.misc or directly from me. Great, but does it has a DEBUG mode :-) ? Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. I speak for me only attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl -------Nancy Reagan on Usenix in San Diego: "Just say *go*"-------
mhw@wittsend.LBP.HARRIS.COM (Michael H. Warfield (Mike)) (01/03/89)
In article <378@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes: > I have just finished installing smail on this system. Now that >I am done I have a question. Since it is apparent that smail is able to >do smart routing, what else does sendmail do that smail does not? Well that diepends on the version of smart mail involved. The level 3.x smart mail (currently 3.1 I believe) is intended as a complete replacement for sendmail. Only thing that smail 3.1 should be missing is some of the sendmail bugs and some of the sendmail confusion (ala sendmail.cf). If you are running smail 2.3 or smail 2.5 then you are missing a great deal. You cannot mail into files or into programs and you have no support for smtp. These can all be worked arround. I have adapted an "smtp" package and an "lmail" package from comp.sources.unix to give me these facilities with smail 2.5. If you're running 2.3, my sympathy and my hearty recommendation that you upgrade. --- Michael H. Warfield (The Mad Wizard) | gatech.edu!galbp!wittsend!mhw (404) 270-2123 / 270-2098 | mhw@wittsend.LBP.HARRIS.COM An optimist believes we live in the best of all possible worlds. A pessimist is sure of it!
wisner@killer.DALLAS.TX.US (Bill Wisner) (01/03/89)
Smail3.1 does speak SMTP. It also includes support for SMTP over UUCP. The smail binary gets linked to several different filenames, one of which is rsmtp. rsmtp, like rmail, is intended as the receiving end of UUCP mail, but rsmtp expects to find things in SMTP format. It is also fairly simple to kludge up Smail3.1 to do batched SMTP, if you really care to bother.
gertjan@atcmpe.UUCP (Gertjan Vinkesteyn) (01/06/89)
I am trying since a couple of days now to bring up smail (2.5/1.14) on a level that it will be accepted by our backbone hp4nl (previously mcvax). In this version I am missing support for Cc: fields and Reply-To: and In-Reply-To: fields. Especially the absence of a Cc: field scanner can cause mail to bounce between major backbones like in the following example: Subject: acceptance test From: gertjan@atcmpe Cc: gertjan To: user@hp4nl results in Subject: acceptance test From: gertjan@atcmpe Cc: gertjan@hp4nl.nluug.nl To: user@hp4nl at the target site. The empty domain address in the Cc: field will be filled in by hp4nl to their domain address. That causes it to bounce between their two computers hp4nl.nluug.nl and mcvax.cwi.nl something what they don't like. So if smail3.x should be accepted in netland, let it be a good MTA mailer, comparable to sendmail and mmdf. Proper handling of RFC822 is first demand. Smail2.5 is considered to be a good LAN mailer but to send mail out of the door is done by sendmail still. My conclusion is that smail is very good in what it does, it is difficult to bring it up as an acceptable MTA mailer without using sendmail (or mmdf). -- UUCP and other network )\/( ..!hp4nl!kunivv1!atcmpe!gertjan connections via mcvax )/\( gertjan@atcmp.nl (at due time) This note does not necessarily represent the position of AT Computing BV
jv@mhres.mh.nl (Johan Vromans) (01/06/89)
From article <398@atcmpe.UUCP>, by gertjan@atcmpe.UUCP (Gertjan Vinkesteyn): > In this version I am missing support for Cc: fields and Reply-To: and > In-Reply-To: fields. Especially the absence of a Cc: field scanner can cause > mail to bounce between major backbones like in the following example: > > From: gertjan@atcmpe > Cc: gertjan > To: user@hp4nl > results in > From: gertjan@atcmpe > Cc: gertjan@hp4nl.nluug.nl > To: user@hp4nl > at the target site. This is not caused by smail2.5, but by the backbone which doesn't handle cc's properly. Unfortunately, RFC822 does not define what to do in the above case. The backbone treats an address without domain as "local" (as all sendmail based MTAs do). Another opinion - and more logical - is to interpret CC-addresses relative to the sender of the message. So the mailers can leave this field alone, and the user agent can handle replys accordingly. > So if smail3.x should be accepted in netland, let it be a good MTA mailer, > comparable to sendmail and mmdf. Proper handling of RFC822 is first demand. ^^^^^^^^^^^^^^^^^^^^^^ But not including sendmail bugs and cryptic configuration files. Smail3.x is plug-compatible with sendmail. And it's worth waiting for. -- Johan Vromans jv@mh.nl via european backbone (mcvax) Multihouse [A-Za-z ]* [NB]V uucp: ..!mcvax!mh.nl!jv Gouda - The Netherlands phone: +31 1820 62944
wisner@killer.DALLAS.TX.US (Bill Wisner) (01/07/89)
Two points: Reply-To: and In-Reply-To: lines are a function of the user agent, not the delivery agent. Specifically, it is the user agent that must insert an In-Reply-To: header when a message is replied to, and it is the user agent that must notice a Reply-To: line and use it to construct an address to reply to. Smail3 is RFC822 conformant and munges Cc: lines on outbound mail correctly. A major goal of the authors is to make it into a complete plug-in replacement for sendmail, so when it is released you should have little trouble.
david@ms.uky.edu (David Herron -- One of the vertebrae) (01/07/89)
The addresses in the header should not be in "local form" when leaving
the site. That is ..
Cc: user
should be
Cc: user@domain
--
<-- David Herron; an MMDF guy <david@ms.uky.edu>
<-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-- Now I know how Zonker felt when he graduated ...
<-- Stop! Wait! I didn't mean to!news@petro.UUCP (Usenet Administrator) (01/08/89)
In article <6618@killer.DALLAS.TX.US> wisner@killer.Dallas.TX.US (Bill Wisner) writes: >On a more pragmatic level it [sendmail] has some very nifty aliasing >features (like piping mail to a program or saving it in an arbitrarily >named file) that are glaringly absent from Smail. Many sites will never >need those features, but then, some will. I've found that creating a paths entry like: site.domain | /usr/lib/mail/gateway %s Works just fine for piping mail destined for a particular system through a program on my machine. Stuff going to a particular user (or daemon) I still use the aliases file (this is under SCO XENIX) which supports the things you mention. Jon -- jon@bodedo.ucm.org "Anywhere is within walking distance... if you have the time."
rick@seismo.CSS.GOV (Rick Adams) (01/11/89)
In article <2754@mhres.mh.nl>, jv@mhres.mh.nl (Johan Vromans) writes: > This is not caused by smail2.5, but by the backbone which doesn't > handle cc's properly. Unfortunately, RFC822 does not define what > to do in the above case. The backbone treats an address without > domain as "local" (as all sendmail based MTAs do). Another > opinion - and more logical - is to interpret CC-addresses relative > to the sender of the message. So the mailers can leave this field > alone, and the user agent can handle replys accordingly. RFC822 is unambiguous about this. Section 6.2.2 EXPLICITLY states When a message crosses a domain boundary, all addresses must be specified in the full format, ending with the top-level name-domain in the rightmost field. You crossed a domain boundary when you forwarded the mail to your backbone site. It was YOUR responsibility to fully qualify those addresses, not someone elses. The backbone is attempting to qualify a garbage address. You can't blame it for making garbage out of garbage. Why is it more logical to expect EVERYONE to know your local mail forwarding rules so that they can reply to your mail and correctly send mail to the CC lines? It seems that fully qualified addresses are easiest for everyone. ---rick
henk@ace.nl (Henk Hesselink) (01/18/89)
In article <2754@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes: >From article <398@atcmpe.UUCP>, by gertjan@atcmpe.UUCP (Gertjan Vinkesteyn): >> In this version I am missing support for Cc: fields and Reply-To: and >> In-Reply-To: fields. Especially the absence of a Cc: field scanner can cause >> mail to bounce between major backbones like in the following example: >> >> From: gertjan@atcmpe >> Cc: gertjan >> To: user@hp4nl >> results in >> From: gertjan@atcmpe >> Cc: gertjan@hp4nl.nluug.nl >> To: user@hp4nl >> at the target site. > >This is not caused by smail2.5, but by the backbone which doesn't >handle cc's properly. This is not caused by improper handling of Cc's by the backbone, but by improper handling of same by the MTA at "atcmpe". Your answer indicates a misunderstanding of the function of an MTA: an MTA is *required* to fully qualify an address when crossing a domain boundary, and in the light of the brain-damage present in some UA's it is not a bad idea to do this for *all* simple local-parts (those with no hostname). The problem stems from misunderstanding the way sender and recipient addresses are processed by sendmail. With respect to From: lines: to help dumb UA's (such as AT&T's stone-age mail) along, sendmail will add a From: line to the message header if such a line is not already present (the format of this line is defined by the `q' macro). Many configuration files simply generate a correct address in $q, and leave it at that. At the same time, the To: line is qualified or not, presumably as the sender specified to the UA. Therefore, presto, mail works. This is, however, only by virtue of the special (or lack of) processing for these specific headers: *all* sender and recipient addresses are processed by the mailer specific rewriting rulesets, and therefore it is there that all simple local-parts, or at least those which will cross a domain boundary, should be qualified. As a result, Cc:/Reply-To:/etc. headers will all magically be correctly qualified. An aside: gertjan@atcmpe.UUCP (Gertjan Vinkesteyn)'s remark that the addition of "hp4nl.nluug.nl" to the Cc local address causes bouncing is incorrect: there is no gertjan on that machine, and hence *one* mail will be returned to "gertjan@atcmpe" stating this. > Unfortunately, RFC822 does not define what >to do in the above case. RFC822 is crystal clear on this point (6.6.2 Abbreviated Domain Specification): When a message crosses a domain boundary, all addresses must be specified in the full format, ending with the top-level name-domain in the right-most field. It is the responsibility of mail forwarding services to ensure that addresses conform with this requirement. > The backbone treats an address without >domain as "local" (as all sendmail based MTAs do). Another >opinion - and more logical - is to interpret CC-addresses relative >to the sender of the message. So the mailers can leave this field >alone, and the user agent can handle replys accordingly. The backbone treats an address without a domain as local, as all MTA's *should* do. Interpreting *any* simple local-part relative to the sender is a gross hack, and one which won't even always work: one problem is that the munging that sender addresses are subjected to may cause ambiguity (what do you do when the From: line contains a!user@b?); another problem is determing the sending host when there are multiple originators (a message may quite legally contain multiple From: mailboxes, a Sender mailbox:, and multiple Reply-To: mailboxes). By the way, note that "mailer" != MTA. > >> So if smail3.x should be accepted in netland, let it be a good MTA mailer, >> comparable to sendmail and mmdf. Proper handling of RFC822 is first demand. > ^^^^^^^^^^^^^^^^^^^^^^ >But not including sendmail bugs and cryptic configuration files. >Smail3.x is plug-compatible with sendmail. And it's worth waiting >for. Cryptic, yes: e-mail is a complex business, TANSTAAFL. Full of bugs, don't be silly: sendmail is a remarkably solid piece of software which unfortunately is delivered by many manufacturers with the most unbelievably cruddy configuration files. Certainly sendmail could be improved. For instance it should be split up into separate functional units (but watch security!); it should differentiate between header and envelope addresses; it should be easier to integrate with e.g. pathalias. I believe Keith Bostic is working on the first point, Lennart Lovstrand's IDA kit (the source modifications) solves the other problems. Smail 3.X may be a fine thing to wait for, but that's precisely the point: my mail has to go out the door *now*. Besides, e-mail being what it is, smail 3.X will have to be a fairly complex piece of software (if it's not, it will probably not be able to do what I want), so how long before it is stable enough that I can really trust it ? >-- >Johan Vromans jv@mh.nl via european backbone (mcvax) >Multihouse [A-Za-z ]* [NB]V uucp: ..!mcvax!mh.nl!jv >Gouda - The Netherlands phone: +31 1820 62944 > > -- Henk Hesselink ACE Associated Computer Experts bv. Amsterdam, The Netherlands e-mail: henk@ace.nl phone: +31 20 6646416