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

Problem with "Try_TLS:send.smtp.com NO"

64 views
Skip to first unread message

Jobst Schmalenbach

unread,
Feb 2, 2022, 9:14:25 PM2/2/22
to
Hi

Using smtp.com as SMART_HOST as the /16 network I am on is too often found on UCEPROTECT and some of our clients/suppliers use the blacklist.

Sending is working, not problem at all.
However I get the following error:

ruleset=try_tls, arg1=send.smtp.com, relay=send.smtp.com, reject=550 5.7.1 <EM...@DOMAIN.COM>... do not try TLS with send.smtp.com [192.40.165.68]

Documentation of smtp.com states to include
Try_TLS:send.smtp.com NO
Try_TLS:192.40.165.68 NO
in /etc/mail/access, which I did.

Yet, still, I get this error!

Here are some of the important settings:
in access
Try_TLS:send.smtp.com NO

in sendmail.mc
FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')

I have recreated all db/cf files and restarted sendmail.

Any ideas anyone?

Claus Aßmann

unread,
Feb 3, 2022, 12:52:03 AM2/3/22
to
Jobst Schmalenbach wrote:

> However I get the following error:

> ruleset=try_tls, arg1=send.smtp.com, relay=send.smtp.com, reject=550 5.7.1
> <EM...@DOMAIN.COM>... do not try TLS with send.smtp.com [192.40.165.68]

It's confusing, but it's not an "error" -- it's just how
the results of a ruleset is currently logged.

The mail is being sent, right?

BTW: why are you supposed to turn off STARTTLS?
Is there a bug at smtp.com?

> FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')

Do NOT use -o, and the rest if default so just use:
FEATURE(`access_db')

--
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.

Jobst Schmalenbach

unread,
Feb 3, 2022, 7:29:33 AM2/3/22
to
On Thursday, 3 February 2022 at 16:52:03 UTC+11, Claus Aßmann wrote:
> Jobst Schmalenbach wrote:
> It's confusing, but it's not an "error" -- it's just how
> the results of a ruleset is currently logged.

OK, I understand now!
Thanks for the clarification.

>
> The mail is being sent, right?
>

Yes it is.

> BTW: why are you supposed to turn off STARTTLS?
> Is there a bug at smtp.com?

Nah, not really. You can send to their 465 port, but you can also send to 25 and 2525.
If you send to 25/2525 they ask you to turn off TLS

> > FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')
> Do NOT use -o, and the rest if default so just use:
> FEATURE(`access_db')

OK, done.

Marco Moock

unread,
Feb 3, 2022, 7:59:23 AM2/3/22
to
Am Donnerstag, 03. Februar 2022, um 04:29:32 Uhr schrieb Jobst
Schmalenbach:

> On Thursday, 3 February 2022 at 16:52:03 UTC+11, Claus Aßmann wrote:
> > Jobst Schmalenbach wrote:
> > It's confusing, but it's not an "error" -- it's just how
> > the results of a ruleset is currently logged.
>
> OK, I understand now!
> Thanks for the clarification.
>
> >
> > The mail is being sent, right?
> >
>
> Yes it is.
>
> > BTW: why are you supposed to turn off STARTTLS?
> > Is there a bug at smtp.com?
>
> Nah, not really. You can send to their 465 port, but you can also
> send to 25 and 2525. If you send to 25/2525 they ask you to turn off
> TLS

But why do they offer TLS over port 465, but don't want that
people use port 25 with STARTTLS?
I also read that GMail doesn't want that MTAs use STARTTLS due to
performance reasons.

0 new messages