Long-term roadmap suggestions?

Use this forum if you want to suggest a new feature to hMailServer. Before posting, please search the forum to confirm that it has not already been suggested.

What would you like the most?

Complete (new) Web Frontend for administration + REST API (and ditch hMailServer Administrator)
24
15%
Cross-platform - Make it possible to run on Linux as well
12
8%
New scripting engine - Add Google V8 javascript engine and extend what could be done using scripting. (more entry points and bigger flexibility)
10
6%
Clustering support - Add built-in support for high-availability such as failover and redundancy.
32
21%
Improved performance - Make everything faster
41
26%
Security/Privacy - Implement much more security/privacy features, such as user-level encryption of messages.
26
17%
Other - Please post
10
6%
 
Total votes: 155

User avatar
martin
Developer
Developer
Posts: 6834
Joined: 2003-11-21 01:09
Location: Sweden
Contact:

Long-term roadmap suggestions?

Post by martin » 2014-10-11 20:30

While adding minor stuff to hMailServer I'm thinking about what should be done in the long term. There's a lot of things which I would enjoy doing, but I don't have time to do it all. Right now I'm not talking about minor stuff such as "Add checkbox X to do Y" but larger changes to how hMailServer works.

In other words, these are things I would enjoy implementing (because they are fun areas) but I'm not sure if they would bring much value. For example, adding cross-platform support would probably be of limited value use because there are already several great email servers for Linux (but so much fun).

Feel free to comment if you have ideas about larger changes to hMailServer. It would be most interesting I think if we could focus on bigger things and not
Martin Knafve
martin@hmailserver.com
https://twitter.com/knafve

User avatar
mattg
Moderator
Moderator
Posts: 20024
Joined: 2007-06-14 05:12
Location: 'The Outback' Australia

Re: Long-term roadmap suggestions?

Post by mattg » 2014-10-12 00:09

Another commonly asked question is the ability to use multiple IP Public addresses, defined per domain...

I am unsure how message encryption could be implemented at the server level without the receiving server also being a hMailserver. Would that break from your concept of sticking with RFCs?

Another idea may be to emulate Exchange more with a group address book, and task list, making hMailserver a groupware server rather than a mail server.
Same for list server.

Perhaps, if you go for the web based administration model, you will then be easily able to add webmail to the same web server that would need to be installed to run the admin (I assume that you will need to install a small web server)

Personally, I'd love to see some FOIP (Fax over internet without a modem or dedicated fax line), or SMS via internet as a way to make hmailserver a 'communications server'.

Thanks for asking. :D

Matt
Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

percepts
Senior user
Senior user
Posts: 5282
Joined: 2009-10-20 16:33
Location: Sceptred Isle

Re: Long-term roadmap suggestions?

Post by percepts » 2014-10-12 16:59

maybe too little for what you are looking for but...

A mechnanism in hmailadmin to display all hmail settings in txt form with a copy button so that users requesting help can provide it on request. Perhaps just added to bottom of diagnostics panel.

The purpose is to greatly reduce the sometimes tortuous process of working out why users configuration is wrong.

And if it could at same time fetch their DNS settings for what they have entered in local host name, A, MX, PTR, SPF, TXT records and include that in the output.

User avatar
Snorkasaurus
Normal user
Normal user
Posts: 188
Joined: 2010-08-29 16:32
Location: Canada
Contact:

Re: Long-term roadmap suggestions?

Post by Snorkasaurus » 2014-10-12 19:06

I'm voting for "cross-platform" and "other" because I wanted to add the point that if hMailServer were to be going cross platform I would much prefer that it not be dependent on supporting applications like Java, Python, Perl, .NET, Ruby, etc.

My mail server also provides http, sshd, irc, mysql, and backup services - all of which I can find suitable Linux replacements for, but I continue to run them all on Windows because I can't find a suitable replacement for hMailServer. There are plenty of Linux based mail server solutions but none of them come close to hMailServer's ability to manage all aspects of what I would consider to be core functions of an MTA. In the Linux world you may choose from:

1. Stringing together a patchwork of at least a half dozen applications to provide all required services (smtp, imap, pop, av, spam, etc)
2. Very limited suite-like solutions like iRedMail or Axigen
3. Commercial and/or proprietary software

I think that if the existing functionality of hMailServer were ported to Linux it would simply blow all other solutions (on any platform) out of the water.

My 3¢
S.

User avatar
Spyd
Normal user
Normal user
Posts: 43
Joined: 2008-02-19 10:15
Location: Barcelona, Spain
Contact:

Re: Long-term roadmap suggestions?

Post by Spyd » 2014-10-14 00:30

I really like hMailServer as it is now, so for me the only major thing is performance.

prisma
Senior user
Senior user
Posts: 309
Joined: 2010-07-09 13:16

Re: Long-term roadmap suggestions?

Post by prisma » 2014-10-14 09:46

My personal opinion is a mailserver has to be reliable, fast and secure.

So, my first vote is Security/Privacy. In times where we have to fight more and more against intelligence services and hackers, we have to continuously improve security/privacy features. If you don't go forward, you go backwards. One thing to implement could be DANE for SMTP. And/or implementing hmailserver as a gateway for S/MIME and GPG/MIME for seamless en-/decryption of messages. This would be a really unique feature!

My second vote is also performance. I love hMailserver because it's one single easy to use windows application to service all needed protocols. But in relation to Linux services based on single process/application per protocol hMailserver is miles behind regarding performance. I don't see any sense to try to port hMailserver to Linux. The rivals are way too established. Dovecot, Postfix, Fetchmail and Co. are very fast and work very well together. And they are rather easy to set up. There are tons of howtos in internet. Regarding the Windows World hMailserver is nearly unique and within his world he should be improved and speeded up.

If I had a third vote, I'd give it for improving the build-in backup feature. It's a little bit a step child of hMailserver...

prisma
Senior user
Senior user
Posts: 309
Joined: 2010-07-09 13:16

