The server I am configuring does not have a mail server running on it. The program ssmtp (https://wiki.debian.org/sSMTP) is used as the Message Transfer Agent (MTA) for other applications to send emails via GMail. No inbound emails can be received this way.

This program is executed at the system command line as a sendmail clone rather than using an HTTP url.

e.g. sendmail t

with message content, including usual message headers, piped in at the command line.

It has its own configuration file that contains the GMail credentials so there is no need for calling programs to know them.

How would I use this program for asmbb outbound emails?

I don't think that's doable, AsmBB expects to connect via TCP/IP.

I would set up a local mail server as a relay, like Postfix, qmail, etc.

jprjr

I don't think that's doable, AsmBB expects to connect via TCP/IP.

I would set up a local mail server as a relay, like Postfix, qmail, etc.

Yes, you need to have local SMTP server. But postfix can be configured to relay the emails to gmail if you want to use gmail address. For example: Configure postfix to use gmail as a mail relay

Also, I am not very sure, but if your web server has a DNS and domain name configured, you can try to configure the gmail address and port 25 directly in AsmBB and possibly the emails will be sent.

johnfound

jprjr

I don't think that's doable, AsmBB expects to connect via TCP/IP.

I would set up a local mail server as a relay, like Postfix, qmail, etc.

Yes, you need to have local SMTP server. But postfix can be configured to relay the emails to gmail if you want to use gmail address. For example: Configure postfix to use gmail as a mail relay

Also, I am not very sure, but if your web server has a DNS and domain name configured, you can try to configure the gmail address and port 25 directly in AsmBB and possibly the emails will be sent.

Setting up a local SMTP server to relay to GMail is possible but I want to avoid the configuration problems. There is a temptation to allow general outbound and inbound mail which also implies configuring DKIM, SPF, DMARC, and worrying about blacklisting. It's no longer a trivial exercise and that is the reason to depend on one of the services (I use both GMail and FastMail).

Looking into the source code reveals the SendEmail function at lines 101 - 281 in http.asm, but it uses the HELO command and my understanding is that only works with port 25. There is no code there for handling TLS.

The admin settings page does not include fields for the login credentials so configuring for smtp.google.com:587 will not get past the EHLO stage of the handshake. And then it will want to use TLS as implied by the 587 port, which is the only one Google now accepts.

Here is what the Fossil documentation says about its outbound email capability under the topic Advanced Email Setups on the page:

https://fossil-scm.org/fossil/doc/trunk/www/alerts.md#advanced

Fossil offers several methods of sending email:

- Pipe the email message text into a command.

- Store email messages as entries in a SQLite database.

- Store email messages as individual files in a directory.

- Send emails to an SMTP relay.

- Send emails directly to the recipients via SMTP.

This wide range of options allows Fossil to talk to pretty much any SMTP setup.

The first four options let Fossil delegate email handling to an existing MTA so that Fossil does not need to implement the roughly two dozen separate RFCs required in order to properly support SMTP email in this complex world we've built. As well, this design choice means you do not need to do duplicate configuration, such as to point Fossil at your server's TLS certificate in order to support users behind mail servers that require STARTTLS encryption.

-

asmbb offers only the last option. Perhaps you could look at Fossil's work as reference.

crustyoz

Here is what the Fossil documentation says about its outbound email capability under the topic Advanced Email Setups on the page:

https://fossil-scm.org/fossil/doc/trunk/www/alerts.md#advanced

Fossil offers several methods of sending email:

- Pipe the email message text into a command.

- Store email messages as entries in a SQLite database.

- Store email messages as individual files in a directory.

- Send emails to an SMTP relay.

- Send emails directly to the recipients via SMTP.

This wide range of options allows Fossil to talk to pretty much any SMTP setup.

The first four options let Fossil delegate email handling to an existing MTA so that Fossil does not need to implement the roughly two dozen separate RFCs required in order to properly support SMTP email in this complex world we've built. As well, this design choice means you do not need to do duplicate configuration, such as to point Fossil at your server's TLS certificate in order to support users behind mail servers that require STARTTLS encryption.

-

asmbb offers only the last option. Perhaps you could look at Fossil's work as reference.

I am hardly reading C/C++ so fossil sources are not the best place to look for reference.

But the above ideas are clear enough, so I can implement some of them. Particularly, saving the emails to files or sqlite database is very easy, although I am not sure how useful this can be. At least you will need some other smtp client that to send these emails further.

Sending email to smpt relay should work right now, if I understand correctly.

And this solution IMHO avoids all the problems with the full featured email infrastructure (blacklists and other email security issues), because the smtp relay should be set to receive emails only from the localhost and works like a SMTP client towards the target smtp server.

johnfound

crustyoz

Here is what the Fossil documentation says about its outbound email capability under the topic Advanced Email Setups on the page:

https://fossil-scm.org/fossil/doc/trunk/www/alerts.md#advanced

Fossil offers several methods of sending email:

- Pipe the email message text into a command.

- Store email messages as entries in a SQLite database.

- Store email messages as individual files in a directory.

- Send emails to an SMTP relay.

- Send emails directly to the recipients via SMTP.

This wide range of options allows Fossil to talk to pretty much any SMTP setup.

The first four options let Fossil delegate email handling to an existing MTA so that Fossil does not need to implement the roughly two dozen separate RFCs required in order to properly support SMTP email in this complex world we've built. As well, this design choice means you do not need to do duplicate configuration, such as to point Fossil at your server's TLS certificate in order to support users behind mail servers that require STARTTLS encryption.

-

asmbb offers only the last option. Perhaps you could look at Fossil's work as reference.

I am hardly reading C/C++ so fossil sources are not the best place to look for reference.

But the above ideas are clear enough, so I can implement some of them. Particularly, saving the emails to files or sqlite database is very easy, although I am not sure how useful this can be. At least you will need some other smtp client that to send these emails further.

Sending email to smpt relay should work right now, if I understand correctly.

And this solution IMHO avoids all the problems with the full featured email infrastructure (blacklists and other email security issues), because the smtp relay should be set to receive emails only from the localhost and works like a SMTP client towards the target smtp server.

But you don't mention the first one: Pipe the email message text into a command.

That one "should" be just a case of using the operating system exec function with a statement like:

sendmail -ti <<thismsg (followed by message header and body terminated by "thismsg" or some such keyword)

That is what I did in one C language application and it works just fine.

Hi John:

I looked through the asmbb source code hoping to find an example of fork(), system(), exec() like functions but had no success. Then I realised asmbb had no need for child processes and otherwise did all its communication through sockets. So, I looked through the freshlib source code hoping to see process related functions that I might be able to use to execute the shell or \/usr/sbin/sendmail directly, but no luck there either.

What to do? My assembler skills are now obsolete (asm86 16 bit without macro-assembler) so providing an alternative interface for sending email from asmbb is beyond my abilities.

I don't think the problem is so large in the Linux world (don't know about Windows world):

