[UFO Chicago] Does this blog post help?

[jay at m5.chicago.il.us]

Original Message:

> 
> Jay F Shachter wrote:
> 
>>
>> Here is a verbatim transcript of an hourlong chat I had with my ATT
>> technical service representative.  I hope it will be more amusing for
>> you to read it than it was for me to participate in it.  And if you
>> can answer the question that Zachary could not even comprehend, I
>> shall be much obliged. [...]
>>
> 

and Neil R. Ormos replied on Wed Jan  8 03:42:44 2014:

>
> Does this blog post help? 
> 
> |> Configure sendmail as a client for SMTPs
> 
> |> Overview 
> 
> |> The motivation to configure sendmail as a
> |> client for Simple Mail Transfer Protocol with
> |> SSL (SMTPS) came about when I switched ISP's
> |> and the new service required authentication as
> |> well as the use of port 465 to submit an email
> |> for delivery. In my case the ISP was AT&T
> |> U-verse powered by Yahoo! Mail. The old ISP
> |> permitted the use of port 25 as long as your IP
> |> address was part of their network, whereas the
> |> new service blocks that port to outgoing
> |> traffic. Setting up SMTPS is fairly easy to do
> |> using a client like Evolution, however, it is
> |> not quite as straightforward to configure
> |> sendmail to do the job. The reason why I needed
> |> sendmail was to allow my home server to send
> |> email using the PHP mail function from a web
> |> page. One of the uses of this server is as a
> |> platform for website development and testing. I
> |> will also show how it is possible to receive
> |> email on your home server using a dynamic dns
> |> provider. [...]
> 
>   <https://fedoraproject.org/wiki/Configure_sendmail_as_a_client_for_SMTPs>
> 
> --Neil Ormos
> 

Yes it did, indirectly.  It did not answer my question, but it led to
a workaround.

My postfix MTA was allowing me to use smtp.att.yahoo.com as a mail
relay host by connecting to port 587, in which the SMTP conversation
is unencrypted until the client sends a STARTTLS (see RFC 3207).  The
above-cited blog post does not discuss how to do that with sendmail.
Rather, it discusses something different, namely, how to connect to
smtp.att.yahoo.com on port 465 using the so-called "SMTPS" protocol,
in which the entire conversation is encrypted ("so-called" because
there is no SMTPS RFC).  Even on port 465, smtp.att.yahoo.com still
requires an authentication phase, which is initiated by sending an
"AUTH LOGIN"; more on that below.

Since sendmail appears not to support encryption of any kind (I hope
that I am mistaken, but so far I have seen no evidence that I am), the
above-cited blog recommended using stunnel to set up an encrypted
tunnel between some available local port -- e.g., 10025 -- and port
465 of the mail relay host.  I was able to get this to work quickly,
all I had to do was download the source to stunnel (which I had never
heard of before) and build, install, and configure it.  Presumably ssh
with the -N and -L options would have accomplished the exact same
thing, but stunnel appears to be superior to ssh if tunneling is all
you want to do, since a single stunnel process can establish multiple
tunnels, whereas it seems that you have to run a separate ssh process
for each tunnel.  You then configure sendmail to use localhost:10025
(or whatever local port number you chose to be tunneled over to port
465 of smtp.att.yahoo.com) as its smart mail relay host.  I had no
problem getting this to work.

The above-cited blog then addressed the "AUTH LOGIN" requirement, and
discussed how to configure sendmail to send the appropriate
authentication credentials after the EHLO.  My sendmail, however,
choked on that configuration, informing me that it can be used only
with a sendmail that has been compiled with -DSASL.  I downloaded the
latest source code to sendmail, and gradually formed the opinion that
to re-build sendmail from source, and to get it exactly like the
sendmail that had already been customized for my system, with the
addition of supporting SASL, would be a hellish task, suitable only to
a nerd who has no life, but not to a spirited bon vivant like myself.
So, vigorously cursing the morons who distributed a sendmail on my
system that lacked SASL support, I undertook the easier task, which
was to write a perl program -- /home/jay/lib/outgoing.pl -- to perform
the SMTP conversation with the relay host.  Since I was already
writing a perl program, I suppose I could have got perl to do the
encryption as well as the SMTP, but since I already had stunnel in
place, I did not disturb it, I just have to make sure that stunnel is
always invoked at boot time.  And then I had to recompile all the MUAs
on my system that send outgoing mail -- e.g., elm and mailto -- and
which formerly had the path of sendmail hard-coded inside of them, to
use my perl program as their outgoing MTA.  I now have two different
MTAs on my system: sendmail, which runs as a daemon, to handle
incoming mail, and /home/jay/lib/outgoing.pl to handle outgoing mail,
and which is invoked as needed, whenever an outgoing mail message is
generated.  If you are reading this message, then I got everything to
work correctly, because I am sending this message from my Solaris
system, which is the system on which I did all of this, because
Solaris uses sendmail rather than postfix.

This workaround is, of course, totally bogus.  In fact, when you look
up the word "bogus" in the dictionary, the dictionary should show you
a picture of my mail configuration.  Perhaps, one of these days, when
I am trying to avoid doing something else, I shall build sendmail
with SASL support, and install it on my computer.  Even so, the use of
stunnel is still bogus, the MTA should handle the encryption directly,
and, in fact, the MTA should handle the STARTTLS command, which is the
only proper way to do encryption with SMTP.


	Jay F. Shachter
	6424 North Whipple Street
	Chicago IL  60645-4111
		(1-773)7613784   landline
		(1-410)9964737   GoogleVoice
                http://m5.chicago.il.us
		jay at m5.chicago.il.us

	"But when she traced the killer's IP address ... it was in the 192.168/16 block!"