Re: Long-term roadmap suggestions?

Post by prisma » 2014-10-14 10:24

PS, regarding clustering support: Would be a great thing, but there are specialists out there for HA clustering. On OS base, on database level, based on whatever. I'm not sure if hMailserver should try to play with these guys :)

User avatar
martin
Developer
Developer
Posts: 6834
Joined: 2003-11-21 01:09
Location: Sweden
Contact:

Re: Long-term roadmap suggestions?

Post by martin » 2014-10-14 16:10

Purpose of clustering is to make sure (implement what is needed) and document how to set up clustering to achieve failover and redundancy is possible. It's not to implement a completely hMailServer specific clustering engine/failover system, which would be a waste of time. As you probably know, setting up clustering can get kid of tricky, depending on your choice of database, environment you're running in (local VMware compared to EC2, Azure etc). Some solid guidelines and tested scenarios would be very helpful I think.

When it comes to performance, where is this a problem to you today? I'm guessing when using IMAP?
Martin Knafve
martin@hmailserver.com
https://twitter.com/knafve

prisma
Senior user
Senior user
Posts: 309
Joined: 2010-07-09 13:16

Re: Long-term roadmap suggestions?

Post by prisma » 2014-10-14 19:24

I'd say yes, IMAP. But also sending of large attachments can be a pain, although connected via LAN and clamav is deactivated...

User avatar
mattg
Moderator
Moderator
Posts: 20024
Joined: 2007-06-14 05:12
Location: 'The Outback' Australia

Re: Long-term roadmap suggestions?

Post by mattg » 2014-10-14 23:53

prisma wrote:One thing to implement could be DANE for SMTP.
If I had a third vote, this I would agree to.
prisma wrote: And/or implementing hmailserver as a gateway for S/MIME and GPG/MIME for seamless en-/decryption of messages. This would be a really unique feature!
I agree that this would be unique, and could only envisage it working with a hMailserver at both ends, unless the keys were somehow shared with a mail client at the other end. Lets add PKI to the mix (That's what we use in Australian Healthcare)
Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

prisma
Senior user
Senior user
Posts: 309
Joined: 2010-07-09 13:16

Re: Long-term roadmap suggestions?

Post by prisma » 2014-10-15 10:50

mattg wrote:I agree that this would be unique, and could only envisage it working with a hMailserver at both ends, unless the keys were somehow shared with a mail client at the other end. Lets add PKI to the mix (That's what we use in Australian Healthcare)
Possibly just a misunderstanding. Of course based on a PKI, how else?
I must confess, this idea is a little bit nerdy. The intention is, to be able to administer a PKI centralized and to have not to deal with the clients. hMailserver "just" had to serve and/or look-up the public keys for encryption and serve the private keys for seamless decryption. Of course this makes only sense for clients being within the same (secured) network together with hMailserver. Whether the complement uses his client or a hMailserver to en-/decrypt makes no difference for the sender ;)

User avatar
mattg
Moderator
Moderator
Posts: 20024
Joined: 2007-06-14 05:12
Location: 'The Outback' Australia

Re: Long-term roadmap suggestions?

Post by mattg » 2014-10-15 12:17

Here we have government issued PKI certificates. (Yes there are some rumblings about not trusting the government to be the issuer of these). I have some PKI certificates that are on a CD, and one that is on a USB dongle.

We have a number of ways to use them.
Some secure messaging services use a deliberate man-in-the-middle server that collects and then distributes all messages, with a client installed at each end to handle the (de)encryption.
Some offer web services that use encrypted connections.
One Secure messaging provider just installs a special mail client at each end that deal with the (de)encryption, and the message is sent via normal email protocols.

Both of these work well, and in theory they should be able to interoperate with each other.
Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

prisma
Senior user
Senior user
Posts: 309
Joined: 2010-07-09 13:16

Re: Long-term roadmap suggestions?

Post by prisma » 2014-10-15 13:05

So, having a mailserver dealing with the PKI centralized would be highly interesting for you. This gave mail administrators the opportunity to offer similar man-in-the-middle services.

Just by the way, in Germany similar "man-in-the-middle" services have been introduced. It's called "De-Mail" or "E-Postbrief" using qualified signature and encryption for legally binding communication with agencies. Users are only able access their mails via SSL-secured webmailer. Message Disposition Notification (MDN) and Delivery Status Notification (DSN) are implicit and mandatory.

... But nobody uses this, because our government wants to have a lot money for a qualified certificate from our "Bundesdruckerei", and/or service providers want to monetary participate in security of our citizens ...

Lefty
New user
New user
Posts: 3
Joined: 2014-10-15 18:09

Re: Long-term roadmap suggestions?

Post by Lefty » 2014-10-15 18:23

Beside more scripting possibilities I’m with mattg.

If you would be able to implement a subset of ActiveSync you would be king of the hill.
What is really missing is the ability to have calendar and contacts synced. Especially for mobile devices.

Reference implementations are Z-Push or O-Push.

But I know this would be a big change.

:D

frank70
Normal user
Normal user
Posts: 51
Joined: 2013-06-04 13:49

Logging

Post by frank70 » 2014-10-16 14:57

I like the hmailserver very much. I would like to run it on linux because linux is more secure, running faster on hardware and much cheaper running on VMs. And i would like more logging. It would be great to see the way from a message, to see where the message has been moved to or when it has been deleted.
OS: MS Server 2008 R2 SP1;8GB RAM;FUJITSU PRIMERGY Xeon(R);E3-1220 V2@3.10GHz; Mails:20k per anno,1 domain,40 account + archiv,40 alias,biggest mail account:30GB;hmail 5.4.1-B1951

User avatar
SorenR
Senior user
Senior user
Posts: 3169
Joined: 2006-08-21 15:38
Location: Denmark

Re: Long-term roadmap suggestions?

Post by SorenR » 2014-10-18 18:44

Perhaps some work on GreyListing is needed...

1) Maillinglists most often use a one-time email address as sender. Is sender a requirement?
2) Support for DNS based Whitelists like dnswl.org
3) Lingertime in minutes (unused records), not days.
4) Whitelist on HELO (with wildcard)
5) Whitelist on domain (with wildcard)
6) Update triplet if mail is accepted via incoming relay (fx. Backup-MX) in second attempt from sender.
SørenR.

