SqueakSource mail/smtp setup

I've been having 'fun' again with my personal squeaksource adventures.

This time it is getting commit mails to actually send; in case I probably need to modify things to use SecureSMTPClient (assuming anyone thinks it still works?) and in another test case I need to change the default port.

Adding a port number to the squeaksource settings page won't be too much of a pain (I hope, assuming I remember any of it after a couple of months) but I'd much rather hear that someone has already solved this and save the time. Anyone?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: LCD: Launch Cartridge Disk

Hi Tim,

On Thu, 28 Nov 2019, tim Rowledge wrote:

> I've been having 'fun' again with my personal squeaksource adventures.
>
> This time it is getting commit mails to actually send; in case I probably need to modify things to use SecureSMTPClient (assuming anyone thinks it still works?) and in another test case I need to change the default port.

You'll only need SecureSMTPClient if your SMTP server uses port 465
to accept mails.
If it uses port 587, then SMTPClient will handle the TLS encryption for
you. But it'll still require a few tweaks. Here's how we create an
SMTPClient to send mails through gmail:

         | client |
         client := SMTPClient new.
         client hostName: 'smtp.gmail.com'.
         client
                 user: '<username>';
                 password: '<password>';
                 localHostName: '127.0.0.1';
                 openOnHost: (NetNameResolver addressForName: 'smtp.gmail.com') port: 587.

Levente

>
> Adding a port number to the squeaksource settings page won't be too much of a pain (I hope, assuming I remember any of it after a couple of months) but I'd much rather hear that someone has already solved this and save the time. Anyone?
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: LCD: Launch Cartridge Disk

Thanks very much for that Levente - I had seen the more complex bits of code that set the port etc but not really noticed them. Looks like I'll need to extend the squeaksource settings page bit to try to handle at least setting the port number. Maybe I can add SecureSMTP support too.

Of course, nothing is a simple as it looks like it should be. I just lost most of a morning trying to work out why I couldn't connect to the relevant server; try from home... no, well maybe the port isn't exported, try running one of the images on the office server, hmph, have to use Chris' Smalltalk run:[]/filein stuff... wait, why does it simply sit there? Build trivial test file, no problem... add bit by bit... wait, simply setting the client password locks things up? What?

Aargh! The password has a ! in the middle. Sigh. Happily, doubling it up works around it (even results in the correct single ! in the client password) and now we can prove that ... the smpt server doesn't want to play nice.

Turns out you can try sending mail with curl, too, which at least supports the theory that the server is the problem and not me/us. Ah, the joys of software.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- J'Y SUIS, J'Y PESTES - I can stay for the weekend

An oddity spotted and possibly a bug at some level - when connecting to an SMTP server we use #ensureConnection, which uses #login, which sends #initiateSession. But the SMTPClient class>>openOnHost:port: over-rides the ProtocolClient class>>openOnHost:port: and adds another #initiateSession.

I'm pretty sure that SMTPClient class>>openOnHost:port:  can simply be removed but it's late on a sunday and reading RFCs has mangled too many braincells. I guess that sending the SMTP server 'EHLO' twice won't cause too many explosions in data centres but it may be a bit rude and certainly wastes network traffic. Does anyone have a strong attachment to double-initialising the connection?

I think it would also be useful to add a utility mail sending method that takes a user name and password for those servers wanting them.

Lastly, the EHLO command wants that awkward local host name, just like SqueakSource does. Levente's suggestion of fudging it to 127.0.0.1 for smtp seems to work ok but it probably isn't bullet-proof. We sure could do with a decently reliable way to get a suitable value.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: MC: Melt down Core

hi Tim,

On Sun, 1 Dec 2019, tim Rowledge wrote:

> An oddity spotted and possibly a bug at some level - when connecting to an SMTP server we use #ensureConnection, which uses #login, which sends #initiateSession. But the SMTPClient class>>openOnHost:port: over-rides the ProtocolClient class>>openOnHost:port: and adds another #initiateSession.
>
> I'm pretty sure that SMTPClient class>>openOnHost:port:  can simply be removed but it's late on a sunday and reading RFCs has mangled too many braincells. I guess that sending the SMTP server 'EHLO' twice won't cause too many explosions in data centres but it may be a bit rude and certainly wastes network traffic. Does anyone have a strong attachment to double-initialising the connection?

The class-side method is indeed flawed and unnecessary. It should be
removed.

>
> I think it would also be useful to add a utility mail sending method that takes a user name and password for those servers wanting them.
>
> Lastly, the EHLO command wants that awkward local host name, just like SqueakSource does. Levente's suggestion of fudging it to 127.0.0.1 for smtp seems to work ok but it probably isn't bullet-proof. We sure could do with a decently reliable way to get a suitable value.

You must specify the name yourself. There is no way to find out the FQDN
of your outgoing IP address from your machine without the help of an
external host, but that is what should be sent in the first place.
127.0.0.1 works, because the RFC allows it, and because of the above: an
internal host cannot know its FQDN.

If your machine had a network interface configured with a global IP
address, then the primLocalAddress could return it to your image. But
nowadays most machines are behind a NAT, so your machine is very unlikely
to have such address.
And even if your machine had such address, your network interface would
have to be called eth0 or wlan0 on linux, because those names are
hardcoded into the VM. On my machine, no such interface exists, so the
primitive always returns 0.0.0.0. That's another bug to be fixed.

Levente

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: MC: Melt down Core

Ah, more fun with smtp;

> On 2019-12-02, at 5:59 PM, Levente Uzonyi <[hidden email]> wrote:
>
> hi Tim,
>
> On Sun, 1 Dec 2019, tim Rowledge wrote:
>
>> An oddity spotted and possibly a bug at some level

[snip]
>
> The class-side method is indeed flawed and unnecessary. It should be removed.

Yup. It's gone and some tidying up makes it simple to use uid/pwd with a nice direct SMTPClient class>>#deliverMailFrom:to:text:usingServer:userName:password: I'll try to commit it later.

>>
>> Lastly, the EHLO command wants that awkward local host name, just like SqueakSource does. Levente's suggestion of fudging it to 127.0.0.1 for smtp seems to work ok but it probably isn't bullet-proof. We sure could do with a decently reliable way to get a suitable value.
>
> You must specify the name yourself.
[snip]
Yeah. Annoying as hell but that's life!

The good news is that I now have email from personal squeaksource working with uid/pwd smtp. At last...


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Dukedom: aristocratic birth control