> I'm still not clear on just how one should write a proper mc for the
> submit.cf
> but I'll look into that later..
>

The default submit.mc is supposed to work for almost everyone. My system has two ports, and has a different name for each port.

One is on the Internet and has one IP address. The other is on my LAN and has, of course, another IP address. By default, sendmail picks the wrong one, so I made my submit.mc look like this:

divert(-1)
#
# Copyright (c) 2001, 2002 Sendmail, Inc. and its suppliers.
#       All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
#

#
#  This is the prototype file for a set-group-ID sm-msp sendmail that
#  acts as a initial mail submission program.
#

divert(0)dnl
VERSIONID(`$Id: submit.mc,v 8.6.2.4 2002/12/29 03:54:34 ca Exp $')
define(`confCF_VERSION', `Submit')dnl
define(`__OSTYPE__',`')dnl dirty hack to keep proto.m4 from complaining
define(`_USE_DECNET_SYNTAX_', `1')dnl support DECnet
define(`confTIME_ZONE', `USE_TZ')dnl
define(`confDONT_INIT_GROUPS', `True')dnl
dnl
dnl ADDED BY JDBEYER (31.8), (31.10.20)          <---<<<
define(`confDOMAIN_NAME', `my.internet.domain')  <---<<<
dnl
dnl If you use IPv6 only, change [127.0.0.1] to [IPv6:::1]
FEATURE(`msp', `[127.0.0.1]')dnl

As you can see, it does not take much. The file is quite simple.

Jean-David Beyer

: As you can see, it does not take much. The file is quite simple.

Yes, it is: but if you are used to sendmail running with one cf file, and haven't yet read about this new submit.cf, sendmail suddenly breaking is unexpected.

I haven't yet had the time to go back and see why this broke (it's an internal machine so I'm not particularly antsy about it), but it was quite a surprise to me :-)

I don't use sendmail a lot - most of my people run qmail (and actually so does this guy except for some internal machines) so I'm a bit behind on it. Not that I'm any great qmail guru either!

I don't like sendmail very much - not because of technical reasons; just that .mc/.cf stuff. More often than not, when I run into a sendmail issue, I find that somebody has added stuff to .cf manually, which means I can't use the .mc to add things without breaking things. And of course .mc files are only a little bit more comprehensible than raw .cf files to start with. Actually, in some ways they are LESS comprehensible: when someone has manually modified .cf, getting .mc to produce the desired output by reverse engineering is at least annoying.

That's the typical headache: I have something where I'd like to just add something to .mc and generate a new .cf. So I do so, but now a bunch of stuff doesn't work (because someone did the .cf manually or edited it) so it's line by line examination to see what they were trying to get done. It's not hard to lookup .mc stuff in the bat book, but the other way around is not so easy. I've got one of those going on now: we just wanted to add the genericstable feature, but it ended up with upgrades and confusion and I'm not sure we're all there even yet.

Oh well. Lesson learned: sendmail now uses two .cf files. Goody - two places to reverse engineer when somebody mucks with them :-)

tony

> I don't like sendmail very much - not because of technical reasons;
> just that .mc/.cf stuff.  More often than not, when I run into a
> sendmail issue, I find that somebody has added stuff to .cf manually,
> which means I can't use the .mc to add things without breaking
> things.

I infer you are a consultant called in when someone has screwed up their system (at least some of the time). Because otherwise, you would either know what is in the .cf file and why it is there, or you would have put all your changes into the .mc file file in the first place. Other than the simplicity (relatively speaking) of the .mc file, I find it handy because a new release can change the .cf file in ways I do not understand and I have to rethink everything. But the stuff I put in my .mc file is a relatively minor change from the default one. So when I install a new version of sendmail, I can be pretty sure that making a new .cf file from the .mc one will get me pretty much what I need. Of course, I do read the READMEs and stuff first (at least skim them).

> And of course .mc files are only a little bit more comprehensible
> than raw .cf files to start with.  Actually, in some ways they are
> LESS comprehensible: when someone has manually modified .cf, getting
>  .mc to produce the desired output by reverse engineering is at least
> annoying.

The nearest I got to modifying a .cf file was when I was sending stuff (smart host) to my ISP's MTA (also sendmail, it happens). Well I have two machines on a LAN, and I did not want to bother sending up to my ISP and back, so I wanted some rules to notice when sending to my other machine and go direct through the LAN. Nowdays, there may be better ways to do this, but I found I could just stick:

dnl Allow hosts on LAN to skip smart host. (4.3.3.7)
LOCAL_NET_CONFIG
R$* < @ $* .$m. > $*   $#smtp $@ $2.$m $: $1 < @ $2.$m > $3

into the .mc file to get the sendmail.cf to say this:

# figure out what should stay in our local mail system
R$* < @ $* .$m. > $*   $#smtp $@ $2.$m $: $1 < @ $2.$m > $3

With tricks like that, I no longer have had to diddle the .cf file directly, though my needs are modest. (BTW, I no longer need smart host, so I guess I could take this out.)

Jean-David Beyer

> I'm still having trouble with that guys files.  I got submit.mc
> to make a submit.cf now that works OK as long as the queue files are 777.
> Setgid is correct on the sendmail binary, group ownerships etc on the
> queues were correct, but it just is not working.  Obviously I'm
> missing something (not that I've had time to read everything carefully
> yet of course).

[...]

There's really no need to change the default submit.{mc|cf} since it's only used when operating sendmail in a non-daemon mode from the localhost. If the customer's previous sendmail.cf file was from an 8.12.x then you don't even need to rebuild that. Just verify permissions on the installation as follows.

sendmail must be a set-group-ID (default group: smmsp, recommended
gid: 25) program to allow for queueing mail in a group-writable
directory.  Two .cf files are required:  sendmail.cf for the daemon
and submit.cf for the submission program.  The following permissions
should be used:

-r-xr-sr-x      root   smmsp    ... /PATH/TO/sendmail
drwxrwx---      smmsp  smmsp    ... /var/spool/clientmqueue
drwx------      root   wheel    ... /var/spool/mqueue
-r--r--r--      root   wheel    ... /etc/mail/sendmail.cf
-r--r--r--      root   wheel    ... /etc/mail/submit.cf

Then start the daemon with a command such as:

/usr/sbin/sendmail -L sm-mta -bd -q15m

in the init script for a 15-minute queue flush daemon.

tony