Announcement

Collapse
No announcement yet.

smart host issues

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • smart host issues

    We're on sbs 2003 R2 running exchange 2003

    This is a long story that I'll make relatively short by saying that we used to use cableone as a smart host to relay our emails through. They apparently switched over to using gmail and the relay no longer worked. CableOne support had me change the settings to the gmail servers and all that but every email from anyone in the company kept showing up from one email address so that was obviously not working. I was told by CableOne that that was just how gmail worked with relaying emails so I set out to find a new smart host this morning. In a rushed panic, I found socketlabs offers a service and set that all up and it seemed to be working fine. However, I am now seeing that quite a few emails are being rejected due to MTA poor reputation, etc. I am looking for advice on either a reputable smart host that I can use or any other possibilities. I know when I tried to send emails directly through the server (our exchange 2003 server), I had issues with a lot of them bouncing back. I don't remember exactly why but a lot of servers on the recipient side seemed to think we were spam because of the way the reverse DNS was set up (or not set up). Any advice?

  • #2
    Re: smart host issues

    I actually found out today that I can use our McAfee service as a smart host using their mxlogic spam servers. I have that all set up and all seems to be working well except certain domains are bouncing emails. It seems to be the exact problem I was trying to avoid by using a smart host. I'm getting the message: <[email protected]>: 550 5.1.1 <[email protected]>: Recipient address rejected: aol.com. Emails to most domains seem to go through just fine, it's just certain email addresses or domains. Any likely culprits? I followed the directions from McAfee for setting the correct settings on the exchange server. I thought it was strange that it did not require basic authentication even but the server address does start with our company name, ie: ourcompanyname.outbound10.mxlogic.net

    Comment


    • #3
      Re: smart host issues

      Why use a smarthost at all? Why make your outgoing email dependent on someone else's server and network? Exchange is completely capable of sending outgoing email on it's own (using DNS) and does so very capably. Your email is not any more likely to be flagged as spam coming directly from your server then it is coming from anyone else's.

      I guess I'm at a loss as to why so many organizations tie their systems to someone else's, such as using a smarthost for outgoing email or using forwarders for external DNS resolution.

      Comment


      • #4
        Re: smart host issues

        Can't speak for everyone Joe, but we tend to do it as many ISPs won't help any other way if you are having reputation issues with your external IP. Many of them don't even know what Reverse DNS is, never mind how to configure it. Also, they've changed now, but for many years it wasn't possible to get static IPs from Virgin Media in the UK, so using their smart host was the only option.

        Agree Re: Forwarders though, I always use root hints although Microsoft seem very keen to make everyone use forwarders.
        BSc, MCSA: Server 2008, MCSE, MCSA: Messaging, MCTS
        sigpic
        Cruachan's Blog

        Comment


        • #5
          Re: smart host issues

          I just know that, when I did try to have exchange send emails directly out, I had quite a few emails bouncing. I don't know if it is because I could never get my reverse DNS set correctly through my ISP or what. When I started using my ISP as a smart host we had zero issues so I was content with that. Now that my ISP no longer offers the service, I seem to be having the same exact issues - even though we're set up to run our email through McAfee's mxlogic servers. I just called our ISP to set our PTR to resolve from our IP address to our server's domain and they said it could take 72 hours to propogate. I'm hoping that is at least part of the issue as I've got a few people that are having trouble contacting certain customers/vendors because of it. Is there anything else I should check? I believe there is an A record pointing from our domain to our static IP address. I'll double check that though.

          Comment


          • #6
            Re: smart host issues

            Our PTR seems to be updated but we are still getting bounce-backs. How would a person know if their PTR was updated everywhere that it needed to be?

            Comment


            • #7
              Re: smart host issues

              You do a reverse lookup.


              http://mxtoolbox.com
              CCNA, CCNA-Security, CCNP
              CCIE Security (In Progress)

              Comment


              • #8
                Re: smart host issues

                Again, not to be harsh but:

                1. The existence of a PTR record doesn't guaranterr that your email will be accepted.

                2. The absence of a PTR record doesn't guaranteee that your email will blocked.

                3. Stop flailing around guessing as to what the problem is and look at what the evidence tells you. Does the bounce specifically state that the email was blocked due to a lack of a PTR record? If not, then you've been wasting your time.

                I see questions posted over and over again stating "I set up a PTR record but my email is still being blocked" or "I set up an SPF record but my email is still being blocked", without the questioner ever having confirmed what the actual reason is. They just flail around trying every bit of wrong headed advice they find on the internet.

                Here's my suggestion: Determine the exact reason that your email is being blocked and address that. Stop guessing as to what the problem is and stop trying to solve it without knowing what the true nature of the problem is.

                Again, forgive me. It may not seem like it but I'm trying to be helpful.

                A doctor never prescribes a cure before he/she diagnoses the illness.

                Comment


                • #9
                  Re: smart host issues

                  The bounce messages are non-specific. For example, we have one vendor where we get an NDR response of: <[email protected].net>: 554 Mail for [email protected].net rejected for policy reasons. Another one is: <[email protected].com>: 550 5.1.1 <example@aol.com>: Recipient address rejected: aol.com.

                  Since that doesn't tell me much, I've been trying to use Google as a resource. How would I go about determining the exact reason the emails are being bounced?

                  Comment


                  • #10
                    Re: smart host issues

                    Both of those give you a clue.

                    For the first one it's probably antispam sotware or an antispam appliance. You'll probably have to contact the postmaster at the recipient domain to get more detailed information.

                    For the second one it appears that the recipient email address isn't recognized at the recipeint domain or email to the recipient is being rejected for some other reason. This one is without a doubt a recipient side problem and as such, there isn't anything you can do about it. You can however, use a third party tool such as you'll find at www.dnsstuff.com to test the email address.

                    Again, I was not, and am not trying to be rude, harsh, or difficult. My point was that I see many people with email problems who fall into the trap of "Such and such and so and so said my PTR record, SPF record, hostname, etc., etc was the problem", without having supporting evidence, and they go off on a wild goose chase of trying everything until something "sticks. That approach is tedious and counterproductive. Glean what you can from the NDR and from your SMTP logs and go from there. In some cases the only thing you can do is to reach out to the postmaster at the recipient domain and hope that they respond to you.

                    At the end of the day, email (as defined in the relevant RFC's) is a "bet attempt" delivery service, and as such, delivery is not guaranteed. There also isn't any rule that says that your email has to be accepted, so if it isn't accepted, and you've done everything you can to adhere to best practice and good netizensip, then there isn't anything more you can do.

                    Comment

                    Working...
                    X