Multiple IP addresses and certificate "common name"
Andrew Gideon
Unless I'm missing something, one defines a single certificate for a
sendmail server. But a single certificate has a single "common name". At
least in the HTTP world, that common name contains the hostname. A
failure to match the hostname to common name causes a warning.
What about the case where a sendmail server has multiple interfaces (and
therefore multiple names)? How is that case handled? Or is "common name"
not used this way for SMTP?
Curiously...
Andrew
Taylor, Grant
I do not know for sure, but I suspect that you would have to do the same thing with Sendmail that you would have to do with your HTTP server. You will need to run Sendmail on multiple interfaces, which you say you are, with a separate server certificate for each interface (presuming that there is only one interface per name). I don't know if it is possible to specify different certificate files for specific interfaces or if you will be running multiple instances of sendmail, one per interface with it's distinct server certificate.
If you do end up having to run multiple instances of Sendmail I'd make sure that each was using a different queue. It would be possible to have multiple simple generic Sendmail daemons running that would relay for the domain for the interface the daemon is running on. Configure all the simple relay Sendmail daemons to relay to your central ""Main Sendmail daemon and let it continue to deliver to your mail store. This type of topology will allow you to have one complex main daemon that is doing most of / all of your Virus / Spam filtering. If you do your filtering during the SMTP transaction, your main Sendmail daemon would reject the messages, thus causing each spoke Sendmail daemon to be responsible for sending out DSNs (a.k.a. bounces). This would make the DSNs appear to be from the correct mail server with the correct server certificate too.
If you take this approach, you may want to put something in place (Mailertable?) that will make your central Sendmail daemon send outbound email through the correct spoke Sendmail daemon.
Grant. . . .
Per Hedeland
<c182d...@gideon.org> writes:
>
>Unless I'm missing something, one defines a single certificate for a
>sendmail server. But a single certificate has a single "common name". At
>least in the HTTP world, that common name contains the hostname. A
>failure to match the hostname to common name causes a warning.
It's the same for SMTP "in principle", only that a) the vast majority of
SMTP servers supporting STARTTLS probably won't have a certificate that
is verifiable anyway, and b) in the (most common?) case of the client
being another MTA, it is probably not set up to do verification even of
verifiable certificates, and c) in the same case, the "warning" is
typically limited to an entry in a log file ("verify=FAIL" in the case
of sendmail). I.e. a pretty sorry state of affairs as far as actually
providing the security of SSL/TLS goes, but maybe still preferable to
cleartext.
>What about the case where a sendmail server has multiple interfaces (and
>therefore multiple names)? How is that case handled? Or is "common name"
>not used this way for SMTP?
Well, the "therefore" isn't really given - what matters is what name the
SMTP client used to find the IP address, and you can certainly have a
name with multiple A records in the DNS, one for each interface (the
"official standard way" - names are for hosts, not interfaces), or use
split DNS, such that the same name resolves to different IP addresses
for intranet vs Internet lookups.
If neither is feasible, and you really want to do the right thing and
have verifiable and verified certificates, you will need to run a
separate sendmail instance for each interface. There was recently a
thread here about this in the case where you really *wanted* separate
names, see:
http://groups.google.com/group/comp.mail.sendmail/browse_frm/thread/26d55461cc47471e
--Per Hedeland
p...@hedeland.org
Per Hedeland
<mailman.84.1149286502.3...@maillists.riverviewtech.net>
"Taylor, Grant" <gta...@riverviewtech.net> writes:
>
>If you do end up having to run multiple instances of Sendmail I'd make
>sure that each was using a different queue.
It should work fine to have them use the same queue I believe.
> It would be possible to
>have multiple simple generic Sendmail daemons running that would relay
>for the domain for the interface the daemon is running on. Configure
>all the simple relay Sendmail daemons to relay to your central ""Main
>Sendmail daemon and let it continue to deliver to your mail store. This
>type of topology will allow you to have one complex main daemon that is
>doing most of / all of your Virus / Spam filtering. If you do your
>filtering during the SMTP transaction, your main Sendmail daemon would
>reject the messages, thus causing each spoke Sendmail daemon to be
>responsible for sending out DSNs (a.k.a. bounces).
This is a really bad idea, as has been discussed here many times - if at
all possible, you really want to avoid sending bounces for virus/spam
rejections, since the sender address is faked most of the time anyway.
Rejection in the SMTP dialogue *with the external SMTP client* is the
way to go. There are several ways to achieve a "multiple daemon" setup
where most everything is shared anyway, i.e. you can easily avoid
duplication of maintenance work and still have them all be "complex" (as
long as they are all on the same host, and that was a prerequisite
here).
This would make the
>DSNs appear to be from the correct mail server with the correct server
>certificate too.
But when sending the DSN (assuming you go that unwise route), that
server is a *client*, i.e. the server certificate isn't used - it can
certainly be set up with a client certificate too, in which case it
should probably be the same as the server certificate, but there is no
need for that in this scenario.
--Per Hedeland
p...@hedeland.org
Andrew Gideon
> You
> will need to run Sendmail on multiple interfaces, which you say you are,
> with a separate server certificate for each interface (presuming that
> there is only one interface per name). I don't know if it is possible to
> specify different certificate files for specific interfaces or if you will
> be running multiple instances of sendmail, one per interface with it's
> distinct server certificate.
Ideally, I believe, there'd be a mechanism to bind a certificate to either
an IP or an interface name. That's the analog of what HTTP servers do.
But I don't see how this can be done in sendmail. Is that my ignorance,
or is there no way? I would prefer to avoid running multiple daemonsm if
only because it adds complexity on a per-server basis (ie. servers will
now differ on more than just configuration files).
The POP/IMAP server I use does provide this capability (though, if memory
serves, someone patched this in). I don't recall the configuration part
(what one "tells" the POP/IMAP server), but the certificates are stored in
files named by IP.
That's not as clean or simple as what Apache does, but it does work.
- Andrew
Andrew Gideon
> The POP/IMAP server I use does provide this capability (though, if memory
> serves, someone patched this in). I don't recall the configuration part
> (what one "tells" the POP/IMAP server), but the certificates are stored in
> files named by IP.
BTW, this is the UW POP/IMAP server, in case anyone cares. I don't know
how other POP/IMAP servers handle this.
- Andrew
Taylor, Grant
Not having done such my self I can not say for sure. From what I have read Sendmail does not like it when something out side of the Sendmail daemon responsible for the queue alters the queue. In other words the main Sendmail daemon will get a bit unhappy when the other daemons are altering the main queue. Hence why I suggested the multiple mail queues. However as I have not done this, your mileage may vary. I'm just going buy what the Sendmail docs say.
>> It would be possible to
>> have multiple simple generic Sendmail daemons running that would relay
>> for the domain for the interface the daemon is running on. Configure
>> all the simple relay Sendmail daemons to relay to your central ""Main
>> Sendmail daemon and let it continue to deliver to your mail store. This
>> type of topology will allow you to have one complex main daemon that is
>> doing most of / all of your Virus / Spam filtering. If you do your
>> filtering during the SMTP transaction, your main Sendmail daemon would
>> reject the messages, thus causing each spoke Sendmail daemon to be
>> responsible for sending out DSNs (a.k.a. bounces).
>
> This is a really bad idea, as has been discussed here many times - if at
> all possible, you really want to avoid sending bounces for virus/spam
> rejections, since the sender address is faked most of the time anyway.
> Rejection in the SMTP dialogue *with the external SMTP client* is the
> way to go. There are several ways to achieve a "multiple daemon" setup
> where most everything is shared anyway, i.e. you can easily avoid
> duplication of maintenance work and still have them all be "complex" (as
> long as they are all on the same host, and that was a prerequisite
> here).
*nod* This is why I tend to try to do all of my filtering DURING the SMTP Transaction so that I can reject the message before accepting it. However in the interest of the discussion and keeping the spoke systems simple I did not go there. You are indeed correct that filtering probably should be done where the message can be rejected before it comes in to your (receiving host) system.
I presume that you are eluding to what is known as back scatter? IMHO _some_ amounts of back scatter is ok to mildly annoying. I personally would like to keep some of the ok to mildly annoying if for nothing else than to itch at the people that may be receiving the back scatter (from their forged source email addresses) so that they will seek out the source of the back scatter and thus the source of the spoofed emails and thus the real problem and fix it. People can not and will not fix what they don't know is wrong. Thus I believe that we should give off some low levels of information that something is wrong that should be corrected. That being said, this is just my opinion. Now, my opinion may change after I mess with SRS some more. I am presently SRSing my outbound email on my servers. I also am planing on seeing if I can not define a Sendmail class / map that lists receiving domains that require SRS addresses on DSNs. I think this will help cut down on the number
of false bounces / back scatter that comes in to my domains. If I am unable to do this, then I may change my earlier opinion, but for now I'm going to stick with it.
> But when sending the DSN (assuming you go that unwise route), that
> server is a *client*, i.e. the server certificate isn't used - it can
> certainly be set up with a client certificate too, in which case it
> should probably be the same as the server certificate, but there is no
> need for that in this scenario.
Hmm, interesting point that I will keep in mind if ever I decide to use TLS.
Grant. . . .
Taylor, Grant
> an IP or an interface name. That's the analog of what HTTP servers do.
*nod* I too agree that this is a shortcoming of Sendmail. I also believe that TLS is relatively new to the SMTP / Sendmail world and as such has some more things that need to happen to become as scalable as say Apache.
> But I don't see how this can be done in sendmail. Is that my ignorance,
> or is there no way? I would prefer to avoid running multiple daemonsm if
> only because it adds complexity on a per-server basis (ie. servers will
> now differ on more than just configuration files).
Having just read the "Sendmail Installation and Operations Guide" v 8.708 (8.13.6) (doc/op/op.ps), I did not see a way that you could list certificates for each interface. However I did see that you can provide multiple CA Root Certificates that will be sent to the client (? as I understand it ?) during the StartTLS handshake. Thus maybe you can send the CA Root Certificate that was used to sign the certificate for the domain in question. This may help get around this. For those who are more interested in this, refer to Section 6.6 on page 98 of the above document.
> The POP/IMAP server I use does provide this capability (though, if memory
> serves, someone patched this in). I don't recall the configuration part
> (what one "tells" the POP/IMAP server), but the certificates are stored in
> files named by IP.
>
> That's not as clean or simple as what Apache does, but it does work.
Grant. . . .
Per Hedeland
<mailman.93.1149520647.3...@maillists.riverviewtech.net>
"Taylor, Grant" <gta...@riverviewtech.net> writes:
[I wrote:]
>> It should work fine to have them use the same queue I believe.
>
>Not having done such my self I can not say for sure. From what I have
>read Sendmail does not like it when something out side of the Sendmail
>daemon responsible for the queue alters the queue.
But there isn't a single "sendmail daemon responsible for the queue".
The "main" daemon that listens on port 25 will fork a new process
whenever it gets a connection, and those processes may/will run in
parallel, and there may also be multiple forked queue runners running in
parallel with them, and still more manually started queue runners...
I.e. sendmail obviously does the locking needed to safely handle
multiple instances of itself (as well as anything else respecting the
same locking rules, such as contrib/qtool.pl).
> However as I have not done this, your mileage may vary. I'm
>just going buy what the Sendmail docs say.
Do you have some reference for that?
>*nod* This is why I tend to try to do all of my filtering DURING the
>SMTP Transaction so that I can reject the message before accepting it.
>However in the interest of the discussion and keeping the spoke systems
>simple I did not go there.
Well, you were the one suggesting the introduction of spoke systems in
this case...
>I presume that you are eluding to what is known as back scatter?
Uh... something like that.
> IMHO
>_some_ amounts of back scatter is ok to mildly annoying. I personally
>would like to keep some of the ok to mildly annoying if for nothing else
>than to itch at the people that may be receiving the back scatter (from
>their forged source email addresses) so that they will seek out the
>source of the back scatter and thus the source of the spoofed emails and
>thus the real problem and fix it. People can not and will not fix what
>they don't know is wrong.
But a) for most people (in most cases) it's effectively impossible to
seek out that ultimate source, and b) I think we can trust that there
will always be enough cluelessly configured mail systems to provide
_some_ amount of backscatter. If you further consider that those bounces
have a high probability of being unsendable and clog up your mail queue,
and that they may get *you* blacklisted, I'd think it's pretty clear
that it's a bad idea.
--Per Hedeland
p...@hedeland.org
Per Hedeland
<mailman.94.1149521367.3...@maillists.riverviewtech.net>
"Taylor, Grant" <gta...@riverviewtech.net> writes:
>
>Having just read the "Sendmail Installation and Operations Guide" v
>8.708 (8.13.6) (doc/op/op.ps), I did not see a way that you could list
>certificates for each interface. However I did see that you can provide
>multiple CA Root Certificates that will be sent to the client (? as I
>understand it ?) during the StartTLS handshake.
Assuming you're referring to CACertFile, no, that's used in conjunction
with client authentication. As the text says, the server sends the DN
(i.e. not the complete cert) of those certificates - the purpose is to
let a client that has a choice of multiple certificates know which of
them to send.
--Per Hedeland
p...@hedeland.org
Grant Taylor
Not that I can site at the moment. All I can say is that I recall multiple sources saying that you should not modify / work / move / delete with files in the queue directory b/c it could mess with Sendmail. The sources mention qtool.pl as one way to work with the queue because it does know how to lock files the way that Sendmail does to prevent conflicts.
That being said it may be possible for multiple Sendmail daemons / queue runners to work with in the same mail queue seeing as how they should know how to lock the file the same way that qtool.pl does.
I'll keep my eyes open to see if I can come across specific references.
Grant. . . .
Per Hedeland
standards, i.e. have a valid References: header to allow them to be
properly threaded? It is possible even when using a news<->mail gateway,
provided the gateway SW and MUA used is clueful enough.
Attribution of quotes is also the norm on Usenet, but given the current
proliferation of people who think that Usenet is just a web forum
invented by Google and don't quote at all, I guess unattributed quotes
are better than none...
In article
<mailman.102.1149558814....@maillists.riverviewtech.net>
Grant Taylor <gta...@riverviewtech.net> writes:
>> Do you have some reference for that?
>
>Not that I can site at the moment. All I can say is that I recall
>multiple sources saying that you should not modify / work / move /
>delete with files in the queue directory b/c it could mess with
>Sendmail.
This is true, of course.
> The sources mention qtool.pl as one way to work with the
>queue because it does know how to lock files the way that Sendmail does
>to prevent conflicts.
And you concluded that sendmail doesn't know how to lock files the way
that sendmail does?:-)
>That being said it may be possible for multiple Sendmail daemons / queue
>runners to work with in the same mail queue seeing as how they should
>know how to lock the file the same way that qtool.pl does.
There's no "may" about the queue runners or the processes forked by the
main daemon to serve the individual connection, it most definitely
works, and must work. The only issue that running multiple "main"
daemons adds is the *creation* of *new* files in the queue by processes
that don't have a common sendmail ancestor. But as far as I know the
"main" daemon doesn't play any role in the creation of those files
(e.g. it doesn't hand out the unique queue ID that the name is based on
or somesuch), so it should be quite irrelevant whether the
per-connection processes (which do create the files) have a common
"main" daemon as ancestor or not.
--Per Hedeland
p...@hedeland.org
Taylor, Grant
> standards, i.e. have a valid References: header to allow them to be
> properly threaded? It is possible even when using a news<->mail gateway,
> provided the gateway SW and MUA used is clueful enough.
I'll work on my NNTP <-> SMTP gateway as it may indeed be having some problems. However if you are referencing your "In article..." lines below, I am far from the only person not posting them. In a quick look back I only see about 1/3 of the posts have that. I'm not saying that they should not be there, I'm just saying that I'm not the only one not putting them.
>> In article
>> <mailman.102.1149558814....@maillists.riverviewtech.net>
>> Grant Taylor <gta...@riverviewtech.net> writes:
> Attribution of quotes is also the norm on Usenet, but given the current
> proliferation of people who think that Usenet is just a web forum
> invented by Google and don't quote at all, I guess unattributed quotes
> are better than none...
In my opinion your statement "...given the current proliferation of people who think that Usenet is just a web forum invented by Google..." is extremely presumptuous. I know many a person that does use NNTP and they all know that it is much more than just something from Google. Many of whom know that Google provided a convenient interface to access said NNTP service.
Here's a thought. Rather than complaining to the "Lay People / Users" complain to the people that would be responsible to correct the problems that you are complaining about. I.e. if you do not like the way that Google posts news, complain to Google to have them fix their interface.
>> The sources mention qtool.pl as one way to work with the
>> queue because it does know how to lock files the way that Sendmail does
>> to prevent conflicts.
>
> And you concluded that sendmail doesn't know how to lock files the way
> that sendmail does?:-)
No, I did not "...conclude..." any thing. I simply errored on the side of caution as well as stating that I was not sure. I was simply giving a heads up on a potential caveat so someone else would be aware of what they might be doing while wielding a sword.
> There's no "may" about the queue runners or the processes forked by the
> main daemon to serve the individual connection, it most definitely
> works, and must work. The only issue that running multiple "main"
> daemons adds is the *creation* of *new* files in the queue by processes
> that don't have a common sendmail ancestor. But as far as I know the
> "main" daemon doesn't play any role in the creation of those files
> (e.g. it doesn't hand out the unique queue ID that the name is based on
> or somesuch), so it should be quite irrelevant whether the
> per-connection processes (which do create the files) have a common
> "main" daemon as ancestor or not.
The understanding that I had was not so much having to do with the creation of new queue files, but rather making sure that multiple queue runners did not try to process the same queue file at the same time. A second issue that I had understood could be a potential problem was the possibility of each Sendmail daemon maintaining a state of the mail queue in memory. If this was indeed the case (which you seem to indicate is not a problem) then there could be potential problems with the in memory state of the daemons missing files or having files in memory that are no longer on disk. Before you ask, no I do not have any documentation or evidence to this fact. I simply have my experience working with similar products in the computer industry. Most of which do not play well with *ANY* thing else working in the queue directory. Further I have seen no documentation that states what is and is not safe to do with the queue directory short of having the single daemon and it's for
ked children process it for you.
Grant. . . .
Per Hedeland
<gta...@riverviewtech.net> writes:
>> Aside: Perhaps you could try to make your followups follow the Usenet
>> standards, i.e. have a valid References: header to allow them to be
>> properly threaded? It is possible even when using a news<->mail gateway,
>> provided the gateway SW and MUA used is clueful enough.
>
>I'll work on my NNTP <-> SMTP gateway as it may indeed be having some
>problems. However if you are referencing your "In article..." lines
>below,
No, the text "a valid References: header" refers to the References:
header... See RFC 1036.
> I am far from the only person not posting them. In a quick look
>back I only see about 1/3 of the posts have that. I'm not saying that
>they should not be there, I'm just saying that I'm not the only one not
>putting them.
There's no need to have the full "In article ..." etc etc stuff that my
newsreader happens to produce, "<Name> wrote:" is fine, the purpose is
just to be able to figure out who said what - which of course is extra
hard when neither attribution nor References: header is present. I don't
know which articles you looked at, but scanning some 100 articles in
this group, the only followups with unattributed quotes that I found
were yours.
>>> In article
>>> <mailman.102.1149558814....@maillists.riverviewtech.net>
>>> Grant Taylor <gta...@riverviewtech.net> writes:
>
>> Attribution of quotes is also the norm on Usenet, but given the current
>> proliferation of people who think that Usenet is just a web forum
>> invented by Google and don't quote at all, I guess unattributed quotes
>> are better than none...
>
>In my opinion your statement "...given the current proliferation of
>people who think that Usenet is just a web forum invented by Google..."
>is extremely presumptuous. I know many a person that does use NNTP and
>they all know that it is much more than just something from Google.
>Many of whom know that Google provided a convenient interface to access
>said NNTP service.
Which of course doesn't contradict the easily observable fact that there
is a lot of people posting from Google without understanding the
mechanisms and conventions of Usenet - no need to presume anything about
that. There are even people putting up web pages to try to remedy the
situation, see e.g. http://cfaj.freeshell.org/google/ . In the little
scan I did, I found many followups that totally lacked quoting - without
exception they were posted from Google.
>Here's a thought. Rather than complaining to the "Lay People / Users"
>complain to the people that would be responsible to correct the problems
>that you are complaining about. I.e. if you do not like the way that
>Google posts news, complain to Google to have them fix their interface.
But I have, long ago, using the handy link on the above page. And Google
doesn't *prevent* people from posting the right way, it just doesn't
make it the default. And "complaining" or not, as long as Google has the
interface it has, it's actually useful for those that use it for posting
to be aware of the issue, to avoid having their followups met with "What
are you talking about?" if not totally ignored. Btw, followups from
Google do have perfect References: header, which at least makes it
possible to find the post that is followed-up to, given a good quality
newsfeed and a capable newsreader.
>No, I did not "...conclude..." any thing. I simply errored on the side
>of caution as well as stating that I was not sure. I was simply giving
>a heads up on a potential caveat so someone else would be aware of what
>they might be doing while wielding a sword.
Not that it matters, but I can't really agree with that description,
since in this thread you were the one that first brought up the idea of
running multiple instances of sendmail, and immediately followed it with
"I'd make sure that each was using a different queue".
>> There's no "may" about the queue runners or the processes forked by the
>> main daemon to serve the individual connection, it most definitely
>> works, and must work. The only issue that running multiple "main"
>> daemons adds is the *creation* of *new* files in the queue by processes
>> that don't have a common sendmail ancestor. But as far as I know the
>> "main" daemon doesn't play any role in the creation of those files
>> (e.g. it doesn't hand out the unique queue ID that the name is based on
>> or somesuch), so it should be quite irrelevant whether the
>> per-connection processes (which do create the files) have a common
>> "main" daemon as ancestor or not.
>
>The understanding that I had was not so much having to do with the
>creation of new queue files,
No, but as I explained to you in the text above, this is the *only*
thing that is different when running multiple instances.
> but rather making sure that multiple queue
>runners did not try to process the same queue file at the same time.
This is of course not a problem, as I have been trying to explain for a
while now, with examples of how it must be handled even if *not* running
multiple instances. Sendmail will not make a mess of the queue just
because you fire up a couple of 'sendmail -q &' when you think the
forked queue runner (which need not be singular either) is doing its job
too slowly.
--Per Hedeland
p...@hedeland.org
Taylor, Grant
> No, the text "a valid References: header" refers to the References:
> header... See RFC 1036.
Thank you for the RFC to refer to. I will do some reading and then start hacking on my NNTP <-> SMTP gateway.
> There's no need to have the full "In article ..." etc etc stuff that my
> newsreader happens to produce, "<Name> wrote:" is fine, the purpose is
> just to be able to figure out who said what - which of course is extra
> hard when neither attribution nor References: header is present. I don't
> know which articles you looked at, but scanning some 100 articles in
> this group, the only followups with unattributed quotes that I found
> were yours.
Hmm. Now that I'm aware of what you are talking about, this seems to be a difference of opinion / environment. The majority of my communications is via mailing lists, hence why I'm doing most of this via SMTP -> NNTP gateway. On the mailing lists that I'm on, people are able to deduce from message thread structure who wrote what, thus we do not put "<who> said:". Now you are saying that my news messages do not maintain the References header for news readers to recreate said structure. Seeing as how I'm in the NNTP world for this I'll try to get my gateway to conform better. In the mean time I'll work around it by reading in one world and posting in the other.
>> No, I did not "...conclude..." any thing. I simply errored on the side
>> of caution as well as stating that I was not sure. I was simply giving
>> a heads up on a potential caveat so someone else would be aware of what
>> they might be doing while wielding a sword.
>
> Not that it matters, but I can't really agree with that description,
> since in this thread you were the one that first brought up the idea of
> running multiple instances of sendmail, and immediately followed it with
> "I'd make sure that each was using a different queue".
Not having a solution for the OP but rather something to try I was stating things that I would look out for while trying said proposed solution that could be a problem and easily resolved.
> This is of course not a problem, as I have been trying to explain for a
> while now, with examples of how it must be handled even if *not* running
> multiple instances. Sendmail will not make a mess of the queue just
> because you fire up a couple of 'sendmail -q &' when you think the
> forked queue runner (which need not be singular either) is doing its job
> too slowly.
I am not and have not been arguing with your explanation, but rather simply stating what my understanding was at the time. You seem to have a better understanding of how the queue runners / daemon interface with each other and the queue files than I do. Like before by stating that I did not know for sure I was and am deferring judgment to someone else with more information than my self.
Grant. . . .