Topics

Webmail Clients

Bryan Hoyer <bhhoyer@...>
 

When using email over RF either peer to peer or winlink a mail client is required.

We support POP3 and IMAP so you may use your favorite standard email client such as Outlook, AppleMail or Thunderbird.

In order to have a configuration free app we also have a webmail client pre-installed on the UDR. Currently we're using Neomail and it is perfectly satisfactory. However it is no longer actively supported.

There are some advanced features that I believe will be important in the future such as:

* Markdown Support
* Authentication
* BBS Style Bulletins

SquirrelMail and Horde look interesting.

What are your thoughts on Webmail Clients? Debian packages strongly preferred.

Cheers,
Bryan K7UDR

Tom Hayward <esarfl@...>
 

On Wed, Mar 12, 2014 at 9:05 AM, Bryan Hoyer <bhhoyer@...> wrote:
When using email over RF either peer to peer or winlink a mail client is required.
...
What are your thoughts on Webmail Clients? Debian packages strongly preferred.
I just want a modem. I can handle application support myself, likely
on another system linked via Ethernet.

Tom KD7LXL

Mark L Friedlander <marklfriedlander@...>
 

I'm running SquirrelMail on my Raspberry Pi with Raspian Wheezy, Postfix and Paclink-Unix. They all seem to play nicely together. Due to the inclusion of SAMBA on my Pi, web clients on my network can easily find the SquirrelMail interface when users type hostname\squirrelmail.

Mark KV4I



On Wed, Mar 12, 2014 at 12:05 PM, Bryan Hoyer <bhhoyer@...> wrote:
When using email over RF either peer to peer or winlink a mail client is required.

We support POP3 and IMAP so you may use your favorite standard email client such as Outlook, AppleMail or Thunderbird.

In order to have a configuration free app we also have a webmail client pre-installed on the UDR. Currently we're using Neomail and it is perfectly satisfactory. However it is no longer actively supported.

There are some advanced features that I believe will be important in the future such as:

* Markdown Support
* Authentication
* BBS Style Bulletins

SquirrelMail and Horde look interesting.

What are your thoughts on Webmail Clients? Debian packages strongly preferred.

Cheers,
Bryan K7UDR

Bill Vodall <wa7nwp@...>
 

On Wed, Mar 12, 2014 at 9:05 AM, Bryan Hoyer <bhhoyer@...> wrote:
When using email over RF either peer to peer or winlink a mail client is required.

We support POP3 and IMAP so you may use your favorite standard email client such as Outlook, AppleMail or Thunderbird.

In order to have a configuration free app we also have a webmail client pre-installed on the UDR. Currently we're using Neomail and it is perfectly satisfactory. However it is no longer actively supported.

There are some advanced features that I believe will be important in the future such as:

* Markdown Support
Interesting that you mention Markdown - it appears to be showing up more..

* Authentication
* BBS Style Bulletins
Didn't you mean to say NNTP? That's how the cool BBS's (like JNOS
and BPQ) deal with Bulletins.

http://squirrelmail.org/plugin_view.php?id=112


SquirrelMail and Horde look interesting.

What are your thoughts on Webmail Clients? Debian packages strongly preferred.
Been using SquirrelMail for many years and will be going back to it as
I get away from G-stuff.

The WL2K folks have an Webmail on Windows setup but I can't find it
right now in my non-notes...

To follow on with what Tom said - get the hardware out and working -
we'll do the apps...

Bill, WA7NWP

bhhoyer@...
 

when you say "linked via ethernet" I assume you mean SSH?
and by "modem" you mean KISS?

Tom Hayward <esarfl@...>
 

On Wed, Mar 12, 2014 at 9:35 AM, <bhhoyer@...> wrote:

when you say "linked via ethernet" I assume you mean SSH?

and by "modem" you mean KISS?
I was thinking more like TCP/IP. Maybe Linux AX25 for the 9600 stuff,
though I'm not a huge fan of AX25. SSH is a layer 7 protocol; a modem
should convert between layer 1 and layer 2.

I already have TNCs that can convert 9600 AX25 to KISS. I don't need
another. I'm hoping for a software-defined modem where I can
experiment with protocols that use FEC and speeds greater than 9600
bps. Eventually I'd like to add this protocol support into the modem,
but for now I would be happy sending IQ data to and from the modem via
UDP.

Tom KD7LXL

Bill Vodall <wa7nwp@...>
 

