Sendmail, smarthost, AUTH, port 587?

[Mike Spencer]

I'm back. Stunnel is working nicely for fetching mail via POP3 on
port 995. Now I have a new problem.

I need to contrive that sendmail, running on localhost, hands outgoing
mail to port 587 on a particular remote host using AUTH/STARTTLS.

Been using sendmail to smarthost for years, connecting to port 25 on my
own ISP's network where no auth is required. Now I need to connect to
the net with one ISP but smarthost mail through another so auth with
STARTTLS on port 587 is required.

I've found what appears to be adequate details for editing
sendmail.mc, constructing authinfo and creating authinfo.db. [1] But
nowhere is there any mention of directing sendmail to use port 587 on
the remote mail server.

Before I undertake tedious (possibly stupid) trial-and-error
experiments, maybe someone can tell me the quick and clean answer.

Applying suggestions from [1] to a currently working sendmail.mc [2],
the resulting sendmail.cf has lines:

# "Smart" relay host (may be null)
DSmail.example.ca

# authinfo list database: contains info for authentication as client
Kauthinfo hash -o /etc/mail/authinfo.db

# Mailer table (overriding domains)
Kmailertable hash /etc/mail/mailertable

RFC 4954 suggests that the authenticated SMTP negotiation will happen
automagically if both side support it but I can find no mention of how
to direct sendmail to reach out to port 587 on the remote server
instead of 25.

I have a few wild guesses on how to do this (see "stupid", above :-)
omitted here for the moment but Gwgle hasn't revealed that any of them
make any sense.



[1] https://www.linuxquestions.org/questions/showthread.php?postid=1144343#post1144343
Scroll down to "Client-Side SMTP AUTH + SMART_HOST"

[2]
# sendmail-trial.mc
#
divert(-1)
divert(0)dnl
VERSIONID(`$Id: generic-linux.mc,v 8.1 1999/09/24 22:48:05 gshapiro Exp $')
OSTYPE(`linux')dnl
DOMAIN(`generic')dnl
# Added from linuxq/auth update: SEE COMMENT BELOW
define(`SMART_HOST',`mail.tallships.ca')dnl
# Added from linuxq/auth update
FEATURE(`authinfo',`hash -o /etc/mail/authinfo.db')dnl
FEATURE(`mailertable', `hash /etc/mail/mailertable')dnl
FEATURE(always_add_domain)dnl
MAILER(local)dnl
MAILER(smtp)dnl



TIA,

[Grant Taylor]

+comp.mail.sendmail — For the unabridged version, see Mike's post to
alt.os.linux.slackware.

Post by Mike Spencer
I'm back. Stunnel is working nicely for fetching mail via POP3 on
port 995.

:-)

Post by Mike Spencer
Now I have a new problem.

:-(

Post by Mike Spencer
I need to contrive that sendmail, running on localhost, hands outgoing
mail to port 587 on a particular remote host using AUTH/STARTTLS.

:-)

Post by Mike Spencer
Been using sendmail to smarthost for years, connecting to port 25 on
my own ISP's network where no auth is required. Now I need to connect
to the net with one ISP but smarthost mail through another so auth
with STARTTLS on port 587 is required.

;-)

Post by Mike Spencer
I've found what appears to be adequate details for editing sendmail.mc,
constructing authinfo and creating authinfo.db. [1] But nowhere is
there any mention of directing sendmail to use port 587 on the remote
mail server.

}:-)

Post by Mike Spencer
Before I undertake tedious (possibly stupid) trial-and-error
experiments, maybe someone can tell me the quick and clean answer.

:-D

Post by Mike Spencer
Applying suggestions from [1] to a currently working sendmail.mc [2],
# "Smart" relay host (may be null)
DSmail.example.ca

:-)

Post by Mike Spencer
# authinfo list database: contains info for authentication as client
Kauthinfo hash -o /etc/mail/authinfo.db

:-)

Post by Mike Spencer
# Mailer table (overriding domains)
Kmailertable hash /etc/mail/mailertable

:-/

Post by Mike Spencer
RFC 4954 suggests that the authenticated SMTP negotiation will happen
automagically if both side support it

:-j

Post by Mike Spencer
but I can find no mention of how to direct sendmail to reach out to
port 587 on the remote server instead of 25.

:-D

Post by Mike Spencer
I have a few wild guesses on how to do this (see "stupid", above :-)
omitted here for the moment but Gwgle hasn't revealed that any of
them make any sense.

:-|

...

Okay, enough with the faces. I wouldn't have done them if I didn't have
a relatively simple answer for you. Especially for Sendmail.

First some comments, more than just faces.

I'm glad that you have POP3S working to your satisfaction.

Why are you using mailertable? Are you routing mail locally in addition
to offloading it to the smart host?

I'm not 100% sure that SMTP Authentication will be used
opportunistically. I believe that providing the authinfo causes
Sendmail to use it, presuming that the remote system offers SMTP
Authentication and that the local system has the proper credentials.

Aside: You can provide cart blanch credentials or per destination
credentials.

Now for the pièce de résistance

define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl

That's the crux of what you need. :-D

I have the following three lines in my sendmail.mc file:

