I'm glad if you still accept wishes...collected from my end-customers and our tech-supports.
1) Un-install option:
if critical bug is found after upgrade or installation of Hotfix and there is no workaround for that,
then customers need to re-image the appliance (to downgrade) and lose all quarantines messages.
2) End-User Blacklist:
1) Backup option, backup all configurations plus quarantined messages:
When a hardware issue occur and need to replace the box, customers need to lose all quarantines messages.
2) Visible backup file:
I want visible backup file and can be edited and reviewed by anyone without restoring it to MEG.
As Switches and Routers do the way, it's more convenient.
3) Download admin-selected logs by one-click option:
4) Notification option for messages quarantined in Failure queue:
I have already submitted it PER but many customers still request this feature.
5) Provide more authority (privilege) in general for admin users:
Customers can deal with most issues without waiting for the support reply.
Able to see and check hardware logs(dmessages) and internal information such as database logs(CLI and GUI).
Able to restart process such as Update process(CLI).
Able to change all configurations by CLI.
Thank you.このメッセージは次により編集されています: helo
I've though up another suggestion:
Allow replaceable variables in the user defined local header rules. For instance - we get a lot of spam now with the subject line consisting of just the first part of the recipients email address. In my case, I get email with the subject line of just amccann which is the part before the @ sign of my email address. Variables such as %localaddress%, %domainname%, etc would be a big help in adding user defined rules, without having to add a dictionary.
15 - An option to only send notifications only periodically (e.g. once an hour, once a day, once per sender, or any similar restriction.) would be helpful in avoiding the occassional mail loop.
16 - We periodically (acquisition, divestiture, spinoff, etc...) need to do things like change
It would be quite helpful if there were additional variables in Envelope Analysis notifications for the 'local' and 'domain' parts of the recipient email address, the bits before and after the '@' sign.
$RECIPIENT-LOCAL$ and $RECIPIENT-DOMAIN$
which could be put in a notification responses
We could then fashion responses such as this, which is more friendly than making the sender figure out the new email from a generic response.
This is in response to your email on <$DATE$> to <$RECIPIENT$> about <$SUBJECT$>.
My email address has been changed. It is now $RECIPIENT-LOCAL$@NewCompany.COM
Please make a note of the new address. You do not need to resend your message, it has been automatically forwarded to my new address. Forwarding will stop working on Month, Day and you will need to begin using the new address before than.
We are combining the Ironmail (McAfee Email Gateway) and EWS product lines into a single appliance product, taking the best pieces of both.
As part of this, we will have a virtual version of our email gateway product. This is due to ship before the end of this year as McAfee Email Gateway v7.0.
The existing 6.7.2 and 5.6 releases of Ironmail and EWS respectively will be supported for a further five years from the 7.0 release.