when you say "linked via ethernet" I assume you mean SSH?
IP - SSH maybe for local (non RF - after all it's HAM Radio) admin but
it won't be needed. Plug in the box. It does a DHCP query on the
network to get an address and it's on the air.

and by "modem" you mean KISS?
For legacy packet operation - the RF side will show simply as an
interface on the Linux AX25 stack. All of the applications and even
TCP/IP come from there.

You should never have to deal with KISS. There is a NET2KISS shim
from the AX25 stack that provides a virtual KISS port to applications
that need it.

Bill, WA7NWP

Bryan Hoyer <bhhoyer@...>
 

Yes, IQ via UDP will be supported for "soft modem" development.

On Mar 12, 2014, at 9:57 AM, Tom Hayward <esarfl@...> wrote:

On Wed, Mar 12, 2014 at 9:35 AM, <bhhoyer@...> wrote:
>
> when you say "linked via ethernet" I assume you mean SSH?
>
> and by "modem" you mean KISS?

I was thinking more like TCP/IP. Maybe Linux AX25 for the 9600 stuff,
though I'm not a huge fan of AX25. SSH is a layer 7 protocol; a modem
should convert between layer 1 and layer 2.

I already have TNCs that can convert 9600 AX25 to KISS. I don't need
another. I'm hoping for a software-defined modem where I can
experiment with protocols that use FEC and speeds greater than 9600
bps. Eventually I'd like to add this protocol support into the modem,
but for now I would be happy sending IQ data to and from the modem via
UDP.

Tom KD7LXL


"Michael E Fox - N6MEF" <n6mef@...>
 

Exactly. 

 

The focus seems to continue to wander.  We can make mail servers and clients on some other machine at any time. 

 

What we don’t have is the radio bridge functionality that the UDR promises (but still hasn’t delivered).  Can we stay focused on delivering that?  Choice of modulation schemes, FEC, management and control (simple, intuitive management screens; snmp; logging, etc.)

 

Michael

N6MEF

 

 

From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...] On Behalf Of Tom Hayward
Sent: Wednesday, March 12, 2014 9:22 AM
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Webmail Clients

 

 

On Wed, Mar 12, 2014 at 9:05 AM, Bryan Hoyer <bhhoyer@...> wrote:
> When using email over RF either peer to peer or winlink a mail client is required.
...
> What are your thoughts on Webmail Clients? Debian packages strongly preferred.

I just want a modem. I can handle application support myself, likely
on another system linked via Ethernet.

Tom KD7LXL

"John D. Hays" <john@...>
 

Michael,

Different team members work on different aspects of the radio.  All of the things you list are being worked on by the engineers who have that responsibility.

We have more than one type of customer.  Many of our early adopters are technologists and are focused on creating systems that work for their specific applications.  Some will port or write software that make the UDRX even more powerful and flexible.  However, we also have customers who need to be able to take the radio out of the box, set a few configuration settings and operate. 

What Bryan and I are working on for these 'plug and play' uses, is a defined set of applications we can pre-load and provide a simple configuration tool or directions.  Almost all of these applications take no additional engineering or development work; e.g. a mail client, mail transfer agent, NNTP, GPSD, etc. We simply need to identify, test, and provide configuration tools or guidance.  It takes nothing away from the engineering work to deliver the radio.  (The old analogy applies, "You can't deliver a baby in 1 month by using 9 mothers")

The critical path engineering is being addressed and we are down to fine tuning on the RF deck and modem chain.

Getting the radio done is first priority.


John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  




On Wed, Mar 12, 2014 at 10:55 AM, Michael E Fox - N6MEF <n6mef@...> wrote:
 

Exactly. 

 

The focus seems to continue to wander.  We can make mail servers and clients on some other machine at any time. 

 

What we don’t have is the radio bridge functionality that the UDR promises (but still hasn’t delivered).  Can we stay focused on delivering that?  Choice of modulation schemes, FEC, management and control (simple, intuitive management screens; snmp; logging, etc.)

 

Michael

N6MEF

 

bhhoyer@...
 

Understand that we are the servant of two masters. Those of you that just want a modem on a network, and appliance operators who need a complete turn-key solution.

You can rest assured that no resources have been pulled off the RF/Hardware team to play with webmail :)

Thanks for the feedback
Bryan K7UDR

basil@...
 

