Subject: Re: updating sendmail
To: admin@datazap.net <admin@datazap.net>
From: John Klos <john@sixgirls.org>
List: port-amiga
Date: 08/28/2003 02:59:49
Hello,

> I know this is going to sound like a crazy question, but here it goes
> anyway.
>
> I am trying to update to lastest version of sendmail. I am able to compile
> it ok, and it installs. But where I have a problem is that it does not
> like the older version of sendmail.cf that I have on my server. So, I took
> a look at the sendmail.cf and it says not to edit the file. OK? Then what
> do I need to do to get the correct sendmail.cf.

Just for clarification for others, I'd like to point out that updating to
the latest Sendmail might have been more easily done had you updated to
the latest version which is in the NetBSD-release source tree - which is
8.11.whatever still, but with all of the security problems patched. No
changes would have been necessary to the sendmail.cf file.

> I googled a bit to try to find the answer, but I came up with nothing. I
> also try to look for the answer on sendmail.org. I could not find one, but
> I did find an example file. Is this something that I could use?

This is definitely one of those things where the answer could fill a book.
So let me give you one answer below.

> Maybe, I should have asked this question first, but would I be better off
> going to postfix or another mail server?

No mail system is perfect, nor is any particularly easy out-of-the-box.
Sendmail is known for being more complicated than many others, but there's
no reason why a good, decent, functional setup should be replaced merely
because of a version upgrade. If there were things Sendmail couldn't do,
or if you chose to spend some energy becoming fluent with another mail
program, then sure, but replacing it because you don't yet know how to
create a .cf file is a little extreme - moving to another system will be
much harder in the long run.

That said, if you're lucky enough to have someone else's Sendmail setup to
borrow (and you are that lucky!), then it's just a few steps, which I can
outline here:

Find your .mc file (or borrow someone's). Since Sendmail was already set
up on your system, it should be on there somewhere; if not, get a copy of
reva.mc off of my server, since it is set up almost identically to yours
(remember we set up sendmail together way back when?) A good place to put
it is in /etc/mail/ for safekeeping, and generally good to name it after
your server.

If you only had an older .mc file, moving from 8.11.x to 8.12.x generally
involves, amonst other things depending on the local setup, removing the
confAUTO_REBUILD option (possible DOS), changing:
FEATURE(`access_db', `hash -o /etc/mail/access')dnl
to
FEATURE(`access_db', `hash -T<TMPF> /etc/mail/access')dnl
and making sure that the MAILER options come AFTER the FEATUREs. At least
this is what you'd have needed to do if you still had your old .mc file.

Next, you need to use m4 to take that .mc file and make the sendmail.cf
file. This is done from a specific place so that references to other files
work. This is it, basically:

cd /usr/local/share/sendmail/cf
ln -s /etc/mail/agnus.mc agnus.mc
mv /etc/mail/sendmail.cf /etc/mail/sendmail.cf.old
m4 agnus.mc > /etc/mail/sendmail.cf
/etc/rc.d/sendmail restart
tail /var/log/maillog (and see what it says)

This assumes that your packages are installed in /usr/local and that you
have already put an .mc file into /etc/mail/ and named it agnus. It also
assumes that you have a good .mc file, and for that, be thankful you don't
have to make one on your own! It's a bit of work.

(Just a note - if you choose to use reva.mc, you'll either need to take
out the line which says FEATURE(`require_dns')dnl, or you'll need to copy
/usr/local/share/sendmail/feature/require_dns.m4 to the corresponding
place on your system. It basically requires that when a connecting machine
uses an IP literal, it matches the RFC described syntax (requires it be in
square brackets), and that the IP given actually match the IP of the
connecting machine. It also requires that the HELO name be resolvable (but
doesn't check that it resolves to the connecting address - that's another
set of rules). This is to minimise SPAM, even though blocking email based
on the HELO is forbidden by the RFCs except where the HELO is
syntactically incorrect. Although, technically, I could just say this is
my (lazy) way of checking the syntax of the HELO string...)

John Klos
Sixgirls Computing Labs