Bug 28361
| Summary: | sendmail.cf is missing some STARTTLS support | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Cyrille Lefevre <clefevre> | ||||
| Component: | conf | Assignee: | Gregory Neil Shapiro <gshapiro> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | 4.3-STABLE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
|
Description
Cyrille Lefevre
2001-06-23 10:20:01 UTC
Responsible Changed From-To: freebsd-bugs->gshapiro Over to in-tree sendmail maintainer. I prefer to take more generic approaches to issues like this. Would you be
satisfied with this solution?
Index: etc/defaults/make.conf
===================================================================
RCS file: /src/FreeBSD/cvsrepo/src/etc/defaults/make.conf,v
retrieving revision 1.97.2.51
diff -u -r1.97.2.51 make.conf
--- etc/defaults/make.conf 2001/06/11 16:28:18 1.97.2.51
+++ etc/defaults/make.conf 2001/06/27 01:35:31
@@ -350,6 +350,12 @@
#
#SENDMAIL_ADDITIONAL_MC=/etc/mail/foo.mc /etc/mail/bar.mc
#
+# Setting the following variable modifies the flags passed to m4 when
+# building a .cf file from a .mc file. It can be used to enable
+# features disabled by default.
+#
+#SENDMAIL_M4_FLAGS=-D_FFR_TLS_O_T
+#
# Setting the following variables modifes the build environment for
# sendmail and its related utilities. For example, SASL support can be
# added with settings such as:
Index: etc/mail/Makefile
===================================================================
RCS file: /src/FreeBSD/cvsrepo/src/etc/mail/Makefile,v
retrieving revision 1.9.2.9
diff -u -r1.9.2.9 Makefile
--- etc/mail/Makefile 2001/05/24 20:51:06 1.9.2.9
+++ etc/mail/Makefile 2001/06/27 01:36:03
@@ -124,8 +124,8 @@
.SUFFIXES: .cf .mc
.mc.cf: ${M4FILES}
- ${M4} -D_CF_DIR_=${SENDMAIL_CF_DIR}/ ${SENDMAIL_CF_DIR}/m4/cf.m4 \
- ${@:R}.mc > ${.TARGET}
+ ${M4} -D_CF_DIR_=${SENDMAIL_CF_DIR}/ ${SENDMAIL_M4_FLAGS} \
+ ${SENDMAIL_CF_DIR}/m4/cf.m4 ${@:R}.mc > ${.TARGET}
#
# Aliases are handled separately since they normally reside in /etc
Index: etc/sendmail/Makefile
===================================================================
RCS file: /src/FreeBSD/cvsrepo/src/etc/sendmail/Makefile,v
retrieving revision 1.3.2.5
diff -u -r1.3.2.5 Makefile
--- etc/sendmail/Makefile 2001/03/06 01:56:44 1.3.2.5
+++ etc/sendmail/Makefile 2001/06/27 01:37:14
@@ -18,7 +18,8 @@
.mc.cf: ${M4FILES}
${RM} ${.TARGET}
(cd ${.CURDIR} && \
- ${M4} -D_CF_DIR_=${CFDIR}/ ${CFDIR}/m4/cf.m4 ${@:R}.mc) > ${.TARGET}
+ ${M4} -D_CF_DIR_=${CFDIR}/ ${SENDMAIL_M4_FLAGS} \
+ ${CFDIR}/m4/cf.m4 ${@:R}.mc) > ${.TARGET}
${CHMOD} ${ROMODE} ${.TARGET}
ALL= freebsd.cf
Gregory Neil Shapiro wrote: > I responded to your PR a few days ago but mail isn't getting out to you: > > f5R1koaj096116 2160 Tue Jun 26 18:46 <gshapiro@horsey.gshapiro.net> > (Deferred: Connection refused by lala.v3.com.) > <clefevre@redirect.to> sorry, but this is just a relay (aka forwarder) and I don't have any control over it. thanks anyway. > I'll leave it in the queue in case the machine starts accepting connections > again. > > Here is my response again in case this address reaches you instead: thanks, I got it :) > I prefer to take more generic approaches to issues like this. Would you be > satisfied with this solution? I'm not sure this is the right way to go since this is relevant to the sendmail maintainer to set or not such flags depending on flags sets to compile the sendmail binary. do you understand what I mean ? but the idea of SENDMAIL_M4_FLAGS for other purpose could stay. [snip] Cyrille. -- home: mailto:clefevre@redirect.to UNIX is user-friendly; it's just particular work: mailto:Cyrille.Lefevre@edf.fr about who it chooses to be friends with. clefevre> I'm not sure this is the right way to go since this is relevant to clefevre> the sendmail maintainer to set or not such flags depending on flags clefevre> sets to compile the sendmail binary. do you understand what I mean ? clefevre> but the idea of SENDMAIL_M4_FLAGS for other purpose could stay. I think I understand what you mean. You don't want the user to have to know to add the -D_FFR_TLS_O_T. How about using my patch exactly as shown except changing the make.conf addition from: +# Setting the following variable modifies the flags passed to m4 when +# building a .cf file from a .mc file. It can be used to enable +# features disabled by default. +# +#SENDMAIL_M4_FLAGS=-D_FFR_TLS_O_T to: +# Setting the following variable modifies the flags passed to m4 when +# building a .cf file from a .mc file. It can be used to enable +# features disabled by default. +# +SENDMAIL_M4_FLAGS=-D_FFR_TLS_O_T That way, the default already includes the -D_FFR_TLS_O_T. Note that I didn't bother going through all of the checking your original patch does as there is no harm done if the FFR is defined on a non-STARTTLS sendmail binary. The extra ruleset it adds will be ignored. State Changed From-To: open->analyzed Working out issues with the submitter State Changed From-To: analyzed->feedback The fix has been committed to the HEAD. I will close this PR when it is MFC'ed to RELENG_4. State Changed From-To: feedback->closed I had to revert the commit adding the FFR as it broken configurations which did not include FEATURE(`access_db'). However, the make.conf variable is in place which lets users add it if they need it. Additionally, 8.12, now released, no longer requires the FFR. This issue will go away when 8.12 is imported. |
