- Stop 'make clean' from removing SENDMAIL_CF
- install and distribute targets should not attempt to build anything
- SENDMAIL_ADDITIONAL_CF were not installed in the distribution case
- If SENDMAIL_SET_USER_ID was defined, submit.cf was needlessly installed
in the distribution case
- Collapse install and distribution target into one to remove code
duplication
Submitted by: ru
MFC after: 5 days
though I would personally prefer to see the broken nameservers fixed
instead of standards compliant applications work around them, I can't
force FreeBSD users to help fight that battle.
Submitted by: Damon Anton Permezel <dap@damon.com>
MFC after: 2 days
pending RE approval
alternative MTAs. Therefore, always install rc.sendmail, regardless of
NO_SENDMAIL make.conf setting. Users can still set mta_start_script to a
different script.
This commit is after a repo-copy of src/etc/sendmail/rc.sendmail to
src/etc/rc.sendmail.
Noticed by: Calvin NG <calvinng@brel.com>
MFC after: 3 days
the .mc file used for /etc/mail/submit.cf. By default,
/etc/mail/freebsd.submit.mc is installed and used.
Requested by: fenner
Submitted by: ume
MFC after: 1 week
again."
As an alternative to sendmail_enable=NONE, solve the boot time problem
for non-sendmail users completely by moving all of the sendmail startup
code from /etc/rc to /etc/rc.sendmail. The source for that script will
be kept in src/etc/sendmail/rc.sendmail so make.conf's NO_SENDMAIL will
prevent it from being installed. A new rc.conf variable,
mta_start_script specifies the script to run to start the user's
preferred MTA. For backward compatibility, it will default to
/etc/rc.sendmail. The specified script is called out of /etc/rc after
checking to make sure it exists. A new rc.sendmail.8 man page has also
been added which now houses the sendmail_* variable descriptions
formerly in rc.conf.5.
Use /etc/rc.sendmail in /etc/mail/Makefile to reduce code duplication.
Reviewed by: -current, -stable, obrien, peter, ru
MFC after: 1 week
black lists in the default config, give a pointer to a non-static list.
I was convinced this was the right thing to do after getting a PR
asking to add ORBZ the day before ORBZ went off the air.
PR: conf/35884
MFC after: 4 days
install /etc/mail/sendmail.cf to /etc/mail/sendmail.cf and exits with an
error:
===> etc/sendmail
install -c -o root -g wheel -m 644 /etc/mail/sendmail.cf /etc/mail/sendmail.cf
install: /etc/mail/sendmail.cf and /etc/mail/sendmail.cf are the same file
*** Error code 64
Catch this in the Makefile and don't call install if the source and target
are the same file.
Reported by: Alexandr Listopad <laa@reis.zp.ua>
MFC after: 1 week
building a .cf file from a .mc file.
Include -D_FFR_TLS_O_T to enable tls policy control since the sendmail binary
build enables that FFR as well.
PR: conf/28361
MFC after: 1 week
1) blackholes.mail-abuse.org is the same as FEATURE(dnsbl), so specifying
it in the "Other DNS based black hole lists" section leads to confusion of
specifying it twice.
2) Formatting issues. If error diagnostic not enclosed in double quotes,
varius visual artefacts appearse like 1) no space after ; and 2) redundant
space after ? (in CGI request), so I add quotes where needed.
3) FEATURE(dnsbl) directly use error code 550 by default, so I made other
dnsbl variants use the same error code too.
4) Comment relays.* list as "open relays" list, just "other" word is not
explain enough.
Submitted by: ache
users should be configuring via m4 now. If set, use m4 to create the .cf
file. Also, if either SENDMAIL_MC or SENDMAIL_CF is set, 'make install' or
'make distribution' in src/etc/sendmail/ will install the appropriate .cf as
/etc/mail/sendmail.cf. This fixes some mergemaster problems.
PR: conf/13016
Makefile to the etc/sendmail Makefile to be consistent with all of the
other /var file creations. In doing so, change the Makefile target from
etc-sendmail.cf to distribution as it installs more than just the sendmail.cf.
Beyond changes to the build system, this includes fixing up the sample
freebsd.mc configuration for changes in defaults and syntax, removing
outdated documentation, and updating the release notes.
The current offical Sendmail Inc. version uses /var/mail/ and when we upgrade
our repository to that version, we will get the change. It is best to make
the path change in 4.0-R (which may not have the latest Sendmail Inc. version,
than to change in mid-4.x stream when we may upgrade.
Ok'ed by: Peter (quite a while ago)
