Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

sendmail 8.15.1 available

183 views
Skip to first unread message

Claus Aßmann

unread,
Dec 6, 2014, 7:20:02 AM12/6/14
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Proofpoint, Inc., and the Sendmail Consortium announce the availability
of sendmail 8.15.1. This release:

o offers more TLS related features,
o does not ignore temporary map lookup failures during header rewriting,
o uses uncompressed IPv6 addresses by default, which is an incompatible
change that requires to update IPv6 related configuration data.

as well as many other enhancements. For details see the release
notes below.

Please send bug reports and general feedback to one of the addresses
listed at: http://www.sendmail.org/email-addresses.html

The version can be found at

ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.15.1.tar.gz
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.15.1.tar.gz.sig
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.15.1.tar.Z
ftp://ftp.sendmail.org/pub/sendmail/sendmail.8.15.1.tar.Z.sig

SHA-256 checksums

ed1f9e0f2a1a58c9ff94950264a2fc186d6fd237bac66b175d79a2b89a950746 sendmail.8.15.1.tar.gz
b13981995b2482be9bd74749590ae2a695e96f5022a299b42b78812546061755 sendmail.8.15.1.tar.gz.sig
823fe8400c09f8d603392ca7e7352cabd26c120da7b52f38a06c830dedfd782d sendmail.8.15.1.tar.Z
f850b44f21cd4d773c067ea60bbc0bfb201b1fca37f764201b050db616854043 sendmail.8.15.1.tar.Z.sig

