Community Discussions and Support
Web Mail Server

Probably the easiest option would be to static the local IP address.

I presume Mercury & apache are on the same machine. You could tell mercury to use localhost, but other pc's won't be able to talk to it.

 

<p>Probably the easiest option would be to static the local IP address.</p><p>I presume Mercury & apache are on the same machine. You could tell mercury to use localhost, but other pc's won't be able to talk to it. </p><p>  </p>

I want to make web mail server using Mercury, is that possible..?

so when i in the office, i can  send/receive email locally using Outlook Express

and when i at home, i can send/receive email using web mail to connect web mail server in the office 

i have static IP from ISP.

 

Thanks for your response.

<p>I want to make web mail server using Mercury, is that possible..?</p><p>so when i in the office, i can  send/receive email locally using Outlook Express</p><p>and when i at home, i can send/receive email using web mail to connect web mail server in the office </p><p>i have static IP from ISP.</p><p> </p><p>Thanks for your response. </p>

There are many IMAP-based webmail servers that work well with Mercury, including SquirrelMail, Horde/IMP, Twig and others.

There will, eventually, be a native webmail server for Mercury (the problem is not Mercury, or the mail part, but the HTML: it's mind-bogglingly difficult to design an effective user interface in HTML, and it's outside my personal skill set), but until that time, one of our priorities is to do some testing and evaluation on the third-party webmail offerings and develop some comprehensive integration guides for one or two of the best. For now, though, I think you'll probably get better assistance from other people in the community than you will from me personally.

Cheers!

-- David --

There are many IMAP-based webmail servers that work well with Mercury, including SquirrelMail, Horde/IMP, Twig and others. There will, eventually, be a native webmail server for Mercury (the problem is not Mercury, or the mail part, but the HTML: it's mind-bogglingly difficult to design an effective user interface in HTML, and it's outside my personal skill set), but until that time, one of our priorities is to do some testing and evaluation on the third-party webmail offerings and develop some comprehensive integration guides for one or two of the best. For now, though, I think you'll probably get better assistance from other people in the community than you will from me personally. Cheers! -- David --

We're running MailBee WebMail with great success. It is translated into a number of languages. However it is not free but very affordable, and installs easily on your IIS webserver without the use of scripting apart from native ASP. You can also alter the log-in to utilize your own database with account information, or build it side by side.

You'll find MailBee at AfterLogics website: http://www.afterlogic.com/mailbee/webmail-pro.asp

<P>We're running MailBee WebMail with great success. It is translated into a number of languages. However it is not free but very affordable, and installs easily on your IIS webserver without the use of scripting apart from native ASP. You can also alter the log-in to utilize your own database with account information, or build it side by side.</P> <P>You'll find MailBee at AfterLogics website: <A href="http://www.afterlogic.com/mailbee/webmail-pro.asp">http://www.afterlogic.com/mailbee/webmail-pro.asp</A></P>

I have SquirrellMail working very well with Mercury.

I've edited the template so it looks a little nicer..

Very happy with it :)
 

<p>I have SquirrellMail working very well with Mercury.</p><p>I've edited the template so it looks a little nicer..</p><p>Very happy with it :)  </p>

Thanks a lot for your respond, i will try your solution.

Thanks a lot for your respond, i will try your solution.

http://www.mail2web.com - Free and works great! I use it with IMAP and have no problems! Zero software to install / maintain.

<a href="http://www.mail2web.com" title="http://www.mail2web.com" target="_blank" mce_href="http://www.mail2web.com">http://www.mail2web.com</a> - Free and works great! I use it with IMAP and have no problems! Zero software to install / maintain.

Does a built-in web mail interface still make sense, when there are so many good web mail interfaces out there? Also, doesn't it broaden the attack surface? If the web server and the mail server are separate processes - maybe on separate machines, breaking one still makes difficult to attack the other, while applications like PHP, Apache or IIS are thoroughly tested by a large number of people, while the embedded web server wouldn't. And once added, you'll have to mantain and update it, and test compatibility with the browser around - and people will soon want AJAX interfaces and the like :-)