define(`SMART_HOST', `REDACTED')dnl
define(`RELAY_MAILER', `esmtp')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl

This will cause Sendmail to configure the relay mailer (Mrelay) to
append 587 to the default argument `TCP $h'. Thus telling Sendmail that
the relay mailer should connect to destination port 587.

Aside: This will use standard (E)SMTP over port 587, which /should/
require the use of a secure channel — STARTTLS — to protect the
credentials. But, things can happen to break STARTTLS, or the remote
system could be misconfigured to not require the secure channel, or
worse, not offer STARTTLS.

I can't help if the remote system doesn't offer STARTTLS. But I can
help with downgrade attacks /if/ the remote system supports SMTPS,
a.k.a. submission, on TCP port 465.

Yes, it is possible to get Sendmail to be an SMTPS client.

I don't have nice MC file syntax. Here's the hacked relay mailer
definition I used to get this to work. (I've re-wrapped this to make it
display better.)

Mrelay,
P=/usr/bin/openssl,
F=mDFMuXa8,
S=EnvFromSMTP/HdrFromSMTP,
R=MasqSMTP,
E=\r\n,
L=2040,
T=DNS/RFC822/SMTP,
A=openssl s_client -host $h -port 465 -quiet

Here's the icing on the cake.

Mrelay,
...
A=openssl s_client -host $h -port 465 -quiet -cert
/etc/mail/tls/REDACTED.crt -key /etc/mail/tls/REDACTED.key

The -cert and -key options tell OpenSSL to present a /client/
certificate to the remote server. This means that if the remote server
is configured properly, the client can authenticate to the remote server
using a TLS certificate. You don't /need/ to use a username and
password. }:-D

I hope the answer was worth all the faces. ;-)

[Grant Taylor]

if the remote server is configured properly, the client can authenticate
to the remote server using a TLS certificate.

Here's how I have my main server, running Sendmail, configured to allow
client's to authenticate with a client TLS certificate.

Add the following entries to the access db, and re-build the map.

# Allow clients to authenticate and relay based on client TLS
certificates

CERTISSUER:/C=US/O=Let's+20Encrypt/CN=Let's+20Encrypt+20Authority+20X3
SUBJECT
CERTSUBJECT:/CN=REDACTED RELAY

The LHS of the CERTISSUER line matches the CA and the RHS tells Sendmail
what to look for. It could be RELAY, but that would allow anybody using
a Let's Encrypt certificate to relay through my server.

The LHS of the CERTSUBJECT line matches the subject of the client
certificate and the RHS tells Sendmail that this client can relay
through this server.

Note: The CERTISSUER and CERTSUBJECT lines are a union. If you have
multiple CERTISSUER lines that state SUBJECT, then the CERTSUBJECT lines
will be indifferent to the CERTISSUER. There's no direct association.

I have configured multiple servers to using client TLS certificates to
authenticate with each other. It works quite nicely. I really like the
idea of not needing to rely on per-client-system credentials.

[Mike Spencer]

+comp.mail.sendmail -- For the unabridged version, see Mike's
post to alt.os.linux.slackware.

Post by Mike Spencer
I'm back. Stunnel is working nicely for fetching mail via POP3 on
port 995.

:-)

Post by Mike Spencer
Now I have a new problem.

:-(

Yow! A clear and detailed reply in no time.

Too late, too much brain fog tonight, to deal w/ it. Cocoa & bed.
But tomorrow I'll get on it, tnx.

I can't help if the remote system doesn't offer STARTTLS. But I can
help with downgrade attacks /if/ the remote system supports SMTPS,
a.k.a. submission, on TCP port 465.

The admin of the remote system has been very helpful for many years in
the past and wrote clearly that they supported "outgoing: SMTP, port
587, STARTTLS". If that proves to be an error, I'm sure he'll be
penitent and responsive.

More later and TYVM,

[Mike Spencer]

Post by Grant Taylor

Post by Mike Spencer
I'm back. Stunnel is working nicely for fetching mail via POP3 on
port 995.

:-)

Post by Mike Spencer
Now I have a new problem.

:-(

Post by Mike Spencer
I need to contrive that sendmail, running on localhost, hands outgoing
mail to port 587 on a particular remote host using AUTH/STARTTLS.

First some comments, more than just faces.
I'm glad that you have POP3S working to your satisfaction.

Me too. I got short notice of the mandatory change and was in a bit
if a panic. Still don't have the "delay" option working as expected
but I can read my mail.

Post by Grant Taylor
Why are you using mailertable?

I don't remember how I got to that 20 years ago when I first started
using Slackware on dialup.

Since then, I've maintained 2 sets of (sendmail.cf, mailertable.db) in
a hidden dir. Dialing in to one of two ISPs automatically swapped in
the matching pair and created an empty /etc/mail/flag$ISP file.
Everything worked without restarting sendmail after a swap. That was
with Slackware 8, 10, 11 & 14.1. Now using Slackware 14.2. sendmail
8.15.

Post by Grant Taylor
Are you routing mail locally in addition to offloading it to the
smart host?

Only local mail is that the system (? or something) very occasionally
sends mail to root that seems to end up in
/var/spool/mail/root. Otherwise, no. Of course, I don't want those
system mssgs to root routed through the smarthost & net.

Post by Grant Taylor
Now for the piece de resistance
define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl
That's the crux of what you need. :-D
define(`SMART_HOST', `REDACTED')dnl
define(`RELAY_MAILER', `esmtp')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl

Okayyyyy. That gives me key words to look up in the Bat Book. [1]
"BB" hereinafter.

Hunting up key words (above, RELAY_MAILER_ARG etc.) it appears that
FEATURE(smarthost) and FEATURE(mailertable) are independent of one
another. Didn't realize that. BB 4.8.24 lists the order in which
FEATURES are parsed and mailertable comes before smarthost.

Still following your pointers, I surmise that a mailertable entry such
as my present one:

. smtp:mail.my-isp.ca

could be changed to invoke the "relay" delivery agent (BB 20.4.13.5)
like:

. relay:mail.my-isp.ca

thereby invoking define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl. The
BB is unclear here as just what kind of args are legit in that
construct isn't made explicit. (See "understood less" in [1] :-)

Post by Grant Taylor
This will cause Sendmail to configure the relay mailer (Mrelay) to
append 587 to the default argument `TCP $h'. Thus telling Sendmail
that the relay mailer should connect to destination port 587.

Okay. Good. More clear than BB.

Post by Grant Taylor
I can't help if the remote system doesn't offer STARTTLS. But I can
help with downgrade attacks /if/ the remote system supports SMTPS,
a.k.a. submission, on TCP port 465.

Well, the sys admin at $ISP has been very helpful & reliable to I'm
going to try to get AUTH, STARTTLS on port 587 working first because
that's what he has told me I should do and what he supports.

Now that I see that mailertable and smarthost are separate things, I
can try to get one or the other to use the data in the "define(..."s
you've suggested.

Post by Grant Taylor
I hope the answer was worth all the faces. ;-)

Oh, yes. Not a problem. A friend had a summer job working on the
computer at MIT (in 1963, when the definite article in that context
was probably meaningful). She told me about smilies used on the
hard-copy terminals. We're doing better than 150 bits/s now but they
remain part of the canonical firmament.

Thank you very much. Now I have to try to convert blah-blah (above)
and multiple PostIt bookmarks in BB into a working sendmail config.


TYVM,
- Mike


[1] Yes, I blew a hundred bucks on the O'Reilly bat book in 2004, 3rd
ed, now three sendmail versions out of date. No, I have not read
the whole thing. I've read Neal Stephenson's Baroque Cycle --
3 books of comparable size -- 10 times. I've read maybe 100 pp of
BB, fully understood less.

[Grant Taylor]

Post by Mike Spencer
Me too. I got short notice of the mandatory change and was in a bit
if a panic. Still don't have the "delay" option working as expected
but I can read my mail.

:-)

Post by Mike Spencer
I don't remember how I got to that 20 years ago when I first started
using Slackware on dialup.

IMHO mailertable's main use is to route email, based on destination
domain, independently of what DNS (et al.) say to do.

Post by Mike Spencer
Since then, I've maintained 2 sets of (sendmail.cf, mailertable.db)
in a hidden dir. Dialing in to one of two ISPs automatically swapped
in the matching pair and created an empty /etc/mail/flag$ISP file.
Everything worked without restarting sendmail after a swap. That was
with Slackware 8, 10, 11 & 14.1. Now using Slackware 14.2. sendmail
8.15.

Hum.

Normally Sendmail needs to be restarted to reference the changed config
file. Maybe a HUP will suffice.

I think the DB file can be swapped with little fuss.

Post by Mike Spencer
Only local mail is that the system (? or something) very
occasionally sends mail to root that seems to end up in
/var/spool/mail/root. Otherwise, no. Of course, I don't want those
system mssgs to root routed through the smarthost & net.

ACK

Post by Mike Spencer
Okayyyyy. That gives me key words to look up in the Bat Book. [1]
"BB" hereinafter.

Sometimes, finding the thread to pull is the hardest part of the problem.

Post by Mike Spencer
Hunting up key words (above, RELAY_MAILER_ARG etc.) it appears that
FEATURE(smarthost) and FEATURE(mailertable) are independent of one
another. Didn't realize that.

Yep. Mailertable is more for B2B situations when you don't want to
route email based on DNS.

Post by Mike Spencer
BB 4.8.24 lists the order in which FEATURES are parsed and mailertable
comes before smarthost.

The smart host is usually the fall back / punt / default gateway (if you
will) of email routing. Send it to that host, it's smart, hopefully it
will know what to do with it.

Post by Mike Spencer
Still following your pointers, I surmise that a mailertable entry
. smtp:mail.my-isp.ca
could be changed to invoke the "relay" delivery agent (BB 20.4.13.5)
. relay:mail.my-isp.ca

Yes.

That mailertable entry will match all destination domains and tell
Sendmail to use the smtp or relay mailer to connect to mail.my-isp.ca.

Post by Mike Spencer
thereby invoking define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl.

Yep.

Post by Mike Spencer
The BB is unclear here as just what kind of args are legit in that
construct isn't made explicit. (See "understood less" in [1] :-)

I'm too lazy to pull my copy of the BB out to look. Please forgive me.

I expect that you can put anything in the RELAY_MAILER_ARTS that would
be legal to put in the arguments part of the mailer definition.

Post by Mike Spencer
Okay. Good. More clear than BB.

:-)

Post by Mike Spencer
Well, the sys admin at $ISP has been very helpful & reliable to I'm
going to try to get AUTH, STARTTLS on port 587 working first because
that's what he has told me I should do and what he supports.
Now that I see that mailertable and smarthost are separate things,
I can try to get one or the other to use the data in the "define(..."s
you've suggested.
Oh, yes. Not a problem. A friend had a summer job working on the
computer at MIT (in 1963, when the definite article in that context
was probably meaningful). She told me about smilies used on the
hard-copy terminals. We're doing better than 150 bits/s now but they
remain part of the canonical firmament.
Thank you very much. Now I have to try to convert blah-blah (above)
and multiple PostIt bookmarks in BB into a working sendmail config.
TYVM, - Mike

You're welcome.

Post by Mike Spencer
[1] Yes, I blew a hundred bucks on the O'Reilly bat book in 2004,
3rd ed, now three sendmail versions out of date. No, I have not
read the whole thing. I've read Neal Stephenson's Baroque Cycle --
3 books of comparable size -- 10 times. I've read maybe 100 pp of BB,
fully understood less.

Now I've got to get off my duff and at least look.

I've got 1st, 2nd, 3rd, and 4th editions of the BB, Sendmail Cookbook,
Sendmail 8.13 Companion, Sendmail Desktop Reference (all O'Reilly), and
I've printed & read multiple versions of the Sendmail Installation and
Administration Guide (op.me) which comes with Sendmail source. I think
I've found the Installation and Administration Guide the most helpful.
IMHO most O'Reilly books are reference when you need to look up syntax.
Conversely, I've found it worth my time to read the Sendmail
Installation and Administration Guide cover to cover. It's about a
quarter of an inch thick when printed. It's worth it. You should check
it out.

[Grant Taylor]

… I've printed & read multiple versions of the Sendmail Installation and
Administration Guide (op.me) which comes with Sendmail source.  I think
I've found the Installation and Administration Guide the most helpful.

I've also found the comp.mail.sendmail newsgroup to be invaluably
helpful over the years.

I find that Claus Aßmann frequently responds to questions too.

[Ted Heise]

On Fri, 17 Apr 2020 23:38:05 -0600,

Post by Grant Taylor

??? I've printed & read multiple versions of the Sendmail
Installation and Administration Guide (op.me) which comes with
Sendmail source.?? I think I've found the Installation and
Administration Guide the most helpful.

I've also found the comp.mail.sendmail newsgroup to be
invaluably helpful over the years.
I find that Claus A??mann frequently responds to questions too.

It's been a few years since I ran my own server, but I found the
Nemeth books (e.g., Nemeth, Snyder & Hein Linux Administration
Handbook) to be extremely clear and helpful. My copy is from 2002
(wow, did not realize it had been *that* long), but there are no
doubt newer editions.

With this book, I only occasionally had to resort to the BB and
its gory details.

[Mike Spencer]

Post by Grant Taylor

Post by Grant Taylor
I've printed & read multiple versions of the Sendmail Installation and
Administration Guide (op.me) which comes with Sendmail source.  I think
I've found the Installation and Administration Guide the most helpful.

Noted.

Post by Grant Taylor
I've also found the comp.mail.sendmail newsgroup to be invaluably
helpful over the years.

I went to alt.os.linux.slackware first in the belief that, since
Slackware is distributed with sendmail, there might more likely be
users there who'd been in my situation while (just guessing)
comp.mail.sendmail would be largely populated by people admining
servers exposed to the net with all the attendant complications.

Post by Grant Taylor
I find that Claus Aßmann frequently responds to questions too.

Noted.

At the moment, other, more quotidian and purely analogue tasks
supervene; back to this real soon.

Tnx,

[Rich]

[sendmail group excluded in this reply]

Post by Mike Spencer

Post by Grant Taylor
I've also found the comp.mail.sendmail newsgroup to be invaluably
helpful over the years.

I went to alt.os.linux.slackware first in the belief that, since
Slackware is distributed with sendmail, there might more likely be
users there who'd been in my situation

Do note that "ships with" does not necessarially equate to "utilized by
the admin".

The first two steps I perform for any Slackware install that is going
to handle email is:

1) removepkg sendmail
2) installpkg postfix
(https://slackbuilds.org/repository/14.2/network/postfix/)

[Mike Spencer]

Post by Rich
[sendmail group excluded in this reply]

Post by Mike Spencer
I went to alt.os.linux.slackware first in the belief that, since
Slackware is distributed with sendmail, there might more likely be
users there who'd been in my situation

Do note that "ships with" does not necessarially equate to "utilized by
the admin".
The first two steps I perform for any Slackware install that is going
1) removepkg sendmail
2) installpkg postfix
(https://slackbuilds.org/repository/14.2/network/postfix/)

Noted. I've just put together the advice from aols and elsewhere in
my sendmail{mc,cf}, mailertable and authinfo files. Attempts to send
to my own account (same server, ISP) via designated smarthost server
rejected. Bounce mssgs to ***@localhost mention "user unknown" and
"Fix reverse DNS for [IP]". Don't understand where the problem is.
Awaiting response to my detailed query from the server admin.

Yes, fuvgpnaavat sendmail and replacing it with postfix (or something
else?) is a possibility if we can't work this out. The mail server
guy is great but support from the ISP through which I can now get
reasonably high speed connection is umm... problematic.

Tnx for the suggestion,

[Rich]

Post by Mike Spencer

Post by Rich
[sendmail group excluded in this reply]

Post by Mike Spencer
I went to alt.os.linux.slackware first in the belief that, since
Slackware is distributed with sendmail, there might more likely be
users there who'd been in my situation

Do note that "ships with" does not necessarially equate to "utilized by
the admin".
The first two steps I perform for any Slackware install that is going
1) removepkg sendmail
2) installpkg postfix
(https://slackbuilds.org/repository/14.2/network/postfix/)

Noted. I've just put together the advice from aols and elsewhere in
my sendmail{mc,cf}, mailertable and authinfo files.

I get that. It is easier to incrementally extend what you've already
got working than to wholesale replace it outright.

In my case, I used to use sendmail, before Postfix appeared. The
moment postfix appeared, I wholesale removed all instances of sendmail
from my email servers, and have never looked back with any regrets.
This was, however, somewhere circa 1998 or so (memory may be foggy, so
take that as +- about 3-4 years).

Post by Mike Spencer
Attempts to send to my own account (same server, ISP) via designated
"user unknown" and "Fix reverse DNS for [IP]". Don't understand
where the problem is.

Those two responses indicate that the "smarthost" does not recognize
your username (meaning either it does not recognize the name part of
the email you are sending as one it receives, or it expects a
username/password login before it accepts email, and it does not
recognize that username).

The fix reverse DNS means it was trying to do an IP to DNS name lookup
on the IP you sent from, and there was no IP->name mapping to be found.

Post by Mike Spencer
Awaiting response to my detailed query from the server admin.
Yes, fuvgpnaavat sendmail and replacing it with postfix (or something
else?) is a possibility if we can't work this out. The mail server
guy is great but support from the ISP through which I can now get
reasonably high speed connection is umm... problematic.

Given that most ISP's 'provide' email service, and most of their users
use that without realizing the implications of doing so, I'd bet that
the ISP's consider someone wanting to run their own email server as an
"expert user who knows what they are doing and does not need our help"
(and that's even assuming they consider that someone might want to run
their own email server). So you might eventually get some answers, but
I fear that unless it is something simple like they need to setup their
smarthost to know it is a relay for your email domain that they won't
be overly helpful.

[Mike Spencer]

Post by Rich

Post by Mike Spencer
Attempts to send to my own account (same server, ISP) via designated
"user unknown" and "Fix reverse DNS for [IP]". Don't understand
where the problem is.

Those two responses indicate that the "smarthost" does not recognize
your username (meaning either it does not recognize the name part of
the email you are sending as one it receives...

Well.... um... :-)

That's not much more clear than the bounce mssg. :-o The intended
recipient "***@my-isp.ca" is reported back in the bounce mssg. It is
correct and is a valid username on that ISP's system. I get email to
that account all the time. So: possible misconfig on their server.

Whether some error/failure occurs in the RCPT TO: part of the SMTP
exchange isn't clear. With simple SMTP on port 25 I would telnet to
port 25 and try it manually to determine where the problem arises. On
port 587 with STARTTLS I can't (AFAIK) do that. For example, I have
no way to determine what is being sent following the HELO or EHLO when
my localhost has a 10.0.0.0 address.

Post by Rich
...or it expects a username/password login before it accepts email,
and it does not recognize that username).

That is what the AUTH command/mechanism (RFC 4964) is supposed to deal
with and what I'm trying to implement. So this implies a failure, at
my end or the remote server's end, in the authentication step using
AUTH. I've tried using (in my authinfo file) both "U:username" and
and the valid email address "U:***@my-isp.ca" and both fail in
the same way.

Either of the above alternatives could derive from a config error at
my end or at the server. Hoping the admin can help but he's off
Sundays.

Post by Rich
The fix reverse DNS means it was trying to do an IP to DNS name lookup
on the IP you sent from, and there was no IP->name mapping to be found.

Which is a potential problem. My desktop has a non-routable address
in 10.0.0.0/8. I assume (??) that the address the server sees is
whetever routable address is held by the "gateway device". The
gateway device uses a SIM card to connect to the net via Telus and
(I'm guessing here) negotiates a new routable address each time it's
powered up. Sending email through Telus' own SMTP server on port 25
works as expected. The present failure is in connecting to the net
via Telus but sending mail through other-isp.ca using AUTH.

Post by Rich

Post by Mike Spencer
Awaiting response to my detailed query from the server admin.
Yes, fuvgpnaavat sendmail and replacing it with postfix (or something
else?) is a possibility if we can't work this out. The mail server
guy is great but support from the ISP through which I can now get
reasonably high speed connection is umm... problematic.

Given that most ISP's 'provide' email service, and most of their users
use that without realizing the implications of doing so, I'd bet that
the ISP's consider someone wanting to run their own email server as an
"expert user who knows what they are doing and does not need our
help"...

Well, the ISP through whose server I'm trying to send is the same
local mom 'n pop ISP who's been providing dialup service for 20 years
and the one where I receive all my email. The admin understands what
I'm doing, knows I'm not running a net-exposed mail server. (He even
knows a bit about Linux. :-) Telus, on the other hand, is a megacorp
with all the attendant shortcomings in getting support (different
support person on every contact; different policy assertions from
different people; exploding head when Liux is mentioned; you know...).

Post by Rich
...(and that's even assuming they consider that someone might want
to run their own email server). So you might eventually get some
answers, but I fear that unless it is something simple like they
need to setup their smarthost to know it is a relay for your email
domain that they won't be overly helpful.

See above. It's really too bad that the mom 'n pop local ISP can't
offer any kind of high-speed connection in my area. Would happily pay
a surcharge for the service to get their end-to-end support.

[Rich]

Post by Mike Spencer

Post by Rich

Post by Mike Spencer
Attempts to send to my own account (same server, ISP) via designated
"user unknown" and "Fix reverse DNS for [IP]". Don't understand
where the problem is.

Those two responses indicate that the "smarthost" does not recognize
your username (meaning either it does not recognize the name part of
the email you are sending as one it receives...

Well.... um... :-)
That's not much more clear than the bounce mssg. :-o The intended
correct and is a valid username on that ISP's system. I get email to
that account all the time. So: possible misconfig on their server.

Yes, as in their outgoing server is not recognizing 'user'@ as a valid
outgoing email address 'user' value. That would still be on their end
however.

But if their smarthost requires authentication to send an email, then
the message could be referring to the 'user' part of the authentication
handshake (but still a config issue on their end if 'user' should be
allowed to send email).

Post by Mike Spencer
Whether some error/failure occurs in the RCPT TO: part of the SMTP
exchange isn't clear. With simple SMTP on port 25 I would telnet to
port 25 and try it manually to determine where the problem arises. On
port 587 with STARTTLS I can't (AFAIK) do that.

Setup an stunnel link on localhost, then you can telnet to localhost as
always, stunnel will TLS to them on 587, and you obviously would need
to type in the STARTTLS handshake commands to get things going.

Post by Mike Spencer
For example, I have no way to determine what is being sent following
the HELO or EHLO when my localhost has a 10.0.0.0 address.

Yeah, that's the problem when you can't see all the handshake in its
full glory.

Post by Mike Spencer

Post by Rich
...or it expects a username/password login before it accepts email,
and it does not recognize that username).

That is what the AUTH command/mechanism (RFC 4964) is supposed to deal
with and what I'm trying to implement. So this implies a failure, at
my end or the remote server's end, in the authentication step using
AUTH. I've tried using (in my authinfo file) both "U:username" and
the same way.

Yes, this could be your end, their end, or both ends. And whatever
'username' you configure on your end, that obviously needs to match
what they are expecting to see on their end. So you'll need to find
out what they are expecting to make sure this works correctly.

Post by Mike Spencer

Post by Rich
The fix reverse DNS means it was trying to do an IP to DNS name lookup
on the IP you sent from, and there was no IP->name mapping to be found.

Which is a potential problem. My desktop has a non-routable address
in 10.0.0.0/8. I assume (??) that the address the server sees is
whetever routable address is held by the "gateway device". The
gateway device uses a SIM card to connect to the net via Telus and
(I'm guessing here) negotiates a new routable address each time it's
powered up. Sending email through Telus' own SMTP server on port 25
works as expected. The present failure is in connecting to the net
via Telus but sending mail through other-isp.ca using AUTH.

Hmm, ok, that resolves the 'reverse ip' issue, Telus likely has no
reverse DNS map for the addresses they are assigning you (and why would
they, as they are likely from a pool and just given to whomever links
in next via their SIM card). Whether this error on the ISP's side is
fatal is again something you need them to help with.

Post by Mike Spencer

Post by Rich

Post by Mike Spencer
Awaiting response to my detailed query from the server admin.
Yes, fuvgpnaavat sendmail and replacing it with postfix (or something
else?) is a possibility if we can't work this out. The mail server
guy is great but support from the ISP through which I can now get
reasonably high speed connection is umm... problematic.

Given that most ISP's 'provide' email service, and most of their users
use that without realizing the implications of doing so, I'd bet that
the ISP's consider someone wanting to run their own email server as an
"expert user who knows what they are doing and does not need our
help"...

Well, the ISP through whose server I'm trying to send is the same
local mom 'n pop ISP who's been providing dialup service for 20 years
and the one where I receive all my email. The admin understands what
I'm doing, knows I'm not running a net-exposed mail server. (He even
knows a bit about Linux. :-) Telus, on the other hand, is a megacorp
with all the attendant shortcomings in getting support (different
support person on every contact; different policy assertions from
different people; exploding head when Liux is mentioned; you know...).

Ok, I'm gaining an understanding of what you are doing. You are using
a second ISP (Telus) to try to connect to your original (first) ISP's
(the dialup one) SMTP server in order to submit email for sending via
first ISP's email server.

Hense why you need to use AUTH, because without AUTH, that path is a
recipie for SPAM, because it would mean first ISP is running an open
relay.

I'm feeling like that when you do get to talk to first ISP's email
guru, you'll find out that something is borked in the AUTH handling
(your end, their end, or both ends) and therefore the error messages.
And, hopefully, once you get AUTH un-borked, things will just start
working smoothly for you again.

[Mike Spencer]

Post by Rich
Ok, I'm gaining an understanding of what you are doing. You are using
a second ISP (Telus) to try to connect to your original (first) ISP's
(the dialup one) SMTP server in order to submit email for sending via
first ISP's email server.
Hense why you need to use AUTH, because without AUTH, that path is a
recipie for SPAM, because it would mean first ISP is running an open
relay.

Exactly.

Post by Rich
I'm feeling like that when you do get to talk to first ISP's email
guru, you'll find out that something is borked in the AUTH handling
(your end, their end, or both ends) and therefore the error messages.
And, hopefully, once you get AUTH un-borked, things will just start
working smoothly for you again.

Yes. I'll no doubt hear from the admin on Monday. And I have to do
more careful testing on my end to ensure that clever things I've done
over there <--- aren't screwing up SMTP over here --->. I forget what
I've done when nothing needs changing for years.

[Mike Spencer]

Post by Rich
Setup an stunnel link on localhost, then you can telnet to localhost
as always, stunnel will TLS to them on 587, and you obviously would
need to type in the STARTTLS handshake commands to get things going.

I'm not sure that would work. The server is speaking cleartext until
STARTTLS is invoked by the client.

For the record, what *does* work is:

openssl s_client -starttls smtp -connect the-server.com:587

openssl s_client apparently does the Right Thing, creating a
connection to the mail server listening on the remote host's port 587
and sending the STARTTLS command at the right point. That leaves me
talking to the remote server from the command line in the usual
RFC 5321 way.

Using this, I've verified that the remote server responds correctly
and accepts AUTH LOGIN. (I haven't figured out how AUTH PLAIN works yet.)

Manually executing the AUTH LOGIN command (translating the
challenge/response exchange from/to base64,) I get authenticated and am
able to enter (manually, using DATA) and send (. by itself) email that
is subsequently delivered.

From scrutinizing maillog and tcpdump output, it appears that my local
sendmail invokes STARTTLS but that the process fails.

From maillog:

Apr 22 17:19:53
bogus sm-mta[7015]: [<--- localhost is named "bogus"]
STARTTLS=client,
relay=the-server.com
version=TLSv1.2,
verify=FAIL,
cipher=DHE-RSA-AES256-GCM-SHA384,
bits=256/256

Result is that the remote server treats the session as unencrypted and
unauthenticated, and so correctly refuses to accept a mssg for
delivery.

So I'm still stuck. Remote server works, local sendmail appears to
fail establishing TLS connection, thus never reaches the AUTH step.

I'll formulate this with more boring detail and post it to
comp.mail.sendmail as Grant Taylor suggested.

In the meantime, any further insights welcome.

[Rich]

Post by Mike Spencer
So I'm still stuck. Remote server works, local sendmail appears to
fail establishing TLS connection, thus never reaches the AUTH step.
I'll formulate this with more boring detail and post it to
comp.mail.sendmail as Grant Taylor suggested.
In the meantime, any further insights welcome.

Hmm... Maybe you need to upgrade your openssl libs on the box running
the SMTP server?

[Mike Spencer]

Post by Rich

Post by Mike Spencer
So I'm still stuck. Remote server works, local sendmail appears to
fail establishing TLS connection, thus never reaches the AUTH step.
I'll formulate this with more boring detail and post it to
comp.mail.sendmail as Grant Taylor suggested.
In the meantime, any further insights welcome.

Hmm... Maybe you need to upgrade your openssl libs on the box running
the SMTP server?

Trouble parsing that.

In the post to which you're replying, I reported that I can connect,
manually invoke AUTH LOGIN and manually send mail via the remote host
by using:

openssl s_client -starttls smtp -connect remote-host.com:587

That should mean the *my* openssl libs and those on the remote host
are compatible.

The question is: Why does this fail when sendmail on localhost
connects to remote-host but gets failure/error when it issues
STARTTLS?

Tediously detailed statement of problem as I now see it to follow. :-)

[Grant Taylor]

Post by Mike Spencer
In the post to which you're replying, I reported that I can connect,
manually invoke AUTH LOGIN and manually send mail via the remote host
openssl s_client -starttls smtp -connect remote-host.com:587
That should mean the *my* openssl libs and those on the remote host
are compatible.

I largely agree. There is always a > 0% chance of some unexpected
interaction based on differences between Sendmail and OpenSSL's
s_client. But I bet that's < 1% chance.

Post by Mike Spencer
The question is: Why does this fail when sendmail on localhost connects
to remote-host but gets failure/error when it issues STARTTLS?

There is a chance that this is not even leaving your system. If your
MSA is trying to communicate to your MTA in a way that your MTA doesn't
currently support, you could be getting weird and potentially misleading
errors too.

Full logs for a message and packet captures will help answer these
questions.

Post by Mike Spencer
Tediously detailed statement of problem as I now see it to follow. :-)

:-)

[Rich]

Post by Mike Spencer

Post by Rich

Post by Mike Spencer
So I'm still stuck. Remote server works, local sendmail appears to
fail establishing TLS connection, thus never reaches the AUTH step.
I'll formulate this with more boring detail and post it to
comp.mail.sendmail as Grant Taylor suggested.
In the meantime, any further insights welcome.

Hmm... Maybe you need to upgrade your openssl libs on the box running
the SMTP server?

Trouble parsing that.
In the post to which you're replying, I reported that I can connect,
manually invoke AUTH LOGIN and manually send mail via the remote host
openssl s_client -starttls smtp -connect remote-host.com:587
That should mean the *my* openssl libs and those on the remote host
are compatible.

On the system from which you run the openssl, yes.

Are you running the openssl test from the same machine that runs the
mailserver? Presumably yes, you are, but I don't know that you've
explicitly stated such yet here in the thread.

Post by Mike Spencer
The question is: Why does this fail when sendmail on localhost
connects to remote-host but gets failure/error when it issues
STARTTLS?

Any way to turn on extended error logging for sendmail? If yes, that
might reveal an answer.

[Grant Taylor]

Post by Rich
Hmm... Maybe you need to upgrade your openssl libs on the box running
the SMTP server?

I doubt that changing any software version is the proper /next/ course
of action.

There should be very clearly defined parameters pointing to the exact
problem to necessitate changing software versions.

All of my questions (outstanding as I type this) should be answered
before considering changing versions of something.

[Grant Taylor]

Post by Mike Spencer
I'm not sure that would work. The server is speaking cleartext until
STARTTLS is invoked by the client.

Agreed.

Post by Mike Spencer
openssl s_client -starttls smtp -connect the-server.com:587
openssl s_client apparently does the Right Thing, creating a connection
to the mail server listening on the remote host's port 587 and sending
the STARTTLS command at the right point. That leaves me talking to
the remote server from the command line in the usual RFC 5321 way.

OpenSSL's s_client will quite happily speak implicit TLS (MSA port 465)
or STARTTLS (MTA port 587). The "-starttls <protocol>" tells s_client
what protocol the underlying transport is and thus what semantics need
to be used to STARTTLS. You obviously want smtp in this case. There
other protocols that transition from cleartext to cyphertext.

Post by Mike Spencer
Using this, I've verified that the remote server responds correctly and
accepts AUTH LOGIN. (I haven't figured out how AUTH PLAIN works yet.)

For giggles, try the same thing but connecting to port 25.

If Sendmail is using port 25 and Telus is intercepting TCP port 25 as
part of their anti-spam measures, they may be rejecting your username &
password.

Again, a packet capture, even one you can't decrypt, can rule out quite
a number of things.

Post by Mike Spencer
Manually executing the AUTH LOGIN command (translating the
challenge/response exchange from/to base64,) I get authenticated
and am able to enter (manually, using DATA) and send (. by itself)
email that is subsequently delivered.

So you know for sure that the credentials you have /do/ work on the MSA
port (587) of your ESP.

Removing unknowns / variables from the equation is always a Good Thing™.

Post by Mike Spencer
From scrutinizing maillog and tcpdump output, it appears that my
local sendmail invokes STARTTLS but that the process fails.
Apr 22 17:19:53
bogus sm-mta[7015]: [<--- localhost is named "bogus"]
STARTTLS=client,
relay=the-server.com
version=TLSv1.2,
verify=FAIL,
cipher=DHE-RSA-AES256-GCM-SHA384,
bits=256/256

Why do you say that STARTTLS fails?

The "verify=FAIL" probably means something other than what you think it
means.

In this case, it means that Sendmail isn't able to verify the identity
of the certificate. This could mean that your local certificate store
that Sendmail is using doesn't include the CA that signed the remote
server's certificate. Or it could mean that the name in the certificate
doesn't match the name that Sendmail is connecting to. The latter could
be quite likely if Sendmail is using the MTA port (25) and Telus is
intercepting the connection. Such an interception would almost
guarantee that the name that Sendmail is connecting to does not match
the name in the certificate being presented.

You might be able to compare ciphers and bits between your Sendmail logs
and your openssl s_client output. I'm not 100% sure what that will tell
you, especially if they are the same. But you can probably tell if they
are WILDLY different and interpret that as an indication that Sendmail
is not connecting to your ESP.

Post by Mike Spencer
Result is that the remote server treats the session as unencrypted
and unauthenticated, and so correctly refuses to accept a mssg for
delivery.

I'm not convinced that it's unencrypted. (See above for why.) Again, a
packet capture will clearly show if it's encrypted or not.

Chances are good that if it is unencrypted that authentication is not
available. Sendmail / SASL tends to require a secure (encrypted)
channel for username & password based authentication to be allowed.

Post by Mike Spencer
So I'm still stuck. Remote server works, local sendmail appears to
fail establishing TLS connection, thus never reaches the AUTH step.

Can we see (a redacted version of) the DSN?

Can you confirm the port that Sendmail is connecting to?

Can you confirm that encryption is or is not being used?

Can we see the definition for the relay mailer?

Can we see the all of the germane log entries for a test message?

Post by Mike Spencer
I'll formulate this with more boring detail and post it to
comp.mail.sendmail as Grant Taylor suggested.

;-)

Post by Mike Spencer
In the meantime, any further insights welcome.

Well, all I have at the moment are questions and how I would go about
collecting the information to answer them. No insight to be had yet.

[Mike Spencer]

This is going to be a long, somewhat messy post.

Grant, I'll answer your questions where I have an answer, include the
requested files/data.

Post by Grant Taylor
Can you confirm the port that Sendmail is connecting to?

Right host: Yes, remote IP address confirmed in tcpdump
Right port: Yes, port 587 confirmed in tcpdump

And reiterating from a previous post, using:

openssl s_client -starttls smtp -connect remote-server.com:587
z
I've verified that the remote server responds correctly, accepts AUTH
LOGIN and accepts & delivers mail subsequently.

Post by Grant Taylor
Can we see the definition for the relay mailer?

Not sure what that means. "relay mailer" == "delivery agent" per
BatBook sec. 20.4?

Using mailertable. Converted to mailertable.db with "makemap hash..."
The sendmail.cf is relevant here so the corresponding sendmail.mc is
also included below. Have I screwed up here somehow by putting
"relay" in mailertable instead of "smtp"?

--- BEGIN /etc/mail/mailertable [real host name redacted] ---

. relay:smtp.remote-server.com

--- END /etc/mail/mailertable [real host name redacted] ---

--- BEGIN sendmail.mc ---

divert(0)dnl
VERSIONID(`$Id: trial-2.mc, 2020/04/18 mds Exp $')
OSTYPE(`linux')dnl
DOMAIN(`generic')dnl
define(`RELAY_MAILER', `esmtp')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl
FEATURE(`authinfo',`hash -o /etc/mail/authinfo.db')dnl
FEATURE(`mailertable', `hash /etc/mail/mailertable.db')dnl
FEATURE(always_add_domain)dnl
MAILER(local)dnl
MAILER(smtp)dnl

--- END sendmail.mc ---

Because it's simple and short, I'm including my authinfo file here.
If, as it appears, the AUTH command is never sent to the remote
server, the authinfo presumably never gets used.

--- BEGIN authinfo ---

AuthInfo:remote-host.com "U:valid-username" "P:rEdAcTeD" "M:LOGIN"

--- END authinfo ---

Post by Grant Taylor
Can you confirm that encryption is or is not being used?

It appears (see "sendmail -X log", below) that encryption *is*
started but then the AUTH command is never issued to the remote server
by my local sendmail. Do I have that right? I can post tcpdump of
the same session if it would reveal a vital clue.

Post by Grant Taylor
Can we see (a redacted version of) the DSN?

See "sendmail -X log", below. What the "sendmail -X log" reports
seems to be a failure by my sendmail to issue the AUTH command once
TLS is running.


1. Transaction of handing mssg *to* sendmail on localhost.
Seems normal. No crypto or AUTH needed

2. Connect to remote server. My sendmail sends EHLO.
The remote server offers STARTTLS but *not* AUTH

3. My sendmail sends "STARTTLS"
Remote replies "Ready to start TLS" in plaintext

This point can be identified in the tcpdump log.

4. My sendmail sends *another* EHLO
Now the remote replies, offering AUTH PLAIN LOGIN

This is *not visible* in the tcpdump -X output as plaintext, so
I infer that TLS is in effect.

5. My sendmail does *not* issue the AUTH command.
Instead, it immediately proceeds to MAIL FROM:

The remote server rejects the mssg.

Here's the session log recorded by adding "-X filename" to
rc.sendmail, the script that runs/restarts sendmail.

It appears to include transcripts of:

+ Receiving mssg from my email client

+ Connecting to remote server and attempting to send mssg

+ Reporting failure to root on local host. A mail mssg to root
showed up in /var/spool/mail/root with substantially the same
text as in the session transcript next below.

Following log is redacted: "valid-***@remote-host.com" always
represents the same ***@address. "smtp.remote-server.com" replaces
the server name I use as well as the CNAME of the same host where it
responds with it.

--- BEGIN sendmail -X log ---

03950 >>> 220 bogus.nodomain.nowhere ESMTP Sendmail 8.15.2/8.15.2; Thu, 23 Apr 2020 18:49:51 -0300
03950 <<< EHLO bogus.nodomain.nowhere
03950 >>> 250-bogus.nodomain.nowhere Hello localhost [127.0.0.1], pleased to meet you
03950 >>> 250-ENHANCEDSTATUSCODES
03950 >>> 250-PIPELINING
03950 >>> 250-EXPN
03950 >>> 250-VERB
03950 >>> 250-8BITMIME
03950 >>> 250-SIZE
03950 >>> 250-DSN
03950 >>> 250-ETRN
03950 >>> 250-AUTH DIGEST-MD5 CRAM-MD5
03950 >>> 250-DELIVERBY
03950 >>> 250 HELP
03950 <<< MAIL From:<valid-***@remote-host.com> SIZE=580
03950 >>> 250 2.1.0 <valid-***@remote-host.com>... Sender ok
03950 <<< RCPT To:<valid-***@remote-host.com>
03950 >>> 250 2.1.5 <valid-***@remote-host.com>... Recipient ok
03950 <<< DATA
03950 >>> 354 Enter mail, end with "." on a line by itself
03950 <<< Received: (from ***@localhost)
03950 <<< by bogus.nodomain.nowhere (8.15.2/8.15.2/Submit) id 03NLnmQ0003947;
03950 <<< Thu, 23 Apr 2020 18:49:48 -0300
03950 <<< Date: Thu, 23 Apr 2020 18:49:48 -0300
03950 <<< Message-Id: <***@bogus.nodomain.nowhere>
03950 <<< X-Authentication-Warning: bogus.nodomain.nowhere: mds set sender to valid-***@remote-host.com using -f
03950 <<< From: valid-***@remote-host.com (Mike Spencer)
03950 <<< To: valid-***@remote-host.com
03950 <<< Subject: Test of port 587/AUTH/STARTTLS with -X queue
03950 <<< Reply-to: valid-***@remote-host.com
03950 <<<
03950 <<<
03950 <<< Test of port 587/AUTH/STARTTLS with -X queue
03950 <<< log file is man/MAIL/wrk/queue
03950 <<< .
03950 >>> 250 2.0.0 03NLnp3n003950 Message accepted for delivery
03950 <<< QUIT
03950 >>> 221 2.0.0 bogus.nodomain.nowhere closing connection


03954 === CONNECT smtp.remote-server.com

03954 <<< 220 smtp.remote-server.com ESMTP Sendmail 8.14.9/8.14.9; Thu, 23 Apr 2020 18:50:06 -0300
03954 >>> EHLO bogus.nodomain.nowhere
03954 <<< 250-smtp.remote-server.com Hello [142.169.78.183], pleased to meet you
03954 <<< 250-ENHANCEDSTATUSCODES
03954 <<< 250-PIPELINING
03954 <<< 250-8BITMIME
03954 <<< 250-SIZE 40960000
03954 <<< 250-DSN
03954 <<< 250-STARTTLS
03954 <<< 250-DELIVERBY
03954 <<< 250 HELP
03954 >>> STARTTLS
03954 <<< 220 2.0.0 Ready to start TLS
03954 >>> EHLO bogus.nodomain.nowhere
03954 <<< 250-smtp.remote-server.com Hello [142.169.78.183], pleased to meet you
03954 <<< 250-ENHANCEDSTATUSCODES
03954 <<< 250-PIPELINING
03954 <<< 250-8BITMIME
03954 <<< 250-SIZE 40960000
03954 <<< 250-DSN
03954 <<< 250-AUTH PLAIN LOGIN
03954 <<< 250-DELIVERBY
03954 <<< 250 HELP
03954 >>> MAIL From:<valid-***@remote-host.com> SIZE=773
03954 <<< 250 2.1.0 <valid-***@remote-host.com>... Sender ok
03954 >>> RCPT To:<valid-***@remote-host.com>
03954 >>> DATA
03954 <<< 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183
03954 <<< 503 5.0.0 Need RCPT (recipient)
03954 >>> RSET
03954 <<< 250 2.0.0 Reset state
03954 >>> This is a MIME-encapsulated message
03954 >>>
03954 >>> --03NLnt3n003954.1587678595/bogus.nodomain.nowhere
03954 >>>
03954 >>> The original message was received at Thu, 23 Apr 2020 18:49:51 -0300
03954 >>> from localhost [127.0.0.1]
03954 >>>
03954 >>> ----- The following addresses had permanent fatal errors -----
03954 >>> <valid-***@remote-host.com>
03954 >>> (reason: 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183)
03954 >>>
03954 >>> ----- Transcript of session follows -----
03954 >>> ... while talking to smtp.remote-server.com:
03954 >>> >>> DATA
03954 >>> <<< 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183
03954 >>> 550 5.1.1 <valid-***@remote-host.com>... User unknown
03954 >>> <<< 503 5.0.0 Need RCPT (recipient)
03954 >>>
03954 >>> --03NLnt3n003954.1587678595/bogus.nodomain.nowhere
03954 >>> Content-Type: message/delivery-status
03954 >>>
03954 >>> Reporting-MTA: dns; bogus.nodomain.nowhere
03954 >>> Received-From-MTA: DNS; localhost
03954 >>> Arrival-Date: Thu, 23 Apr 2020 18:49:51 -0300
03954 >>>
03954 >>> Final-Recipient: RFC822; valid-***@remote-host.com
03954 >>> Action: failed
03954 >>> Status: 5.7.1
03954 >>> Remote-MTA: DNS; smtp.remote-server.com
03954 >>> Diagnostic-Code: SMTP; 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183
03954 >>> Last-Attempt-Date: Thu, 23 Apr 2020 18:49:55 -0300
03954 >>>
03954 >>> --03NLnt3n003954.1587678595/bogus.nodomain.nowhere
03954 >>> Content-Type: message/rfc822
03954 >>>
03954 >>> Return-Path: <valid-***@remote-host.com>
03954 >>> Received: from bogus.nodomain.nowhere (localhost [127.0.0.1])
03954 >>> by bogus.nodomain.nowhere (8.15.2/8.15.2) with ESMTP id 03NLnp3n003950
03954 >>> for <valid-***@remote-host.com>; Thu, 23 Apr 2020 18:49:51 -0300
03954 >>> Received: (from ***@localhost)
03954 >>> by bogus.nodomain.nowhere (8.15.2/8.15.2/Submit) id 03NLnmQ0003947;
03954 >>> Thu, 23 Apr 2020 18:49:48 -0300
03954 >>> Date: Thu, 23 Apr 2020 18:49:48 -0300
03954 >>> Message-Id: <***@bogus.nodomain.nowhere>
03954 >>> X-Authentication-Warning: bogus.nodomain.nowhere: mds set sender to valid-***@remote-host.com using -f
03954 >>> From: valid-***@remote-host.com (Mike Spencer)
03954 >>> To: valid-***@remote-host.com
03954 >>> Subject: Test of port 587/AUTH/STARTTLS with -X queue
03954 >>> Reply-to: valid-***@remote-host.com
03954 >>>
03954 >>>
03954 >>> Test of port 587/AUTH/STARTTLS with -X queue
03954 >>> log file is man/MAIL/wrk/queue
03954 >>>
03954 >>> --03NLnt3n003954.1587678595/bogus.nodomain.nowhere--
03954 >>>
03954 >>> RSET
03954 <<< 250 2.0.0 Reset state
03954 >>> MAIL From:<> SIZE=1797
03954 <<< 250 2.1.0 <>... Sender ok
03954 >>> RCPT To:<valid-***@remote-host.com>
03954 >>> DATA
03954 <<< 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183
03954 <<< 503 5.0.0 Need RCPT (recipient)
03954 >>> RSET
03954 <<< 250 2.0.0 Reset state
03954 >>> This is a MIME-encapsulated message
03954 >>>
03954 >>> --03NLnt3o003954.1587678595/bogus.nodomain.nowhere
03954 >>>
03954 >>> The original message was received at Thu, 23 Apr 2020 18:49:55 -0300
03954 >>> from localhost
03954 >>> with id 03NLnt3n003954
03954 >>>
03954 >>> ----- The following addresses had permanent fatal errors -----
03954 >>> <valid-***@remote-host.com>
03954 >>> (reason: 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183)
03954 >>>
03954 >>> ----- Transcript of session follows -----
03954 >>> ... while talking to smtp.remote-server.com:
03954 >>> >>> DATA
03954 >>> <<< 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183
03954 >>> 550 5.1.1 <valid-***@remote-host.com>... User unknown
03954 >>> <<< 503 5.0.0 Need RCPT (recipient)
03954 >>>
03954 >>> --03NLnt3o003954.1587678595/bogus.nodomain.nowhere
03954 >>> Content-Type: message/delivery-status
03954 >>>
03954 >>> Reporting-MTA: dns; bogus.nodomain.nowhere
03954 >>> Received-From-MTA: DNS; localhost
03954 >>> Arrival-Date: Thu, 23 Apr 2020 18:49:55 -0300
03954 >>>
03954 >>> Final-Recipient: RFC822; valid-***@remote-host.com
03954 >>> Action: failed
03954 >>> Status: 5.7.1
03954 >>> Remote-MTA: DNS; smtp.remote-server.com
03954 >>> Diagnostic-Code: SMTP; 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183
03954 >>> Last-Attempt-Date: Thu, 23 Apr 2020 18:49:55 -0300
03954 >>>
03954 >>> --03NLnt3o003954.1587678595/bogus.nodomain.nowhere
03954 >>> Content-Type: message/rfc822
03954 >>>
03954 >>> Return-Path: <MAILER-DAEMON>
03954 >>> Received: from localhost (localhost)
03954 >>> by bogus.nodomain.nowhere (8.15.2/8.15.2) id 03NLnt3n003954;
03954 >>> Thu, 23 Apr 2020 18:49:55 -0300
03954 >>> Date: Thu, 23 Apr 2020 18:49:55 -0300
03954 >>> From: Mail Delivery Subsystem <MAILER-DAEMON>
03954 >>> Message-Id: <***@bogus.nodomain.nowhere>
03954 >>> To: <valid-***@remote-host.com>
03954 >>> MIME-Version: 1.0
03954 >>> Content-Type: multipart/report; report-type=delivery-status;
03954 >>> boundary="03NLnt3n003954.1587678595/bogus.nodomain.nowhere"
03954 >>> Subject: Returned mail: see transcript for details
03954 >>> Auto-Submitted: auto-generated (failure)
03954 >>>
03954 >>> This is a MIME-encapsulated message
03954 >>>
03954 >>> --03NLnt3n003954.1587678595/bogus.nodomain.nowhere
03954 >>>
03954 >>> The original message was received at Thu, 23 Apr 2020 18:49:51 -0300
03954 >>> from localhost [127.0.0.1]
03954 >>>
03954 >>> ----- The following addresses had permanent fatal errors -----
03954 >>> <valid-***@remote-host.com>
03954 >>> (reason: 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183)
03954 >>>
03954 >>> ----- Transcript of session follows -----
03954 >>> ... while talking to smtp.remote-server.com:
03954 >>> >>> DATA
03954 >>> <<< 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183
03954 >>> 550 5.1.1 <valid-***@remote-host.com>... User unknown
03954 >>> <<< 503 5.0.0 Need RCPT (recipient)
03954 >>>
03954 >>> --03NLnt3n003954.1587678595/bogus.nodomain.nowhere
03954 >>> Content-Type: message/delivery-status
03954 >>>
03954 >>> Reporting-MTA: dns; bogus.nodomain.nowhere
03954 >>> Received-From-MTA: DNS; localhost
03954 >>> Arrival-Date: Thu, 23 Apr 2020 18:49:51 -0300
03954 >>>
03954 >>> Final-Recipient: RFC822; valid-***@remote-host.com
03954 >>> Action: failed
03954 >>> Status: 5.7.1
03954 >>> Remote-MTA: DNS; smtp.remote-server.com
03954 >>> Diagnostic-Code: SMTP; 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183
03954 >>> Last-Attempt-Date: Thu, 23 Apr 2020 18:49:55 -0300
03954 >>>
03954 >>> --03NLnt3n003954.1587678595/bogus.nodomain.nowhere
03954 >>> Content-Type: message/rfc822
03954 >>>
03954 >>> Return-Path: <valid-***@remote-host.com>
03954 >>> Received: from bogus.nodomain.nowhere (localhost [127.0.0.1])
03954 >>> by bogus.nodomain.nowhere (8.15.2/8.15.2) with ESMTP id 03NLnp3n003950
03954 >>> for <valid-***@remote-host.com>; Thu, 23 Apr 2020 18:49:51 -0300
03954 >>> Received: (from ***@localhost)
03954 >>> by bogus.nodomain.nowhere (8.15.2/8.15.2/Submit) id 03NLnmQ0003947;
03954 >>> Thu, 23 Apr 2020 18:49:48 -0300
03954 >>> Date: Thu, 23 Apr 2020 18:49:48 -0300
03954 >>> Message-Id: <***@bogus.nodomain.nowhere>
03954 >>> X-Authentication-Warning: bogus.nodomain.nowhere: mds set sender to valid-***@remote-host.com using -f
03954 >>> From: valid-***@remote-host.com (Mike Spencer)
03954 >>> To: valid-***@remote-host.com
03954 >>> Subject: Test of port 587/AUTH/STARTTLS with -X queue
03954 >>> Reply-to: valid-***@remote-host.com
03954 >>>
03954 >>>
03954 >>> Test of port 587/AUTH/STARTTLS with -X queue
03954 >>> log file is man/MAIL/wrk/queue
03954 >>>
03954 >>> --03NLnt3n003954.1587678595/bogus.nodomain.nowhere--
03954 >>>
03954 >>>
03954 >>> --03NLnt3o003954.1587678595/bogus.nodomain.nowhere--
03954 >>>
03954 === EXEC procmail -f MAILER-***@bogus.nodomain.nowhere -Y -a -d root
03954 >>> Return-Path: <MAILER-***@bogus.nodomain.nowhere>
03954 >>> Received: from localhost (localhost)
03954 >>> by bogus.nodomain.nowhere (8.15.2/8.15.2) id 03NLnt3o003954;
03954 >>> Thu, 23 Apr 2020 18:49:55 -0300
03954 >>> Date: Thu, 23 Apr 2020 18:49:55 -0300
03954 >>> From: Mail Delivery Subsystem <MAILER-***@bogus.nodomain.nowhere>
03954 >>> Message-Id: <***@bogus.nodomain.nowhere>
03954 >>> To: ***@bogus.nodomain.nowhere
03954 >>> MIME-Version: 1.0
03954 >>> Content-Type: multipart/report; report-type=delivery-status;
03954 >>> boundary="03NLnt3o003954.1587678595/bogus.nodomain.nowhere"
03954 >>> Subject: Postmaster notify: see transcript for details
03954 >>> Auto-Submitted: auto-generated (postmaster-notification)
03954 >>>
03954 >>> This is a MIME-encapsulated message
03954 >>>
03954 >>> --03NLnt3o003954.1587678595/bogus.nodomain.nowhere
03954 >>>
03954 >>> The original message was received at Thu, 23 Apr 2020 18:49:55 -0300
03954 >>> from localhost
03954 >>> with id 03NLnt3n003954
03954 >>>
03954 >>> ----- The following addresses had permanent fatal errors -----
03954 >>> <valid-***@remote-host.com>
03954 >>> (reason: 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183)
03954 >>>
03954 >>> ----- Transcript of session follows -----
03954 >>> ... while talking to smtp.remote-server.com:
03954 >>> >>> DATA
03954 >>> <<< 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183
03954 >>> 550 5.1.1 <valid-***@remote-host.com>... User unknown
03954 >>> <<< 503 5.0.0 Need RCPT (recipient)
03954 >>>
03954 >>> --03NLnt3o003954.1587678595/bogus.nodomain.nowhere
03954 >>> Content-Type: message/delivery-status
03954 >>>
03954 >>> Reporting-MTA: dns; bogus.nodomain.nowhere
03954 >>> Received-From-MTA: DNS; localhost
03954 >>> Arrival-Date: Thu, 23 Apr 2020 18:49:55 -0300
03954 >>>
03954 >>> Final-Recipient: RFC822; valid-***@remote-host.com
03954 >>> Action: failed
03954 >>> Status: 5.7.1
03954 >>> Remote-MTA: DNS; smtp.remote-server.com
03954 >>> Diagnostic-Code: SMTP; 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183
03954 >>> Last-Attempt-Date: Thu, 23 Apr 2020 18:49:55 -0300
03954 >>>
03954 >>> --03NLnt3o003954.1587678595/bogus.nodomain.nowhere
03954 >>> Content-Type: message/rfc822
03954 >>>
03954 >>> Return-Path: <MAILER-DAEMON>
03954 >>> Received: from localhost (localhost)
03954 >>> by bogus.nodomain.nowhere (8.15.2/8.15.2) id 03NLnt3n003954;
03954 >>> Thu, 23 Apr 2020 18:49:55 -0300
03954 >>> Date: Thu, 23 Apr 2020 18:49:55 -0300
03954 >>> From: Mail Delivery Subsystem <MAILER-DAEMON>
03954 >>> Message-Id: <***@bogus.nodomain.nowhere>
03954 >>> To: <valid-***@remote-host.com>
03954 >>> MIME-Version: 1.0
03954 >>> Content-Type: multipart/report; report-type=delivery-status;
03954 >>> boundary="03NLnt3n003954.1587678595/bogus.nodomain.nowhere"
03954 >>> Subject: Returned mail: see transcript for details
03954 >>> Auto-Submitted: auto-generated (failure)
03954 >>>
03954 >>> This is a MIME-encapsulated message
03954 >>>
03954 >>> --03NLnt3n003954.1587678595/bogus.nodomain.nowhere
03954 >>>
03954 >>> The original message was received at Thu, 23 Apr 2020 18:49:51 -0300
03954 >>> from localhost [127.0.0.1]
03954 >>>
03954 >>> ----- The following addresses had permanent fatal errors -----
03954 >>> <valid-***@remote-host.com>
03954 >>> (reason: 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183)
03954 >>>
03954 >>> ----- Transcript of session follows -----
03954 >>> ... while talking to smtp.remote-server.com:
03954 >>> >>> DATA
03954 >>> <<< 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183
03954 >>> 550 5.1.1 <valid-***@remote-host.com>... User unknown
03954 >>> <<< 503 5.0.0 Need RCPT (recipient)
03954 >>>
03954 >>> --03NLnt3n003954.1587678595/bogus.nodomain.nowhere
03954 >>> Content-Type: message/delivery-status
03954 >>>
03954 >>> Reporting-MTA: dns; bogus.nodomain.nowhere
03954 >>> Received-From-MTA: DNS; localhost
03954 >>> Arrival-Date: Thu, 23 Apr 2020 18:49:51 -0300
03954 >>>
03954 >>> Final-Recipient: RFC822; valid-***@remote-host.com
03954 >>> Action: failed
03954 >>> Status: 5.7.1
03954 >>> Remote-MTA: DNS; smtp.remote-server.com
03954 >>> Diagnostic-Code: SMTP; 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.183
03954 >>> Last-Attempt-Date: Thu, 23 Apr 2020 18:49:55 -0300
03954 >>>
03954 >>> --03NLnt3n003954.1587678595/bogus.nodomain.nowhere
03954 >>> Content-Type: message/rfc822
03954 >>>
03954 >>> Return-Path: <valid-***@remote-host.com>
03954 >>> Received: from bogus.nodomain.nowhere (localhost [127.0.0.1])
03954 >>> by bogus.nodomain.nowhere (8.15.2/8.15.2) with ESMTP id 03NLnp3n003950
03954 >>> for <valid-***@remote-host.com>; Thu, 23 Apr 2020 18:49:51 -0300
03954 >>> Received: (from ***@localhost)
03954 >>> by bogus.nodomain.nowhere (8.15.2/8.15.2/Submit) id 03NLnmQ0003947;
03954 >>> Thu, 23 Apr 2020 18:49:48 -0300
03954 >>> Date: Thu, 23 Apr 2020 18:49:48 -0300
03954 >>> Message-Id: <***@bogus.nodomain.nowhere>
03954 >>> X-Authentication-Warning: bogus.nodomain.nowhere: mds set sender to valid-***@remote-host.com using -f
03954 >>> From: valid-***@remote-host.com (Mike Spencer)
03954 >>> To: valid-***@remote-host.com
03954 >>> Subject: Test of port 587/AUTH/STARTTLS with -X queue
03954 >>> Reply-to: valid-***@remote-host.com
03954 >>>
03954 >>>
03954 >>> Test of port 587/AUTH/STARTTLS with -X queue
03954 >>> log file is man/MAIL/wrk/queue
03954 >>>
03954 >>> --03NLnt3n003954.1587678595/bogus.nodomain.nowhere--
03954 >>>
03954 >>>
03954 >>> --03NLnt3o003954.1587678595/bogus.nodomain.nowhere--
03954 >>>
03954 <<< [EOF]
03954 >>> QUIT
03954 <<< 221 2.0.0 smtp.remote-server.com closing connection

--- END sendmail -X log ---

[Grant Taylor]

Hi Mike,

I'll reply with more details later after reviewing the log file. I
wanted to respond to your other answers / points fairly quickly.

Post by Mike Spencer
This is going to be a long, somewhat messy post.

That seems somewhat apropos for Sendmail not doing something as desired.
;-)

Post by Mike Spencer
Grant, I'll answer your questions where I have an answer, include
the requested files/data.

Perfect.

Post by Mike Spencer
Right host: Yes, remote IP address confirmed in tcpdump
Right port: Yes, port 587 confirmed in tcpdump

Good! That tells me that Sendmail is connecting where you want it to.
Which means that the syntax is likely correct in the configuration files
{mc,cf}.

Post by Mike Spencer
openssl s_client -starttls smtp -connect remote-server.com:587
I've verified that the remote server responds correctly, accepts AUTH
LOGIN and accepts & delivers mail subsequently.

Yep.

Post by Mike Spencer
Not sure what that means.

I was referring to the lines in the sendmail.cf that define the mailer.
I.e.

Mrelay, P=[IPC], F=mDFMuXa8, S=EnvFromSMTP/HdrFromSMTP, R=MasqSMTP,
E=\r\n, L=2040,
T=DNS/RFC822/SMTP,
A=TCP $h 587

This is my current relay mailer definition in my sendmail.cf. I say
current because I've been playing with the TLS support more.

Post by Mike Spencer
"relay mailer" == "delivery agent" per BatBook sec. 20.4?

Yes, I believe that's a fair association.

Sendmail uses the mailer to deliver messages to where they belong, be
that a mailbox, a mailing list, or a remote server.

Post by Mike Spencer
Using mailertable. Converted to mailertable.db with "makemap hash..."
The sendmail.cf is relevant here so the corresponding sendmail.mc
is also included below. Have I screwed up here somehow by putting
"relay" in mailertable instead of "smtp"?

I don't think you've messed anything up.

I was wanting to look at the files to see if there was anything obvious
that might be preventing AUTH from being used.

Post by Mike Spencer
--- BEGIN /etc/mail/mailertable [real host name redacted] ---
. relay:smtp.remote-server.com
--- END /etc/mail/mailertable [real host name redacted] ---

This effectively tells Sendmail that anything through the relay mailer
to smtp.remote-server.com.

One thing that /might/ be influencing this is the lack of square
brackets around smtp.remote-server.com.

By default Sendmail will do an MX lookup on hostnames. You can disable
that by putting square brackets around them.

I don't know if this is related to this issue or not. But
hypothetically, smtp.remote-server.com could have an MX record that
returns otherserver.remote-server.com. Thus Sendmail will really try to
connect to otherserver.remote-server.com. The important thing here is
if the resolved name doesn't match the server for credentials, Sendmail
won't find a match and won't try to use AUTH. Which /might/ explain
what's happening. It will depend if there is an MX record for
smtp.remote-server.com, what it expands to, and how that intersects with
authinfo.

Post by Mike Spencer
--- BEGIN sendmail.mc ---
divert(0)dnl
VERSIONID(`$Id: trial-2.mc, 2020/04/18 mds Exp $')
OSTYPE(`linux')dnl
DOMAIN(`generic')dnl
define(`RELAY_MAILER', `esmtp')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl
FEATURE(`authinfo',`hash -o /etc/mail/authinfo.db')dnl
FEATURE(`mailertable', `hash /etc/mail/mailertable.db')dnl
FEATURE(always_add_domain)dnl
MAILER(local)dnl
MAILER(smtp)dnl
--- END sendmail.mc ---

This all looks okay.

Note: I'm still waking up, so I may miss something.*

*Being completely honest, waking up doesn't change that I could miss
something.

Post by Mike Spencer
Because it's simple and short, I'm including my authinfo file here.

Thank you.

Post by Mike Spencer
If, as it appears, the AUTH command is never sent to the remote server,
the authinfo presumably never gets used.

:-/

So that leaves us wondering why Sendmail isn't attempting to use the
auth info.

Post by Mike Spencer
--- BEGIN authinfo ---
AuthInfo:remote-host.com "U:valid-username" "P:rEdAcTeD" "M:LOGIN"
--- END authinfo ---

And that might be why.

Try changing the line from:

AuthInfo:remote-host.com "U:valid-username" "P:rEdAcTeD" "M:LOGIN"

To:

AuthInfo:smtp.remote-host.com "U:valid-username" "P:rEdAcTeD" "M:LOGIN"

You're dealing with hostnames, not domain names here. The following
three names are completely different when it comes to authinfo:

- remote-host.com
- smtp.remote-host.com
- otherserver.remote-host.com

So, if Sendmail is connecting to smtp.remote-host.com and there is no
entry for smtp.remote-host.com, Sendmail won't try to use AUTH.

This is seeming like a good candidate for the simple toe stubbor that
might be getting you.

Post by Mike Spencer
It appears (see "sendmail -X log", below) that encryption *is* started
but then the AUTH command is never issued to the remote server by
my local sendmail. Do I have that right? I can post tcpdump of the
same session if it would reveal a vital clue.
See "sendmail -X log", below. What the "sendmail -X log" reports
seems to be a failure by my sendmail to issue the AUTH command once
TLS is running.

I'll review the log and reply with more details later.

Post by Mike Spencer
1. Transaction of handing mssg *to* sendmail on localhost.
Seems normal. No crypto or AUTH needed

ACK

Post by Mike Spencer
2. Connect to remote server. My sendmail sends EHLO. The remote
server offers STARTTLS but *not* AUTH

This seems normal to me.

AUTH, particularly PLAIN, needs a secure channel, and unencrypted SMTP
is not.

Post by Mike Spencer
3. My sendmail sends "STARTTLS" Remote replies "Ready to start TLS"
in plaintext

ACK

Post by Mike Spencer
This point can be identified in the tcpdump log.

Good.

Post by Mike Spencer
4. My sendmail sends *another* EHLO Now the remote replies, offering
AUTH PLAIN LOGIN

Seeing that now the connection is inside an encrypted secure channel,
AUTH can safely be used.

Post by Mike Spencer
This is *not visible* in the tcpdump -X output as plaintext, so I
infer that TLS is in effect.

Agreed.

I like how much can be confirmed with a packet capture, even if it's not
possible to decrypt things.

I feel like we know so much more than we did when asked questions yesterday.

Post by Mike Spencer
5. My sendmail does *not* issue the AUTH command. Instead, it

This is what I would expect if there is a mis-match with the server name
in authinfo and the server name that Sendmail is connecting to.

Post by Mike Spencer
The remote server rejects the mssg.

This makes sense.

Post by Mike Spencer
Here's the session log recorded by adding "-X filename" to rc.sendmail,
the script that runs/restarts sendmail.
+ Receiving mssg from my email client
+ Connecting to remote server and attempting to send mssg
+ Reporting failure to root on local host. A mail mssg to root
showed up in /var/spool/mail/root with substantially the same text
as in the session transcript next below.
the server name I use as well as the CNAME of the same host where it
responds with it.

ACK

I'll reply after I have a chance to review the sendmail -X log.

[Mike Spencer]

Post by Grant Taylor
Hi Mike,
I'll reply with more details later after reviewing the log file. I
wanted to respond to your other answers / points fairly quickly.

Post by Mike Spencer
Because it's simple and short, I'm including my authinfo file here.
If, as it appears, the AUTH command is never sent to the remote server,
the authinfo presumably never gets used.

:-/
So that leaves us wondering why Sendmail isn't attempting to use the
auth info.

Post by Mike Spencer
--- BEGIN authinfo ---
AuthInfo:remote-host.com "U:valid-username" "P:rEdAcTeD" "M:LOGIN"
--- END authinfo ---

And that might be why.
AuthInfo:remote-host.com "U:valid-username" "P:rEdAcTeD" "M:LOGIN"
AuthInfo:smtp.remote-host.com "U:valid-username" "P:rEdAcTeD" "M:LOGIN"
You're dealing with hostnames, not domain names here. The following
- remote-host.com
- smtp.remote-host.com
- otherserver.remote-host.com
So, if Sendmail is connecting to smtp.remote-host.com and there is no
entry for smtp.remote-host.com, Sendmail won't try to use AUTH.
This is seeming like a good candidate for the simple toe stubbor that
might be getting you.

That was the problem.

The sys admin told me to direct my mail to smtp.remote-host.com.
That's a valid name with a DNS entry. Using that name in the
mailertable file works as expected (to the extent that local sendmail
obediently opens a connection to the right host.)

But that's not the CNAME of the box in question. The CNAME is
main-box.remote-host.com. And it is the CNAME with which it
identifies itself when the connection is opened on port 587 and
subsequently in response to EHLO.

Putting main-box.remote-host.com in the authinfo file results in AUTH
LOGIN being sent by my sendmail and accepted by the remote server.

For the record, these lines are in /usr/share/sendmail/cf/README:

The authinfo ruleset looks up {server_name} using the tag
AuthInfo: in the access map. If no entry is found,
{server_addr} is looked up in the same way and finally just
the tag AuthInfo: to provide default values.

Note: searches for domain parts or IP nets are ONLY PERFORMED IF
THE ACCESS MAP IS USED; if the authinfo feature is used then ONLY
UP TO THREE LOOKUPS ARE PERFORMED (two exact matches, one
default).

Bat Book 10.9.3.2 is not clear on this. And neither BB nor README
mention the matter of some-valid-hostname versus CNAME. Author of
article at [1] in section "Client-Side SMTP AUTH + SMART_HOST" refers
to the authinfo line with a space after "Authinfo:" instead of a
hostname but doesn't understand that it's a default.

Now I have authinfo like this

AuthInfo:main-box.remote-host.com "U:usernaame" "P:PasWoRd" "M:LOGIN"
AuthInfo: "U:usernaame" "P:PasWoRd" "M:LOGIN"

And I owe you an apology because I screwed up the log file I posted
last. When I redacted real hostnames, I replace both
smtp.remote-host.com and main-box.remote-host.com with the same
substitute name, probably depriving you of a glaring clue that your
notion (quoted near the beginning of this reply) might be correct.
Mea culpa.

So I have sent *one* mssg via port 587 and the mssg was delivered.
Remains to be seen how well it will work with daily usage but I'm
very hopeful.

Thank you *so* much for your help and attention. If you're ever in
the neighborhood, I owe you a cold beer or $BEVERAGE_OF_CHOICE.

- Mike


[1] https://www.linuxquestions.org/questions/showthread.php?postid=1144343#post1144343

[Grant Taylor]

Post by Mike Spencer
That was the problem.

:-)

Post by Mike Spencer
The sys admin told me to direct my mail to smtp.remote-host.com.
That's a valid name with a DNS entry. Using that name in the
mailertable file works as expected (to the extent that local sendmail
obediently opens a connection to the right host.)

*nod*

Post by Mike Spencer
But that's not the CNAME of the box in question. The CNAME is
main-box.remote-host.com. And it is the CNAME with which it identifies
itself when the connection is opened on port 587 and subsequently in
response to EHLO.

I was wondering if such was the case.

Note: I think the canonical name that the CNAME record refers is MUCH
more important than what the server HELOs / EHLOs as. — Think about it
this way, changing what credentials are sent based on information the
remote server provides is a potential security vulnerability.

Post by Mike Spencer
Putting main-box.remote-host.com in the authinfo file results in AUTH
LOGIN being sent by my sendmail and accepted by the remote server.

Yay!

Post by Mike Spencer
in the access map. If no entry is found, {server_addr} is looked
up in the same way and finally just the tag AuthInfo: to provide
default values.

That means that Sendmail is looking up the following, in this sequence:

AuthInfo:main-box.remote-host.com creds
main-box.remote-host.com creds
AuthInfo: creds

Post by Mike Spencer
Note: searches for domain parts or IP nets are ONLY PERFORMED IF THE
ACCESS MAP IS USED; if the authinfo feature is used then ONLY UP TO
THREE LOOKUPS ARE PERFORMED (two exact matches, one default).

This tells me that a subset of the access map / Access DB is used if the
access_db FEATURE isn't also used.

Or said another way, FEATURE(`access_db') enables more granular searches
for AuthInfo:.

Post by Mike Spencer
Bat Book 10.9.3.2 is not clear on this. And neither BB nor README
mention the matter of some-valid-hostname versus CNAME.

It might not mention it in the context you were reading.

But CNAMEs are a known toe stubbor in Sendmail. I'm confident they are
discussed, possibly at length, elsewhere and that knowledge is expected
to apply anywhere that CNAMEs might be encountered. Much like MX
lookups unless the name is enclosed in square brackets.

Post by Mike Spencer
Author of article at [1] in section "Client-Side SMTP AUTH +
SMART_HOST" refers to the authinfo line with a space after "Authinfo:"
instead of a hostname but doesn't understand that it's a default.

ACK

Post by Mike Spencer
Now I have authinfo like this
AuthInfo:main-box.remote-host.com "U:usernaame" "P:PasWoRd" "M:LOGIN"
AuthInfo: "U:usernaame" "P:PasWoRd" "M:LOGIN"

I would probably remove the default.

That will cause Sendmail to send (leak) your credentials to any server
it connects to that offers AUTH.

Granted, this might not be a problem for your use case, with a smart
host. But it's unnecessary, and a potential leak is worth avoiding if
possible.

Post by Mike Spencer
And I owe you an apology because I screwed up the log file I
posted last. When I redacted real hostnames, I replace both
smtp.remote-host.com and main-box.remote-host.com with the same
substitute name, probably depriving you of a glaring clue that your
notion (quoted near the beginning of this reply) might be correct.
Mea culpa.

Apology returned to sender as it's unnecessary.

I was able to see what I wanted to in the logs you provided. As you've
seen, I have no qualms asking for more details.

Post by Mike Spencer
So I have sent *one* mssg via port 587 and the mssg was delivered.
Remains to be seen how well it will work with daily usage but I'm
very hopeful.

That's a start.

Good luck.

Post by Mike Spencer
Thank you *so* much for your help and attention. If you're ever in
the neighborhood, I owe you a cold beer or $BEVERAGE_OF_CHOICE.

You're quite welcome. :-)

Feel free to reply to this thread, start a new thread, or email me
directly if you need / want more help.

Aside: That applies to anybody really.

[Mike Spencer]

Post by Grant Taylor

But that's [hostname in mailertable] not the CNAME of the box in
question. The CNAME is main-box.remote-host.com. And it is the
CNAME with which it identifies itself when the connection is opened
on port 587 and subsequently in response to EHLO.

I was wondering if such was the case.
Note: I think the canonical name that the CNAME record refers is MUCH
more important than what the server HELOs / EHLOs as. -- Think about
it this way, changing what credentials are sent based on information
the remote server provides is a potential security vulnerability.

Good point. You're suggesting that sendmail does a DNS lookup of the
hostname it *thinks* it's talking to and uses that to ascertain the
CNAME of that host? That doesn't show up in the log output from
"sendmail -X logfilename" but I suppose it could be determined by
close scrutiny of a packet dump. In any case, look like a good idea.

Post by Grant Taylor

Now I have authinfo like this
AuthInfo:main-box.remote-host.com "U:usernaame" "P:PasWoRd" "M:LOGIN"
AuthInfo: "U:usernaame" "P:PasWoRd" "M:LOGIN"

I would probably remove the default.
That will cause Sendmail to send (leak) your credentials to any
server it connects to that offers AUTH.
Granted, this might not be a problem for your use case, with a smart
host. But it's unnecessary, and a potential leak is worth avoiding
if possible.

Right, probably not a problem with a single designated smart host but
potential for trouble if connection to designated host goes awry.

Post by Grant Taylor

So I have sent *one* mssg via port 587 and the mssg was delivered.
Remains to be seen how well it will work with daily usage but I'm
very hopeful.

That's a start.

Several mssgs now sent via new setup. All logged as "accepted for
delivery" by the smarthost. Those for which I can verify delivery
were delivered. Looks good.

Post by Grant Taylor
Feel free to reply to this thread, start a new thread, or email me
directly if you need / want more help.
Aside: That applies to anybody really.

Generous offer. Email address filed for future reference.

I hope I'm done with this thread now. Tnx to all who offered help.

I have yet to rejigger the script that swaps in/out files in /etc/mail
to match the particular ISP I'm connecting through or the preferred
outbound mail routing. The whole point here was to have one remote
smarthost usable from any connection including random public wifi
locations. But I want the other routes available as backup.

In the last major power outage, our lightly used, newish gen set (that
had been test-run the previous week) failed. But we kept our freezers
going because we had a mil surplus, Korean War-vintage genset as
backup. Only 1500 W but enough for the freezers & fridge. Same
principle with having more than one outbound mail route.

Thanks again,

[Grant Taylor]

Post by Mike Spencer
Several mssgs now sent via new setup. All logged as "accepted for
delivery" by the smarthost. Those for which I can verify delivery
were delivered. Looks good.

I think that it's quite likely going to work. The problem that was
found would definitely cause the symptoms that were seen.

I like having a very clear cause / solution for a problem.

Post by Mike Spencer
Generous offer. Email address filed for future reference.

:-)

Post by Mike Spencer
I have yet to rejigger the script that swaps in/out files in /etc/mail
to match the particular ISP I'm connecting through or the preferred
outbound mail routing. The whole point here was to have one remote
smarthost usable from any connection including random public wifi
locations. But I want the other routes available as backup.

I believe there is a Fall Back MX host option. You might want to look
into that. Perhaps you can configure Sendmail to have affinity to your
Smart Host and fall back to an alternate when the Smart Host is
inaccessible for some reason.

Post by Mike Spencer
Thanks again,

You're welcome.

[Grant Taylor]

Post by Mike Spencer
That's not much more clear than the bounce mssg. :-o The intended
correct and is a valid username on that ISP's system. I get email
to that account all the time. So: possible misconfig on their server.

Did my other replies help shed any light on the possible reason for the
errors and what they might mean?

Would you be willing to share your DSN with us? Possibly redacted.
There's likely something in it that would mean something to us that
might not yet mean anything to you.

Post by Mike Spencer
Whether some error/failure occurs in the RCPT TO: part of the SMTP
exchange isn't clear. With simple SMTP on port 25 I would telnet to
port 25 and try it manually to determine where the problem arises.
On port 587 with STARTTLS I can't (AFAIK) do that. For example,
I have no way to determine what is being sent following the HELO or
EHLO when my localhost has a 10.0.0.0 address.

As you indicate in another post, there is a way for you to test.

There's also the possibility of having Sendmail save the ephemeral key
information (via hacking the source) and having Wireshark decrypt the
traffic. You can also capture the traffic between Sendmail and your
ESP, send the packet capture to them and ask them to decrypt it with
their access to the server's private key.

There are ways. }:-)

They just might not be convenient ways.

Post by Mike Spencer
That is what the AUTH command/mechanism (RFC 4964) is supposed to deal
with and what I'm trying to implement. So this implies a failure,
at my end or the remote server's end, in the authentication step
using AUTH. I've tried using (in my authinfo file) both "U:username"
in the same way.

This is where the packet capture really sines. You can see what's
happening. (Presuming that you can get it decrypted.)

There is also a chance that Sendmail isn't using the MSA port as
expected combined with the fact that some email server operators don't
offer SMTP Authentication on the MSA port. If Sendmail is using the MTA
port (25) and the ESP doesn't offer SMTP Auth on it, that's probably why
SMTP Auth isn't being used. That would also account for why typical MTA
anti-spam checks of reverse DNS are being applied to your connection.

A packet capture will easily show you the ports being used, even if you
can't decrypt it.

Post by Mike Spencer
Either of the above alternatives could derive from a config error at my
end or at the server. Hoping the admin can help but he's off Sundays.

I've learned to really like packet captures. tcpdump is one of the
earlier tools that I'll reach for when anything network related is
involved. That or Wireshark.

Post by Mike Spencer
Which is a potential problem. My desktop has a non-routable
address in 10.0.0.0/8. I assume (??) that the address the server
sees is whetever routable address is held by the "gateway device".

Most definitely.

Depending on the wording of the "fix your DNS" message, it might tell
you what the server thinks your IP is.

The packet capture will likely show you want the server thinks that your
IP is in the "hello such and such, nice to meet you" reply to your EHLO
command.

Post by Mike Spencer
The gateway device uses a SIM card to connect to the net via Telus and
(I'm guessing here) negotiates a new routable address each time it's
powered up. Sending email through Telus' own SMTP server on port 25
works as expected. The present failure is in connecting to the net
via Telus but sending mail through other-isp.ca using AUTH.

The port, encryption, and authentication are *CRITICAL* for this to work.

That being said, it should be completely possible to make this work.

Post by Mike Spencer
Well, the ISP through whose server I'm trying to send is the same
local mom 'n pop ISP who's been providing dialup service for 20 years
and the one where I receive all my email. The admin understands what
I'm doing, knows I'm not running a net-exposed mail server. (He even
knows a bit about Linux. :-) Telus, on the other hand, is a megacorp
with all the attendant shortcomings in getting support (different
support person on every contact; different policy assertions from
different people; exploding head when Liux is mentioned; you know...).

Yep.

I've stuck with many small providers that I can work with over my career.

Post by Mike Spencer
See above. It's really too bad that the mom 'n pop local ISP can't
offer any kind of high-speed connection in my area. Would happily
pay a surcharge for the service to get their end-to-end support.

There may be something that's preventing them from doing it.

[Mike Spencer]

Post by Grant Taylor
Did my other replies help shed any light on the possible reason for the
errors and what they might mean?

Some, consistent with what I'm gradually (tediously :-) weaseling out.
Your "define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl" was the essential
item to get sendmail talking to the right port.

Hmm... I guess I better look at a packet dump or something to verify
that sendmail really *is* doing that.

Post by Grant Taylor
Would you be willing to share your DSN with us? Possibly redacted.
There's likely something in it that would mean something to us that
might not yet mean anything to you.

Post by Mike Spencer

DATA

<<< 550 5.7.1 <valid-***@remote-host.com>... Fix reverse DNS for 142.169.78.237
550 5.1.1 <valid-***@remote-host.com>... User unknown
<<< 503 5.0.0 Need RCPT (recipient)

(142.169.78.237 is a Telus host somewhere with no RDNS. Remote-host.com
gets its IP block from a very different backbone provider.)

I think we're agreed that this happens because STARTTLS has failed and
& subsequent AUTH never happens.

Post by Grant Taylor
[ packet capture etc.]

Don't have wireshark running on this machine yet. Trying to get
adequate info from tcpdump -X. More on that later if warranted.

Post by Grant Taylor

Post by Mike Spencer
It's really too bad that the mom 'n pop local ISP can't
offer any kind of high-speed connection in my area. Would happily
pay a surcharge for the service to get their end-to-end support.

There may be something that's preventing them from doing it.

No cable on this road. No telco box near enough for ADSL copper, let
alone fiber. Only HS service is "rural wireless" (that turned out to
be a financial fiasco for the contracting cableco and is
technologically 2nd rate by current standards) or cellco/SIM card
service. Mom & Pop may be a reseller for net-over-cable but not rural
wireless.

[Grant Taylor]

Post by Mike Spencer
Some, consistent with what I'm gradually (tediously :-) weaseling out.

:-)

Post by Mike Spencer
Your "define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl" was the essential
item to get sendmail talking to the right port.

That makes the implicit assumption that the relay mailer is being used
and not a different mailer.

There are other similar definitions for some of the other mailers.

Post by Mike Spencer
Hmm... I guess I better look at a packet dump or something to verify
that sendmail really *is* doing that.

Yep.

First, find out what Sendmail is doing. Second, if it's not what you
expect, find out why it's not doing what you expect.

Post by Mike Spencer
<<< 503 5.0.0 Need RCPT (recipient)

Yep.

Post by Mike Spencer
(142.169.78.237 is a Telus host somewhere with no RDNS. Remote-host.com
gets its IP block from a very different backbone provider.)

ACK

Post by Mike Spencer
I think we're agreed that this happens because STARTTLS has failed
and & subsequent AUTH never happens.

That'd definitely a concern that needs to be checked out.
ACK

Do you see AUTH listed in the response to EHLO?

What about if you use openssl s_client to do the same thing but with
STARTTLS?

Post by Mike Spencer
Don't have wireshark running on this machine yet. Trying to get
adequate info from tcpdump -X. More on that later if warranted.

I think that tcpdump is sufficient for identifying the port.

You can also use tcpdump to capture to a file, transfer the file to a
machine with Wireshark, and use Wireshark to look at the capture. ;-)

Post by Mike Spencer
No cable on this road. No telco box near enough for ADSL copper,
let alone fiber. Only HS service is "rural wireless" (that turned
out to be a financial fiasco for the contracting cableco and is
technologically 2nd rate by current standards) or cellco/SIM card
service. Mom & Pop may be a reseller for net-over-cable but not
rural wireless.

I get it.

[Jerry Peters]

Post by Mike Spencer

Post by Rich

Post by Mike Spencer
Attempts to send to my own account (same server, ISP) via designated
"user unknown" and "Fix reverse DNS for [IP]". Don't understand
where the problem is.

Those two responses indicate that the "smarthost" does not recognize
your username (meaning either it does not recognize the name part of
the email you are sending as one it receives...

Well.... um... :-)
That's not much more clear than the bounce mssg. :-o The intended
correct and is a valid username on that ISP's system. I get email to
that account all the time. So: possible misconfig on their server.
Whether some error/failure occurs in the RCPT TO: part of the SMTP
exchange isn't clear. With simple SMTP on port 25 I would telnet to
port 25 and try it manually to determine where the problem arises. On
port 587 with STARTTLS I can't (AFAIK) do that. For example, I have
no way to determine what is being sent following the HELO or EHLO when
my localhost has a 10.0.0.0 address.

Set up stunnel to connect to the smarthost, then you can telnet into
localhost <local port> and see what the server is expecting.
Example:

[smtp]
accept = 26
delay = yes
#connect = imailhost.worldnet.att.net:465 # old
connect = smtp.att.yahoo.com:465

Note that delay must be before connect to work.

[Grant Taylor]

Post by Jerry Peters
Set up stunnel to connect to the smarthost, then you can telnet into
localhost <local port> and see what the server is expecting.

That will work /if/ the smart host offers SMTPS on TCP port 465. Not
all smart hosts do.

Seeing as how the mail server admin told the OP to use the MSA port 587,
that's not a safe assumption.

[Grant Taylor]

Post by Rich
The fix reverse DNS means it was trying to do an IP to DNS name lookup
on the IP you sent from, and there was no IP->name mapping to be found.

This type of check shouldn't be happening on an MSA (port). It is an
anti-spam measure intended for MTAs.

MSAs are intended as the connection from users somewhere in the wild
west that is the Internet.

This type of filtering /may/ be being applied because authentication is
failing for some reasons.

[Grant Taylor]

Post by Mike Spencer
Noted. I've just put together the advice from aols and elsewhere in
my sendmail{mc,cf}, mailertable and authinfo files.

We've all collected little notes and tidbits from various places over
the years.

Post by Mike Spencer
Attempts to send to my own account (same server, ISP) via designated
smarthost server rejected.

Hum. :-/

Post by Mike Spencer
reverse DNS for [IP]". Don't understand where the problem is.

The "unknown user" could be a red herring. That tends to frequently be
a default catch all error message, for various reasons.

"Fix reverse DNS..." tells me that the receiving system isn't
considering you as authenticated to send. Hence it's applying typical
anti-spam rules to your supposedly authenticated connection.

Post by Mike Spencer
Awaiting response to my detailed query from the server admin.

I'll be curious to lean what the admin thinks.

Post by Mike Spencer
Yes, fuvgpnaavat sendmail and replacing it with postfix (or something
else?) is a possibility if we can't work this out.

Obviously I'm biased towards Sendmail. }:-)

Post by Mike Spencer
The mail server guy is great but support from the ISP through which
I can now get reasonably high speed connection is umm... problematic.

That's the wonderful thing about submission on TCP ports 465 & 587. You
are supposed to be able to use those from (ideally) anywhere in the
world. So your actual connection method & provider shouldn't matter.

Post by Mike Spencer
Tnx for the suggestion,

:-)

[Mike Spencer]

Post by Grant Taylor

Post by Mike Spencer
I've just put together the advice from aols and elsewhere in
my sendmail{mc,cf}, mailertable and authinfo files.
[snip]
reverse DNS for [IP]". Don't understand where the problem is.

The "unknown user" could be a red herring. That tends to frequently be
a default catch all error message, for various reasons.
"Fix reverse DNS..." tells me that the receiving system isn't
considering you as authenticated to send. Hence it's applying typical
anti-spam rules to your supposedly authenticated connection.

Yes, both of those. I'm pretty sure now the problem is that STARTTLS
issued by sendmail on localhost fails. The "Fix RDNS" occurs because
the remote server falls back to verifying that I'm connecting from
a remote-host.com domain address. (Which I'm not.)

The command (new to me; learn something every day :-):

openssl s_client -starttls smtp -connect remote-host.com:587

does STARTTLS successfully and allows me to do EHLO, invoke AUTH
LOGIN, do the challenge/response manually and send email that is
delivered.

Using sendmail on localhost in the usual way, connecting to the net
via Telus but trying to send mail through non-Telus remote-host.com,
maillog reports:

Apr 22 17:19:53
bogus sm-mta[7015]:
STARTTLS=client, relay=remote-host.com,
version=TLSv1.2, verify=FAIL,
cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256

Post by Grant Taylor

Post by Mike Spencer
Awaiting response to my detailed query from the server admin.

I'll be curious to lean what the admin thinks.

He has been unusually slow to respond. But this mess includes problems
sending email to the domain owning the server. I'll have to resend.

Post by Grant Taylor
That's the wonderful thing about submission on TCP ports 465 & 587. You
are supposed to be able to use those from (ideally) anywhere in the
world. So your actual connection method & provider shouldn't matter.

Exactly.

[Grant Taylor]

Post by Mike Spencer
Yes, both of those. I'm pretty sure now the problem is that STARTTLS
issued by sendmail on localhost fails. The "Fix RDNS" occurs because
the remote server falls back to verifying that I'm connecting from
a remote-host.com domain address. (Which I'm not.)

ACK

Post by Mike Spencer
openssl s_client -starttls smtp -connect remote-host.com:587

ProTip: Some servers are *EXTREMELY* pedantic in the <CR><LF> they
expect to see. OpenSSL's s_client has a -crlf (or something like that)
option to cause it to send end-of-line characters as <CR><LF>. If you
ever run into that, it will be as if the remote system doesn't think you
hit enter (sent <CR><LF>).

Post by Mike Spencer
does STARTTLS successfully and allows me to do EHLO, invoke AUTH LOGIN,
do the challenge/response manually and send email that is delivered.
Using sendmail on localhost in the usual way, connecting to the net
via Telus but trying to send mail through non-Telus remote-host.com,
Apr 22 17:19:53
STARTTLS=client, relay=remote-host.com,
version=TLSv1.2, verify=FAIL,
cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256

See one of tonight's other replies. I don't see anything wrong with
this log. The "verify=FAIL" doesn't concern me. It only mildly annoys me.

Post by Mike Spencer
He has been unusually slow to respond. But this mess includes problems
sending email to the domain owning the server. I'll have to resend.

Considering current events, I'd give them a few more days. ;-)

[Chris Vine]

On 19 Apr 2020 02:57:58 -0300

Post by Mike Spencer

Post by Rich
[sendmail group excluded in this reply]

Post by Mike Spencer
I went to alt.os.linux.slackware first in the belief that, since
Slackware is distributed with sendmail, there might more likely be
users there who'd been in my situation

Do note that "ships with" does not necessarially equate to "utilized by
the admin".
The first two steps I perform for any Slackware install that is going
1) removepkg sendmail
2) installpkg postfix
(https://slackbuilds.org/repository/14.2/network/postfix/)

Noted. I've just put together the advice from aols and elsewhere in
my sendmail{mc,cf}, mailertable and authinfo files. Attempts to send
to my own account (same server, ISP) via designated smarthost server
"Fix reverse DNS for [IP]". Don't understand where the problem is.
Awaiting response to my detailed query from the server admin.
Yes, fuvgpnaavat sendmail and replacing it with postfix (or something
else?) is a possibility if we can't work this out. The mail server
guy is great but support from the ISP through which I can now get
reasonably high speed connection is umm... problematic.

For what it is worth I have a postfix server running on localhost port
25 on my machine which will forward my outgoing mail to the appropriate
SMTP server. So emails expressed to come from my gmail account go on
to smtp.gmail.com via TLS on port 587, and emails from a plusnet account
go on to relay.plus.net (which uses SASL but not TLS) and so on, and
thence to the ultimate recipient.

This is a very lengthy exchange so I don't know if this resembles
what you are trying to do, but if so it's relatively trivial to set up -
merely a matter of setting up the sender_dependent_relayhost_maps,
smtp_tls_policy_maps and smtp_sasl_password_maps options in main.cf.
If you only have one SMTP relay to forward to it would of course be
easier: you wouldn't need mapping files, but it's nice to keep the
flexibility.

I have not used sendmail for 10 years and I miss it not at all.

[Grant Taylor]

Post by Chris Vine
For what it is worth I have a postfix server running on localhost
port 25 on my machine which will forward my outgoing mail to the
appropriate SMTP server. So emails expressed to come from my gmail
account go on to smtp.gmail.com via TLS on port 587, and emails from a
plusnet account go on to relay.plus.net (which uses SASL but not TLS)
and so on, and thence to the ultimate recipient.

What port do you connect to on plus net? 25 / 465 / 587

Post by Chris Vine
This is a very lengthy exchange so I don't know if this resembles what
you are trying to do, but if so it's relatively trivial to set up -
merely a matter of setting up the sender_dependent_relayhost_maps,
smtp_tls_policy_maps and smtp_sasl_password_maps options in main.cf.

I would be curious in seeing how you are choosing smart hosts / relays
based on the source domain.

Post by Chris Vine
If you only have one SMTP relay to forward to it would of course
be easier: you wouldn't need mapping files, but it's nice to keep
the flexibility.

ACK

Post by Chris Vine
I have not used sendmail for 10 years and I miss it not at all.

To each their own.

During a discussion in another newsgroup, I briefly considered adding a
new protocol to Sendmail via a new mailer. I don't know how easy it is
to do something like that with Postfix. It's relatively trivial with
Sendmail.

[Chris Vine]

On Thu, 23 Apr 2020 09:01:19 -0600

Post by Grant Taylor

Post by Chris Vine
For what it is worth I have a postfix server running on localhost
port 25 on my machine which will forward my outgoing mail to the
appropriate SMTP server. So emails expressed to come from my gmail
account go on to smtp.gmail.com via TLS on port 587, and emails from a
plusnet account go on to relay.plus.net (which uses SASL but not TLS)
and so on, and thence to the ultimate recipient.

What port do you connect to on plus net? 25 / 465 / 587

587

Post by Grant Taylor

Post by Chris Vine
This is a very lengthy exchange so I don't know if this resembles what
you are trying to do, but if so it's relatively trivial to set up -
merely a matter of setting up the sender_dependent_relayhost_maps,
smtp_tls_policy_maps and smtp_sasl_password_maps options in main.cf.

I would be curious in seeing how you are choosing smart hosts / relays
based on the source domain.

First it is worth examining how you can forward with postfix using only
one mail relay, which I will assume for the sake of the argument uses
SASL with TLS encryption. I would generally add something like this to
the top of main.cf (obviously relay addresses, usernames and passwords
are fictitious). I am not a security expert, nor an SMTP server
expert, YMMV, it works for me, E&OE:

--------------------------------------

relayhost = smtp.relay.net:587
smtpd_use_tls = yes
smtp_sasl_auth_enable = yes

# This forces encryption using STARTTLS
smtp_tls_security_level = encrypt

smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_mechanism_filter = plain
smtp_sasl_tls_security_options = noanonymous

sasl_passwd contains something like this:

smtp.relay.net:587 my_name:my_password

--------------------------------------

If I want to add other provision for, say, email using gmail addresses,
I can keep smtp.relay.net as the default but then override it for the
particular gmail cases. You can also make TLS optional. Let's assume
that the default smtp.relay.net is not to use TLS but gmail emails are
to do so, which is in fact the position I am in. I have something like
this I am not a security expert, nor an SMTP server expert, YMMV, it
works for me, E&OE:

--------------------------------------

relayhost = smtp.relay.net:587
smtpd_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sender_dependent_authentication = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_mechanism_filter = plain
smtp_sasl_tls_security_options = noanonymous

sasl_passwd contains something like this:

# sender dependent sasl authentication
***@gmail.com ***@gmail.com:user1_password
***@gmail.com ***@gmail.com:user2_password

# sasl authentication for default relay
smtp.relay.net:587 my_name:my_password

sender_relay contains something like this:

***@gmail.com [smtp.gmail.com]:587
***@gmail.com [smtp.gmail.com]:587

tls_policy contains something like:

[smtp.gmail.com]:587 encrypt

If you want every relay to use TLS encryption, then you don't need the
policy map. You can just set the security level to encrypt and leave
it at that. I use procmail to handle stuff sent from localhost to
localhost (other incoming mail is via POP), so in addition I have
mailbox_command set to /usr/bin/procmail. I also have myhostname set.
The postfix documentation is pretty good.

[Grant Taylor]

Thank you Chris.

That's the exact type of information I was hoping to see when I asked. :-)

[Grant Taylor]

Post by Mike Spencer
I went to alt.os.linux.slackware first in the belief that, since
Slackware is distributed with sendmail, there might more likely
be users there who'd been in my situation while (just guessing)
comp.mail.sendmail would be largely populated by people admining
servers exposed to the net with all the attendant complications.

I don't fault your logic.

I got started with Sendmail on Slackware back in '98 or '99.

[Henrik Carlqvist]

I'm back. Stunnel is working nicely for fetching mail via POP3 on port
995. Now I have a new problem.
I need to contrive that sendmail, running on localhost, hands outgoing
mail to port 587 on a particular remote host using AUTH/STARTTLS.
Been using sendmail to smarthost for years, connecting to port 25 on my
own ISP's network where no auth is required. Now I need to connect to
the net with one ISP but smarthost mail through another so auth with
STARTTLS on port 587 is required.

Many years ago I used to run sendmail even without any smart relay host
for my outgoing email and fetchmail to sendmail for my incoming email.

As many started to blacklist dial up IP addresses I instead of having
sendmail on localhost for outgoing mail configured my email client (today
sylpheed, back then maybe something like netscape) to use different SMTP
servers for my different email accounts. I don't have any email account
at my ISP, instead I have different email accounts at web hotels.

I prefer this solution instead of configuring sendmail as I have
different email accounts at different web hotels and at least in theory
if I would add another user to my machine I would prefer that user to
configure his/her own email client instead of sending outgoing emails
through my credentials at the ISP.

The only thing I miss by having outgoing email from my email client to
the web hotels SMTP servers instead of going through sendmail is the log
messages saying that my local sendmail has passed my mails on.

regards Henrik

[Grant Taylor]

Post by Henrik Carlqvist
I prefer this solution instead of configuring sendmail as I have
different email accounts at different web hotels and at least in
theory if I would add another user to my machine I would prefer that
user to configure his/her own email client instead of sending outgoing
emails through my credentials at the ISP.

The credentials are used to identify the sending client to the relaying
server. These credentials are usually independent of the email being
sent, or the SMTP envelope being sent. Usually. Some providers make an
association.

Said another way, the credentials (usually) identify the sending device,
not what is being sent.

Post by Henrik Carlqvist
The only thing I miss by having outgoing email from my email client
to the web hotels SMTP servers instead of going through sendmail is
the log messages saying that my local sendmail has passed my mails on.

I'm quite confident that it should be possible to do that with Sendmail.
Though I don't know any solution off hand.

I suspect it would be somewhat custom and choose the mailer (or it's
destination smart host) to use based on the SMTP envelope address. This
should be possible to do. But I don't know as I've not done it.