Hello,

I have in my sendmail.mc

DAEMON_OPTIONS(`Addr=aa.bb.cc.123, Port=465, Name=MTA-123-TLS, M=a,p')
DAEMON_OPTIONS(`Addr=aa.bb.cc.124, Port=465, Name=MTA-123-TLS, M=a,p')

and

O CACertPath=/etc/mail/tls
O CACertFile=/etc/mail/tls/ca.crt
O ServerCertFile=/etc/mail/tls/sendmail-server.crt
O ServerKeyFile=/etc/mail/tls/sendmail-server.key
O ClientCertFile=/etc/mail/tls/sendmail-client.crt
O ClientKeyFile=/etc/mail/tls/sendmail-client.key

Now,

aa.bb.cc.123 dns name is mail123.domain.com
aa.bb.cc.124 dns name is mail124.domain.com

Is it possible to have server to present/verify different
certificate for each daemon ? Actually verification is
not the point, the problem is, that when I have one
server certificate used on all daemons, and different
users use different daemons for sending their emails,
the certificate name (CN) doesn't match with
the server name, and they always get annoying
dialog box. I'm using my own CA and my root CA certificate
is installed on all client machines, all generated certs
are signed properly, it's only about the DNS name of particular
IP address.

I could create different sendmail instances with different .cf files,
or simply make the same DNS name to be resolved in two
addresses randomly, but none of these does not satisfy me.
I just would like to have different certs on different daemons,
is it possible?
Regards,
DT

In article <1177445578.903860.171080@n35g2000prd.googlegroups .com> DT
<pwadas@jewish.org.pl> writes:
>
>I have in my sendmail.mc
>
>DAEMON_OPTIONS(`Addr=aa.bb.cc.123, Port=465, Name=MTA-123-TLS, M=a,p')
>DAEMON_OPTIONS(`Addr=aa.bb.cc.124, Port=465, Name=MTA-123-TLS, M=a,p')

Hm, not that it has anything to do with your question, but it's a bit
"odd" to use the SMTPS port when you do STARTTLS - a major reason for
STARTTLS (and the equivalent in other protocols) as opposed to "SSL
wrapping" such as SMTPS is that it doesn't require a special port...
Btw, the modifiers given after M= should not be comma-separated but
simply concatenated - the comma is currently ignored along with any
other unassigned characters, but when the sendmail developers have run
out of letters the comma may be given a meaning...:-)

>Is it possible to have server to present/verify different
>certificate for each daemon ?

No, but it would be a meaningful addition I think - a patch to implement
it may be accepted at sendmail.org.

>I could create different sendmail instances with different .cf files,
>or simply make the same DNS name to be resolved in two
>addresses randomly, but none of these does not satisfy me.

Your best option could possibly be to have a single sendmail.cf but with
the DaemonPortOptions and ServerCertFile/ServerKeyFile options given (or
overridden) on the daemon startup commandline.

See also the threads at

http://groups.google.com/group/comp....1ac62c88927ffa

and

http://groups.google.com/group/comp....d55461cc47471e

--Per Hedeland
per@hedeland.org

I've read this
http://groups.google.pl/group/comp.m...caf5e0bdb23c99
and this
http://groups.google.com/group/comp....d55461cc47471e

However this made me sad
But I noticed in my configuration the following:

define( `confCW_FILE',
`@ldap: -o -h127.0.0.1 -w3 -p389 -d `cn=readonly'
-M `simple' -P `secret-file'
-b `dc=foo,dc=bar
-k `(&'_MYFILTER_`(objectClass=sendmailMTAClass)
(sendmailMTAClassName=w))'
-v `sendmailMTAClassValue'')dnl

define(`ALIAS_FILE',
`ldap: -o -h127.0.0.1 -w3 -p389 -d"cn=readonly"
-M `simple' -P `secret-file'
-b `dc=foo,dc=bar
-k"(&(objectClass=sendmailMTAAlias)(sendmailMTAKey= %0))"
-v"sendmailMTAAliasValue"')dnl

What about such trick?

define(`confSERVER_CERT',
`ldap: -o -h127.0.0.1 -w3 -p389 -d"cn=readonly"
-M `simple' -P `secret-file'
-b `dc=foo,dc=bar
-k"(&(objectClass=someclass)(objectclass=$
{some_daemon_name_macro_here}))"
-v"someAttributeContainingBase64cert"')dnl

I do not expect this to work, but I'm gonna try..

DT

In article <1177564540.002261.264880@r30g2000prh.googlegroups .com> DT
<pwadas@jewish.org.pl> writes:
>
>define( `confCW_FILE',
> `@ldap: -o -h127.0.0.1 -w3 -p389 -d `cn=readonly'
> -M `simple' -P `secret-file'
> -b `dc=foo,dc=bar
> -k `(&'_MYFILTER_`(objectClass=sendmailMTAClass)
>(sendmailMTAClassName=w))'
> -v `sendmailMTAClassValue'')dnl
>
>define(`ALIAS_FILE',
> `ldap: -o -h127.0.0.1 -w3 -p389 -d"cn=readonly"
> -M `simple' -P `secret-file'
> -b `dc=foo,dc=bar
> -k"(&(objectClass=sendmailMTAAlias)(sendmailMTAKey= %0))"
> -v"sendmailMTAAliasValue"')dnl

Hm, maybe you should look into using confLDAP_DEFAULT_SPEC.:-)

>What about such trick?
>
>define(`confSERVER_CERT',
> `ldap: -o -h127.0.0.1 -w3 -p389 -d"cn=readonly"
> -M `simple' -P `secret-file'
> -b `dc=foo,dc=bar
> -k"(&(objectClass=someclass)(objectclass=$
>{some_daemon_name_macro_here}))"
> -v"someAttributeContainingBase64cert"')dnl
>
>I do not expect this to work, but I'm gonna try..

Your expectations are on the mark, so I wouldn't waste time trying - as
explained in cf/README (and implicitly in doc/op/op.*), what you can use
LDAP for is "ALIASES, MAPS, AND CLASSES" - i.e. things where sendmail
itself "reads" the "contents". The confSERVER_CERT is just a file name
passed to OpenSSL, which doesn't know anything about sendmail's LDAP
features.

What *could* work (but doesn't) would be "dynamic" macro expansion of
the file name you specified, i.e. having e.g. $&{daemon_name} being part
of the name. However sendmail.cf option lines (as opposed primarily to
ruleset contents) are macro expanded, but only "statically" - i.e. at
the point when sendmail reads sendmail.cf, and using the macro
definitions that are in effect at that point.

I'm not sure if there is a fundamental architectural reason for this, or
if it's just that for most options it wouldn't work (because the option
value can't really change dynamically) or wouldn't make sense to do
"dynamic" expansion. In this particular case it would work perfectly,
since the file name is passed to OpenSSL at the start of each SSL/TLS
session, at a point when (e.g.) the $&{daemon_name} macro has the
appropriate value (it could even work for SMTPS I think).

Other possibilities to do this "the sendmail way" could be

a) have the file name that is actually passed to OpenSSL be a macro,
that is initialized from the option setting but could be redefined via
the 'macro' map in e.g. Local_check_relay, or

b) make it possible to specify the file name as a field in
DaemonPortOptions/DAEMON_OPTIONS.

It would be quite trivial to implement a) I think, and it's extremely
flexible, in the sendmail tradition, but perhaps it's a bit complex to
use - you would have to write a custom rule or two. It would of course
be simpler (and less flexible) to use b), but it requires a bit more
implementation-wise, and following this path in general will eventually
make DaemonPortOptions incredibly complex - but it was the choice for a
handful of options-made-per-daemon in 8.14:

New suboptions for DaemonPortOptions to set them individually
per daemon socket:
DeliveryMode DeliveryMode
refuseLA RefuseLA
delayLA DelayLA
queueLA QueueLA
children MaxDaemonChildren

- so maybe it's the "preferred" way.

--Per Hedeland
per@hedeland.org

DT wrote:

> I could create different sendmail instances with different .cf files,
> or simply make the same DNS name to be resolved in two
> addresses randomly, but none of these does not satisfy me.

Why not? Different configurations -> different instances...

That's the simplest approach (and therefore probably the best).

Per Hedeland wrote:

> implementation-wise, and following this path in general will eventually
> make DaemonPortOptions incredibly complex - but it was the choice for a
> handful of options-made-per-daemon in 8.14:

> - so maybe it's the "preferred" way.

No.

That is the "sendmail must work around problems in other software"
way.

Moreover, those are ugly hacks (and some of the options don't even
work, see the 8.14.1 release notes, and it is still broken, but it
seems almost nobody noticed).

In article <f0rned$14o$1@obelix.informatik.uni-kiel.de> Claus
=?iso-8859-1?Q?A=DFmann?=
<ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> writes:
>DT wrote:
>
>> I could create different sendmail instances with different .cf files,
>> or simply make the same DNS name to be resolved in two
>> addresses randomly, but none of these does not satisfy me.
>
>Why not? Different configurations -> different instances...
>
>That's the simplest approach (and therefore probably the best).

Well, by that reasoning you should remove the possibility to listen to
multiple addresses (in the same address family) for MTA service.:-) But
seriously, I think the presence of this capability in combination with
providing STARTTLS with only a single server cert/key borders on being a
bug - it's quite unlikely that same cert would be "valid" on all
addresses.

What did you think of my cert-file-via-macro idea? I might do a patch
for it, it's been a while...:-)

--Per Hedeland
per@hedeland.org

Per Hedeland wrote:

> >Why not? Different configurations -> different instances...

> Well, by that reasoning you should remove the possibility to listen to
> multiple addresses (in the same address family) for MTA service.:-) But

Those are not different configurations.

> What did you think of my cert-file-via-macro idea? I might do a patch

You have to check whether the data flow can deal with that.

In article <f0uc6j$1o0$1@obelix.informatik.uni-kiel.de> Claus
=?iso-8859-1?Q?A=DFmann?=
<ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> writes:
>Per Hedeland wrote:
>
>> >Why not? Different configurations -> different instances...
>
>> Well, by that reasoning you should remove the possibility to listen to
>> multiple addresses (in the same address family) for MTA service.:-) But
>
>Those are not different configurations.

Uh, that's rather circular reasoning - they're not different
configurations just because you now *have* the possibility of
configuring multiple addresses in one .cf - back in the old days when
you could only have a single DaemonPortOptions option (pre 8.10 I
believe), it *would* have been different configurations. Likewise, if
server cert/key could be specified via (e.g.) DaemonPortOptions, having
per-address settings of those wouldn't be multiple configurations
either.

>> What did you think of my cert-file-via-macro idea? I might do a patch
>
>You have to check whether the data flow can deal with that.

Yes of course - I take that answer to mean that the concept isn't
totally broken.

--Per Hedeland
per@hedeland.org

On Apr 27, 3:28 pm, p...@hedeland.org (Per Hedeland) wrote:
> In article <f0rned$14...@obelix.informatik.uni-kiel.de> Claus
> =?iso-8859-1?Q?A=DFmann?=
>
> <ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> writes:
> >DT wrote:
>
> >> I could create different sendmail instances with different .cf files,
> >> or simply make the same DNS name to be resolved in two
> >> addresses randomly, but none of these does not satisfy me.
>
> >Why not? Different configurations -> different instances...
>
> >That's the simplest approach (and therefore probably the best).
>
> Well, by that reasoning you should remove the possibility to listen to
> multiple addresses (in the same address family) for MTA service.:-) But
> seriously, I think the presence of this capability in combination with
> providing STARTTLS with only a single server cert/key borders on being a
> bug - it's quite unlikely that same cert would be "valid" on all
> addresses.

I think you are correct. Conceptually, DaemonPortOptions should be
able to configure all things that will reasonably differ from
listening instance to listening instance.

>
> What did you think of my cert-file-via-macro idea? I might do a patch
> for it, it's been a while...:-)

I think it would only be better were it to be configurable via
DaemonPortOptions and controllable via ruleset.

>
> --Per Hedeland
> p...@hedeland.org