IMHO it would be better to allocate development resource in other improvements - like allowing Mercury to run as a service, for example, or adding a way to administer it remotely without using a remote control software like VNC or Remote Desktop, maybe a web interface to administer it could be welcome.

<P>Does a built-in web mail interface still make sense, when there are so many good web mail interfaces out there? Also, doesn't it broaden the attack surface? If the web server and the mail server are separate processes - maybe on separate machines, breaking one still makes difficult to attack the other, while applications like PHP, Apache or IIS are thoroughly tested by a large number of people, while the embedded web server wouldn't. And once added, you'll have to mantain and update it, and test compatibility with the browser around - and people will soon want AJAX interfaces and the like :-)</P> <P>IMHO it would be better to allocate development resource in other improvements - like allowing Mercury to run as a service, for example, or adding a way to administer it remotely without using a remote control software like VNC or Remote Desktop, maybe a web interface to administer it could be welcome.</P>

Taking Mercury to work as a native service is the next step. This functionality was taken out of the beta prior to release since it would have deferred the release by a couple of months.

My belief regarding making M/32 a native webmail client is that this functionality within the mail server software is a remnance from the past, when good clients lacked lot of Pegasus Mail capability. Today however the scene has shifted, and a web-administration tool would be lots more appreciated along with running Mercury as a native service. Mercury's strength lies in its diversity as a server software. It can easily be added to, to get the functionality and the personal touch that many administrators want for their culture set. It clearly lacks the native service capability, as well as remote administration without the need of other products. I'm quite positive Davids shares this vision, but with absolute certainty - no -, David has as always the final say, since he is "the author".

<P>Taking Mercury to work as a native service is the next step. This functionality was taken out of the beta prior to release since it would have deferred the release by a couple of months.</P> <P>My belief regarding making M/32 a native webmail client is that this functionality within the mail server software is a remnance from the past, when good clients lacked lot of Pegasus Mail capability. Today however the scene has shifted, and a web-administration tool would be lots more appreciated along with running Mercury as a native service. Mercury's strength lies in its diversity as a server software. It can easily be added to, to get the functionality and the personal touch that many administrators want for their culture set. It clearly lacks the native service capability, as well as remote administration without the need of other products. I'm quite positive Davids shares this vision, but with absolute certainty - no -, David has as always the final say, since he is "the author".</P>

Is there a particular webmail utility that you would recommend for use with mercury?

Is there a particular webmail utility that you would recommend for use with mercury?

squirrelmail works well, but I don't like the interface / look

I installed  http://roundcube.net/ ( also open source ) and its a recent software, but it works well and looks soooooooooo cooool!! and clean and easy to use  :)
Not easy to install as squirrelmail as you need to setup mysql to keep user preferences.
 

<p>squirrelmail works well, but I don't like the interface / look </p><p>I installed  http://roundcube.net/ ( also open source ) and its a recent software, but it works well and looks soooooooooo cooool!! and clean and easy to use  :) Not easy to install as squirrelmail as you need to setup mysql to keep user preferences.  </p>

I've tried RoundCube.. Like you say it looks great, but doesn't have any filtering support.

This can be a pain as Mercury doesn't have filtering support either :(

<p>I've tried RoundCube.. Like you say it looks great, but doesn't have any filtering support.</p><p>This can be a pain as Mercury doesn't have filtering support either :( </p>

[quote user="tomt"]

I've tried RoundCube.. Like you say it looks great, but doesn't have any filtering support.

This can be a pain as Mercury doesn't have filtering support either :(

[/quote]

Let's be fair here: it's not that Mercury doesn't have filtering support - it's that IMAP doesn't have filtering support. Mercury has so much filtering overall that you could practically sort sand with it. I could easily enough add filtering into the IMAP equation, but there would be no standard way of manipulating the filters, and no way of having IMAP clients apply the filters on demand; it would all have to be automatic and rather ad-hoc.

If enough of you feel there might be a value in adding a proprietary, ad-hoc filtering extension to MercuryI, I'm willing to consider it, I guess, even if by doing so I *am* opening myself to the brigade of knockers who will crucify me for being non-standard.

Cheers!

-- David --