Just to be clear:
The hardware interface will be a posix network interface.
It can & has been bolted on to the bottom of AX.25 & TCP/IP.
What ever protocol you want to use needs to talk to a network interface.
paclink-unix, used for Winlink support, uses a mail MTA, postfix, & movemail. There will be a minimal mail server (Dovecot) to allow support for pop3/imap clients. I have used our mail setup with mutt, thunderbird, neomail, claws-mail & K-9 mail on my Android tablet. 
Not sure where the 'lack of focus' thing is coming from but let me just say you are wrong.
If you want to develop something  and are familiar with BSD or posix sockets you will be fine.
We currently have the interface running on a browser using websockets talking to a node.js server in the cloud which talks to a daemon on the radio platform at my house. The components can be split apart & run on different machines or all together on the same udr platform.
There are many different ideas about how this box will be used. Since our group is heavily invested in this project you might figure out that it will do what we have the most fun doing. The software will be all open sourced so that you can make it do what you have the most fun doing.

/Basil N7NIX








Mark L Friedlander <marklfriedlander@...>
 

"However, we also have customers who need to be able to take the radio out of the box, set a few configuration settings and operate. "

Did somebody call my name? Definitely build something for us appliance operators.

Mark KV4I



On Wed, Mar 12, 2014 at 2:17 PM, John D. Hays <john@...> wrote:
 

Michael,

Different team members work on different aspects of the radio.  All of the things you list are being worked on by the engineers who have that responsibility.

We have more than one type of customer.  Many of our early adopters are technologists and are focused on creating systems that work for their specific applications.  Some will port or write software that make the UDRX even more powerful and flexible.  However, we also have customers who need to be able to take the radio out of the box, set a few configuration settings and operate. 

What Bryan and I are working on for these 'plug and play' uses, is a defined set of applications we can pre-load and provide a simple configuration tool or directions.  Almost all of these applications take no additional engineering or development work; e.g. a mail client, mail transfer agent, NNTP, GPSD, etc. We simply need to identify, test, and provide configuration tools or guidance.  It takes nothing away from the engineering work to deliver the radio.  (The old analogy applies, "You can't deliver a baby in 1 month by using 9 mothers")

The critical path engineering is being addressed and we are down to fine tuning on the RF deck and modem chain.

Getting the radio done is first priority.


John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223 
  




On Wed, Mar 12, 2014 at 10:55 AM, Michael E Fox - N6MEF <n6mef@...> wrote:
 

Exactly. 

 

The focus seems to continue to wander.  We can make mail servers and clients on some other machine at any time. 

 

What we don’t have is the radio bridge functionality that the UDR promises (but still hasn’t delivered).  Can we stay focused on delivering that?  Choice of modulation schemes, FEC, management and control (simple, intuitive management screens; snmp; logging, etc.)

 

Michael

N6MEF

 


Mathison Ott <mathisono@...>
 

Some of the ee, students are interested in the unit. After our 87+ licensing exam last week. Is any one around in the bay area that could give a talk about the devise?

73 kj6dzb mathison

On Mar 12, 2014 10:34 AM, "Bill Vodall" <wa7nwp@...> wrote:
 

> when you say "linked via ethernet" I assume you mean SSH?