1. define configuration field to hold path name of executable (e.g. \/usr/sbin/sendmail),

2. assume piped input for that executable, of email content including To:, From:, and Subject: lines,

3. call the equivalent of the system() function to execute the sendmail program within a shell,

4. ignore return value since the shell is unlikely to pass a failure back from sendmail.

Help requested please.

Chris

crustyoz

Hi John:

I looked through the asmbb source code hoping to find an example of fork(), system(), exec() like functions but had no success. Then I realised asmbb had no need for child processes and otherwise did all its communication through sockets. So, I looked through the freshlib source code hoping to see process related functions that I might be able to use to execute the shell or \/usr/sbin/sendmail directly, but no luck there either.

What to do? My assembler skills are now obsolete (asm86 16 bit without macro-assembler) so providing an alternative interface for sending email from asmbb is beyond my abilities.

I don't think the problem is so large in the Linux world (don't know about Windows world):

1. define configuration field to hold path name of executable (e.g. \/usr/sbin/sendmail),

2. assume piped input for that executable, of email content including To:, From:, and Subject: lines,

3. call the equivalent of the system() function to execute the sendmail program within a shell,

4. ignore return value since the shell is unlikely to pass a failure back from sendmail.

Help requested please.

Chris

All such functions are in FreshLib. But executing external programs for Linux is simply not implemented yet.