[quote user="tomt"]<p>I've tried RoundCube.. Like you say it looks great, but doesn't have any filtering support.</p><p>This can be a pain as Mercury doesn't have filtering support either :( </p>[/quote] Let's be fair here: it's not that Mercury doesn't have filtering support - it's that IMAP doesn't have filtering support. Mercury has so much filtering overall that you could practically sort sand with it. I could easily enough add filtering into the IMAP equation, but there would be no standard way of manipulating the filters, and no way of having IMAP clients apply the filters on demand; it would all have to be automatic and rather ad-hoc. If enough of you feel there might be a value in adding a proprietary, ad-hoc filtering extension to MercuryI, I'm willing to consider it, I guess, even if by doing so I *am* opening myself to the brigade of knockers who will crucify me for being non-standard. Cheers! -- David --

[quote user="David Harris"]

If enough of you feel there might be a value in adding a proprietary, ad-hoc filtering extension to MercuryI, I'm willing to consider it, I guess, even if by doing so I *am* opening myself to the brigade of knockers who will crucify me for being non-standard.

[/quote]

+1 [:D]

Would this take the form of an extension to the existing filtering rules with a new action "Move/copy.. to IMAP subfolder" (e.g. SPAM) ?

If not, what do you envision?

I would expect more advanced (or more personal) filtering (like "Move my Widget production reports to the widget folder, except the ones sent on a Wednesday") to be a client side operation.

If this is the sort of things webmail users want the server to do (and be able to change themselves), I can see your reasons for reluctance. (Is that a can of worms in your hand [:P])

<p>[quote user="David Harris"]</p><p>If enough of you feel there might be a value in adding a proprietary, ad-hoc filtering extension to MercuryI, I'm willing to consider it, I guess, even if by doing so I *am* opening myself to the brigade of knockers who will crucify me for being non-standard. [/quote]</p><p>+1 [:D]</p><p>Would this take the form of an extension to the existing filtering rules with a new action "Move/copy.. to IMAP subfolder" (e.g. SPAM) ?</p><p>If not, what do you envision?</p><p>I would expect more advanced (or more personal) filtering (like "Move my Widget production reports to the widget folder, except the ones sent on a Wednesday") to be a client side operation.</p><p>If this is the sort of things webmail users want the server to do (and be able to change themselves), I can see your reasons for reluctance. (Is that a can of worms in your hand [:P]) </p>

David Harris writes:

> Let's be fair here: it's not that Mercury doesn't have filtering support - it's that IMAP doesn't have filtering support. Mercury has so much > filtering overall that you could practically sort sand with it. I could easily enough add filtering into the IMAP equation, but there would > be no standard way of manipulating the filters, and no way of having IMAP clients apply the filters on demand; it would all have to be > automatic and rather ad-hoc.

One thing your filtering system won't allow just yet is per-user-specified filters for mail delivered into a specific user's mailbox to be routed to subfolders. That's an essential first step, of course. There can be no GUI; it'll have to be a file dropped in the user's mail directory. A user can update that file to get mail sorted into the proper physical subfolders in their maildrop and observe the benefits in Pegasus Mail, with IMAP or with webmail using IMAP.

I still maintain that doing the filtering on the server automatically is the proper and correct thing to do. Letting clients do it using IMAP is just slow and 'orrible. Letting clients touch the filtering rules in standard filtering language form (Sieve from the IETF, for instance) is a nice idea, except of course that there's no way to do it over the network presently and Sieve still finds greatest usage between cooperating processes on the same box (EG: mail delivery agent / webmail facility). The greatest weakness in a Mercury-backended webmail is that it has IMAP as an exclusive abstraction for Webmail rather than file-based access to filter files and mailboxes, neither of which are really open.