The quantum rule of insecurity which states that the act of observing how vulnerable a host or service is changes the insecurity level of the service.

percepts
Senior user
Senior user
Posts: 5282
Joined: 2009-10-20 16:33
Location: Sceptred Isle

Re: Long-term roadmap suggestions?

Post by percepts » 2014-10-18 19:09

Mail archiving functionality seems to crop up as a regular question from users on forums.

Some system either to copy out mails to a database where mails are searchable and selectively restorable

AND / OR

as a relatively simple (I think but not sure whats involdved) option to limit by date what hmail returns to users.
I'm thinking a date option on application, and one on domain(inherits application date unless manually changed) and one on account (inherits domain date unless manually changed).
Then only mails after that date would be returned to client. That way you could control how far back users can view email from but provide for circumstances where a user needs permission to look back further.
Would this increase performance where IMAP users are sorting on date or subject? I think maybe it would where people have large mail folders going back years.
So this would effectively be archiving mail from a users perspective but leaving it in hmail system for access if necessary.

LesD
Senior user
Senior user
Posts: 343
Joined: 2009-01-15 20:22
Location: London, UK.

Re: Long-term roadmap suggestions?

Post by LesD » 2014-10-18 19:14

I have a NO vote for the first suggestion - to remove the built-in hMS Admin interface.

I run all my hMS installations as basic VMs without a web server. So, unless there was some built in web server, for me at least, having a web-only admin interface is a non starter.

For local administration I do not see any advantage in being web based. On the contrary, I always find web based interfaces much inferior to what can be done using classical methods.

For remote admin, I would not want to trust the security of my server to a web browser. I would much rather log in via something like Remote Desktop and use the traditional interface.

So by all means enhance the web interface but please do not remove or downgrade the built-in one.

User avatar
Snorkasaurus
Normal user
Normal user
Posts: 188
Joined: 2010-08-29 16:32
Location: Canada
Contact:

Re: Long-term roadmap suggestions?

Post by Snorkasaurus » 2014-10-18 20:07

LesD wrote:I have a NO vote for the first suggestion - to remove the built-in hMS Admin interface.
I guess when I initially read that first option I didn't pay enough attention to the "ditch" part - I would also vote no on this (if I were allowed a third vote)... or at least provide an option during the install to go with web-based or app-based admin.

S.

User avatar
SorenR
Senior user
Senior user
Posts: 3169
Joined: 2006-08-21 15:38
Location: Denmark

Re: Long-term roadmap suggestions?

Post by SorenR » 2014-10-18 21:02

Snorkasaurus wrote:
LesD wrote:I have a NO vote for the first suggestion - to remove the built-in hMS Admin interface.
I guess when I initially read that first option I didn't pay enough attention to the "ditch" part - I would also vote no on this (if I were allowed a third vote)... or at least provide an option during the install to go with web-based or app-based admin.

S.
The REST API looks quite nice and the major change is that HTML is used to replace RPC/COM. By using the REST API it will be possible to run a GUI on Windows/Linux/Android/iOS and IF hMailServer is to have an embedded HTML server/engine running on a non-standard IP port... Well...

Not saying you SHOULD... BUT... If you "happen" to be driving a Tesla S (or D), you could potentially manage your mailserver from the onboard computer by installing the "app"... :mrgreen:
SørenR.

The quantum rule of insecurity which states that the act of observing how vulnerable a host or service is changes the insecurity level of the service.

User avatar
Snorkasaurus
Normal user
Normal user
Posts: 188
Joined: 2010-08-29 16:32
Location: Canada
Contact:

Re: Long-term roadmap suggestions?

Post by Snorkasaurus » 2014-10-18 21:23

SorenR wrote:The REST API looks quite nice and the major change is that HTML is used to replace RPC/COM. By using the REST API it will be possible to run a GUI on Windows/Linux/Android/iOS and IF hMailServer is to have an embedded HTML server/engine running on a non-standard IP port... Well...
I am not sure what the end result of the "REST API/HTML admin design" would be. Are you saying that I would have hMailServer installed on a Windows box, plus a web server on that same box, and then I would use a browser (or some other application) on that box (or any other) to manage it?

S.

LesD
Senior user
Senior user
Posts: 343
Joined: 2009-01-15 20:22
Location: London, UK.

Re: Long-term roadmap suggestions?

Post by LesD » 2014-10-18 21:38

High-availability
Not sure what exactly this means.

What sort of events do you have in mind which cannot be catered for by using multiple MX records?

User avatar
martin
Developer
Developer
Posts: 6834
Joined: 2003-11-21 01:09
Location: Sweden
Contact:

Re: Long-term roadmap suggestions?

Post by martin » 2014-10-18 21:53

LesD wrote:
High-availability
Not sure what exactly this means.

What sort of events do you have in mind which cannot be catered for by using multiple MX records?
Let's say you're using hMailServer with IMAP. The server goes down. Incoming email will still be queued up even if you just have a single MX record (hopefully), but now you can't access your email (because the server where the messages resides is down). If it were possible to host a single hMailServer domain on multiple separate physical machines, possibly in different data centers and these would stay in sync, then you could continue to access your email,. send email and what not even if one of the machines fail.
Martin Knafve
martin@hmailserver.com
https://twitter.com/knafve

User avatar
Snorkasaurus
Normal user
Normal user
Posts: 188
Joined: 2010-08-29 16:32
Location: Canada
Contact:

Re: Long-term roadmap suggestions?

Post by Snorkasaurus » 2014-10-18 21:58