You can see the interface of the Exec function in freshlib/system/process.asm. The implementations are in the respective OS depending directories: freshlib/system/Win32/process.asm for Win32, freshlib/system/Linux/_process_posix.asm for Linux/posix and freshlib/system/Linux/_process_native.asm for Linux/native.

You can see, that the Linux implementations are dummy placeholders. In addition, this interface does not provide a way to pipe some input/output to/from the executed process.

johnfound

crustyoz

Hi John:

I looked through the asmbb source code hoping to find an example of fork(), system(), exec() like functions but had no success. Then I realised asmbb had no need for child processes and otherwise did all its communication through sockets. So, I looked through the freshlib source code hoping to see process related functions that I might be able to use to execute the shell or \/usr/sbin/sendmail directly, but no luck there either.

What to do? My assembler skills are now obsolete (asm86 16 bit without macro-assembler) so providing an alternative interface for sending email from asmbb is beyond my abilities.

I don't think the problem is so large in the Linux world (don't know about Windows world):

1. define configuration field to hold path name of executable (e.g. \/usr/sbin/sendmail),

2. assume piped input for that executable, of email content including To:, From:, and Subject: lines,

3. call the equivalent of the system() function to execute the sendmail program within a shell,

4. ignore return value since the shell is unlikely to pass a failure back from sendmail.

Help requested please.

Chris

All such functions are in FreshLib. But executing external programs for Linux is simply not implemented yet.

You can see the interface of the Exec function in freshlib/system/process.asm. The implementations are in the respective OS depending directories: freshlib/system/Win32/process.asm for Win32, freshlib/system/Linux/_process_posix.asm for Linux/posix and freshlib/system/Linux/_process_native.asm for Linux/native.

You can see, that the Linux implementations are dummy placeholders. In addition, this interface does not provide a way to pipe some input/output to/from the executed process.

I see the stub for Exec in the Linux files. Let me see what I can do to extend those FreshLib source files. No promises of delivery or time. I will need to become familiar with the entire assembler environment and that does not come quickly to a grey beard. My focus is on Golang applications at the moment.

crustyoz

I see the stub for Exec in the Linux files. Let me see what I can do to extend those FreshLib source files. No promises of delivery or time. I will need to become familiar with the entire assembler environment and that does not come quickly to a grey beard. My focus is on Golang applications at the moment.

Well, there are changes. I already started to implement something here: http://fresh.flatassembler.net/fossil/repo/fresh/artifact?ln=53..115&name=ae08ac7dcd812e54 The interface is in system/process.asm:

interface Exec2, .hCommand, .hStdIn, .hStdOut, .hStdErr

It is implemented only for Linux right now and only by using the system calls. Seems to work somehow but is not actively tested at all.

Of course you can still try to implement it another way (for example, by using standard posix libs - it will be useful for separating posix/native Linux ports) or try to test the code.

Which can be some kind of soft introduction to FreshLib programming. You can see some testing code (naive) in test_code/TestPThreads.fpr.

Well, I have made it. Now the sending of the emails can be delegated to external programs.

The source:

The source is in the with_sendmail branch. (Later will be merged with the trunk, but some more work has to be done)

The implementation itself is in the file command.asm

Not tested

The source is tested only that it works. I.e. it runs the external program and pipes the email to it.

Settings