Right now, the Unix world gets the benefit of, for instance, procmail or maildrop (and most recently Sieve's) prevalent usage by most MTAs for mail delivery, both of which support mailbox formats all servers and MUAs can read and so several webmail packages are able to support filtering from the web interface quite simply - they just write a user's .procmailrc for them and, assuming the MTA uses procmail to deliver, bingo. And since their MUA and IMAP server will be reading mailboxes from the same structure, that one change affects all their mail. With a few modifications to popular Open Source webmail packages, we can hope for a similar opportunity for Mercury using IMAP. Perhaps Sieve would be a good choice of language for such filter files.

Cheers,

Sabahattin

David Harris writes: > Let's be fair here: it's not that Mercury doesn't have filtering support - it's that IMAP doesn't have filtering support. Mercury has so much > filtering overall that you could practically sort sand with it. I could easily enough add filtering into the IMAP equation, but there would > be no standard way of manipulating the filters, and no way of having IMAP clients apply the filters on demand; it would all have to be > automatic and rather ad-hoc. One thing your filtering system won't allow just yet is per-user-specified filters for mail delivered into a specific user's mailbox to be routed to subfolders. That's an essential first step, of course. There can be no GUI; it'll have to be a file dropped in the user's mail directory. A user can update that file to get mail sorted into the proper physical subfolders in their maildrop and observe the benefits in Pegasus Mail, with IMAP or with webmail using IMAP. I still maintain that doing the filtering on the server automatically is the proper and correct thing to do. Letting clients do it using IMAP is just slow and 'orrible. Letting clients touch the filtering rules in standard filtering language form (Sieve from the IETF, for instance) is a nice idea, except of course that there's no way to do it over the network presently and Sieve still finds greatest usage between cooperating processes on the same box (EG: mail delivery agent / webmail facility). The greatest weakness in a Mercury-backended webmail is that it has IMAP as an exclusive abstraction for Webmail rather than file-based access to filter files and mailboxes, neither of which are really open. Right now, the Unix world gets the benefit of, for instance, procmail or maildrop (and most recently Sieve's) prevalent usage by most MTAs for mail delivery, both of which support mailbox formats all servers and MUAs can read and so several webmail packages are able to support filtering from the web interface quite simply - they just write a user's .procmailrc for them and, assuming the MTA uses procmail to deliver, bingo. And since their MUA and IMAP server will be reading mailboxes from the same structure, that one change affects all their mail. With a few modifications to popular Open Source webmail packages, we can hope for a similar opportunity for Mercury using IMAP. Perhaps Sieve would be a good choice of language for such filter files. Cheers, Sabahattin

[quote user="David Harris"][quote user="tomt"]

I've tried RoundCube.. Like you say it looks great, but doesn't have any filtering support.

This can be a pain as Mercury doesn't have filtering support either :(

[/quote]

Let's be fair here: it's not that Mercury doesn't have filtering support - it's that IMAP doesn't have filtering support. Mercury has so much filtering overall that you could practically sort sand with it. I could easily enough add filtering into the IMAP equation, but there would be no standard way of manipulating the filters, and no way of having IMAP clients apply the filters on demand; it would all have to be automatic and rather ad-hoc.

If enough of you feel there might be a value in adding a proprietary, ad-hoc filtering extension to MercuryI, I'm willing to consider it, I guess, even if by doing so I *am* opening myself to the brigade of knockers who will crucify me for being non-standard.

Cheers!

-- David --

[/quote]

Hi David

I didn't mean this to sound like I was knocking Mercury.. Mercury is a great product. :)[Y]

I think IMAP filtering is important..Doing it at the mail server should be faster and better than doing it via a client.

I have played with HMailServer - this does offer IMAP filtering.. But I still prefer Mercury.

 Regards
 


 

 

I  

[quote user="David Harris"][quote user="tomt"]<p>I've tried RoundCube.. Like you say it looks great, but doesn't have any filtering support.</p><p>This can be a pain as Mercury doesn't have filtering support either :( </p><p>[/quote] Let's be fair here: it's not that Mercury doesn't have filtering support - it's that IMAP doesn't have filtering support. Mercury has so much filtering overall that you could practically sort sand with it. I could easily enough add filtering into the IMAP equation, but there would be no standard way of manipulating the filters, and no way of having IMAP clients apply the filters on demand; it would all have to be automatic and rather ad-hoc. If enough of you feel there might be a value in adding a proprietary, ad-hoc filtering extension to MercuryI, I'm willing to consider it, I guess, even if by doing so I *am* opening myself to the brigade of knockers who will crucify me for being non-standard. Cheers! -- David -- [/quote]</p><p>Hi David</p><p> I didn't mean this to sound like I was knocking Mercury.. Mercury is a great product. :)[Y]</p><p>I think IMAP filtering is important..Doing it at the mail server should be faster and better than doing it via a client.</p><p>I have played with HMailServer - this does offer IMAP filtering.. But I still prefer Mercury.</p><p> Regards  </p><p>  </p><p> </p><p>I  </p>

> I have played with HMailServer - this does offer IMAP filtering.. But I still prefer Mercury.

How is the filtering controlled by the user in HMailServer?

>
>  Regards

> I have played with HMailServer - this does offer IMAP filtering.. But I still prefer Mercury. How is the filtering controlled by the user in HMailServer? > >  Regards

[quote user="Thomas R. Stephenson"]> I have played with HMailServer - this does offer IMAP filtering.. But I still prefer Mercury.

How is the filtering controlled by the user in HMailServer?

>
>  Regards

[/quote]

 

These 2 links explain..

http://www.hmailserver.com/documentation/?page=howto_move_spam_to_IMAP_folder

http://www.hmailserver.com/documentation/?page=reference_rules

<P>[quote user="Thomas R. Stephenson"]> I have played with HMailServer - this does offer IMAP filtering.. But I still prefer Mercury. How is the filtering controlled by the user in HMailServer? > >  Regards [/quote]</P> <P mce_keep="true"> </P> <P>These 2 links explain..</P> <P><A href="http://www.hmailserver.com/documentation/?page=howto_move_spam_to_IMAP_folder">http://www.hmailserver.com/documentation/?page=howto_move_spam_to_IMAP_folder</A></P> <P><A href="http://www.hmailserver.com/documentation/?page=reference_rules">http://www.hmailserver.com/documentation/?page=reference_rules</A></P>

[quote user="tomt"]

[quote user="Thomas R. Stephenson"]> I have played with HMailServer - this does offer IMAP filtering.. But I still prefer Mercury.

How is the filtering controlled by the user in HMailServer?

>
>  Regards

[/quote]

 

These 2 links explain..

http://www.hmailserver.com/documentation/?page=howto_move_spam_to_IMAP_folder

http://www.hmailserver.com/documentation/?page=reference_rules

[/quote]

 

I'm confused, I thought we were talking about IMAP4 user filters.  .  How does the casual IMAP4 user access and control the mail server?  This just looks likwe something the system admin has to do and all users get the same filter.

 

 

[quote user="tomt"]<p>[quote user="Thomas R. Stephenson"]> I have played with HMailServer - this does offer IMAP filtering.. But I still prefer Mercury. How is the filtering controlled by the user in HMailServer? > >  Regards [/quote]</p> <p mce_keep="true"> </p> <p>These 2 links explain..</p> <p><a href="http://www.hmailserver.com/documentation/?page=howto_move_spam_to_IMAP_folder" mce_href="http://www.hmailserver.com/documentation/?page=howto_move_spam_to_IMAP_folder">http://www.hmailserver.com/documentation/?page=howto_move_spam_to_IMAP_folder</a></p> <p><a href="http://www.hmailserver.com/documentation/?page=reference_rules" mce_href="http://www.hmailserver.com/documentation/?page=reference_rules">http://www.hmailserver.com/documentation/?page=reference_rules</a></p><p>[/quote]</p><p> </p><p>I'm confused, I thought we were talking about IMAP4 user filters.  .  How does the casual IMAP4 user access and control the mail server?  This just looks likwe something the system admin has to do and all users get the same filter.</p><p> </p><p> </p>

Hi Thomas.

I'm pushing for filtering.. But I'm happy for it to be done at the server level by the mail server administrator.

Client filtering can be done in Outlook or SquirrelMail .
Outlook I don't use and doing it via SquirrelMail is slow.

If I could be done within Mercury then that should work better.
 

<p>Hi Thomas.</p><p>I'm pushing for filtering.. But I'm happy for it to be done at the server level by the mail server administrator. Client filtering can be done in Outlook or SquirrelMail . Outlook I don't use and doing it via SquirrelMail is slow. If I could be done within Mercury then that should work better.  </p>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft