|
Dave, Yes, it was your post that I came across immediately when I started to try to set this up. Curiously enough, I had researched this before and came up with the following: http://forums.smartertools.com/ShowPost.aspx?PostID=4647 The support person there clearly misstated/misunderstood it's capabilities. I just didn't expect to run into this issue, and when I did, I still expected to find a way around it but after a whole day of trying, I just came up with other limitations that prevented the kludge. I thought I was there until I found that they only skip spam blocking when addresses match instead of using AUTH checking. I'm torn however. SmarterMail has the nicest interface that I have seen outside of Mdaemon, but comes at about a 1/3 of the price. A good interface is worth a ton when it comes to justifying value to my customers, and they won't care about not being able to lock down the server unless it directly affects them. The prospects of having a migration tool are also very attractive to me. I spent this evening looking at other platforms and I can't find anything that I would have any more confidence in except for Mdaemon. I really expected a bit more from the marketplace, but I was being unrealistic I guess. I was also taken back by their rush to close my ticket and refund my money without any attempt to resolve the issue or even offer when they might address it, or even if they would be addressing it. I purposefully tried to not be rude about how I presented things to them, and offered three things, the last of which was "If none of this is possible, would you please direct me as to how to go about getting a refund", and they went straight to that. The rush to refund also concerns me as far as how they treat their customers, but maybe I ticked someone off without intending to. Who knows. Your point about this being an RFC compliance issue isn't perfectly accurate. I believe that the RFC states that this is only a recommended implementation and not a requirement. Everyone knows however that it makes little sense to not require AUTH on 587 on a public server. I believe the RFC makes allowances for non-AUTH because not every situation would require it. I would think that changing this behavior on their server would be wise to do, but possibly not easy to do as they are probably only just listening on two ports instead of having separate capabilities bound to each port. The bottom line here is that SmarterMail needs some sort of mechanism to block non-authenticated E-mail that doesn't come from a gateway, and this is an oversight that one would think they would be very interested in correcting. I could do this in several was if I only got one of the components to make this work. With a JunkMail Standard license, and WHITELIST AUTH capability in SmarterMail, I could make this work in no time, but they have yet to introduce something that allows Declude to WHITELIST AUTH in SmarterMail. This has been discussed before around here, but it seems that the earliest that this would be available would be in Q4. I would hope that for the sake of Declude that SmarterMail would at least try to rush this one thing out. I'm going to call sales in the morning and see if they care about this stuff enough to want to try to convince me that they are aware of the shortcomings in this respect and whether or not they have plans to address them. I would settle for either WHITELIST AUTH w/Declude functionality, or the AUTH-only submission port. Matt Dave Beckstrom wrote: I filed a support ticket with smartertools about the port 587 problem:"[22B-0A663758-9813] No port 587 support = huge gaping flaw in smartermail" They said they "might" add the 587 SMTP Auth support but not any time in the near future. They just don't seem to "get" that if they aren't supporting an RFC requirement, which includes port 587, that they have seriously dropped the ball and the consequences impacts their sales. So I'm in the same boat except I bought smartermail. I'm now looking at other mail solutions.-----Original Message----- From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- [EMAIL PROTECTED]] On Behalf Of Robert E. Spivack Sent: Thursday, July 14, 2005 9:38 PM To: [email protected] Subject: RE: [Declude.JunkMail] SmarterMail shortcomings in a gateway environment Thank you for the detailed analysis - We have been considering SmarterMail as a migration path from IMail but will probably "go slow" until they grow up a bit more. How about open source? I seem to recall there are a few open source mail servers based on decent code (ASP.NET) that run on Windows servers. It's starting to look like no solution will be malleable unless as a last resort the code is available to do quick fixes like this that the vendor/providers just don't seem able to comprehend or have any interest in fixing. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Sent: Thursday, July 14, 2005 3:50 PM To: [email protected] Subject: [Declude.JunkMail] SmarterMail shortcomings in a gateway environment Why does this always happen to me... I was looking to leave my IMail/Declude setup as my gateway spam blocking component, and move hosted E-mail to a different server. All I needed in the hosted mail server was something that could be configured in such a way as to only accept SMTP AUTH E-mail or E-mail that only came from my own gateway. I figured that SmarterMail with port 587 support (the SMTP submission port) would do the trick. Well, it turns out that despite earlier claims, SmarterMail supports another SMTP port of your choosing, but it doesn't limit it to SMTP AUTH-only. This means that the spammers that have a habit of bypassing your MX records for indefinite periods of time will be able to still hit the SmarterMail server and bypass the scanning gateways. I found a post from two days ago that pointed out this major shortcoming, and despite an earlier thread on the topic, it turns out that this is a real limitation. I started searching for alternative methods around this, such as setting up a custom zone that blacklists the whole Internet except for the IP space of my scanning servers and using their internal spam blocking to delete anything that didn't come from my own space or was AUTHed. I ran into another problem here however...their blacklist capabilities don't allow for unique result codes, so anything that returns a result from a blacklist is treated as a positive hit. I had to actually create a CNAME record for a bogus domain to correspond to this space in order to work around that limitation and it worked. I then however figured out that they do not whitelist based on SMTP AUTH, but instead, they whitelist anything with a local address, and if a user doesn't have a local address in their headers but still AUTH's, it won't be whitelisted. So due to this shortsighted implementation on multiple fronts, there is no practical way to accomplish this and have it be reliable. I also came across another thread while researching things where some fellow Declude users were pointing out how their gateway configuration affected blacklists. We all know here that when gatewaying through a different server, you need something that is the equivalent of IPBYPASS for the gateway. They overlooked this, and after it was pointed out to them they suggested that they instead test all hops, which would have resulted in tagging many messages that are sent from clients on DUL IP space. I'm not sure that by the end of the thread that the concept stuck with them. It is a very pretty application, but it has a lot of settings within it and a few of them don't seem very well thought out. I E-mailed their tech support asking for ways around this or an indication of plans to support AUTH-only on the SMTP submission port and they ducked the questions saying that it wasn't possible to do at this time and directed my ticket to their sales staff so that I could get a refund. Unfortunately they seem to need to create a functional whitelisting mechanism for AUTHed users also for this to work instead of one based on the Mail From address. I'm a little put off by the short answers in response to such things, and the rubber stamped reply that it will be added to their suggestion database. Maybe I'm expecting too much... At this point, I'm looking for alternatives...including using IMail on the new server (I can do this with 8.20). I am also hopeful that maybe some of the others around here have run into this issue and possibly have some alternative suggestions. While I don't want to support IMail any longer and feel that they might again pull the rug out from under me, I can migrate things in a snap and I won't have to worry about taking a risk with SmarterMail. Matt -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ ===================================================== --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. -- ===================================================== MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ ===================================================== |
- Re: [Declude.JunkMail] SmarterMail shortcomings in a gateway... Matt