IP - SSH maybe for local (non RF - after all it's HAM Radio) admin but
it won't be needed. Plug in the box. It does a DHCP query on the
network to get an address and it's on the air.

> and by "modem" you mean KISS?

For legacy packet operation - the RF side will show simply as an
interface on the Linux AX25 stack. All of the applications and even
TCP/IP come from there.

You should never have to deal with KISS. There is a NET2KISS shim
from the AX25 stack that provides a virtual KISS port to applications
that need it.

Bill, WA7NWP

bhhoyer@...
 

Hi Matt,

I get down to the Bay Area from time to time, which University are you associated with?

Bryan K7UDR

Mathison Ott <mathisono@...>
 

Uc Berkeley. I can forword any message on to the ee email list down here. Great group they all just got wookfong hts, the first assinment is aprs email clints... Moving on to sdr dsp work. This devise is realy a first!

73 mathison

On Mar 12, 2014 2:06 PM, <bhhoyer@...> wrote:
 

Hi Matt,


I get down to the Bay Area from time to time, which University are you associated with?

Bryan K7UDR

John Ronan <jpronans@...>
 

On 12/03/14 16:34, Bill Vodall wrote:
On Wed, Mar 12, 2014 at 9:05 AM, Bryan Hoyer <bhhoyer@...> wrote:
To follow on with what Tom said - get the hardware out and working - we'll do the apps... Bill, WA7NWP
+1

Well, we'll try to at least.

While being a primarily a (S)IMAP user, I appreciate having a webmail client to fall back on. No preference really, as, for me it is only ever a fallback. I think you have some good feedback to work from already.

Regards
John
EI7IG

Steve Stroh N8GNJ <steve.n8gnj@...>
 

Bryan:

SquirrelMail at least the last time I was forced to use it 5+ years
ago, is, at best, adequate. But there's got to be something better. As
a result of the infestation of Google+ into Gmail, there are several
projects going on to replicate the Gmail experience on one's own
server, and those might be worth investigating.

I've found that text mode PINE mail client to be more usable than
SquirrelMail. I believe Pine and it's associated text mode, text
editor Pico, are open source from the UW here in the Seattle area.
http://en.wikipedia.org/wiki/Pine_(email_client). Apparently there is
a successor to Pine - Alpine. In contrast to most text mode mail
clients, Pine was intuitive and easy to use. Being text mode, it was
very responsive. Its one downside is that it didn't deal with
attachments very well. One real positive was being text only, it
stripped "foo foo'd" email messages with lots of fonts, colors,
dancing bears, etc. down to just the text.

Pine also did a great job of reading USENET News -
http://www.washington.edu/pine/faq/news.html#top

I think the POP/SMTP capability will be more widely used with
Thunderbird, which is a pretty good mail client.

BBS Style Bulletins...
1. For semi-static content (my station information) it would be great
if the web apps could include a Wiki, preferably a "federated" Wiki
like what Ward Cunningham discussed at last year's MicroHAMS Digital
Conference - changes in one are automatically replicated to others
that are subscribed.
2. Some kind of simple blog generation would also be great, and you
can subscribe to it using RSS. That works great, lots of RSS clients
out there in opensourceland, and it's pretty lightweight to poll a
blog with RSS to see if there's an update.
3. NNTP / USENET servers / clients are THE way to go in Amateur Radio
TCP/IP Networking. It's just such a good match overall with the likely
way that UDRX networks will likely evolve.
4. Markdown - yes. It's the new HTML, and even more efficient.

One related comment related to the apps - please include some simple
way for the system to be able to make use of secondary storage, such
as a USB flash drive, for storage of user content such as email
messages, etc. I think that I'm going to be using my UDRX so much that
I don't want to fill up and overflow whatever native storage the UDRX
will include in the base unit.

I'm glad that you responded in detail to those that just want a
flexible RF modem. Good grief - that functionality is IN there for the
1% that want to play at that level. Apparently it's tough to convince
the 1% that they're not paying any more, waiting any longer, suffering
from any inefficiencies for having a processor and OS that supports
apps that they can easily bypass and play with pure I and Q.

For the rest of us (you know, the ones that want to throw money at you
and buy MULTIPLE radios, build networks, encourage others to buy
UDRXs)... PLEASE DO develop apps that will be included, supported, and
documented!!!

Thanks,

Steve Stroh N8GNJ
Redmond, WA area
unabashed UDRX fanboy

On Wed, Mar 12, 2014 at 9:05 AM, Bryan Hoyer <bhhoyer@...> wrote:
When using email over RF either peer to peer or winlink a mail client is required.

We support POP3 and IMAP so you may use your favorite standard email client such as Outlook, AppleMail or Thunderbird.

In order to have a configuration free app we also have a webmail client pre-installed on the UDR. Currently we're using Neomail and it is perfectly satisfactory. However it is no longer actively supported.

There are some advanced features that I believe will be important in the future such as:

* Markdown Support
* Authentication
* BBS Style Bulletins

SquirrelMail and Horde look interesting.

What are your thoughts on Webmail Clients? Debian packages strongly preferred.

Cheers,
Bryan K7UDR

"Michael E Fox - N6MEF" <n6mef@...>
 

You missed the point.

 

My point is that all this time spent on defining applications could and should be spent on defining management/configuration screens, status screens, logging, etc. for the primary purpose of this box.  This would include screens for OS (disk usage, memory usage, etc.), radio (power level, SWR, etc.), signal levels (including historical), modulation schemes (selection, status, …), link status, error rates, and bridging function (STP, forwarding status, MAC cache, etc.).  If all that stuff is not “IN there” and done well, then the primary function, the ONE thing that we need this box for -- RF bridging -- is not achieved (at least not in a manageable/deployable way).  (Just look at a $95 Ubiquity 802.11 radio for an idea of some of the stuff that’s needed to actually operate RF bridges in real world networks.  Everything else, all your apps, can be done elsewhere/anywhere (and already are).  I don’t really care if they get added, but we can add linux packages ourselves.  What we can’t do is develop the management/config/status/troubleshooting screens.  That’s gotta be done by the folks building the unit.  In my opinion, any time not focused on that is time that should be refocused. 

 

And not to put too fine a point on it, but for those of us who do intend to purchase multiple radios and incorporate them into real networks, the user applications will be (or already are) on their own machines with RAID storage, plenty of memory, etc., with their own security.  Subjecting a network device to user logins compromises the security of the network path itself.  And creating a single point of failure by mixing an application server and a network device would be a real junior level move.  To use your percentages, 99% of network design/management folks would never do that.  The other 1% are probably unemployed.  If you want to play around that way, or use it as an end-user station, that’s up to you – it’s a free country, and, after all, it’s a hobby.  But your assertion that only 1% would keep user apps and network function separate is just ridiculous and indicates you’ve never really run a substantial network.

 

I’ve said my piece.  The developers can choose to listen or not.  I hope they do.

 

Michael

N6MEF

 

From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...] On Behalf Of Steve Stroh N8GNJ
Sent: Thursday, March 13, 2014 9:17 AM
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Webmail Clients

 

 


I'm glad that you responded in detail to those that just want a
flexible RF modem. Good grief - that functionality is IN there for the
1% that want to play at that level. Apparently it's tough to convince
the 1% that they're not paying any more, waiting any longer, suffering
from any inefficiencies for having a processor and OS that supports
apps that they can easily bypass and play with pure I and Q.

For the rest of us (you know, the ones that want to throw money at you
and buy MULTIPLE radios, build networks, encourage others to buy
UDRXs)... PLEASE DO develop apps that will be included, supported, and
documented!!!

Thanks,

Steve Stroh N8GNJ
Redmond, WA area
unabashed UDRX fanboy


Matthew Pitts <daywalker_blade_2004@...>
 

What do you think the Node.js and Socket.io stuff that John talked about at DCC last fall is for? Besides, they had working prototypes at Dayton in 2012.

Matthew Pitts
N8OHU


On March 13, 2014 1:44:35 PM EDT, Michael E Fox - N6MEF wrote:
 

You missed the point.

 

My point is that all this time spent on defining applications could and should be spent on defining management/configuration screens, status screens, logging, etc. for the primary purpose of this box.  This would include screens for OS (disk usage, memory usage, etc.), radio (power level, SWR, etc.), signal levels (including historical), modulation schemes (selection, status, …), link status, error rates, and bridging function (STP, forwarding status, MAC cache, etc.).  If all that stuff is not “IN there” and done well, then the primary function, the ONE thing that we need this box for -- RF bridging -- is not achieved (at least not in a manageable/deployable way).  (Just look at a $95 Ubiquity 802.11 radio for an idea of some of the stuff that’s needed to actually operate RF bridges in real world networks.  Everything else, all your apps, can be done elsewhere/anywhere (and already are).  I don’t really care if they get added, but we can add linux packages ourselves.  What we can’t do is develop the management/config/status/troubleshooting screens.  That’s gotta be done by the folks building the unit.  In my opinion, any time not focused on that is time that should be refocused. 

 

And not to put too fine a point on it, but for those of us who do intend to purchase multiple radios and incorporate them into real networks, the user applications will be (or already are) on their own machines with RAID storage, plenty of memory, etc., with their own security.  Subjecting a network device to user logins compromises the security of the network path itself.  And creating a single point of failure by mixing an application server and a network device would be a real junior level move.  To use your percentages, 99% of network design/management folks would never do that.  The other 1% are probably unemployed.  If you want to play around that way, or use it as an end-user station, that’s up to you – it’s a free country, and, after all, it’s a hobby.  But your assertion that only 1% would keep user apps and network function separate is just ridiculous and indicates you’ve never really run a substantial network.

 

I’ve said my piece.  The developers can choose to listen or not.  I hope they do.

 

Michael

N6MEF

 

From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...] On Behalf Of Steve Stroh N8GNJ
Sent: Thursday, March 13, 2014 9:17 AM
To: UniversalDigitalRadio@...
Subject: Re: [UniversalDigitalRadio] Webmail Clients

 

 


I'm glad that you responded in detail to those that just want a
flexible RF modem. Good grief - that functionality is IN there for the
1% that want to play at that level. Apparently it's tough to convince
the 1% that they're not paying any more, waiting any longer, suffering
from any inefficiencies for having a processor and OS that supports
apps that they can easily bypass and play with pure I and Q.

For the rest of us (you know, the ones that want to throw money at you
and buy MULTIPLE radios, build networks, encourage others to buy
UDRXs)... PLEASE DO develop apps that will be included, supported, and
documented!!!

Thanks,

Steve Stroh N8GNJ
Redmond, WA area
unabashed UDRX fanboy



--
Sent from my Android device with K-9 Mail. Please excuse my brevity.