SSL+OE works, SSL+(Outlook or Netscape) failed
Uri Shkolnik
9 (kernel 2.4.20 x86 machine).
I have wired problem...
Sendmail is receiving mail both on clear via SMTP port 25 and encrypt via
SMTPS port 465, both were configured from sendmail.mc:
DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
I also configured stunnel to bind port 466 (as "accept") to 25 (as
"connect") in order to have a secondary encrypted port for testing the
problem (which is explained below)
The Problem:
All tested email clients (Outlook Express v6, Mozilla v1.6, Netscape v7.1
and Outlook v2002) use the clear channel (on port 25) to send emails
smoothly.
But.
Only Outlook Express succeeds to send encrypted emails on ports 465 and 466.
Any ideas???
Ken Murchison
Netscape/Mozilla don't do SMTP over SSL (smtps), they use the STARTTLS
command within SMTP. The Outlook clients can do STARTTLS on port 25,
but as soon as you switch to a different port, they only do smtps. I
combat/support all of the different flavors, I use the following config:
DAEMON_OPTIONS(`Name=MTA, M=AS')dnl # Disable AUTH & TLS on MTA
DAEMON_OPTIONS(`Port=587, Name=MSA, M=E')dnl # MSA
DAEMON_OPTIONS(`Port=465, Name=SSA, M=Es')dnl # SSL MSA
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
Uri Shkolnik
SMTPS port 465, both were configured from sendmail.mc:
DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
I also configured stunnel to bind port 466 (as "accept") to 25 (as
"connect") in order to have a secondary encrypted port for testing the
problem (which is explained below)
The Problem:
-------------
All tested email clients (Outlook Express v6, Mozilla v1.6, Netscape v7.1
and Outlook v2002) use the clear channel (on port 25) to send emails
smoothly.
But-
Only Outlook Express succeeds to send encrypted emails on ports 465 and 466.
Any ideas???
Uri
FYI - I'm running Sendmail v8.12.8, cyrus-sasl-2.1.10 and OpenSSL 0.9.7 on
Alexander Dalloz
Why don't you read and respect the answer you got a few days ago in MsgID
<cmu-nntpd-677...@eagle.oceana.com>? You asked the same
question! So why a new thread with same question?
Alexander
--
Alexander Dalloz | Enger, Germany
PGP key valid: made 13.07.1999
PGP fingerprint: 2307 88FD 2D41 038E 7416 14CD E197 6E88 ED69 5653
Jennifer Knoell
> Uri Shkolnik wrote:
>
>> I'm running Sendmail v8.12.8, cyrus-sasl-2.1.10 and OpenSSL 0.9.7 on
>> RedHat 9 (kernel 2.4.20 x86 machine).
>>
>>
>> Sendmail is receiving mail both on clear via SMTP port 25 and
>> encrypt via SMTPS port 465, both were configured from sendmail.mc:
>>
>> DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl
>> DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl
>>
>
> command within SMTP. The Outlook clients can do STARTTLS on port 25,
> but as soon as you switch to a different port, they only do smtps. I
> combat/support all of the different flavors, I use the following
> config:
>
> DAEMON_OPTIONS(`Name=MTA, M=AS')dnl # Disable AUTH & TLS
> on MTA DAEMON_OPTIONS(`Port=587, Name=MSA, M=E')dnl # MSA
> DAEMON_OPTIONS(`Port=465, Name=SSA, M=Es')dnl # SSL MSA
I am struggling with the same problem I think, so I'll just attach to this
tread instead of opening a new one. But so far, none of the solutions do the
trick for me. I've got mostly Outlook clients here in the office, so these
are the only concern. What I want to achieve is that clients all use port
465 (some are roaming on unsecured networks) and SMTP AUTH simultaneously.
Everything works fine on port 25. But not on port 465. The configs I've
tried are:
DAEMON_OPTIONS(`Port=465, Name=SSLMTA')dnl
DAEMON_OPTIONS(`Port=465, Name=SSLMTA, M=Es')dnl
DAEMON_OPTIONS(`Port=465, Name=SSLMTA, M=s')dnl
As long as I use stunnel for just forwarding port 465 to 25 everything
works - except that this solution opens smtps to spammers. Sendmail thinks
at this point that the connection comes from localhost, and accepts
submissions unconditionally.
The error I get from sendmail indicates that Outlook just starts with SSL -
and I have no idea how to tell sendmail to just assume SSL:
Feb 4 13:10:39 vmlinux sm-mta[10195]: i14KAdpK010195: [10.0.0.111] did not
issue MAIL/EXPN/VRFY/ETRN during connection to SSLMTA
I'm sure I am missing something, but what?
Thanks
Jennifer
Rabellino Sergio
O DaemonPortOptions=Port=25,Name=MTA
O DaemonPortOptions=Port=587,Name=MSA,M=au
O DaemonPortOptions=Port=465,Name=SSA,M=EsSau
Bye.
Jennifer Knoell
> Jennifer Knoell wrote:
>> DAEMON_OPTIONS(`Port=465, Name=SSLMTA')dnl
>> DAEMON_OPTIONS(`Port=465, Name=SSLMTA, M=Es')dnl
>> DAEMON_OPTIONS(`Port=465, Name=SSLMTA, M=s')dnl
>
> Now I'm using these settings and all things are fine.
>
> O DaemonPortOptions=Port=25,Name=MTA
> O DaemonPortOptions=Port=587,Name=MSA,M=au
> O DaemonPortOptions=Port=465,Name=SSA,M=EsSau
So you can connect with _Outlook_ to port 465 using SSL and it works...?
Because for me it still doesn't :(
Whenever I try and set Outlook to port 465 _and_ SSL, I get this in the
sendmail logs:
Feb 5 12:29:29 vmlinux sm-mta[15312]: i15JTTiW015312: [10.0.0.111] did
not issue MAIL/EXPN/VRFY/ETRN during connection to SSLMTA
And Outlook says:
The TCP/IP connection was unexpectedly terminated by the server. (Account:
'mail.inet', SMTP Server: 'vmlinux.inet', Error Number: 0x800ccc0f).
I suspect that Outlook needs SSL started automatically? Is there any
documentation for these M= flags anywhere?
Thank you very much
Jennifer
Per Hedeland
<pan.2004.02.05....@doesnt.want.spam.ing.twinwave.net>
Jennifer Knoell <jenn...@doesnt.want.spam.ing.twinwave.net> writes:
>On Thu, 05 Feb 2004 15:49:40 +0100, Rabellino Sergio wrote:
>
>> Jennifer Knoell wrote:
>>> DAEMON_OPTIONS(`Port=465, Name=SSLMTA')dnl
>>> DAEMON_OPTIONS(`Port=465, Name=SSLMTA, M=Es')dnl
>>> DAEMON_OPTIONS(`Port=465, Name=SSLMTA, M=s')dnl
>>
>> Now I'm using these settings and all things are fine.
>>
>> O DaemonPortOptions=Port=25,Name=MTA
>> O DaemonPortOptions=Port=587,Name=MSA,M=au
>> O DaemonPortOptions=Port=465,Name=SSA,M=EsSau
>
>So you can connect with _Outlook_ to port 465 using SSL and it works...?
>Because for me it still doesn't :(
>
>Whenever I try and set Outlook to port 465 _and_ SSL, I get this in the
>sendmail logs:
>Feb 5 12:29:29 vmlinux sm-mta[15312]: i15JTTiW015312: [10.0.0.111] did
>not issue MAIL/EXPN/VRFY/ETRN during connection to SSLMTA
Why are you meddling with SMTPS / port 465 at all? AFAIK all MUAs that
can do SSL at all implement the standard method, i.e. STARTTLS at port
25. Some may implement SMTPS too, and I believe one (don't remember
which) may run that automatically if you tell it to go to anything other
than port 25 - which just adds to the confusion.
About the only time you'd need SMTPS in sendmail is if you have a
totally SSL-incapable MUA and run client-side stunnel to get around that
(though I wouldn't be surprised if stunnel can do STARTTLS too
nowadays).
Furthermore, the SMTPS functionality in sendmail isn't even enabled by
default - you need to use a FFR define at compile time, which also
implies that it isn't necessarily well tested or even working at all.
>I suspect that Outlook needs SSL started automatically? Is there any
>documentation for these M= flags anywhere?
Yes, in doc/op/op.* - search for DaemonPortOptions. However the 's' flag
is undocumented on purpose due to the above.
Just use STARTTLS instead.
--Per Hedeland
p...@hedeland.org
Uri Shkolnik
Uri
"Jennifer Knoell" <jenn...@doesnt.want.spam.ing.twinwave.net> wrote in
message
news:pan.2004.02.05....@doesnt.want.spam.ing.twinwave.net...
Jennifer Knoell
> In article
> <pan.2004.02.05....@doesnt.want.spam.ing.twinwave.net>
> Jennifer Knoell <jenn...@doesnt.want.spam.ing.twinwave.net> writes:
> [...]
>>Whenever I try and set Outlook to port 465 _and_ SSL, I get this in the
>>sendmail logs:
>>Feb 5 12:29:29 vmlinux sm-mta[15312]: i15JTTiW015312: [10.0.0.111] did
>>not issue MAIL/EXPN/VRFY/ETRN during connection to SSLMTA
>
> Why are you meddling with SMTPS / port 465 at all? AFAIK all MUAs that
> can do SSL at all implement the standard method, i.e. STARTTLS at port
> 25. Some may implement SMTPS too, and I believe one (don't remember
> which) may run that automatically if you tell it to go to anything other
> than port 25 - which just adds to the confusion.
Two reasons actually.. first, some of our locations are connected via ISPs
that block port 25 (which I applaud), second, I want to keep company
internal mail encrypted because some people here send sensitive information
via email (which I don't applaud). So I force everyone to use SSL at this
time.
Eventually I'll switch to VPN, but at this time I don't have that option.
Anyway, looks like I'm back to the drawing board for a while :)
Thanks nonetheless for the wealth of information
Jennifer
Neil W Rickert
Hash: SHA1
p...@hedeland.org (Per Hedeland) writes:
>Why are you meddling with SMTPS / port 465 at all? AFAIK all MUAs that
>can do SSL at all implement the standard method, i.e. STARTTLS at port
>25. Some may implement SMTPS too, and I believe one (don't remember
>which) may run that automatically if you tell it to go to anything other
>than port 25 - which just adds to the confusion.
Regrettably, that's incorrect.
Outlook express can do STARTTLS over port 25. But if you specify any
other port (such as 587), then it will only attempt direct SSL. In
practice, this means that if an OE user wants to use SSL to your
server, and his ISP blocks port 25, then he will need to use port 465
(or at least will need to support smtps).
I'm not sure about Outlook -- I seem to recall that it wanted to use
direct SSL even on port 25. In any case, I abandoned attempts at
testing it, when it refused to authenticate. It apparently only
understands the microsoft proprietary version of authentication. At
least OE can authenticate in a semi-compatible manner.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (SunOS)
iD8DBQFAJ8UTvmGe70vHPUMRAi8YAJ9Zxk+//N9MrhZRuu01y2E53Bw4rgCg/NeQ
k34UD9TfmInni7FHbk/kIQI=
=Bv6B
-----END PGP SIGNATURE-----
Per Hedeland
<jenn...@doesnt.want.spam.ing.twinwave.net> writes:
>Per Hedeland wrote:
>
>> In article
>> <pan.2004.02.05....@doesnt.want.spam.ing.twinwave.net>
>> Jennifer Knoell <jenn...@doesnt.want.spam.ing.twinwave.net> writes:
>> [...]
>>>Whenever I try and set Outlook to port 465 _and_ SSL, I get this in the
>>>sendmail logs:
>>>Feb 5 12:29:29 vmlinux sm-mta[15312]: i15JTTiW015312: [10.0.0.111] did
>>>not issue MAIL/EXPN/VRFY/ETRN during connection to SSLMTA
>>
>> Why are you meddling with SMTPS / port 465 at all? AFAIK all MUAs that
>> can do SSL at all implement the standard method, i.e. STARTTLS at port
>> 25. Some may implement SMTPS too, and I believe one (don't remember
>> which) may run that automatically if you tell it to go to anything other
>> than port 25 - which just adds to the confusion.
>
>Two reasons actually.. first, some of our locations are connected via ISPs
>that block port 25 (which I applaud), second, I want to keep company
>internal mail encrypted because some people here send sensitive information
>via email (which I don't applaud). So I force everyone to use SSL at this
>time.
OK, I see - I think you'll need two non-25 ports to cover all of that,
one where you run SMTPS (i.e. 465 makes the most sense) for those/the
MUA that insists on doing that for SSL on a non-standard port, and one
where you don't just offer but *require* STARTTLS (e.g. 587). You
obviously can't require MUAs to do SMTPS.
Now, there is no "sendmail option setting" to require STARTTLS, so you'd
have to do that with some custom rules - I believe it should be possible
to do it within Local_check_mail, e.g. check that $&{verify} isn't NONE,
and if it is give a 5xx code. You might want to do the check only for
the MTA listening on the STARTTLS-requiring port (i.e. check
$&{daemon_name} or $&{daemon_port}), but if *all* connections to this
sendmail should be SSL you may not need to.
And you will have to tell users to use different ports depending on what
MUA they use.
--Per Hedeland
p...@hedeland.org
Per Hedeland
<ricke...@cs.niu.edu> writes:
>
>p...@hedeland.org (Per Hedeland) writes:
>
>>Why are you meddling with SMTPS / port 465 at all? AFAIK all MUAs that
>>can do SSL at all implement the standard method, i.e. STARTTLS at port
>>25. Some may implement SMTPS too, and I believe one (don't remember
>>which) may run that automatically if you tell it to go to anything other
>>than port 25 - which just adds to the confusion.
>
>Regrettably, that's incorrect.
>
>Outlook express can do STARTTLS over port 25. But if you specify any
>other port (such as 587), then it will only attempt direct SSL.
Hm, I think that's what I said I believed:-) - though I didn't know that
it was Outlook, far less what model of it.
> In
>practice, this means that if an OE user wants to use SSL to your
>server, and his ISP blocks port 25, then he will need to use port 465
>(or at least will need to support smtps).
Yep, I hadn't realized that there was a requirement to use a different
port than 25 (regardless of the SSL issue).
--Per Hedeland
p...@hedeland.org
Claus Aßmann
> Now, there is no "sendmail option setting" to require STARTTLS, so you'd
> have to do that with some custom rules - I believe it should be possible
Something like:
TLS_Clt: ENCR:112
should do the trick (unless I misunderstand the problem...)
--
A: Maybe because some people are too annoyed by top-posting.
Q: Why do I not get an answer to my question(s)?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Rich Graves
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> p...@hedeland.org (Per Hedeland) writes:
>
>>Why are you meddling with SMTPS / port 465 at all? AFAIK all MUAs that
>>can do SSL at all implement the standard method, i.e. STARTTLS at port
>>25. Some may implement SMTPS too, and I believe one (don't remember
>>which) may run that automatically if you tell it to go to anything other
>>than port 25 - which just adds to the confusion.
As OP pointed out, alternate ports are required to get around ISPs that
restrict outgoing port 25.
> Outlook express can do STARTTLS over port 25. But if you specify any
> other port (such as 587), then it will only attempt direct SSL. In
> practice, this means that if an OE user wants to use SSL to your
> server, and his ISP blocks port 25, then he will need to use port 465
Correct.
This behavior is somewhat broken, but to be fair, the first implementation
of SMTP over SSL in OE (and Netscape 4.x) predated the STARTTLS standard.
Suddenly changing the meaning of existing configuration settings would
have been Bad.
The best answer is Eudora's -- you can set the port and the SSL popup
is trinary cleartext, STARTTLS, SSL. Eudora could do this because they
were the *last* major email client to implement SSL/TLS (though they had
supported Kerberos for a long time).
> I'm not sure about Outlook -- I seem to recall that it wanted to use
> direct SSL even on port 25. In any case, I abandoned attempts at
> testing it, when it refused to authenticate. It apparently only
> understands the microsoft proprietary version of authentication. At
> least OE can authenticate in a semi-compatible manner.
We have many users on Outlook. Like OE it requires SSLMTA over port 465
and only supports AUTH LOGIN, not PLAIN.
Other annoying problems to be aware of:
If MacOS X Mail is configured to support SMTP AUTH, it will refuse to send
mail through a server that does not require authentication (no AUTH in
EHLO). Workaround: Make sure you always require authentication on 587.
But to avoid unneccessarily annoying local and pop-before-smtp users, we
do not offer AUTH on port 25 unless accessdb/popauth shows we would need
to.
Our end-user documentation is http://mail.brandeis.edu/ and a recent
sendmail.mc is on http://web.brandeis.edu/pages/view/Network/EmailArchitecture
Note that our default advice is "Due to the complexity of these issues,
most off-campus users are advised to use http://webmail.brandeis.edu/ or
Pine, and not worry about this at all."
Per Hedeland
=?iso-8859-1?Q?A=DFmann?=
<ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> writes:
>Per Hedeland wrote:
>
>> Now, there is no "sendmail option setting" to require STARTTLS, so you'd
>> have to do that with some custom rules - I believe it should be possible
>
>Something like:
>
>TLS_Clt: ENCR:112
>
>should do the trick (unless I misunderstand the problem...)
Hm, but it will not catch the case where the MUA simply doesn't do the
STARTTLS at all, will it? It might be needed in *addition* though -
could it be the case that STARTTLS is issued but due to failure in the
handshake we end up with no encryption? I would hope not, but...
--Per Hedeland
p...@hedeland.org
David Stern
had Refuse_LA set to 5 and Queue_LA set to 4 (it's a tiny U10)
During a mailstorm, it protected itself somewhat ie it did refuse
connections and I could login from the console but not st I could
do any work. Clearly, I need to tune down these numbers.
Would it be of any help to also add in Delay_LA? I presume it should
be a number between queueLA and refuseLA, right? Or would it be a better
practise to replace refuse_la with delay_la?
Thanks
Claus Aßmann
> In article <c097fi$p79$1...@zardoc.esmtp.org> Claus Aßmann
> >Per Hedeland wrote:
> >> Now, there is no "sendmail option setting" to require STARTTLS, so you'd
> >> have to do that with some custom rules - I believe it should be possible
> >Something like:
> >TLS_Clt: ENCR:112
> >should do the trick (unless I misunderstand the problem...)
> Hm, but it will not catch the case where the MUA simply doesn't do the
> STARTTLS at all, will it? It might be needed in *addition* though -
It will. cf/README:
tls_client is called when sendmail acts as server, after a STARTTLS command
has been issued, and from check_mail. The parameter is the value of
${verify} and STARTTLS or MAIL, respectively.
Since it is also called from check_mail it will reject the MAIL
command if STARTTLS isn't active.
> could it be the case that STARTTLS is issued but due to failure in the
> handshake we end up with no encryption? I would hope not, but...
The access_db entry requires encryption.
Weldon Whipple
I'm not sure, but the load-average options *could* be one of those topics
that starts fights in bars.
Recently (when some servers were being hammered by MyDoom), I found that
the following worked quite well (after some experimentation)--on a
high-powered relay (through a virtusertable) server:
define(`confQUEUE_LA',`1000')dnl
define(`confDELAY_LA',`40')dnl
define(`confREFUSE_LA',`100')dnl
define(`confCONNECTION_RATE_THROTTLE',`3')dnl
Note that the queue LA setting is absurdly high--I never want the boxes to
queue (and risk becoming vegetables). These boxes actually behave quite
well up to a load average of about 80 or so (!!!). However, during a
serious DoS attack, the load average seemed to lag behind as an indicator
of the boxes' stress level.
After watching the boxes' load averages fluctuate wildly about two weeks
ago, I found that the connection rate throttle returned the servers to a
load average < 1 most of the time. (Also, surprisingly, any time I connect
to the server's ports 25 or 587, the response is immediate, so I don't
*think* starvation is occurring ...)
I am becoming of the opinion that no single set of LA options is right for
all servers. A lot depends on the mix of traffic, the size of the server,
... and administrator preferences ...
(Feel free to disagree ... anyone )
--
Weldon Whipple
wel...@whipple.org
Uri Shkolnik
I'm the person who the original post belong to....
I still don't understand why SSL-only (TLS) port is accessible by Outlook
Express but Netscape/Mozilla/Outlook are fail to access it
Uri
"Claus Aßmann" <ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de>
wrote in message news:c0auc7$2ic$1...@zardoc.esmtp.org...
Per Hedeland
=?iso-8859-1?Q?A=DFmann?=
<ca+sendmail(-no-copies-please)@mine.informatik.uni-kiel.de> writes:
>Per Hedeland wrote:
>> In article <c097fi$p79$1...@zardoc.esmtp.org> Claus Aßmann
>
>> >Per Hedeland wrote:
>
>> >> Now, there is no "sendmail option setting" to require STARTTLS, so you'd
>> >> have to do that with some custom rules - I believe it should be possible
>
>> >Something like:
>
>> >TLS_Clt: ENCR:112
>
>> >should do the trick (unless I misunderstand the problem...)
>
>> Hm, but it will not catch the case where the MUA simply doesn't do the
>> STARTTLS at all, will it? It might be needed in *addition* though -
>
>It will. cf/README:
>
>tls_client is called when sendmail acts as server, after a STARTTLS command
>has been issued, and from check_mail. The parameter is the value of
>${verify} and STARTTLS or MAIL, respectively.
Great, no custom rules needed then. (And sorry for not reading the docs
for once.:-)
--Per Hedeland
p...@hedeland.org
Per Hedeland
<uri...@yahoo.com> writes:
>
>I still don't understand why SSL-only (TLS) port is accessible by Outlook
>Express but Netscape/Mozilla/Outlook are fail to access it
At least regarding Netscape/Mozilla probably because they don't
implement the "SSL-only" a.k.a. SMTPS mechanism - they expect to use the
standard STARTTLS mechanism, where the session is initiated in cleartext
and switches to SSL/TLS when the client sends the STARTTLS ESMTP command
- see RFC 2487. In another branch of the thread, someone said that
Outlook (like Outlook Express) would do SMTPS if asked to do SSL on
another port than 25 - personally I wouldn't know.
--Per Hedeland
p...@hedeland.org
Nick Christenson
Weldon Whipple <wel...@whipple.org> wrote:
>
>On Tue, 10 Feb 2004, David Stern wrote:
>
>> I have a solaris sendmail host that was built with load averaging and
>> had Refuse_LA set to 5 and Queue_LA set to 4 (it's a tiny U10)
>> During a mailstorm, it protected itself somewhat ie it did refuse
>> connections and I could login from the console but not st I could
>> do any work. Clearly, I need to tune down these numbers.
So, this is basically a desktop machine that also does email? If
being a workstation is a priority, then the Refuse_LA number seems
roughly reasonable to me, although I'd still set Queue_LA to be much
higher than Refuse_LA -- I'd rather see the machine refuse mail than
queue and not deliver it.
Note, the corellation between load average and "real email server work"
on Solaris is generally pretty low, so this likely won't help you very much
no matter what you do.
>> Would it be of any help to also add in Delay_LA? I presume it should
>> be a number between queueLA and refuseLA, right? Or would it be a better
>> practise to replace refuse_la with delay_la?
I'd set Delay_LA to be lower than either Refuse_LA and Queue_LA
in your case. Maybe "4", "6", and "a billion" respectively, if I were to
set them at all.
>I'm not sure, but the load-average options *could* be one of those topics
>that starts fights in bars.
Nah. Whether or not an MTA should fork a copy for each recipient might
start a fight in a bar, but load-average stuff is your own problem. Do
what you want, the rest of us don't care.
>Recently (when some servers were being hammered by MyDoom), I found that
>the following worked quite well (after some experimentation)--on a
>high-powered relay (through a virtusertable) server:
>
>define(`confQUEUE_LA',`1000')dnl
>define(`confDELAY_LA',`40')dnl
>define(`confREFUSE_LA',`100')dnl
>define(`confCONNECTION_RATE_THROTTLE',`3')dnl
For some sorts of machines I could see these sorts of numbers, but
generally for dedicated mail servers, I say let it run as busy as it
can. It's usually better at allocating its own resources than you or I
would be.
These big numbers make me think you're running Linux and not Solaris,
right?
>Note that the queue LA setting is absurdly high--I never want the boxes to
>queue (and risk becoming vegetables).
Rightly so.
> These boxes actually behave quite
>well up to a load average of about 80 or so (!!!). However, during a
>serious DoS attack, the load average seemed to lag behind as an indicator
>of the boxes' stress level.
Yes, the load average is a lagging average (since it can't predict future
load) over time. Load average will lag current load.
>After watching the boxes' load averages fluctuate wildly about two weeks
>ago, I found that the connection rate throttle returned the servers to a
>load average < 1 most of the time.
This *may* not be a good thing! You very well may have been limiting the
amount of useful work the box could be doing! Now, if delivering mail
is a secondary priority, that's fine. If it's a mail server, this
might be a catastrophe.
Remember, a high load average is an indicator that the box is doing a
lot of work. Let it. It means there's a lot of work to be done.
> (Also, surprisingly, any time I connect
>to the server's ports 25 or 587, the response is immediate, so I don't
>*think* starvation is occurring ...)
Depends on where most of your email is coming from.
>I am becoming of the opinion that no single set of LA options is right for
>all servers. A lot depends on the mix of traffic, the size of the server,
>... and administrator preferences ...
This is true. It also strongly depends on the primary function of the
server. My best recommendation is that for machines for which email
is a secondary concern, set the values as high as possible for you to
continue to get useful work done. For mail servers my best recommendation
in all but pathological mail servers is to get out of the box's way and
let it run.
--
Nick Christenson
n...@jetcafe.org