Error messages from try_tls ruleset

Is there any way to prevent the logging of the "reject=550 5.7.1
<...>... do not try TLS with ..." error message that results from
having STARTTLS blocked in the /etc/mail/access file, or is this just
an unavoidable side effect of the way the try_tls ruleset operates?

I am running CentOS 5 (RHEL5 clone), which provides sendmail 8.13.8.

Background:

I connect to a Comcast smart host via an SSL tunnel to port 465 because
that is the only connection Comcast allows from outside the Comcast
network. (Port 587 is not an option. Comcast disallows connections
from outside its network to that port "for security reasons.")
Unfortunately, the Comcast server advertises STARTTLS capability even
though the connection on its end is already secure. That secure
connection will hang when sendmail issues STARTTLS, so I have to block
that. I have everything working 100%, but my mail log gets cluttered by
a 550 error message from every connecton. Getting rid of that would be
nice.

In /etc/mail/sendmail.mc:
define(`RELAY_MAILER_ARGS',`TCP $h 465')dnl
define(`ESMTP_MAILER_ARGS',`TCP $h 465')dnl
define(`SMART_HOST', `[127.0.0.25]')dnl

In /etc/mail/access:
Try_TLS:127.0.0.25 NO

In stunnel.conf:
# Configuration file for stunnel to provide an SSL tunnel for sendmail
# to smtp.comcast.net port 465.
client = yes
pid=/var/run/mailtunnel.pid
[rev-smtps]
accept = 127.0.0.25:465
connect = smtp.comcast.net:465

--
Bob Nichols AT comcast.net I am "RNichols42"

Re: Error messages from try_tls ruleset

In article Robert Nichols
writes:
>Is there any way to prevent the logging of the "reject=550 5.7.1
><...>... do not try TLS with ..." error message that results from
>having STARTTLS blocked in the /etc/mail/access file, or is this just
>an unavoidable side effect of the way the try_tls ruleset operates?

You could define your own LOCAL_TRY_TLS ruleset that produced different
code(s) and/or message, but it has to return $#error, and so will be
logged with reject=.

A different take could be to use a mailer that included the '2' flag for
this destination:

2 Don't use ESMTP even if offered; this is useful
for broken systems that offer ESMTP but fail on
EHLO (without recovering when HELO is tried next).

Without ESMTP, there can be no STARTTLS - but of course you may care
about other ESMTP functionality that you lose this way.

Finally, you could disable client STARTTLS altogether, by using M=S for
ClientPortOptions (CLIENT_OPTIONS() in the .mc):

S don't use STARTTLS when sending e-mail

- that's maybe the best option, since you seem to send all non-local
mail to that destination anyway:

>In /etc/mail/sendmail.mc:
> define(`RELAY_MAILER_ARGS',`TCP $h 465')dnl
> define(`ESMTP_MAILER_ARGS',`TCP $h 465')dnl
> define(`SMART_HOST', `[127.0.0.25]')dnl

--Per Hedeland
per@hedeland.org

Re: Error messages from try_tls ruleset

In article , Per Hedeland wrote:
:In article Robert Nichols
: writes:
:>Is there any way to prevent the logging of the "reject=550 5.7.1
:><...>... do not try TLS with ..." error message that results from
:>having STARTTLS blocked in the /etc/mail/access file, or is this just
:>an unavoidable side effect of the way the try_tls ruleset operates?
:
:You could define your own LOCAL_TRY_TLS ruleset that produced different
:code(s) and/or message, but it has to return $#error, and so will be
:logged with reject=.
:
:A different take could be to use a mailer that included the '2' flag for
:this destination:
:
: 2 Don't use ESMTP even if offered; this is useful
: for broken systems that offer ESMTP but fail on
: EHLO (without recovering when HELO is tried next).
:
:Without ESMTP, there can be no STARTTLS - but of course you may care
:about other ESMTP functionality that you lose this way.
:
:Finally, you could disable client STARTTLS altogether, by using M=S for
:ClientPortOptions (CLIENT_OPTIONS() in the .mc):
:
: S don't use STARTTLS when sending e-mail
:
:- that's maybe the best option, since you seem to send all non-local
:mail to that destination anyway:

Thanks much for the suggestions. Looks like either of those last two
should work for me.

--
Bob Nichols AT comcast.net I am "RNichols42"