topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday March 28, 2024, 6:44 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Last post Author Topic: Dealing with spam  (Read 22419 times)

Stoic Joker

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 6,646
    • View Profile
    • Donate to Member
Re: Dealing with spam
« Reply #25 on: January 07, 2008, 08:52 PM »
Imho if you set up your own SMTP server (unless you mean serious business), it should only be for incoming mails, not for sending outgoing - use your ISP or "something big & well-known" for sending.

Hm... Kinda. Once you decide to handle your own mail it's an all-or-none affair. Unless you like making a confusing mess out of the client side (workstations) mail setup by splitting it between servers. Best to keep the internal stuff nice and simple...Remember you may have to walk an end user through the setup on the phone... *Shudder* ...Besides securing a server against relaying is simple ... You just gota remember to do it!

If you're handling the incoming mail, then you're handling the incoming spam. Spam must be handled at the server, by the time it gets to the clients ... You Have Lost The War.

1. The server has waisted tons of cycle time and resources parsing all the excess crap. So with servers like Exchange that use a db for their mail stores the  now bloated transaction logs are only the tip of the IT iceberg. The bloated logs have to be replayed (/committed) into the Jet db which can add tons of time (and size) to the backups. Not to mention the loss of disk space caused by the ever swelling db size, that can only be recovered by running an offline defragmentation of the db using esutil....which requires even more free space to complete (Ever try juggling 3 copies of a 20+ Gig db across the wire while the client breaths down your neck because they want their mail server back online...now...?).

2. If you let the end user sort through their own junk mail...they will waste all day doing it. I keep our spam filter (GFi MailEssentials) set to where 99% of the spam is kept away from the user. The filters are broken into 2 categories: Those that never get false positives (DNS black lists, directory harvesting, etc.) are auto deleted, and those that typically get false positives (Baysien, header keyword checking, etc.) are set to a trap account and stored for 2 weeks. Any user who didn't get something they think they should have can simply ask me to look for mail from X & I'll go dig it out of the (sandboxed) trap account and forward it to them (usually only takes about Min).

3. If a group of end user are left to (their own devices...) sort through their own junk mail, the chance of them clicking on something (there is one in every crowd...) they shouldn't is approx. 182%


Problem is even with a static IP, unless you pay for what some ISP's in Denmark call a "global IP", you won't always have control of the IP's reverse-DNS... people & software get suspicious when my.serious.biz resolves to 1.3.3.7, but 1.3.3.7 reverse-dns is something like 0x12345678.slnxx7.adsl-dhcp.tele.dk instead of my.serious.biz.

Quite true/OK, I was a bit vague earlier...Here's the thing (I'm going to side-track a bit). Companies with an online presence like (need) to look like a professional operation. If your Company Email address (Like on a business card) is [email protected] ... You're going to look about half as professional as some guy selling crap out of a van in an alley :) - Now if your Email address is [email protected] ... you now appear to have some sense about you.

Sure you can have your web hosting company handle the mail for you but:

1. Their spam filters always err on the side of (panic) caution, and let tons of junk get through.

2. While they promise to backup your stuff ... they never really seem to get around to it.

3. If a government agency asks to see a history of your electronic correspondence, you better have it (see item 2).

4. Expecting an end user to remember to backup anything is just silly.

This is why I like MS Exchange servers. Centralized storage and backup of all mail for the entire company in one tidy package. (Actually to be fair, any IMAP server will do the same thing...I just happen to like Exchange)

Now to be able to pass the reverse DNS test for a server on a user7863.adsl.isp.com address one simply needs to setup their (the client's) mail server to relay through their (the client's) ISP supplied SmartHost which will validate the source (sending server/them) for the target server and allow the mail to be accepted/Reverse DNS test to pass because all the receiving server ever "sees" is the IPS's obviously valid mail server. Most ISP's (happily supply a SmartHost "GateWay") actually prefer that you do this so they can still keep an eye on your outbound "activities".

Note: This is a matter of setting up a secure OutBound Relay, which is perfectly safe. Inbound Open Relays are the ones you have to avoid like the plague.

I have setup fully redundant mail systems with split MX records load balanced between a commercial hosting company and an in-house mail server. this allows the users to always have access to their Email even if one or the other goes down. Considering that the company is totally dependent on their Email and several of the users travel allot, this configuration was mandatory to ensure the mail gets through ... it works flawlessly. Regardless of whether their in house or out of town, or whether either (or both) systems go off line, they still have complete access to their Email due to the amount of redundancy built into the system.
« Last Edit: January 07, 2008, 09:04 PM by Stoic Joker »