The settings dialog (the tab Server) contains one more input field labeled Pipe the emails through:. Put there the full path to program that will expect the email data from the STDIN. sSMTP should work if properly configured by itself.

johnfound

Well, I have made it. Now the sending of the emails can be delegated to external programs.

The source:

The source is in the with_sendmail branch. (Later will be merged with the trunk, but some more work has to be done)

The implementation itself is in the file command.asm

Not tested

The source is tested only that it works. I.e. it runs the external program and pipes the email to it.

Settings

The settings dialog (the tab Server) contains one more input field labeled Pipe the emails through:. Put there the full path to program that will expect the email data from the STDIN. sSMTP should work if properly configured by itself.

I think this is good news!

I've updated my copy of the repository and reviewed the code, but have not assembled and tested.

I notice you provide a field (smtp_exec) to contain the path name of the executable. Does it allow for command line options? The \/usr/sbin/sendmail executable requires "-t" or "-ti" in order to accept input from stdin. There are many other options in the original sendmail, but the ssmtp version just used "-ti".

I know I am pushing you too much and for that I apologise :-)

But, I see you have implemented the sendmail piped out function as a part of the commands.asm SendActivationEmail function rather than as a generic SendPipedEmail (or some such name) function.

Reason: For a low volume forum, it would be very desirable to notify registered users by email when new posts have been written. As an example of a higher volume forum doing this, I cite the fossil-scm.org/forum where I receive 30 to 40 emails daily, telling me the contents of new posts. I suspect that is over the limit for most interested readers, but they are easy to delete. About 1 in 20 are of direct interest and I go to the forum to refresh context while reading the new post.

Such notification requires that the registered user have the option to turn it off, so a new preference is needed there. And the forum administrator will need a global flag to turn on/off the feature.

crustyoz

I think this is good news!

I've updated my copy of the repository and reviewed the code, but have not assembled and tested.

I notice you provide a field (smtp_exec) to contain the path name of the executable. Does it allow for command line options? The \/usr/sbin/sendmail executable requires "-t" or "-ti" in order to accept input from stdin. There are many other options in the original sendmail, but the ssmtp version just used "-ti".

Yes, it allows command line parameters. But is not tested very well.

crustyoz

I know I am pushing you too much and for that I apologise :-)

But, I see you have implemented the sendmail piped out function as a part of the commands.asm SendActivationEmail function rather than as a generic SendPipedEmail (or some such name) function.

Reason: For a low volume forum, it would be very desirable to notify registered users by email when new posts have been written. As an example of a higher volume forum doing this, I cite the fossil-scm.org/forum where I receive 30 to 40 emails daily, telling me the contents of new posts. I suspect that is over the limit for most interested readers, but they are easy to delete. About 1 in 20 are of direct interest and I go to the forum to refresh context while reading the new post.

Such notification requires that the registered user have the option to turn it off, so a new preference is needed there. And the forum administrator will need a global flag to turn on/off the feature.

Well, I am trying to keep the email activity of the engine as low as possible. Starting to use emails for notifications and as a side channel for communication with the users is dangerous and can easy turn the forum engine into a spam source.

On the other hand, I am planning to implement RSS/Atom feeds in order to allow fine grained notification channel about threads and posts changes. IMHO, this will be way better solution of this problem.

johnfound

Well, I am trying to keep the email activity of the engine as low as possible. Starting to use emails for notifications and as a side channel for communication with the users is dangerous and can easy turn the forum engine into a spam source.

On the other hand, I am planning to implement RSS/Atom feeds in order to allow fine grained notification channel about threads and posts changes. IMHO, this will be way better solution of this problem.

I think I could live with RSS notifications. It means informing users about that channel and assumes their email program is capable. I've never used RSS myself neither as originator nor recipient.

crustyoz

I've never used RSS myself neither as originator nor recipient.

Me too. I am reading specifications and trying to understand how it works.