sendmail as relay client over port 465 with SSL
Nietzsche
ISP via smtps over port 465, I followed the instructions here:
http://www.sendmail.org/~ca/email/auth.html#authinstsendmail
Basically:
build sendmail with SASL
# mkdir /etc/mail/auth
# chmod 700 /etc/mail/auth
Add AuthInfo:your.isp.net "U:root" "I:user" "P:password"
to /etc/mail/auth/client-info
makemap hash client-info < client-info
# chmod 600 client-info*
add the following to the sendmail.mc file:
define(`RELAY_MAILER_ARGS', `TCP $h 465')
define(`ESMTP_MAILER_ARGS', `TCP $h 465')
define(`SMART_HOST',`your.isp.net')dnl
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5
LOGIN PLAIN')dnl
FEATURE(`authinfo',`hash /etc/mail/auth/client-info')dnl
Build and install sendmail.cf file, run sendmail.
So far everything has gone smoothly but when I try to send a message I
get:
<sc00...@yahoo.com>... Connecting to
mx1.balanced.randy.mail.dreamhost.com. port 465 via relay...
<sc00...@yahoo.com>... Deferred: Connection refused by
mx1.balanced.randy.mail.dreamhost.com.
The only info I can get from dreamhost is that I need SSL and port 465.
And it works fine with any mail client (like thunderbird for example).
I tried increasing the debug level of sendmail but I don't get any more
info.
Anyone have even a remote clue as to what I good do to trouble shoot?
Per Hedeland
"Nietzsche" <sc00...@yahoo.com> writes:
>Been trying to set up sendmail so I can use my laptop relay through my
>ISP via smtps over port 465,
Sendmail doesn't do client-side SMTPS, but read on...
> I followed the instructions here:
>http://www.sendmail.org/~ca/email/auth.html#authinstsendmail
Nothing about SSL there:-) (the canonical page for info about that,
beyond what is in the bundled docs, is
http://www.sendmail.org/~ca/email/starttls.html).
>Add AuthInfo:your.isp.net "U:root" "I:user" "P:password"
>define(`SMART_HOST',`your.isp.net')dnl
I assume the "your.isp.net" isn't literal...
><sc00...@yahoo.com>... Connecting to
>mx1.balanced.randy.mail.dreamhost.com. port 465 via relay...
><sc00...@yahoo.com>... Deferred: Connection refused by
>mx1.balanced.randy.mail.dreamhost.com.
You need to use `[your.isp.net]' (still not literally) for SMART_HOST,
i.e. put the host name in [brackets]. This avoids the MX resolution
which makes you end up at the "wrong" host. ISP instructions are
generally targeted at MUAs, which don't do MX resolution (why so many
ISPs put in MX records for their "smarthost" is still a mystery).
>The only info I can get from dreamhost is that I need SSL and port 465.
Well, if you *really* need that, you can't manage with sendmail alone,
see above. Possibly you could set it up to use 'stunnel'. But ISP
instructions should be taken with a big grain of salt:-), it is quite
likely that besides the non-standard SMTPS on port 465 they're also
doing the standard STARTTLS on port 25, just that they've found that
sticking to the above line causes the least amount of subsequent support
calls...
As a quick feasibility test, you can telnet to port 25 on the smarthost
and issue a 'EHLO your.host.name' command (quit with QUIT). If the
response includes STARTTLS, at least the SSL (TLS) part should work w/o
any special sendmail config (i.e. get rid of the *_MAILER_ARGS
definitions) - the AUTH part may still have problems though (e.g. they
may not have it configured for port 25).
>I tried increasing the debug level of sendmail but I don't get any more
>info.
"Connection refused" is 100% info, nothing more to be had.:-) It means
that sendmail tried to connect to a port where no process is listening
(the MX host you ended up at doesn't do SMTPS / port 465).
--Per Hedeland
p...@hedeland.org
Nietzsche
Thanks for the feedback, Per.
I think http://www.sendmail.org/~ca/email/starttls.html is for if I
wanto t authenticate users. All I'm asking sendmai to do as a smarthost
is connect to port 465 and send my username and passwd. Can it be that
difficult to get sendmail to to what outlook does or any other relay
does?
Someone else in another thread has the same set up as me for username
and pas via 465 and says it works ok. I replaced the mx records with
[ip addresses] and sendmail connects to the right host on the right
port (I see it with netstat), but then times out with a read error. I'm
so close. I just wish I could see more of the transaction conversation.
I tried running ethereal but got a bunch of illegible junk. Maybe it's
tme to try postfix or qmail.
Per Hedeland
"Nietzsche" <sc00...@yahoo.com> writes:
>
>I think http://www.sendmail.org/~ca/email/starttls.html is for if I
>wanto t authenticate users.
Not really - it deals with how to do SMTP with SSL/TLS, which is what
you want to do, but it's mostly for the server side since client-side
STARTTLS doesn't really require any config - and it doesn't deal at all
with client-side SMTPS, which is the method you think you need to use.
> All I'm asking sendmai to do as a smarthost
>is connect to port 465 and send my username and passwd. Can it be that
>difficult to get sendmail to to what outlook does or any other relay
>does?
No, just that someone has to write the code that implements it... The
thing is, this practice of just "wrapping" TCP sessions in SSL and using
a separate port, which is at least the de facto standard for HTTP
(i.e. HTTPS), is generally deprecated in favor of "STARTTLS" type
mechanisms, where you initiate a cleartext session on the standard port
and then negotiate a switch to SSL/TLS in the same session.
For HTTP, we will clearly always have HTTPS (though there is a STARTTLS
equivalent for HTTP too these days), but for SMTP, the "wrapping" SMTPS
variant didn't become pervasive before the SMTP STARTTLS was formally
standardized. So, when SSL support for sendmail was implemented, with
limited resources, it was natural to go for the standard STARTTLS rather
than the SMTPS "hack". Later SMTPS *server side* support was
implemented, since there were MUAs out there that could do that but not
STARTTLS. MTAs that can do SMTPS but not STARTTLS are very unusual I
think, which doesn't motivate the effort to implement client-side SMTPS
for sendmail.
>Someone else in another thread has the same set up as me for username
>and pas via 465 and says it works ok.
Well, there is a misunderstanding about what is being done in that case
- of course sendmail can do client-side *cleartext* SMTP with any
destination port, but the code for client-side SMTPS just isn't there.
> I replaced the mx records with
>[ip addresses] and sendmail connects to the right host on the right
>port (I see it with netstat), but then times out with a read error. I'm
>so close. I just wish I could see more of the transaction conversation.
>I tried running ethereal but got a bunch of illegible junk.
No, you're not close at all, and the illegible junk is probably the
remote sending SSL while sendmail is waiting for a cleartext SMTP
greeting - it won't help if you can decode it.
> Maybe it's tme to try postfix or qmail.
Or try what I recommended:
>> Possibly you could set it up to use 'stunnel'. But ISP
>> instructions should be taken with a big grain of salt:-), it is quite
>> likely that besides the non-standard SMTPS on port 465 they're also
>> doing the standard STARTTLS on port 25, just that they've found that
>> sticking to the above line causes the least amount of subsequent support
>> calls...
>>
>> As a quick feasibility test, you can telnet to port 25 on the smarthost
>> and issue a 'EHLO your.host.name' command (quit with QUIT). If the
>> response includes STARTTLS, at least the SSL (TLS) part should work w/o
>> any special sendmail config (i.e. get rid of the *_MAILER_ARGS
>> definitions) - the AUTH part may still have problems though (e.g. they
>> may not have it configured for port 25).
--Per Hedeland
p...@hedeland.org
Nietzsche
Thanks again, Per. I rebuilt sendmail, it has STARTTLS compiled in as
can be seen with the "-d0.1" switch.
I'm not sure how to correctly generate the certificates. But then I
never send certs to the relay so why would I need them?. Now I'm trying
to figure out where to put my user name and passowrd. Sendmail comes
with 13 READMEs. I've read all of them and not a hint of how I should
do this. Maybe it's not possible?
I downloaded stunnel but can't figure out how to use it either. I put
[smtp]
accept = 25
connect = 465
in the stunnel.conf file but running stunnel /etc/stunnel/stunnel.conf,
does nothing. The examples at stunnel.org show switches like -d, -r, -l
which are *not* mentioned anywhere in the man page! I posted a question
about it on the stunnel group. Maybe someone will give me a hint and
I'll be able to get it going.
Per Hedeland
"Nietzsche" <sc00...@yahoo.com> writes:
>
>Per Hedeland wrote:
>> >>
>> >> As a quick feasibility test, you can telnet to port 25 on the smarthost
>> >> and issue a 'EHLO your.host.name' command (quit with QUIT). If the
>> >> response includes STARTTLS, at least the SSL (TLS) part should work w/o
>> >> any special sendmail config
Did you try this yet?
>Thanks again, Per. I rebuilt sendmail, it has STARTTLS compiled in as
>can be seen with the "-d0.1" switch.
Good.
>I'm not sure how to correctly generate the certificates. But then I
>never send certs to the relay so why would I need them?.
You don't really need any certs for client-side setup - i.e. there is no
config that needs to be done for client-side STARTTLS.
> Now I'm trying
>to figure out where to put my user name and passowrd.
But you already had that in your original post, the authinfo stuff. It
is possible to use SSL/TLS for authentication, but I think it's quite
unusual, in particular with an ISP. So in general:
SSL/TLS (whether via SMTPS or STARTTLS) is only used for encrypting the
session.
Authentication is done with SMTP AUTH (authinfo etc).
They're fuctionally totally independent, the touching point being that
if you use a cleartext mechanism for SMTP AUTH, you surely want the
session to be encrypted - and it's possible that the server requires it
(sendmail can certainly be configured that way).
> Sendmail comes
>with 13 READMEs. I've read all of them and not a hint of how I should
>do this. Maybe it's not possible?
:-) Most everything about config is in the README file in the cf
directory, both STARTTLS and SMTP AUTH is there - but it's not a "HowTo"
type document. For more hand-holding info you want Claus' pages at
sendmail.org, both already mentioned.
>I downloaded stunnel but can't figure out how to use it either.
Try STARTTLS on port 25 first - if it works, and SMTP AUTH works on port
25 with STARTTLS, the config and maintenance will be literally
infinitely simpler than with stunnel. I.e. zero config of sendmail for
client-side STARTTLS and no additional sofware, vs configuring stunnel
to do what you want *plus* configuring sendmail to use stunnel for the
connection.
--Per Hedeland
p...@hedeland.org
Nietzsche
Thanks for your patience, Per. I cannot test port 25 because I'm behind
a firewall I have no control of that blocks 25. That's why I need to
access 465.
I installed stunnel. I was stumped for a while because the man page
makes no mention of important switches like -c, -d, -l, -r. I found out
about them through some examples on stunnel.org but the descriptions of
what they do seem vague. For example:
stunnel -c -d 127.0.0.1:25 -r my-relay.net:465
as I understand it, will listen on port 25 and forward everything it
receives to my-relay wrapped in SSL. I'm running in the highest debug
mode and all I see in the log is "smtp connected from 127.0.0.1".
netstat shows no attempt to connect to my-relay.
But besides that there seems no explanation as to how the tunneled app
works in this environment. I guess stunnel takes the place of the
"sendmail -bd" and when you run "sendmail som...@nowhere.com
<file.txt" sendmail feeds everything to stunnel which is supposed to
forward it as specified. So I guess I don't need sendmail's SMART_HOST
option. I'll keep digging. Feel free to throw me a bone if you have any
insight. Thanks again.
Per Hedeland
"Nietzsche" <sc00...@yahoo.com> writes:
>
>Thanks for your patience, Per. I cannot test port 25 because I'm behind
>a firewall I have no control of that blocks 25. That's why I need to
>access 465.
Ah, you could've mentioned that earlier.:-) So I take it the host you
want to connect to is not your ISP's..
>I installed stunnel. I was stumped for a while because the man page
>makes no mention of important switches like -c, -d, -l, -r. I found out
>about them through some examples on stunnel.org but the descriptions of
>what they do seem vague.
Well, the documentation seems to think that you should use a config
file, and I can't really see a problem with that. In fact the version I
have here doesn't seem to recognize any of the commandline options you
(and stunnel.org) mention.
> For example:
>
>stunnel -c -d 127.0.0.1:25 -r my-relay.net:465
>
>as I understand it, will listen on port 25 and forward everything it
>receives to my-relay wrapped in SSL.
Yes, this should be OK I think, except using local port 25 is probably
not a good idea, see below. Pick something unused, and while at it pick
something above 1024, then you don't need to run it as root either. E.g.
stunnel -c -d 127.0.0.1:2525 -r my-relay.net:465
- which could equally well be achieved by using a config file with:
client = yes
[rev-smtps]
accept = 127.0.0.1:2525
connect = my-relay.net:465
> I'm running in the highest debug
>mode and all I see in the log is "smtp connected from 127.0.0.1".
>netstat shows no attempt to connect to my-relay.
Strange, maybe there are more firewalls, maybe even on your own host -
but probably not if you saw a connection from sendmail to
my-relay.net:465 when you had configured that way. Anyway a config file
very much like the above worked perfectly for me when I tried it now - I
specified remote port 443 on a HTTPS server since I don't have a SMTPS
listener handy, and I could then telnet to localhost port 2525 and send
HTTP requests and get responses just fine. Anyway, telnet'ing to the
local port is a handy way to debug the stunnel part of things.
>But besides that there seems no explanation as to how the tunneled app
>works in this environment. I guess stunnel takes the place of the
>"sendmail -bd" and when you run "sendmail som...@nowhere.com
><file.txt" sendmail feeds everything to stunnel which is supposed to
>forward it as specified. So I guess I don't need sendmail's SMART_HOST
>option.
Yes, this is what will happen when you set it up to listen on port 25 -
the submit.cf-driven instance of sendmail, a.k.a. the MSP, will end up
connecting directly to the remote host through the tunnel rather than to
the local MTA, and it isn't really "meant" to do that. Shouldn't be a
connectivity issue, but there may be problems with adresses not being
properly masqueraded etc.
I'd suggest that you instead use a different port like above, and run
the local sendmail daemon on port 25 as you "should". Then it needs to
be configured with a variant of your original of course:
define(`RELAY_MAILER_ARGS', `TCP $h 2525')
define(`ESMTP_MAILER_ARGS', `TCP $h 2525')
define(`SMART_HOST',`[127.0.0.1]')
--Per Hedeland
p...@hedeland.org
Nietzsche
Well, stunnel works fine.
stunnel /etc/stunnel/stunnel.conf -c -d 127.0.0.1:2525 -r
my-relay-ip:465
I can telnet 127.0.0.1 and send mail with smtp commands after sending
my 64-bit encoded userID and password.
Sendmail doesn't have the inteneded effect if I set the SMART_HOST to
127.0.0.1. If I send something to som...@yahoo.com, sendmail tries to
connect directly to a yahoo MX server on port 2525, completely
bypassing 127.0.0.1. I checked it wasn't a config error on my part by
simply changing the SMART_HOST to something other than 127.0.0.1 and I
could see it working correctly with netstat.
The whole reason for all this is just so can I can use my favorite
email client, mutt:) At this point I think I'll write a script that
uses nc or telnet over via stunnel that mutt can pipe into.
Per Hedeland
"Nietzsche" <sc00...@yahoo.com> writes:
>
>Sendmail doesn't have the inteneded effect if I set the SMART_HOST to
>127.0.0.1. If I send something to som...@yahoo.com, sendmail tries to
>connect directly to a yahoo MX server on port 2525, completely
>bypassing 127.0.0.1. I checked it wasn't a config error on my part by
>simply changing the SMART_HOST to something other than 127.0.0.1 and I
>could see it working correctly with netstat.
Right, sendmail is soo smart, a SMART_HOST that is in class {w} gets
eliminated.:-) You could try defining a name for it in /etc/hosts:
127.0.0.1 smarthost-local
Note - leave the original "localhost" line in place, and make sure this
one is *after* it. Seems to work for me with a quick test.
>The whole reason for all this is just so can I can use my favorite
>email client, mutt:) At this point I think I'll write a script that
>uses nc or telnet over via stunnel that mutt can pipe into.
But now you're *really* close...!:-)
--Per Hedeland
p...@hedeland.org
Nietzsche
Very good! Yes, that worked. Now sendmail talks to the relay but I get
"Relay access denied".
To recap on my config options I have:
My sendmail.mc contains:
define(`SMART_HOST',`smarthost-local')
define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5
LOGIN PLAIN')
FEATURE(`authinfo',`hash /etc/mail/auth/client-info')
stunnel runs as:
stunnel /etc/stunnel/stunnel.conf -c -d smarthost-local:2525 -r
my-realy-domain-name:465
my client-info file contains:
AuthInfo:smarthost-local "U:root" "I:mail-user" "P:mail-user-password"
And client-info.db is made with "makemap hash client-info <
client-info"
I also tried my encrypted userID and password with the
"I=encrypted-user" and "P=encrypted-password" syntax per the cf/README.
I used the encrypted ID and password when I logged in with telnet.
I increased the log level to 15 in the cf file and I noticed a lot of
complaints about not being able to read the SSL certs. I wonder if I
need to have those working properly (even though I don't use them) in
order for the authentication to work. I don't see anything in the log
that indicates an attempt to read the client-info file.
Per Hedeland
"Nietzsche" <sc00...@yahoo.com> writes:
>
>Very good! Yes, that worked. Now sendmail talks to the relay but I get
>"Relay access denied".
>
>To recap on my config options I have:
>
>My sendmail.mc contains:
>define(`SMART_HOST',`smarthost-local')
>define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5
>LOGIN PLAIN')
>FEATURE(`authinfo',`hash /etc/mail/auth/client-info')
>
>stunnel runs as:
>stunnel /etc/stunnel/stunnel.conf -c -d smarthost-local:2525 -r
>my-realy-domain-name:465
>
>my client-info file contains:
>AuthInfo:smarthost-local "U:root" "I:mail-user" "P:mail-user-password"
>
>And client-info.db is made with "makemap hash client-info <
>client-info"
>
>I also tried my encrypted userID and password with the
>"I=encrypted-user" and "P=encrypted-password" syntax per the cf/README.
>I used the encrypted ID and password when I logged in with telnet.
Hm, the '=' form expects base64, which isn't "encryption":-) - I guess
this is intended for when your username or rather password includes
characters that could mess up the parsing of the entry (e.g. embedded
'"' characters). If you don't have such, don't bother with it.
>I increased the log level to 15 in the cf file and I noticed a lot of
>complaints about not being able to read the SSL certs. I wonder if I
>need to have those working properly (even though I don't use them) in
>order for the authentication to work.
No, as I explained before, SSL/TLS is separate from SMTP AUTH - all the
more so in your current setup where sendmail isn't doing the SSL at all,
stunnel is. But if you have configured certificates, sendmail will
probably try to load them, and complain if there are problems with
them. Since you have no use for them, it would be better to remove them
from the config.
> I don't see anything in the log
>that indicates an attempt to read the client-info file.
I don't think the normal logging will show map lookups even at high
levels, but you can use the -d38.20 debug flag to see them. For this you
should run the sendmail.cf-driven instance directly, and run it as root,
e.g.:
# date | sendmail -Am -v -odi -d38.20 us...@some.domain
At a guess, it might be looking for the wrong host name in client-info
(in my test with "smarthost-local", it got qualified to
smarthost-local.my.domain for some reason, not sure if it was the doing
of sendmail or my OS). Since you only have one entry in there anyway,
you could avoid such problems by getting rid of the host name part,
i.e. use:
AuthInfo: "U:root" "I:mail-user" "P:mail-user-password"
Or perhaps use 127.0.0.1 - it should work there.:-) Do note that in case
you change your setup such that sendmail may connect to other hosts, a
host-less "AuthInfo:" will have the effect that your username and
password will be sent to any MTA that offers AUTH (and doesn't match a
different entry).
--Per Hedeland
p...@hedeland.org
Nietzsche
I have it working. I took out the "Authinfo:" and "U:" fields in
client-info, like so:
AuthInfo: "U:" "I:username" "P:password" "M:LOGIN PLAIN"
This works fine. I noticed when I used the -d38.20 option there was a
lot of unecessary STARTTLS chat going on. I tried disabling it with
Try_TLS: NO
Srv_Features: V
in the access file (per the cf/README) but I still got a lot of TLS
chat so I recompiled without STARTTLS but with SASL (needed for auth)
although it wasn't necessary as it worked by tweaking the client-info
file regardless.
You help is much appreciated. I would never have got there without your
suggestions. Many thanks.
Per Hedeland
"Nietzsche" <sc00...@yahoo.com> writes:
>
>I have it working. I took out the "Authinfo:" and "U:" fields in
>client-info, like so:
>
>AuthInfo: "U:" "I:username" "P:password" "M:LOGIN PLAIN"
>
>This works fine.
Great!
> I noticed when I used the -d38.20 option there was a
>lot of unecessary STARTTLS chat going on.
Hm, that's weird - I guess the remote must be advertising STARTTLS in
the SMTPS session, which seems quite broken (sendmail doesn't do
that:-). Then again, there's no formal standard for SMTPS. Hm, maybe
they've just put an stunnel instance in front of their cleartext-
speaking MTA.:-)
> I tried disabling it with
>
>Try_TLS: NO
>Srv_Features: V
>
>in the access file (per the cf/README) but I still got a lot of TLS
>chat so I recompiled without STARTTLS but with SASL (needed for auth)
>although it wasn't necessary as it worked by tweaking the client-info
>file regardless.
Yes, the Try_TLS entry should have turned it off - but I guess it's not
worth the effort to debug why it didn't.
>You help is much appreciated. I would never have got there without your
>suggestions. Many thanks.
And now it's documented in dejaGoogle for all eternity how to set this
up.:-) I do think I've seen at least one question about client-side
SMTPS here before...
--Per Hedeland
p...@hedeland.org