martin wrote:Let's say you're using hMailServer with IMAP. The server goes down. Incoming email will still be queued up even if you just have a single MX record (hopefully), but now you can't access your email (because the server where the messages resides is down). If it were possible to host a single hMailServer domain on multiple separate physical machines, possibly in different data centers and these would stay in sync, then you could continue to access your email,. send email and what not even if one of the machines fail.
Would this require shared storage or block-level replication?
S.

LesD
Senior user
Senior user
Posts: 343
Joined: 2009-01-15 20:22
Location: London, UK.

Re: Long-term roadmap suggestions?

Post by LesD » 2014-10-18 23:16

Sounds a good idea - both for failover and off-site backup.
martin wrote:Let's say you're using hMailServer with IMAP. The server goes down. Incoming email will still be queued up even if you just have a single MX record (hopefully),
I presume you mean queued up in the sense that the sending MTAs will keep retrying
martin wrote:but now you can't access your email (because the server where the messages resides is down).
I use Thunderbird set to download all emails so I have a local copy. So I can see all my old emails. I accept that someone using webmail would lose it all. Sending out emails would be cumbersome.
quote="martin"]If it were possible to host a single hMailServer domain on multiple separate physical machines, possibly in different data centers and these would stay in sync, then you could continue to access your email,. send email and what not even if one of the machines fail.[/quote]
I have to admit that this is something that I have thought long and hard about. Not so much for instant fail-over but for warm or even cold backup.

I run hMS in a dedicated VM with MySQL and the data on the host server.

Having a copy of the VM is not an issue.

I use Syncovery to sync the data as it changes but have an issue with keeping an up to date copy of the MySQL database due to the way that MySQL stores its data.

Syncovery can trigger a script to dump the MySQL data on a regular basis and back it up but the restore has to be done manually.

If all of that could be automated so there was an exact mirror at a remote site then it could be very useful.

I do not see how you would implement the continuity of receiving emails at the mirror site without the use of a backup MX.

Then you would have the job of synchronising the mirror to the master when the master comes back on line. And you would also need to simultaneously remove the backup MX as you would not want mail delivered to the mirror while the master was running.

Looks to me to be a major and difficult project.

User avatar
SorenR
Senior user
Senior user
Posts: 3169
Joined: 2006-08-21 15:38
Location: Denmark

Re: Long-term roadmap suggestions?

Post by SorenR » 2014-10-18 23:17

Snorkasaurus wrote:
SorenR wrote:The REST API looks quite nice and the major change is that HTML is used to replace RPC/COM. By using the REST API it will be possible to run a GUI on Windows/Linux/Android/iOS and IF hMailServer is to have an embedded HTML server/engine running on a non-standard IP port... Well...
I am not sure what the end result of the "REST API/HTML admin design" would be. Are you saying that I would have hMailServer installed on a Windows box, plus a web server on that same box, and then I would use a browser (or some other application) on that box (or any other) to manage it?

S.
If you were to use a browser and a webserver there would not be a need for an API per se.

Code: Select all

REST API...
<Application>-<HTML connector>---(TCP/IP)---<HTML connector>-<Server>
|<----------- Any OS -------------->|<--------- Windows ----------->|

