Hi, SmarterMail ist available in german. The german strings where translated by the community and customers. Usually i had to fix some typos and some strange phrases ;-) The support is english spoken, but we will create a german support community in july/august based on communityserver (www.communityserver.org).
Mit freundlichen Grüssen ---------------------------------------------------------------------------- ------- Merlin Consulting | Martin Schaible Bahnhofstrasse 27 | CH-8702 Zollikon | Switzerland Tel.: +41 44 391 30 00 | Fax: +41 44 391 32 49 Mail: [EMAIL PROTECTED] | www.merlinconsulting.ch Support: support.merlinconsulting.ch GPS: N47 20.235 E8 34.226 ---------------------------------------------------------------------------- ------- News - Unsere Produkte: .:. Ipswitch Premium Partner .:. mxGuard/InvURIBL/MessageSniffer Antispam Lösung für IMail .:. Brainware Columbus Software Management .:. delight software GmbH .:. NewAtlanta BlueDragon .:. JMuffin CMS .:. NOD32 Antivirus System .:. Kiwi Syslog Monitor .:. Lockstep Systems - Backup Software .:. Paessler Network Monitoring .:. SmarterTools ---------------------------------------------------------------------------- ------- > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Rainer Noa > Gesendet: Freitag, 18. Mai 2007 08:03 > An: [email protected] > Betreff: AW: [IMail Forum] Grey Listing > > Hello Martin, is SmarterMail available in German version with German > support? > See the website, looks good! > The pricing is Ok to. > Perhaps you will contact me! > > Best regards :) > -- > i.A. Rainer Noa > Projektmanager > > MilesTec AG > Prager Ring 2 > 66482 Zweibrücken > > Fon: (06332) 479 00 30 > Fax: (01212) 518 21 06 71 > Mobil: (0171) 742 18 56 > Email: [EMAIL PROTECTED] > > Sitz der Gesellschaft: Zweibrücken > Handelsregister: Amtsgericht Zweibrücken HRB 1663 Z > Vorsitzender des Aufsichtsrates: Rüdiger Burkart > Vorstand: Oliver Reinking > Steuer-Nr.: DE196797197 USt-IdNr.: 35.657.06220 > > > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von > Martin Schaible > Gesendet: Freitag, 18. Mai 2007 00:18 > An: [email protected] > Betreff: AW: [IMail Forum] Grey Listing > > Hi to all, > > I agree with all responses from you. Maybe i have to explain > my situation a > bit more. I learned, that market for mail servers is in > general full up, at > least in our small country. I sold my last Imail license 6 > Month ago. We're > looking for a solution to move forward to our very loyal > customer base. > Mostly all of them have now mxGuard and MessageSniffer. All > customers are in > small and medium region, the average user count per server > might around 100 > to 150. Some customers are ISP's like our hosting company, > having around > 2000 accounts. No question, that small companies are not in > the mood to have > an second server using ASSP or others. A second box makes > really sense for > high volume mail servers. > > We also realized, that the development process at Ipswitch > takes a lot of > time, kinda "slow motion development". I think, the resources are very > limited at Ipswitch. Since a year, we have Imail 2006 and > they spent the > whole year to get rid of the bugs from the new WebMail and > WebAdmin. That's > it. > Customers are asking, why the have to renew the subscription. > It looks like, > that they are expecting more. > > More and more the customers are also asking for groupware > functionalities > like Imail premium offers partially. This is now the point, which my > favorite software enters the stage: SmarterMail. This piece > of Software runs > really perfectly and the guys at SmarterTools are investing a lot of > manpower to develop the product further on. SmarterMail uses > SpamAsassin to > fight against spam, which is ok for most all cases. The groupware > functionality is awesome and the WebMail looks really nice. > > The only drawback is, that mxGuard and all optional filters are not > available for SmarterMail. This would be the "dreamteam" for > us and our > (small/medium) customers: SmarterMail and mxGuard with MessageSniffer. > Especially for customers, which already have such licenses. > > We have to find a decision until July, which way we want to > go. It looks bad > for Imail. > > Mit freundlichen Grüssen > > -------------------------------------------------------------- > -------------- > ------- > Merlin Consulting | Martin Schaible > Bahnhofstrasse 27 | CH-8702 Zollikon | Switzerland > Tel.: +41 44 391 30 00 | Fax: +41 44 391 32 49 > Mail: [EMAIL PROTECTED] | www.merlinconsulting.ch > Support: support.merlinconsulting.ch > GPS: N47 20.235 E8 34.226 > -------------------------------------------------------------- > -------------- > ------- > > News - Unsere Produkte: > .:. Ipswitch Premium Partner > .:. mxGuard/InvURIBL/MessageSniffer Antispam Lösung für IMail > .:. Brainware Columbus Software Management > .:. delight software GmbH > .:. NewAtlanta BlueDragon > .:. JMuffin CMS > .:. NOD32 Antivirus System > .:. Kiwi Syslog Monitor > .:. Lockstep Systems - Backup Software > .:. Paessler Network Monitoring > .:. SmarterTools > -------------------------------------------------------------- > -------------- > ------- > > > > -----Ursprüngliche Nachricht----- > > Von: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Im Auftrag von > > Andy Schmidt > > Gesendet: Donnerstag, 17. Mai 2007 15:39 > > An: [email protected] > > Betreff: RE: [IMail Forum] Grey Listing > > > > Hi Martin: > > > > Don't get your hopes up. IMail is a great "application" (e.g., their > > back-end), but on the systems end (dealing with the SMTP > > protocol), they've > > never been able to catch up with real-life demands. It's > > possible that they > > just don't have any strong talent in that area. > > > > Most of their anti-spam implementation is of little value, > > because it forces > > us to first ACCEPT a mail and THEN (if we were to follow > RFCs) notify > > apparent senders of our non-delivery. That was fine 10 or 15 > > years ago, when > > this was once conceived. But given the realities of 2007 (and > > the several > > prior years), 99% of the apparent senders are non-existing > accounts or > > joe-jobs who would end up being spammed by us. If we simply "delete" > > messages, then you run the risk of deleting or blocking > > legitimate messages > > WITHOUT giving the sender (and the recipient) the required > > (and absolutely > > necessary) notification that "something's wrong with your message". > > > > The obvious solution has always been to REFUSE the acceptance > > of mail as > > early as possible - meaning, during the actual SMTP > connection. If one > > chooses to block mail based on failed SPF, missing RevDNS > > (whether you agree > > with that or not), faked HELO strings or even certain > > internal or public IP > > or domain black-lists, then this should be done during the > > connection - not > > after the "ship has sailed". This way, the sending mail > > server would receive > > a proper error-return and IT will be responsible of notifying > > its OWN users > > (if indeed there was a legitimate user involved). > > > > The same holds true of the ability to "fortify" certain > > accounts (such as > > abuse@, postmaster@,...). We should be able to set up > > "policies" where any > > mail directed to these accounts is not permitted to have more > > than xxx other > > recipients (possibly as little as 1). > > > > Moving on to SURBL and other content checking (even virus > > checking). Some > > could be performed before confirming the receipt of the DATA > > command and > > still refused at that time. While connection dropping at that > > point is not > > an option offered by the RFC, it is now a very common and > > thus justifiable > > practice. > > > > All of these things are trivial to implement - yet, they never get > > accomplished. Consequently, I can't imagine them having > the necessary > > expertise to implement more sophisticated schemes, such as > > grey-listing. > > > > Your solution is to use Imail as the great back-end > > "application software" > > that it is, but to front-end it with more current technology > > by more capable > > "systems" vendors. For small users, Imail might work out of > > the box, but for > > more "exposed" mail domains, Imail is not a serious > contender for spam > > control and appears to have no ambitions in that direction. > > > > Best Regards, > > Andy > > > > > > > > ----- Original Message ----- > > From: "Martin Schaible" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Wednesday, May 16, 2007 8:44 PM > > Subject: AW: [IMail Forum] Grey Listing > > > > > > Hi, > > > > I expected a short statement from ipswitch. So, is a native > > greylisting > > somewhere on the horizon, or do we have to wait another year? > > > > > > > > Mit freundlichen Grüssen > > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > > List Archive: > > http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > List Archive: > http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > List Archive: > http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
