We have completed the rollout of PHP 5.1.6 scripting language on our clustered web hosting platform. PHP 5.1.6 is our first upgrade from PHP 4.x and opens up a new world of possibilities for our partners and customers to utilize many open source and commercial web applications free of charge on top of their web hosting accounts.
Due to the enormous amount of feedback by our customer base we are stepping up the defense from NDRs received for the emails that were not originated by your users to begin with. This is often called NDR blowback, backscatter, fake virus or worm storm, etc. It happens when someone uses your email address to relay an enormous amount of SPAM to the remote servers and encounters a lot of dead mailboxes that may have already been removed or had their quotas filled with SPAM. Naturally, an error bounces back to you because the remote server thinks you sent it. We have had NDR backscatter protection for quite some time but the cries from our customer base have forced us to take away our liberal stance on this issue. We are now strictly enforcing NDR legitimacy, meaning that we will only deliver NDR mail if the message was sent through one of our outbound servers. Anything else, because we cannot validate it, will be automatically thrown into the SPAM queue if you choose to quarantine SPAM messages. Are NDRs SPAM? No, the non-delivery receipts and delivery status notifications are not SPAM. They do not contain any unsolicited commercial communication, they are not selling anything, they are not dangerous in any way. They are annoying, very annoying when you receive a few hundred in a span of a minute. How did this happen? Well, someone you previously emailed likely got infected by a worm or a virus that searched their hard drive (mailboxes) for email addresses. It then took a random address and joined a botnet and sent thousands of messages and made them appear they came from you. Because the remote (recipient) server did not have proper SPAM protection it blindly accepted the message and issued a rejection. How does ExchangeDefender know what passed through it and what did not? ExchangeDefender outbound network stamps each outgoing message with a hash key. When the message is returned in a form of a DSN or NDR we check the SMTP header for the presence of our hash key, we decode it and compare with the local copy stored in our server along with the matching From: message. If the hash key matches the sender of the message the email is passed on to other filters. If it doesn’t it means that the message is a bounce to the message you never sent in the first place because it did not go through our network and it did not get stamped. What to do if you still keep on getting NDRs? There are a few things:
Thank you for trusting us with your mail.
The long awaited upgrades to our client software are finally out and available for download below. These updates address the issues found in the original releases that prevented the systems from rebooting in certain circumstances. This is a bugfix release only, if you’re not having problems there is no need to download them. First up, ExchangeDefender SPAM Monitor that alerts you of SPAM waiting for you on the server:
Second, the Shockey Monkey Server Agent software designed for Microsoft Windows (2000, XP, 2003, Vista and 2008) used to collect server inventory, logs, WMI data and intelligently feed it to Shockey Monkey for managed services and asset management:
Two builds are provided as .exe and .msi, you only need one. The .msi build is special because it can be used to roll out the software automatically using third party management tools.
With more and more misconfigured mail servers generating junk rejections we felt it was time to discuss our official policy on realtime blacklists (RBL) and the extent to which we support them. First of all, all Own Web Now Corp mail servers and every piece of mail leaving our network is scanned for SPAM, Viruses, malware and just about everything we scan inbound mail for we also scan outbound mail for. We do not allow open/blind relaying, we disinfect anything dangerous and take every precaution to keep dangerous content off the Internet. However, from time to time something may slip. Clients still get infected with viruses, clients still use weak passwords or their systems that open up their infrastructure to worms and mail blasts, stuff happens. OWN Network Operations monitors network activity and RBL lookups 24/7/365 and if there is an item that slipped our post and made it into an RBL (it usually takes just one piece) we immediately quarantine the user and request removal. We monitor over 100 RBLs and immediately act to make sure none of your mail is returned or bounced. However, as more and more mail server administrators lose control over their servers, they start implementing policies that affect the ability to deliver legitimate mail to them. Because some of the best RBLs are also commercial some users stoop to stealing DNS RBL zones, longer RBL lookup caching to avoid being rate-limited and kicked off the free service, or their mail servers simply have no resources to fight with the SPAM. Because our servers act as a transparent stateful proxies, meaning that we deliver your mail on your behalf, if there is a time that we have to return the message you will see outbound.exchangedefender.com as the server providing information on why the message was returned. This does not mean that outbound.exchangedefender.com rejected your message, it is simply quoting the error it received from the remote server. Own Web Now Corp does not have control of the remote servers, it usually does not have a relationship or contact information for neither the sending server (you) or the recipient (where you are sending mail) so we are unable to help with any rejections that happen outside of the generally accepted rules and protocols around mail delivery. If the mail server on the other side didn’t implement their RBL directives correctly, if they are overloaded, if they manually chose to program in a configuration to reject your mail or anything out of the normal course of server management - we can’t help. If you are seeing sources that are not adhering to these generally accepted rules such as quoting why the IP was blocked or message returned, we recommend you remove outbound.exchangedefender.com from your smarthost configuration and route messages to them directly. If that fails as well, try to contact the mail server administrator if you can locate their contact information. If you are tech savvy, you can create an SMTP connector for a given address space and route mail for particular domains directly to their mail servers, bypassing ExchangeDefender outbound proxies completely. Just to repeat, we constantly monitor network traffic and actively keep our servers off RBLs that you can find at www.dnsstuff.com. We do everything in our power to assure mail delivery but if the configuration change on the remote end specifically interferes with that delivery that is the place you need to contact and find a way to get mail from your network delivered to theirs.
Lately we have been fielding a lot of questions about why [SPAM] and [SURESPAM] messages keep on sliding through to the end users. We have also seen a lot of activity with users complaining about SPAM making it to them uninterrupted when it comes from an email address within their domain. Here is the problem:
Why would this happen? Well, users tend to scan messages and look for familiar names and subjects. When they encounter something they recognize, like an email address from their colleague or from themselves, they trust the sender. When they trust the spoofed address, all future mail comes through, causing frustration for everyone involved. Advise your users not to trust their own email address space when it shows up in ExchangeDefender SPAM reports. ExchangeDefender only intercepts messages going in and out of the organization, it does not filter internal messages. Any mail with the domains address space caught by ExchangeDefender is highly likely to be spoofed. Of course, usage and configuration of ExchangeDefender is up to you, we make the product flexible enough to allow you to set your own policies. But blindly trusting entire domains and mirrored trust sets (from exchangedefender.com to exchangedefender.com for example) will only let dangerous items through. Consider tightening up the ship if you are seeing ExchangeDefender starting to slip, our metrics show that our detection rate keeps on going up as both volume and percentage. As always, thanks for letting us clean your mail.
Shockey Monkey 2.0 Beta (build 1.9.21) was upgraded on all portals last night and is fully supported by Own Web Now Corp as mentioned last week. We anticipate this beta interval to last roughly one month with most attention being paid to the sensible integration of all the Shockey Monkey features. There are two threads activated specifically for build related bugfixes and feature requests. Simply login to https://support.ownwebnow.com and paste either shortcut to join the active development of the PSA system designed specifically for the needs of the small business specialists. Roadmap: Once the beta is completed in late May, Shockey Monkey signup forms will be available on the homepage. In the meantime, Shockey Monkey is in a closed beta and only available to our valued partners that make it possible for us to build these solutions. So join in on the fun and help us design something uniquely suited to your business. OWN is a dedicated partner company. Sincerely,
Scope of Support Technical support will be limited to the use of the product as documented, installation and configuration, third party software integration and basic configuration troubleshooting. Any bugs or feature requests are not covered under the scope of support as they require development, testing, analysis, documentation and deployment management and will be handled by teams other than support. Should you encounter a bug or can think of a great feature, click on the Development tab in our system and provide a bug or a feature. If you create a support request that is a bug or a feature request we will move the support request to the feature request or bug sections of our portal on your behalf. For support, https://support.ownwebnow.com
With ExchangeDefender 4.x infrastructure already in place on the inbound servers, we are moving our focus to the implementation of ExchangeDefender 4.x on the outbound servers. The new systems will go into production this weekend, April 5-6, and will feature new IP address relay servers:
This is the same IP range that is currently in use so you should not have to make any modifications or changes to your systems. Everything will just work transparently. If you are currently using SPF, which we do not recommend, you will have to adjust it to include the new IP addresses. For illustration purposes, here is a look at the possible SPF record:
This record will restrict relaying for domain.com to ExchangeDefender outbound servers only (naturally you should include your own IP as well for non-smarthosted deliveries) but the above should get you started. We don’t expect any issues as the new system has been in beta testing for a few months with no significant problems. Performance, logging, reporting and enforcement functionality that it delivers are far beyond comparison with the current service so we are really looking forward to it!
Join Vlad Mazek, Own Web Now Corp CEO for a chat with Karl Palachuk of KP Enterprises at about noon today (Eastern -5:00 GMT) for a discussion about SMB technology and where OWN solutions fit in it as well as the road ahead:
Generally we reserve network events and alerts for our Network Operations site but the volume of support regarding this single issue has prompted us to post it here. I hope you are not offended by the technical information regarding a third party service that may not affect you. In the old, dark ages of Internet when ExchangeDefender grew out of the primordial stew, people used connection-based filtering to blindly reject content using nothing but faith in the independent listing service. One of the popular realtime blacklists (RBL) was ORDB and it was a database of mail servers that were open relays. These servers could be used by anyone, without authentication of any sort, to send SPAM content all over the Internet. In December of 2006, ORDB went offline. On the morning of March 25, 2008 relays.ordb.org came back online, blacklisting everything. How, why, when and so on are not important, the only relevant task here is to stop using this RBL. If you receive the following context error, the remote server is still using ORDB to detect SPAM and it is dropping all your inbound mail:
If you use Exchange 2003 Service Pack 2 you can quickly remove ORDB from your RBL query list by opening up Exchange System Manager, navigating to Global Settings, right clicking on Message Delivery and selecting properties. On the Connection Filtering tab you will find the RBLs you currently query. If you are protected by ExchangeDefender, this list should be blank. If you use a mail server other than Exchange consult your vendor. I hope you have a wonderful day and thank you for letting us manage your SPAM so you don’t have to deal with the above every day Vlad Mazek |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ExchangeDefender SPAM Monitor
Shockey Server Agent
Thank you for your business.