As it is now.. (if I'm not completely mistaken...)
<Application>-<COM connector>-<RPC>---(TCP/IP)---<RPC>-<COM connector>-<Server>
|<-------------------------------- Windows ---------------------------------->|
SørenR.

The quantum rule of insecurity which states that the act of observing how vulnerable a host or service is changes the insecurity level of the service.

User avatar
Snorkasaurus
Normal user
Normal user
Posts: 188
Joined: 2010-08-29 16:32
Location: Canada
Contact:

Re: Long-term roadmap suggestions?

Post by Snorkasaurus » 2014-10-19 00:19

SorenR wrote:If you were to use a browser and a webserver there would not be a need for an API per se.

Code: Select all

REST API...
<Application>-<HTML connector>---(TCP/IP)---<HTML connector>-<Server>
|<----------- Any OS -------------->|<--------- Windows ----------->|

As it is now.. (if I'm not completely mistaken...)
<Application>-<COM connector>-<RPC>---(TCP/IP)---<RPC>-<COM connector>-<Server>
|<-------------------------------- Windows ---------------------------------->|
Well there's a vote for porting to other OS's if I ever saw one. :-)

Since my server also needs to have "other services" managed, I just find it easier to RDP to the box and manage all of them. I can't say that I have ever found management of a remote hMailServer an inconvenient thing (in fact it is often significantly less inconvenient than most of the other services on that same box).

S.

LesD
Senior user
Senior user
Posts: 343
Joined: 2009-01-15 20:22
Location: London, UK.

Re: Long-term roadmap suggestions?

Post by LesD » 2014-10-19 00:29

I have googled a bit and found some RESTful articles. Maybe the penny had dropped.

SorenR: Are you saying that a web server is not required?

Is this the way that ASSP works? I have never thought about it, but ASSP runs on the same VM as hMS and it is maintained via a web browser and to best of my knowledge there is no web server running there.

If this is the case then please (repeated 1001 times) can we stick with the current admin interface!

Sorry to be a Luddite but the ASSP interface is 'most unfortunate' to put it mildly.

Of course, if there is a major gain by doing it that way that I am missing then I am happy to learn.

percepts
Senior user
Senior user
Posts: 5282
Joined: 2009-10-20 16:33
Location: Sceptred Isle

Re: Long-term roadmap suggestions?

Post by percepts » 2014-10-19 00:57

I think what is being mooted is along the lines of:

viewtopic.php?p=165186&sid=9a26ccac0220 ... 97#p165186

LesD
Senior user
Senior user
Posts: 343
Joined: 2009-01-15 20:22
Location: London, UK.

Re: Long-term roadmap suggestions?

Post by LesD » 2014-10-19 01:17

percepts wrote:I think what is being mooted is along the lines of:

viewtopic.php?p=165186&sid=9a26ccac0220 ... 97#p165186
Thanks - understood. I understand the benefits of a single local/remote used/admin combined interface (assuming good security). I am just sad about losing a local admin interface that is crisp and fast to navigate. This is progress I suppose.

percepts
Senior user
Senior user
Posts: 5282
Joined: 2009-10-20 16:33
Location: Sceptred Isle

Re: Long-term roadmap suggestions?

Post by percepts » 2014-10-19 15:31

There would be a question about domain name for a web admin interface. I think there will be users who have their website hosted externally but want to run their email from an office server. So they can't use same domain for webhost in their office. And many webhost companies won't allow installation of exe or dll files or they may be unix webhosts and/or they may not run ASP if that is required.
So hmail user may be forced to purchase another domain to be able to install hmail with a web only admin solution unless they use IP as web address which I guess is doable but not very user friendly.

User avatar
katip
Senior user
Senior user
Posts: 673
Joined: 2006-12-22 07:58
Location: Istanbul

Re: Long-term roadmap suggestions?

Post by katip » 2014-10-19 17:49

Bayesian & regex based antispam detection i'd like to see. Current methods are very basics only. w/o ASSP (or similar) HMS would serve moderately for an ISP but not for a company.
Katip
--
HMS 5.7.0-B2428-LTS-64-bit, MySQL 5.7.24, SA 3.4.2, ClamAV 0.101.2 + SaneS

User avatar
martin
Developer
Developer
Posts: 6834
Joined: 2003-11-21 01:09
Location: Sweden
Contact:

Re: Long-term roadmap suggestions?

Post by martin » 2014-10-21 12:28

katip wrote:Bayesian & regex based antispam detection i'd like to see. Current methods are very basics only. w/o ASSP (or similar) HMS would serve moderately for an ISP but not for a company.
Sort of agree, but I'm not sure that means that integrating all possible spam mechanisms in hMailServer would be sane. It's such a large area that it would be wiser to use something like ASSP or SpamAssassin with hMailServer. There's no way I'll have time to implement what already exists in SpamAssassin, so it would always make sense to install it if you want less spam...
Martin Knafve
martin@hmailserver.com
https://twitter.com/knafve

User avatar
martin
Developer
Developer
Posts: 6834
Joined: 2003-11-21 01:09
Location: Sweden
Contact:

Re: Long-term roadmap suggestions?

Post by martin » 2014-10-21 13:27

percepts wrote:There would be a question about domain name for a web admin interface. I think there will be users who have their website hosted externally but want to run their email from an office server. So they can't use same domain for webhost in their office. And many webhost companies won't allow installation of exe or dll files or they may be unix webhosts and/or they may not run ASP if that is required.
So hmail user may be forced to purchase another domain to be able to install hmail with a web only admin solution unless they use IP as web address which I guess is doable but not very user friendly.
Today when an administrator wants to start the Admin tool he probably clicks an icon in the start menu or on on the desktop. Starting a web UI would be just the same, just a link which opens up http://localhost:8080 (or whatever port is good). I think this would be pretty user-friendly (similar to today).

If the admin then wants to be able to access the UI from other machines, all he has to do is open up the firewall for the port 8080. Then of course he has to decide whether he wants to be able to access it remotely with a domain name and if so assign that domain name to the machine.

My idea with a web interface is primarily "one way to manage hMailServer", rather than two which we have today.
Martin Knafve
martin@hmailserver.com
https://twitter.com/knafve

User avatar
mattg
Moderator
Moderator
Posts: 20024
Joined: 2007-06-14 05:12
Location: 'The Outback' Australia

Re: Long-term roadmap suggestions?

Post by mattg » 2014-10-21 14:21

port 8080 is fairly common with this sort of thing
(Sharepoint for one)

Perhaps choose a different port, or at least allow it to be configurable
Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

LesD
Senior user
Senior user
Posts: 343
Joined: 2009-01-15 20:22
Location: London, UK.

Re: Long-term roadmap suggestions?

Post by LesD » 2014-10-21 14:54

As I have mentioned before, my personal view of web based configuration screen for complex software is rather negative, but there is no denying the advantage both for the developer and the user for having a single interface for making changes - subject to adequate security.

So I give a positive vote for a new web based admin to replace the existing two methods.

User avatar
SorenR
Senior user
Senior user
Posts: 3169
Joined: 2006-08-21 15:38
Location: Denmark

Re: Long-term roadmap suggestions?

Post by SorenR » 2014-10-21 14:56

martin wrote:
percepts wrote:There would be a question about domain name for a web admin interface. I think there will be users who have their website hosted externally but want to run their email from an office server. So they can't use same domain for webhost in their office. And many webhost companies won't allow installation of exe or dll files or they may be unix webhosts and/or they may not run ASP if that is required.
So hmail user may be forced to purchase another domain to be able to install hmail with a web only admin solution unless they use IP as web address which I guess is doable but not very user friendly.
Today when an administrator wants to start the Admin tool he probably clicks an icon in the start menu or on on the desktop. Starting a web UI would be just the same, just a link which opens up http://localhost:8080 (or whatever port is good). I think this would be pretty user-friendly (similar to today).

If the admin then wants to be able to access the UI from other machines, all he has to do is open up the firewall for the port 8080. Then of course he has to decide whether he wants to be able to access it remotely with a domain name and if so assign that domain name to the machine.

My idea with a web interface is primarily "one way to manage hMailServer", rather than two which we have today.
Or... By using the REST API you could make a Java based GUI distributed via Java Web Start.
Just like Cisco do with their products...

Something completely different - high availability...
Split hMailServer into multiple services (DB, Main app, SMTP, IMAP and POP3) connected via a common "bus" to allow SMTP/IMAP/POP3 service to run on multiple boxes leaving only the "Main app" and/or "DB" clustered. If one service go down - the others are not affected.

If the SMTP service was installed on a different box it could have a subset of the database replicated to a local DB so that it could continue accepting mail even if the "Main app" was down or off-line...

I used to work for a company making IP Billing software and we could install the system (Database, GUI, Rating Engine, Provisioning Agents, Collection Agents, RADIUS Servers etc.) on one box - or multiple boxes across country borders (which we did for several customers). The product had a back-end web GUI to monitor services, start/stop services and show status on remote nodes.
The product started as "IMS" back in the 1990'ies, then it became "DCP"... Made by Belle Systems, namechange to Digiquant, sold part to Volubill and part to Intec Systems and now CSG brought it all back together bying VoluBill and Intec :wink:
SørenR.

The quantum rule of insecurity which states that the act of observing how vulnerable a host or service is changes the insecurity level of the service.

percepts
Senior user
Senior user
Posts: 5282
Joined: 2009-10-20 16:33
Location: Sceptred Isle

Re: Long-term roadmap suggestions?

Post by percepts » 2014-10-21 15:43

mattg wrote:port 8080 is fairly common with this sort of thing
(Sharepoint for one)

Perhaps choose a different port, or at least allow it to be configurable
+1

If admin is available on the web from anywhere then obviously its far more prone to password breach so being able to configure your own chosen port would be a good thing rather than having a fixed one which the whole world knows.

User avatar
Snorkasaurus
Normal user
Normal user
Posts: 188
Joined: 2010-08-29 16:32
Location: Canada
Contact:

Re: Long-term roadmap suggestions?

Post by Snorkasaurus » 2014-10-21 15:47

SorenR wrote:Or... By using the REST API you could make a Java based GUI distributed via Java Web Start.
Just like Cisco do with their products...

Something completely different - high availability...
Split hMailServer into multiple services (DB, Main app, SMTP, IMAP and POP3) connected via a common "bus" to allow SMTP/IMAP/POP3 service to run on multiple boxes leaving only the "Main app" and/or "DB" clustered. If one service go down - the others are not affected.

If the SMTP service was installed on a different box it could have a subset of the database replicated to a local DB so that it could continue accepting mail even if the "Main app" was down or off-line...
Running an extra web server for the admin interface is more than my P4 w/ 2G of memory wants to handle... Java and clustering would be well outside the universe of reality for me. :-(

S.

percepts
Senior user
Senior user
Posts: 5282
Joined: 2009-10-20 16:33
Location: Sceptred Isle

Re: Long-term roadmap suggestions?

Post by percepts » 2014-10-21 16:12

martin wrote:
percepts wrote:There would be a question about domain name for a web admin interface. I think there will be users who have their website hosted externally but want to run their email from an office server. So they can't use same domain for webhost in their office. And many webhost companies won't allow installation of exe or dll files or they may be unix webhosts and/or they may not run ASP if that is required.
So hmail user may be forced to purchase another domain to be able to install hmail with a web only admin solution unless they use IP as web address which I guess is doable but not very user friendly.
Today when an administrator wants to start the Admin tool he probably clicks an icon in the start menu or on on the desktop. Starting a web UI would be just the same, just a link which opens up http://localhost:8080 (or whatever port is good). I think this would be pretty user-friendly (similar to today).

If the admin then wants to be able to access the UI from other machines, all he has to do is open up the firewall for the port 8080. Then of course he has to decide whether he wants to be able to access it remotely with a domain name and if so assign that domain name to the machine.

My idea with a web interface is primarily "one way to manage hMailServer", rather than two which we have today.
But users have access too so they can change their password. If they are out on the road with a latop and wifi access, opening up a firewall/port isn't going to be an option for them.

User avatar
SorenR
Senior user
Senior user
Posts: 3169
Joined: 2006-08-21 15:38
Location: Denmark

Re: Long-term roadmap suggestions?

Post by SorenR » 2014-10-21 17:20

percepts wrote:But users have access too so they can change their password. If they are out on the road with a latop and wifi access, opening up a firewall/port isn't going to be an option for them.
What is the difference from what we have today?

If it runs on port 80 or 8080... If you have webhosting using Apache you can use the internal proxy to connect to 8080 on a different server behind your firewall...

As Master Yoda would put it; "A strong resistance against evolution, I sense" :wink:

May the Force be with you, Martin ... :mrgreen:
SørenR.

The quantum rule of insecurity which states that the act of observing how vulnerable a host or service is changes the insecurity level of the service.

User avatar
Snorkasaurus
Normal user
Normal user
Posts: 188
Joined: 2010-08-29 16:32
Location: Canada
Contact:

Re: Long-term roadmap suggestions?

Post by Snorkasaurus » 2014-10-21 18:51

SorenR wrote:As Master Yoda would put it; "A strong resistance against evolution, I sense" :wink:
I believe that my resistance would be the evolution from
me wrote:an MTA that I can use on my crappy old P4 to serve private email for my friends and family along with other services like http, ssh, irc, and teamspeak
to
me wrote:an enterprise grade collaboration suite capable of meeting all of my company's email, scheduling and project management needs, which will require multiple dedicated servers that are less than four years old, a shared storage NAS, a network load balancing appliance, optional paid support contract, and...
A bit of an exaggeration perhaps, but that is the direction it looks like to me. The best features of hMailServer are the fact that it (1) doesn't require heavy infrastructure and (2) doesn't require three months of patching together postfix, amavis, openssl, spamassassin, dovecot, courier, phpmyadmin, mysql, pam, sasl, and clamav - only to find out that greylisting (a feature I would consider a core function of an MTA) is a separate application or plugin.

Having a backup MX is a basic level of fault tolerance and availability... clustering support can't be done without heavy hardware and operating system requirements.

I can't possibly see better performance. I run hMailServer [remotely via rdp I might add] just fine on a crappy P4 over a residential 12Mbit DSL connection... who needs better than that? I also can't imagine that adding an http/https web server to the mix will help to improve performance.

And I am all for security and privacy, but user-level encryption simply does not get used by "regular users" because (1) regular users will never be willing to read fifteen minutes of documentation to understand how to use it (2) regular users have nobody to send encrypted mail to anyways and (3) people who understand endpoint mail encryption already have a system in place and use it less than 1% of the time. Don't get me wrong, I think that smtp is brutally flawed because of its lack of encryption, sender identification, and route control... and I wish that the whole world would commit to endpoint encryption for email, but I can't see it happening. :-(

My 3¢
S.

User avatar
SorenR
Senior user
Senior user
Posts: 3169
Joined: 2006-08-21 15:38
Location: Denmark

Re: Long-term roadmap suggestions?

Post by SorenR » 2014-10-21 19:10

Embedding a webserver in hMailServer can be done quite easily and with an extreme low footprint - unless PHP is a requirement.. :roll:

https://github.com/cesanta/mongoose
SørenR.

The quantum rule of insecurity which states that the act of observing how vulnerable a host or service is changes the insecurity level of the service.

LesD
Senior user
Senior user
Posts: 343
Joined: 2009-01-15 20:22
Location: London, UK.

Re: Long-term roadmap suggestions?

Post by LesD » 2014-10-21 20:42

Can we just clarify whether a real web server is required for this proposed new web based admin.

I currently run hMS in a VM with 1GB of memory. It includes an install of ASSP.

Now ASSP is administered via a web browser on port 55555 from any machine on the LAN or anywhere else for that matter, if set to do so.

Is ASSP running some web server or using some other magic to support the web based admin? I somehow doubt that a web server is involved.

User avatar
Snorkasaurus
Normal user
Normal user
Posts: 188
Joined: 2010-08-29 16:32
Location: Canada
Contact:

Re: Long-term roadmap suggestions?

Post by Snorkasaurus » 2014-10-21 20:56

LesD wrote:Is ASSP running some web server or using some other magic to support the web based admin? I somehow doubt that a web server is involved.
Sounds like ASSP has its own web server according to this post.
S.

User avatar
SorenR
Senior user
Senior user
Posts: 3169
Joined: 2006-08-21 15:38
Location: Denmark

Re: Long-term roadmap suggestions?

Post by SorenR » 2014-10-21 21:40

Snorkasaurus wrote:
LesD wrote:Is ASSP running some web server or using some other magic to support the web based admin? I somehow doubt that a web server is involved.
Sounds like ASSP has its own web server according to this post.
S.
It does... Been going through the code but have not yet figured out how they do it, they don't use the standard Perl modules for running a webserver but OTOH it's a purpose built interface that do not need to support every aspect of a "normal" webserver.
SørenR.

The quantum rule of insecurity which states that the act of observing how vulnerable a host or service is changes the insecurity level of the service.

User avatar
Snorkasaurus
Normal user
Normal user
Posts: 188
Joined: 2010-08-29 16:32
Location: Canada
Contact:

Re: Long-term roadmap suggestions?

Post by Snorkasaurus » 2014-10-21 23:51

SorenR wrote:It does... Been going through the code but have not yet figured out how they do it, they don't use the standard Perl modules for running a webserver but OTOH it's a purpose built interface that do not need to support every aspect of a "normal" webserver.
True, it is not like you can add things like php or cgi to the assp web server (at least I would assume that you can't do that easily). As long as the "destination management interface" for hMailServer doesn't increase resource requirements I wouldn't be bothered by it. I would be disappointed about having to install a browser on my server but I would probably deal with it. However, it would be hard to beat the existing interface for resource usage.

Hey, that gives me an idea... if the management interface is going to be web based perhaps it would be a good idea to have an anti-hammering mechanism for it?

S.

User avatar
SorenR
Senior user
Senior user
Posts: 3169
Joined: 2006-08-21 15:38
Location: Denmark

Re: Long-term roadmap suggestions?

Post by SorenR » 2014-10-22 00:35

Snorkasaurus wrote:Hey, that gives me an idea... if the management interface is going to be web based perhaps it would be a good idea to have an anti-hammering mechanism for it?

S.
IP Range and Auto-Ban ??
SørenR.

The quantum rule of insecurity which states that the act of observing how vulnerable a host or service is changes the insecurity level of the service.

User avatar
Snorkasaurus
Normal user
Normal user
Posts: 188
Joined: 2010-08-29 16:32
Location: Canada
Contact:

Re: Long-term roadmap suggestions?

Post by Snorkasaurus » 2014-10-22 00:42

Yeah, exactly... just like the hMailServer internal auto-ban mechanism. Currently my admin interface is not accessible from outside of the network that the mail server sits on, if I were to open a web-admin interface to the outside world (so I could avoid putting a browser on my server) I would like to see a feature that will ban an IP for X minutes if Y bad attempts are made.

S.

Kelden
Normal user
Normal user
Posts: 42
Joined: 2011-05-02 13:58

Re: Long-term roadmap suggestions?

Post by Kelden » 2014-10-22 23:26

Better and simpler backup and restore.
Better restore for single messages.

Lefty
New user
New user
Posts: 3
Joined: 2014-10-15 18:09

Re: Long-term roadmap suggestions?

Post by Lefty » 2014-10-23 16:30

SorenR wrote:Or... By using the REST API you could make a Java based GUI distributed via Java Web Start.
Just like Cisco do with their products...
Having Java on the Server is not the best idea one could have. But thats only my opinion.

User avatar
Snorkasaurus
Normal user
Normal user
Posts: 188
Joined: 2010-08-29 16:32
Location: Canada
Contact:

Re: Long-term roadmap suggestions?

Post by Snorkasaurus » 2014-10-23 16:36

Lefty wrote:Having Java on the Server is not the best idea one could have. But thats only my opinion.
Mine too.
S.

percepts
Senior user
Senior user
Posts: 5282
Joined: 2009-10-20 16:33
Location: Sceptred Isle

Re: Long-term roadmap suggestions?

Post by percepts » 2014-10-23 18:58

Kelden wrote:Better and simpler backup and restore.
Better restore for single messages.
I think the hmail backup works OK as is. It is really only designed, I think, for smaller setups. Larger setups should be using other using other means such as disk mirroring or DB and Datafolder backups off site.

However, I think a Data export and import facility would be extremely useful and could also be used as backup method.
I'm thinking a tool which could export by selected domains (or all domains) and import to another existing hmail setup without wiping whats already in that setup. This is something that is asked about in the forums from time to time when people want to shift domains from one server to another. I know there are IMAP tools out there which can do this but an hmail specific addon would be nice to have.

User avatar
mattg
Moderator
Moderator
Posts: 20024
Joined: 2007-06-14 05:12
Location: 'The Outback' Australia

Re: Long-term roadmap suggestions?

Post by mattg » 2014-10-23 23:35

I like the idea of 'restoring' a single domain (ie moving from one hMailserver to another).
I like the idea of a single message restore.
Just 'cause I link to a page and say little else doesn't mean I am not being nice.
https://www.hmailserver.com/documentation

User avatar
katip
Senior user
Senior user
Posts: 673
Joined: 2006-12-22 07:58
Location: Istanbul

Re: Long-term roadmap suggestions?

Post by katip » 2014-10-24 05:53

Deleted accounts should automatically be deleted from distribution lists too. It's a pain to remember in which list(s) it was a member and delete one by one manually.
Katip
--
HMS 5.7.0-B2428-LTS-64-bit, MySQL 5.7.24, SA 3.4.2, ClamAV 0.101.2 + SaneS

User avatar
ras07
Normal user
Normal user
Posts: 193
Joined: 2010-03-11 08:51

Re: Long-term roadmap suggestions?

Post by ras07 » 2014-10-29 07:42

percepts wrote:
Kelden wrote:Better and simpler backup and restore.
Better restore for single messages.
I think the hmail backup works OK as is. It is really only designed, I think, for smaller setups. Larger setups should be using other using other means such as disk mirroring or DB and Datafolder backups off site.
I agree with Kelden that some backup improvements would be really useful. The current backup system is only useful for very small setups. There's a big gap between that and a larger setup that warrants advanced backup capability.

User avatar
bagu
Normal user
Normal user
Posts: 210
Joined: 2005-06-17 03:08
Location: France
Contact:

Re: Long-term roadmap suggestions?

Post by bagu » 2014-10-30 00:02

Snorkasaurus wrote:I'm voting for "cross-platform" and "other" because I wanted to add the point that if hMailServer were to be going cross platform I would much prefer that it not be dependent on supporting applications like Java, Python, Perl, .NET, Ruby, etc.

My mail server also provides http, sshd, irc, mysql, and backup services - all of which I can find suitable Linux replacements for, but I continue to run them all on Windows because I can't find a suitable replacement for hMailServer. There are plenty of Linux based mail server solutions but none of them come close to hMailServer's ability to manage all aspects of what I would consider to be core functions of an MTA. In the Linux world you may choose from:

1. Stringing together a patchwork of at least a half dozen applications to provide all required services (smtp, imap, pop, av, spam, etc)
2. Very limited suite-like solutions like iRedMail or Axigen
3. Commercial and/or proprietary software

I think that if the existing functionality of hMailServer were ported to Linux it would simply blow all other solutions (on any platform) out of the water.

My 3¢
S.
Same thing here. Cross plateform will really be a great and usefull thing.
hMailServer 5.6.8 With SpamAssassin 3.4.2

sergey-xrus
New user
New user
Posts: 2
Joined: 2014-09-17 13:53

Re: Long-term roadmap suggestions?

Post by sergey-xrus » 2014-11-02 15:51

Cross platform under FreeBSD, would be by the way, because I nenadal not one mail server capable as what is in hmailserver windows to perform typical mail server functions, especially in the context of the finished product and the available recovery options with full collapse (no mail server which can be restored by copying the folders in the directory and start the synchronization directory and mysql database!!!

Yes I will agree there are some problems, such as: not recover the password hashes when restoring a server (have again their account to register), but this is minor compared to the fact that, in General, performs and manages the server hmailserver!!!

If critical what you need: the platform , the solution to the rapid recovery of the fallen server (mysql database recovery with the correct recovery password hashes accounts, so as not to set them manually after the restore), to sort messages in real subfolders mailbox (mailbox/inbox , mailbox/mail out ) with the translation of other language folders on the Latin alphabet, and seamlessly synchronize folders box with mysql database in accordance with the existing folders (exclude the situation when all the letters are in imap inbox!!!!

Add the ability to import/export lists: white list, grey list and white list for independent data generation system administrators what is possible and what not to miss in users ' mailboxes.
S0*********.du.sha*****l.n*t
*.67.*.223
Rejected by Spam
and priority response in the form of digits something like this

and the ability to import and export these data in files and from files openoofice 4 tables and Excel (preferably the first format because it's free (as is convenient of these formats to unload and reload the files from 1C 8.3 native configuration on Information security.)

joseasl
New user
New user
Posts: 5
Joined: 2014-08-31 14:16

Re: Long-term roadmap suggestions?

Post by joseasl » 2014-11-07 12:12

I vote like Mattg for the ability to use multiple IP Public addresses, defined per domain. This is essential for me.
I also vote for Firebird SQL support, and more scripting options. I'd like to be able to choose a mail route for a message inside the script; like sending emails with more than N recipients through another server (or another IP if multiple IP support is available). Then I can ensure certain IPs are spammer safe (customer with bad habits, virus, hacked accounts, whatever).

Regards

alescan
Normal user
Normal user
Posts: 43
Joined: 2014-11-11 17:29
Location: Italy
Contact:

Re: Long-term roadmap suggestions?

Post by alescan » 2014-11-14 18:14

I vote for others:
I like the idea of this guy, viewtopic.php?f=20&t=15514, cleanup the folders that in long time use could become unused or empty. And also the database of course.
The script is no longer available cause is not working, but I think it could be very useful if it were natively in the program.
HMS 5.6.7 B2425 on Win Server 2012 R2 Standard with SQL Server 2014 SP2

Post Reply