FOWBLE@OHSTPHRM.BITNET (Jack Fowble) (06/29/89)
... I am beginning to appreciate the annotations in sendmail.cf's
about xyz-madness, vomiting, etc....
Some time ago I gave up trying to get the mail functions on our
4D70GT to perform properly -- always ended up with uucp-style
destination addresses and error "can't even parse postmaster!"
Recently discovered a new master sendmail.cf for this campus
(anonymous ftp from tut.cis.ohio-state.edu as /pub/sendmail/Tut:sendmail.cf)
that gave new hope, and so launched into it once more.
I now have a sort-of working mail function, with the bad behavior noted
below.
Messages created with /bin/mail always arrive at destination hosts with
header line "Apparently-To: " u@h.d. This is also true when mail is
invoked with the -t option, and when sendmail is started with -t switch.
(Pretty impressive to see all those redundant "To: " lines!!!)
Messages created with /usr/sbin/Mail arrive with proper "To: " header.
Second, messages created on other systems and delivered via SMTP to
the IRIS are apparently negotiated correctly (sendmail confirms
delivery to the destination u@h.d, but a few seconds later the
mail is bounced back as undeliverable with error msgs
"mail: Options MUST PRECEDE persons"
"554 <"u@h.d">... unknown mailer error 5"
Looks like the sendmail and SMTP components are OK, but the local
delivery by System V mail is cracked.
I tried using the bsd Mail as the designated local mailer,
but all messages got stuffed into /usr/spool/mqueue as 'deferred',
either due to unresolved host.domain or no reason given.
When I remade sendmail.cf to use /bin/mail, then killed and restarted
sendmail, all these deferred msgs were immediately shot back to
the sender with the undeliverable conditions above.
I've checked and implemented the caveats posted in this list before.
Steve Dempsey's caution about avoiding the 'n' flag was a big help.
Others have asked for assists getting this stuff working, but not
much comment ensued on the list.
Questions!!! (sigh...)
Does anyone have this stuff really working well?
I telnet'd into sgi.com (port 25) and saw there a very recently
updated sendmail.cf version indicated in the startup message. Might
it be possible to ftp a more "robust" version of sendmail.cf from
sgi or other repository? (Actually, I think the config I'm based on
now is pretty solid -- the problem seems to be in persuading the
local mailer to behave itself.)
Where do I learn the significance of options used in the Argv of
the mailer definitions? For instance, every local definition has
something like A=mail -d $u, but -d isn't a documented option for
mail! Similarly, the SGI config has A=mail -s -d $u ; what is -s ?
Has anyone successfully used Mail (/usr/sbin that is... not /usr/bsd)
to support all the local mail functions? If so, what are the magic
thumbscrews to turn?
My sys_id is presently a simple host name, and sendmail.cf is
set to supply the domain field. Is it possible that /bin/mail
wants something different/doesn't like this?
In previous discussions here about messed-up implied host aliases
in /etc/hosts, it was suggested that an entry like
xxx.xxx.xxx.xxx host.domain host
was proper. I wouldn't like to believe it, but could an entry like
xxx.xxx.xxx.xxx host host.domain
(that is, positional reordering of names) cause a problem?
Any assistance would be most appreciated! I'd really like to get this
monkey off my back (with a happy resolution). Based on other queries
in the archives (eg. Jim Diamond's ca 8/88), I think others could
benefit as well.vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (07/01/89)
The /usr/lib/sendmail.cf in all currently shipping IRIS releases is based on a snapshot of what was running on sgi.sgi.com some time ago. At that time, we were sending more mail using UUCP over XNS than SMTP. That sendmail.cf will still work provided canonical names of hosts do not include dots (.). The trouble with dots is that sometimes you want to treat them as letters as in the hostname <foo.bar.com> and sometimes as sendmail "tokens" as in the separater between the hostname and domain name in <foo><.><bar.com>. In 3.2, we will be shipping a new but temporary sendmail.cf. It is based on a more recent snapshot of what is on sgi.sgi.com. It is temporary because our sendmail still does not handle MX records. RealSoonNow I'll merge 5.61 and other stuff. Impatent hackers who do not care about pathalias routing, YP aliases, and other minor hassles could get 5.61 from one of the public places. It ports easily, provided one remembers -I/usr/include/bsd and -lbsd. The delivery program of choice is /bin/mail. A long time ago we added a minor taste of BSD /bin/mail to SVR3 /bin/mail. The arguments for the local mailer are correct in my opinion. You are of course welcome to change them to something else. You've noticed that sgi.sgi.com answers on port 25. That is because we use sendmail internally. We currently have multiple YP domains hooked together with DNS. Mail is transported with SMTP and UUCP. The version number on sgi.sgi.com's sendmail.cf changes when I remember to change it, about once every 100 changes to the rest of sendmail.cf, or equivalently about once a week. Someday, either it will be perfect or I'll be dead and gone--bet on the latter. As a special, introductory offer to the first 17 callers, a genuine simulated gold-plated copy of the 3.2 sendmail.cf can be found in the public ftp directory on sgi.sgi.com in pub/src/sendmail.cf. The hotline may not be familiar with it yet, so be gentle with any bug reports. Unfortunately, I cannot offer any individual help. The hotline has the franchise on that part of the business. Vernon Schryver Silicon Graphics vjs@sgi.com