> Yes I have but AJAX is not the only way to do things.
> if there is no need for anything more than the stdin/stdout redirection then anything more is a moot point.
Never said that CGI can't work - just that it's being phased out due to its shortcomings. You can code the application of tomorrow, or that of yesterday.
> Ok, I see you want to be picky.
No, I am just correct. That's science - you can be correct or wrong, not "picky". Therefore I have no misconception about what is needed and what is not.
> Now to address the subject of dll files. As of Windows 2000, dll files once loaded stay in memory until the system is rebooted,
Again, not true.
> HKEY_LOCAL_MACHINE > Software > Microsoft > Windows > CurrentVersion > Explorer > AlwaysUnloadDLL
That's just avoid the "cache time" Windows Explorer uses when an application exits and its dll are unloaded - as long no other application uses them. That's to avoid to reload them from disk if the next app needs them. Ask yourself why this key is not the default if so useful...
>. You cannot tax 486 DX2 66 on a T1 with NT4 running, with todays computers....
Don't know where you live, but I can easily overwhelm a P4 with Windows 2003 with the bandwith and users available here.
> So you are implying that I cannot write a webmail system that is useful and should use an existing package.
No, I am just implying that your foundations are probably wrong, or obsolete. Feel free to write your own, but I suggest you to compare yours with those already available, and ask yourself why someone should use yours instead of the others.
> Because I want to.
Good luck. Bidirectional synchronization is always a nightmare, believe me. You are just reimplmenting the wheel, adding more complexity and the need of more resources, with no benefits. But you're the kind of guy who needs to hit the wall to acknowledge it's there.
Then feel free to insult me when you're unable to support you claims with facts.
Perhaps using the existing add a block of text tool as a basis allow administrators to set up a logo and effectively company wide signature for all outgoing email. In our case we would use the current disclaimer text along with company contact information and our logo.
The transaction filter on the HELO state works well if the announced name is the actual name. Spammers very often insert something else that changes faster than I can change my socks. This makes catching things like *adsl* not work all the time. If Mercury did an RDNS and the transaction could home in on the RDNS result then this would defeat the spammers. If when the RDNS finds that there is no name associated with the IP address, Mercury could insert, say "NULL" (as that is what gethostbyaddr returns), that could also be picked up by the transaction filter.
RDNS should be an option that can be turned on/off just in case there is too much of a performance hit for someone or is just not needed.
As Thomas already stated, There is Squirrelmail for webmail, and with use of daemons (even with out them) Mercury is already powerfull. Spamhalter, Greywall and Content Control and even the standard filtering Rules... and more...
I run Mercury as a service (win32) that starts up automatically when I start up the computer. When starting, the startup screen always appears for couple of seconds.
It would be nice to have a parameter (for example mercury.exe -nosplash) that starts up Mercury without splash screen so that it feels as an "invisible" service when starting up the computer.
Comments: Strangly if srvany.exe is used (part of Windows Resource Kit Tools) to create the effect of Mercury as nt service, there is no start-up screen when the parameter mercury.exe -m is used, but there is a minimized window of mercury in the taskbar that disappears when you click on it.
When the program FireDaemon () is used to let seem Mercury as a nt service, there is no minimized window but still a startup screen.
For internal reasons (to do with the way Mercury manages the list files) it's not a trivial change to sort the subscriber list. It's a reasonably common request, but implementing it will take quite a bit of effort.
We create the smtpauth.mer file with the same pairs as local mailbox name (= username) and the pop3 password. If your local mailboxes follow the syntax you should be able to have that combination within smtpauth.mer.
However, we've found it to be limiting, narrowminded and confusing for the users to have local mailboxes equal the mail-address. It gets very hard to explain that a mailbox has mail addresses attached to it, and that you can have as many as you like connected with a mailbox. Also for our users when using the webmail interface our users can log in using either their email address or their mailbox name, and a conversion is made if needed into the pair of mailbox/password for proper pop and imap fetch.
At this point, you can't really write a Daemon that could have a significant impact on the way MercuryP operates - I haven't as yet opened up its innards in the way I have for MercuryS... GreyWall is a good example of the type of minute control that the new protocol-level event mechanism I have developed for Daemons allows, but I'm retrofitting the event mechanism on a module by module basis, and MercuryP hasn't been done yet (even for v4.5). It's on the list though.
That said, the sorting idea isn't a difficult option to add, so that seems like a reasonable compromise in the short term.
Commentary on Point 1. The 30 char limit on email address in the Syslog (I and O records) will truncate this : Symantec_Mail_Security_for_SMTP@workorder.se Changing to variable-length records will also allow the addition of new fields more easily.
Commentary on Point 2 relating to mail stats. In trying to determine bandwidth usage per user, I have been examining the "I" and "O" records from the Syslog. 2.1 Mail between Local users only generates an "I" record. 2.2 A Local / Non-Local identifier on each address would be most useful for reporting (as indicated in the Core display) This to be able to split reporting between Local and Non-Local traffic. 2.3 Inbound mail indicates the TO address as the "mailbox" name and not the "alias" (email address) Outbound mail shows the FROM address as the email address and not eh "mailbox" name. Correlating the two is not possible by looking at the data only - a matching table is required.
Have you had a look at PopfileD? It's a server-side daemon for mercury that uses popfile to classify mails.
I have 5 separate buckets set up; you could create a bucket for 'houses' that adds an X-Text-Classification header to the mails, then your boss could filter houses mail as spam, and you could filter it into your 'todo' folder for example.