You either need the first two files or the third and fourth,
i.e., the gzip'ed version or the compressed version and the
corresponding sig file. The PGP signature was created using
the Sendmail Signing Key/2014, available on the web site
(http://www.sendmail.com/sm/open_source/download/) or on
the public key servers (keyid 0x61DE11ECE2763A73).

Since sendmail 8.11 and later includes hooks to cryptography, the
following information from OpenSSL applies to sendmail as well.

PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG CRYPTOGRAPHY
SOFTWARE, PROVIDING CRYPTOGRAPHY HOOKS OR EVEN JUST COMMUNICATING
TECHNICAL DETAILS ABOUT CRYPTOGRAPHY SOFTWARE IS ILLEGAL IN SOME
PARTS OF THE WORLD. SO, WHEN YOU IMPORT THIS PACKAGE TO YOUR
COUNTRY, RE-DISTRIBUTE IT FROM THERE OR EVEN JUST EMAIL TECHNICAL
SUGGESTIONS OR EVEN SOURCE PATCHES TO THE AUTHOR OR OTHER PEOPLE
YOU ARE STRONGLY ADVISED TO PAY CLOSE ATTENTION TO ANY EXPORT/IMPORT
AND/OR USE LAWS WHICH APPLY TO YOU. THE AUTHORS ARE NOT LIABLE FOR
ANY VIOLATIONS YOU MAKE HERE. SO BE CAREFUL, IT IS YOUR RESPONSIBILITY.


SENDMAIL RELEASE NOTES


This listing shows the version of the sendmail binary, the version
of the sendmail configuration files, the date of release, and a
summary of the changes in that release.

8.15.1/8.15.1 2014/12/06
SECURITY: Properly set the close-on-exec flag for file descriptors
(except stdin, stdout, and stderr) before executing mailers.
If header rewriting fails due to a temporary map lookup failure,
queue the mail for later retry instead of sending it
without rewriting the header. Note: this is done
while the mail is being sent and hence the transaction
is aborted, which only works for SMTP/LMTP mailers
hence the handling of temporary map failures is
suppressed for other mailers. SMTP/LMTP servers may
complain about aborted transactions when this problem
occurs.
See also "DNS Lookups" in sendmail/TUNING.
Incompatible Change: Use uncompressed IPv6 addresses by default,
i.e., they will not contain "::". For example,
instead of ::1 it will be 0:0:0:0:0:0:0:1. This
permits a zero subnet to have a more specific match,
such as different map entries for IPv6:0:0 vs IPv6:0.
This change requires that configuration data
(including maps, files, classes, custom ruleset,
etc) must use the same format, so make certain such
configuration data is updated before using 8.15.
As a very simple check search for patterns like
'IPv6:[0-9a-fA-F:]*::' and 'IPv6::'. If necessary,
the prior format can be retained by compiling with:
APPENDDEF(`conf_sendmail_ENVDEF', `-DIPV6_FULL=0')
in your devtools/Site/site.config.m4 file.
If debugging is turned on (-d0.14) also print the OpenSSL
versions, both build time and run time
(provided STARTTLS is compiled in).
If a connection to the MTA is dropped by the client before its
hostname can be validated, treat it as "may be forged",
so that the unvalidated hostname is not passed to a
milter in xxfi_connect().
Add a timeout for communication with socket map servers
which can be specified using the -d option.
Add a compile time option HESIOD_ALLOW_NUMERIC_LOGIN to allow
numeric logins even if HESIOD is enabled.
The new option CertFingerprintAlgorithm specifies the finger-
print algorithm (digest) to use for the presented cert.
If the option is not set, md5 is used and the macro
{cert_md5} contains the cert fingerprint.
However, if the option is set, the specified algorithm
(e.g., sha1) is used and the macro {cert_fp} contains
the cert fingerprint.
That is, as long as the option is not set, the behaviour
does not change, but otherwise, {cert_md5} is superseded
by {cert_fp} even if you set CertFingerprintAlgorithm
to md5.
The options ServerSSLOptions and ClientSSLOptions can be used
to set SSL options for the server and client side
respectively. See SSL_CTX_set_options(3) for a list.
Note: this change turns on SSL_OP_NO_SSLv2 and
SSL_OP_NO_TICKET for the client. See doc/op/op.me
for details.
The option CipherList sets the list of ciphers for STARTTLS.
See ciphers(1) for possible values.
Do not log "STARTTLS: internal error: tls_verify_cb: ssl == NULL"
if a CRLFfile is in use (and LogLevel is 14 or higher.)
Store a more specific TLS protocol version in ${tls_version}
instead of a generic one, e.g., TLSv1 instead of
TLSv1/SSLv3.
Properly set {client_port} value on little endian machines.
Patch from Kelsey Cummings of Sonic.net.
Per RFC 3848, indicate in the Received: header whether SSL or
SMTP AUTH was negotiated by setting the protocol clause
to ESMTPS, ESMTPA, or ESMTPSA instead of ESMTP.
If the 'C' flag is listed as TLSSrvOptions the requirement for the
TLS server to have a cert is removed. This only works
under very specific circumstances and should only be used
if the consequences are understood, e.g., clients
may not work with a server using this.
The options ClientCertFile, ClientKeyFile, ServerCertFile, and
ServerKeyFile can take a second file name, which must be
separated from the first with a comma (note: do not use
any spaces) to set up a second cert/key pair. This can
be used to have certs of different types, e.g., RSA
and DSA.
A new map type "arpa" is available to reverse an IP (IPv4 or IPv6)
address. It returns the string for the PTR lookup, but
without trailing {ip6,in-addr}.arpa.
New operation mode 'C' just checks the configuration file, e.g.,
sendmail -C new.cf -bC
will perform a basic syntax/consistency check of new.cf.
The mailer flag 'I' is deprecated and will be removed in a
future version.
Allow local (not just TCP) socket connections to the server, e.g.,
O DaemonPortOptions=Family=local, Addr=/var/mta/server.sock
can be used.
If the new option MaxQueueAge is set to a value greater than zero,
entries in the queue will be retried during a queue run
only if the individual retry time has been reached which
is doubled for each attempt. The maximum retry time is
limited by the specified value.
New DontBlameSendmail option GroupReadableDefaultAuthInfoFile
to relax requirement for DefaultAuthInfo file.
Reset timeout after receiving a message to appropriate value if
STARTTLS is in use. Based on patch by Kelsey Cummings
of Sonic.net.
Report correct error messages from the LDAP library for a range of
small negative return values covering those used by OpenLDAP.
Fix compilation with Berkeley DB 5.0 and 6.0. Patch from
Allan E Johannesen of Worcester Polytechnic Institute.
CONFIG: FEATURE(`nopercenthack') takes one parameter: reject or
nospecial which describes whether to disallow "%" in the
local part of an address.
DEVTOOLS: Fix regression in auto-detection of libraries when only
shared libraries are available. Problem reported by
Bryan Costales.
LIBMILTER: Mark communication socket as close-on-exec in case
a user's filter starts other applications.
Based on patch from Paul Howarth.
Portability:
SunOS 5.12 has changed the API for sigwait(2) to conform
with XPG7. Based on patch from Roger Faulkner of Oracle.
Deleted Files:
libsm/path.c

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUgefAAAoJEGHeEezidjpz7sYH/j9+EziE3q7MG2Mi5ZSEmSqo
UHrGicYFX/IJr24/IRlHvrwOU16Y5wMN9Rf0DI6xX1Gh8YqiDQjmCEk68x2QxB4k
JjObeI2yyBp+IQrp5AUsefo7ATQuajUlnt6qy+zUL4ZubXdZzgBZPq+c7avb0hqe
oLraPH9UbhoITIY7RlXCIky9ODErn+8bCdwTrdcj5aNI98FiQNm2sCtUrk6aSWHi
XWmp4KSsTjNr9iqPaei9Mxefn9Sd4TgAU7WUEUnsSAuxtUauVqKnvIWijH2d0Ug7
f7xbj1Lxetq0/A1l3GeXe6fIBi2KXtCEzRvBBL1MLvt60ktiLfJrlpAmkJAFgOA=
=yoMt
-----END PGP SIGNATURE-----

Sergey

unread,
Dec 8, 2014, 4:11:05 AM12/8/14
to
Claus Aßmann wrote:

>         If header rewriting fails due to a temporary map lookup failure,
>                 queue the mail for later retry instead of sending it
>                 without rewriting the header.  Note: this is done
>                 while the mail is being sent and hence the transaction
>                 is aborted, which only works for SMTP/LMTP mailers
>                 hence the handling of temporary map failures is
>                 suppressed for other mailers. SMTP/LMTP servers may
>                 complain about aborted transactions when this problem
>                 occurs.
>                 See also "DNS Lookups" in sendmail/TUNING.

I think I encountered this problem after upgrading. Some messages is not
received by Cyris-IMAP via LMTP (cyrusv2d - RTCyrus2 from Andrzej Adam Filip).
This is a very small number of messages.

Dec 8 11:58:04 sendmail[279079]: sB87vswL279079: from=<in...@another.example.com>,
size=43750, class=0, nrcpts=1, msgid=<548559EA...@another.example.com>,
bodytype=8BITMIME, proto=ESMTP, daemon=MTA, relay=relay3.another.example.com
[10.20.20.20]
Dec 8 11:59:06 sendmail[279189]: sB87vswL279079: SYSERR(root): timeout writing
message to imap.example.com.
Dec 8 11:59:06 sendmail[279189]: sB87vswL279079: to=<us...@example.com>,
delay=00:01:02, xdelay=00:01:01, mailer=cyrusv2d, pri=163750, relay=imap.example.com.
[10.10.10.10], dsn=4.4.2, stat=Deferred: Name server: imap.example.ru.: host
name lookup failure

I do not understand it:
"relay=imap.example.com. [10.10.10.10]" and
"imap.example.ru.: host name lookup failure"
at one time.

But it is only for this message. It remains in the spool:

Dec 8 12:21:06 sendmail[295353]: sB87vswL279079: SYSERR(root): timeout writing
message to imap.example.com.
Dec 8 12:21:06 sendmail[295353]: sB87vswL279079: to=<us...@example.com>,
delay=00:23:02, xdelay=00:01:02, mailer=cyrusv2d, pri=253750, relay=imap.example.com.
[10.10.10.10], dsn=4.4.2, stat=Deferred: Name server: imap.example.ru.: host name
lookup failure

Many other messages are delivered right at this time. For <us...@example.com>
also. The message sB87vswL279079 delivered after I change Sendmail to 8.14.9.

--
Regards, Sergey

Sergey

unread,
Dec 8, 2014, 4:37:36 AM12/8/14
to
Sergey wrote:

> Dec  8 11:59:06 sendmail[279189]: sB87vswL279079: to=<us...@example.com>,
>   delay=00:01:02, xdelay=00:01:01, mailer=cyrusv2d, pri=163750,
>   relay=imap.example.com. [10.10.10.10], dsn=4.4.2, stat=Deferred:
>   Name server: imap.example.ru.: host name lookup failure

cyrusv2d mailer works with LMTP, source of Cyrus-IMAP is not
contain the message "host name lookup failure".

--
Regards, Sergey

Claus Aßmann

unread,
Dec 8, 2014, 7:40:03 AM12/8/14
to
Sergey wrote:
> Claus Aßmann wrote:

> > If header rewriting fails due to a temporary map lookup failure,
> > queue the mail for later retry instead of sending it
> > without rewriting the header.

> > See also "DNS Lookups" in sendmail/TUNING.

> I think I encountered this problem after upgrading. Some messages is not

So did you follow the advice to read sendmail/TUNING?

> But it is only for this message. It remains in the spool:

Yes, that's what the doc says...

> Many other messages are delivered right at this time.

That's the problem with DNS lookups: you barely ever can reproduce
temporary failures...

See the doc what to do about this.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Claus Aßmann

unread,
Dec 8, 2014, 8:20:02 AM12/8/14
to
Sergey wrote:

> Dec 8 12:21:06 sendmail[295353]: sB87vswL279079: to=<us...@example.com>,
> delay=00:23:02, xdelay=00:01:02, mailer=cyrusv2d, pri=253750, relay=imap.example.com.
> [10.10.10.10], dsn=4.4.2, stat=Deferred: Name server: imap.example.ru.: host name
> lookup failure

BTW:
Next time such a problem happens, run the queued item in verbose mode:

sendmail -qI.... -d21.4 -d9.1 -d38.20 -v

and check the output.

Sergey

unread,
Dec 8, 2014, 8:44:52 AM12/8/14
to
Claus Aßmann wrote:

>> I think I encountered this problem after upgrading. Some
>> messages is not
>
> So did you follow the advice to read sendmail/TUNING?

Yes, but I pointed to what I do not understand:

| I do not understand it:
| "relay=imap.example.com. [10.10.10.10]" and
| "imap.example.ru.: host name lookup failure"
| at one time.

> That's the problem with DNS lookups: you barely ever can
> reproduce temporary failures...

I hope that my DNSes working well... NSes for "example.com" and
"10.10.10.in-addr.arpa" under my full control. Moreover, the mail
server has its own DNS cache. I do not think that the problem in
these zones.

Can this error be related to one of the zones in the "From" or
"To" fields of message header ?

Two related questions:
1. Why the error looks like received from "relay=imap.example.com" ?
2. Is it possible to show the real host name that caused the error ?

--
Regards, Sergey

Claus Aßmann

unread,
Dec 8, 2014, 9:10:02 AM12/8/14
to
Sergey wrote:

> Can this error be related to one of the zones in the "From" or
> "To" fields of message header ?

Any address field in the header.

> 1. Why the error looks like received from "relay=imap.example.com" ?

It's the server, right?

> 2. Is it possible to show the real host name that caused the error ?

That requires a source patch... maybe you can contribute one?

Anyway, I would simply turn that stuff off as explained in the docs.

Sergey

unread,
Dec 8, 2014, 12:58:20 PM12/8/14
to
Claus Aßmann wrote:

>> Can this error be related to one of the zones in the
>> "From" or "To" fields of message header ?
>
> Any address field in the header.

Hm. I did not think that this is checked too... The problem was
repeated. It is in this. "To" field contains a set of recepients
and only one is a user of imap.example.com:

To: <us...@example.com>, <us...@blah-blah-blah.ru>

> sendmail -qI.... -d21.4 -d9.1 -d38.20 -v

>>> RCPT To:<us...@example.com>
>>> DATA
250 2.1.5 ok
354 go ahead
rewrite: ruleset canonify input: ...
<skip>
getcanonname(bla-bla-bla.ru), failed, status=68
FAIL (2)
blah-blah-blah.ru: Name server timeout
<skip>
timeout writing message to imap.example.com.
<us...@example.com>... Deferred: Name server: imap.example.com.: host name lookup failure

So, us...@blah-blah-blah.ru is causing the problem...
Ok, FEATURE(`nocanonify') must be used. :-)

But messages in the log are difficult to interpret in this sense.

>> 1. Why the error looks like received from "relay=imap.example.com" ?
>
> It's the server, right?

Yes, but the problem is not with this server and not with user of
this server... Better would be

Deferred: timeout writing message to imap.example.com.

or this:

>> 2. Is it possible to show the real host name that caused the error ?
>
> That requires a source patch... maybe you can contribute one?

I can not promise this. I have been programming a long time ago.

> Anyway, I would simply turn that stuff off as explained in the docs.

I didn't expect that message in the log is not very reliable.

--
Regards, Sergey

Claus Aßmann

unread,
Dec 8, 2014, 1:40:03 PM12/8/14
to
Sergey wrote:

> >> 2. Is it possible to show the real host name that caused the error ?

> > That requires a source patch... maybe you can contribute one?

> I didn't expect that message in the log is not very reliable.

Sorry, but the way the code handles this kind of temporary map failure
is "not nice" (and it's non-trivial to change it).
It was already complicated enough to propagate the error "upwards"
(where it will treated as an I/O error...), so I did not spend too much
time on a "nice" error message.
As I mentioned before: these DNS lookups should NOT be used on an MTA,
hence I added all that information to the docs...

ict....@gmail.com

unread,
Dec 16, 2014, 5:02:21 PM12/16/14
to

dear Claus,

the homepage should be updated too
http://www.sendmail.com/sm/open_source/download/

it still says 8.14.9

thanks for your great job.

// hans

Claus Aßmann

unread,
Dec 16, 2014, 6:20:04 PM12/16/14
to
hans wrote:

> the homepage should be updated too

Let's say "It's complicated" :-( I don't have (write) access
to that website... Thanks for the reminder.
Message has been deleted

Claus Aßmann

unread,
Dec 18, 2014, 7:40:02 PM12/18/14
to
D. Stussy wrote:

> Is there a reason you went with this approach instead of the
> {client_reverse} macro I suggested on January 3, 2013 in Message-ID:

Yes.

sm8 doesn't have a large macro space.
Message has been deleted

Claus Aßmann

unread,
Dec 19, 2014, 8:10:03 PM12/19/14
to
D. Stussy wrote:

> Also, does the DNSBL feature search for the IPv4 address if an IPv6 address
> that contains an embedded IPv4 address doesn't match (e.g. "::/96" or
> "2002::/16" addresses)?

Take a look at the feature...
AFAICT it works only for IPv4 addresses.
Message has been deleted

Bleve

unread,
Mar 22, 2015, 12:30:02 AM3/22/15
to
This update just bit me (using NetBSD pkgsrc updates without looking closely!). I am seeing this :

550 5.7.1 <foo@bar>... Relaying denied. IP name possibly forged
[IPv6:0:0:0:0:0:0:0:1]

on a previously untouched for years sendmail setup.

Is there a Q&D way to fix it? I'm phasing out the sendmail server and my sendmail config clues are very very rusty indeed, but the box is still in use - I can revert back to 8.14, but if it's as simple as "turn off IPv6 on the server" then I won't have to do that.

Claus Aßmann

unread,
Mar 22, 2015, 8:10:03 AM3/22/15
to
Bleve wrote:

> 550 5.7.1 <foo@bar>... Relaying denied. IP name possibly forged
> [IPv6:0:0:0:0:0:0:0:1]

> Is there a Q&D way to fix it?

Upgrade to 8.15.1.22 or look at its changes at least and "backport"
the ones you need.

Turning off IPv6 should do the trick too and fixing DNS for
that address might also help.

Bleve

unread,
Mar 22, 2015, 6:02:48 PM3/22/15
to
On Sunday, March 22, 2015 at 11:10:03 PM UTC+11, Claus Aßmann -no-copies-please wrote:

> Upgrade to 8.15.1.22 or look at its changes at least and "backport"
> the ones you need.
>
> Turning off IPv6 should do the trick too and fixing DNS for
> that address might also help.
>

Thank you Claus, I've temporarily backed out to 8.14.9, pending what happens with NetBSD's pkgsrc. Is 8.15.1.22 an official release that they might pick up?

Claus Aßmann

unread,
Mar 22, 2015, 10:10:02 PM3/22/15
to
Bleve wrote:

> Thank you Claus, I've temporarily backed out to 8.14.9, pending what happens with NetBSD's
> pkgsrc. Is 8.15.1.22 an official release that they might pick up?

8.15.1.22 is a snapshot.
I don't know NetBSDs policy.

Bleve

unread,
Mar 23, 2015, 9:45:05 PM3/23/15
to
On Monday, March 23, 2015 at 1:10:02 PM UTC+11, Claus Aßmann -no-copies-please wrote:

> 8.15.1.22 is a snapshot.
> I don't know NetBSDs policy.

Understood - will this be "fixed/reverted to old behaviour" in 8.15.2 or some other formal release or is it a permanent change?

Thanks again

Carl


Claus Aßmann

unread,
Mar 23, 2015, 10:10:03 PM3/23/15
to
Bleve wrote:

> Understood - will this be "fixed/reverted to old behaviour" in 8.15.2 or some other formal
> release or is it a permanent change?

Whatever is fixed in a snapshot will be in a subsequent "GA" release.

0 new messages