Announcement

Collapse
No announcement yet.

email problem

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

  • email problem

    I'm not sure where to post this, but here goes:
    We generate and email about 500 invoices on the first of the month.
    We use an in-house accounting program and I use SocketTools to send the email from my application.
    It works except emails sent to gMail accounts using our Send Mail server get caught in the gMail spam filter. Here is a header:
    Code:
    Delivered-To: [email protected]
    Received: by 10.64.149.12 with SMTP id w12cs15372qbd;
            Thu, 18 Oct 2007 09:19:53 -0700 (PDT)
    Received: by 10.142.157.15 with SMTP id f15mr259397wfe.1192724392868;
            Thu, 18 Oct 2007 09:19:52 -0700 (PDT)
    Return-Path: <[email protected]>
    Received: from mail.nbson.net (mail.nbson.net [12.163.40.4])
            by mx.google.com with ESMTP id u6si1272547pyb.2007.10.18.09.19.52;
            Thu, 18 Oct 2007 09:19:52 -0700 (PDT)
    Received-SPF: pass (google.com: domain of [email protected] designates 12.163.40.4 as permitted sender) client-ip=12.163.40.4;
    Authentication-Results: mx.google.com; spf=pass (google.com: domain of [email protected] designates 12.163.40.4 as permitted sender) [email protected]
    Received: from ShawnAnderson.nbson.com (nbson.com [12.163.40.18])
    	by mail.nbson.net (8.13.1/8.13.1) with ESMTP id l9IGJpYP006992
    	for <[email protected]>; Thu, 18 Oct 2007 11:19:52 -0500
    Message-Id: <[email protected]>
    From: [email protected]
    To: [email protected]
    Date: Thu, 18 Oct 2007 11:19:54 -0500
    Subject: Invoice #7176
    MIME-Version: 1.0
    Content-Type: multipart/mixed; boundary="----=_ST5020_0001_054FB13C_0A9F6278"
    Content-Transfer-Encoding: 7bit
    
    This is a multi-part message in MIME format.
    
    ------=_ST5020_0001_054FB13C_0A9F6278
    Content-Type: multipart/alternative; boundary="----=_ST5020_0002_054FB13C_0A9F6278"
    Content-Transfer-Encoding: 7bit
    
    
    ------=_ST5020_0002_054FB13C_0A9F6278
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    In trying to figure this out, I tried sending the email out through the SpamArrest email server whom which I have an account. That is NOT caught buy the gMail server:

    Code:
    Delivered-To: [email protected]
    Received: by 10.64.149.12 with SMTP id w12cs36719qbd;
            Thu, 18 Oct 2007 15:23:28 -0700 (PDT)
    Received: by 10.141.51.15 with SMTP id d15mr631198rvk.1192746207599;
            Thu, 18 Oct 2007 15:23:27 -0700 (PDT)
    Return-Path: <[email protected]>
    Received: from eq2.spamarrest.com (eq2.spamarrest.com [66.150.163.135])
            by mx.google.com with ESMTP id l31si2621129rvb.2007.10.18.15.23.26;
            Thu, 18 Oct 2007 15:23:27 -0700 (PDT)
    Received-SPF: softfail (google.com: domain of transitioning [email protected] does not designate 66.150.163.135 as permitted sender) client-ip=66.150.163.135;
    Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning [email protected] does not designate 66.150.163.135 as permitted sender) [email protected]
    Received: from ShawnAnderson.nbson.com (nbson.com [12.163.40.18])
    	by eq2.spamarrest.com (Postfix) with ESMTP id 045A560C1E5
    	for <[email protected]>; Thu, 18 Oct 2007 15:23:25 -0700 (PDT)
    From: [email protected]
    To: [email protected]
    Date: Thu, 18 Oct 2007 17:23:28 -0500
    Subject: Invoice #7176
    MIME-Version: 1.0
    Content-Type: multipart/mixed; boundary="----=_ST5020_0001_069C8D07_0D391A0E"
    Content-Transfer-Encoding: 7bit
    Message-Id: <[email protected]>
    
    This is a multi-part message in MIME format.
    
    ------=_ST5020_0001_069C8D07_0D391A0E
    Content-Type: multipart/alternative; boundary="----=_ST5020_0002_069C8D17_0D391A2E"
    Content-Transfer-Encoding: 7bit
    
    
    ------=_ST5020_0002_069C8D17_0D391A2E
    Content-Type: text/plain; charset=us-ascii
    Content-Transfer-Encoding: 7bit
    I checked and our server is not blacklisted anywhere that I can find. The SpamArrest email even failed the SPF test where ours did not! Can anyone tell why it is failing on our mail server?

  • #2
    We generate and email about 500 invoices on the first of the month
    It might not be the specific message, but the amount you're sending within a short period of time. If you have a lot of gmail addresses and you start sending them right after each other, the gmail servers might flag this as a spam attack and greylist/blacklist you for a short period of time. You might want to either put some pauses in there, or separate out the domains while sending.

    I don't see anything specific in the headers that indicates why their getting blocked, so it may be something beyond the specific message.
    Software makes Hardware Happen

    Comment


    • #3
      I don't see anything different either, except for the specific differences (different mail server names, etc.)

      This happens when I only send one email. We ran into the problem last month and I'm trying to figure it out before the next billing cycle.

      Thanks!

      Comment


      • #4
        The problem is the 12.163.40.4 ip address it does not reverse out when you do a a reverse lookup as a mail server the 66.150.163.135 does. Gmail treats the first addresses as spammer. You will the same problem with most mail servers as it is the first way most now block spammers.

        Comment


        • #5
          it does according to:
          http://www.dnsstuff.com/tools/ptr.ch?ip=mail.nbson.net

          Comment


          • #6
            I think some of Martin's information is important in understanding how Grey List operate. To get through a Grey List process, the mail server must resend the message. Grey List filters consider the first occurrence of a message as a Spam message and wait for the mail server to resend the message.

            I discovered this recently and have a Socket Tools mail process that won't get through a mail system that is running a Grey List filter unless the user puts the sending address into its White List.
            Greylisting
            Greylisting temporarily delays incoming mail from unknown e-mail addresses by 30 minutes to an hour. All future e-mails from the same address will be delivered immediately. Since ISPs re-send delayed e-mail correctly but many spammers do not, all of your real e-mails will still arrive and a large amount of spam will be transparently blocked. Spam blocked by greylisting never makes it to your account, and will not show up in Held Mail.
            I need to solve this same problem along with an SSL problem with the same mail process so I'll be watching to see what creative approaches appear to get this resolved.
            Last edited by Roger Rines; 24 Oct 2007, 11:11 AM.
            Roger...

            Comment


            • #7
              When I send the email, it immediately appears (seconds) in the gMail account (as spam). Does that mean that grey listing isn't the issue?

              My work-around right now is to use SpamArrest as my authenticated SMTP server. Their tech support told me it wouldn't be an issue sending several hundred emails in a row, over the course of about an hour. I'm going to find out in about a week if it works, unless I can come up with something else.

              Comment


              • #8
                Originally posted by Shawn Anderson View Post
                When I send the email, it immediately appears (seconds) in the gMail account (as spam). Does that mean that grey listing isn't the issue?
                It isn't possible to know if they are using Grey Listing from your response, but it sounds like that could be the case, especially if this is a new problem, as Google is a strong believer in Spam filtering and recent changes made by Spamcop was to add Grey Listing.

                If you have access to Google's technical support people, ask them to look at the reason code of the email being diverted. In most cases the reason code will not only have the name of the process diverting the email, but in the case of Spam Assassin, there will also be an Assassin Score as well.

                Once you know why the message gets diverted you'll be in a better position to develop or ask for help in finding a solution.

                Here is a snippet of what I see in my SPAM Holding area:
                Check All Reset
                [141262] [email protected] (The tiny company walking in the footsteps of Microsoft Preview )
                Wed, 24 Oct 2007 12:48:29 -0400 (Blocked SpamAssassin=6)

                [141263] [email protected] (=?windows-1251?B?WzM2XTog0eTl6+Dp8uUg7+7k4PDu6iDx4u7o7CDk8PPn/P/sIOgg6u7r6+Xj4Owg?= =?windows-1251?B?ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg?= =?windows-1251?B?ICAgICAgICAgICBqcXF4Z3FjeXly?= Preview )
                Wed, 24 Oct 2007 19:44:16 +0300 (Blocked cbl.abuseat.org)
                In my case, the only way I know to get around a Grey Listing process is to resend the email, but with no email server experience as how that is accomplished without changing the email identity I'm left to a trial an error process that hasn't generated any positive results, yet.
                Roger...

                Comment


                • #9
                  Originally posted by Shawn Anderson View Post
                  When I send the email, it immediately appears (seconds) in the gMail account (as spam). Does that mean that grey listing isn't the issue?
                  I would say so. Because grey listing's purpose is to prevent spam from reaching your inbox (which includes your spam filter). The main reason for the invention is to throttle down the spam traffic's bandwidth.

                  Grey listing starts immediately after the SMTP session is invoked, meaning your mail server hasn't to consume all the bytes from the potential spam message in the first place. It therefore saves you both bandwidth at your network connection (because the connection gets terminated after a few bytes) and storage space on the mail server (because the mail doesn't reach your inbox).

                  Comment


                  • #10
                    Originally posted by Knuth Konrad View Post
                    Grey listing starts immediately after the SMTP session is invoked, meaning your mail server hasn't to consume all the bytes from the potential spam message in the first place. It therefore saves you both bandwidth at your network connection (because the connection gets terminated after a few bytes) and storage space on the mail server (because the mail doesn't reach your inbox).
                    This isn't how it is working on my mail server. In my case, the entire message is consumed and left in a Grey List holding pen where I can enter and release the entire message. If the message ages past 48-hours without being resent or released, it looses its content and the message is moved over to a Grey List Blocked list where I can still White List the sender, but the message contents are no longer available because they got removed with the transfer to the failed resend list.

                    Added Later:
                    It is possible that Knuth is correct about the message not being stored and the fact that I get the entire message pushed through after releasing the sender is the originating mail server sent the message again shortly after I released it making me think I had the entire message all the time.
                    Last edited by Roger Rines; 24 Oct 2007, 06:30 PM.
                    Roger...

                    Comment


                    • #11
                      Grey listing depends on the basic ability of SMTP to try very hard to deliver a message. The e-mail servers that I've seen that use it don't store the message the first time. The grey listing mechanism usually records sender info, then sends a "I'm real busy now, try back later" message. On subsequent attempts, the sender info matches, and the message is accepted.

                      Personally, I never, ever try to send directly to the destination SMTP server. More and more e-mail admins are very suspicious of an un-authenticated connection from outside their network that doesn't look like it's another server. I hand the message off to my server, and let it deal with re-transmissions, etc.
                      Real programmers use a magnetized needle and a steady hand

                      Comment


                      • #12
                        Grey listing while send a 4XX reply at the mail to command which you have to detect and then reschedule to email within a period 15 to 60 minutes which the normal mail server retry times. If you get a 5XX reply then you have been blocked.

                        The reverse lookup takes the ip address and tries to get the fqdn. The way to check it, is to tracert to the ip address.

                        From here when you tracert 12.163.40.4 the ip does not reverse to the fqdn
                        Tracing route to 12.162.40.4 over a maximum of 30 hops

                        1 <1 ms <1 ms <1 ms 192.168.1.254
                        2 16 ms 16 ms 10 ms dsl-lns1.qld.chariot.net.au [203.87.61.9]
                        3 19 ms 14 ms 19 ms bri-pow-ibo-zeu-1-ge-2-1.tpgi.com.au [203.213.7.
                        193]
                        4 28 ms 21 ms 18 ms bri-nxg-ibo-zeu-1-pos-2-0.tpgi.com.au [202.7.162
                        .198]
                        5 25 ms 35 ms 31 ms syd-nxg-ibo-ero-pos-7-2.tpgi.com.au [202.7.162.2
                        29]
                        6 183 ms 181 ms 177 ms 207.114.154.9
                        7 258 ms 229 ms 186 ms 66.192.251.27
                        8 207 ms 210 ms 240 ms 192.205.33.221
                        9 249 ms 257 ms 256 ms tbr1.la2ca.ip.att.net [12.123.222.18]
                        10 251 ms 247 ms 244 ms tbr1.sffca.ip.att.net [12.122.10.25]
                        11 247 ms 247 ms 250 ms tbr1.cgcil.ip.att.net [12.122.10.5]
                        12 266 ms 265 ms 255 ms gbr5.cgcil.ip.att.net [12.122.11.42]
                        13 249 ms 244 ms 243 ms ar1.chgil.ip.att.net [12.123.193.101]
                        14 250 ms 272 ms 254 ms 12.127.237.198
                        15 260 ms 261 ms 260 ms 12.162.40.4 <-------

                        Comment


                        • #13
                          Thanks Martin,
                          are you tracert'ing to the correct IP?
                          It should be 12.163.40.4 but you have 12.162.40.4.
                          Last edited by Shawn Anderson; 29 Oct 2007, 07:04 AM.

                          Comment


                          • #14
                            Hmm, looking up the MX record for nbson.net comes back with

                            Code:
                            ns.nbson.com reports the following MX records:
                            Preference	Host Name	IP Address	TTL	 	 
                            10	mail2.nbson.net	12.163.40.43	3600
                            Is there perhaps a missing entry for mail.nbson.net and that might be the problem?

                            Comment


                            • #15
                              mail2.nbson.com is our barracuda spam filter. It doesn't send any mail, it only recieves mail. We made the mx record entry anyway, but it didn't change anything. thanks though!

                              Comment


                              • #16
                                It might not be the specific message, but the amount you're sending within a short period of time....the gmail servers might flag this as a spam attack...
                                It's not just gmail. Both my mail servers have rules to prevent me from sending mail with too many recipients or with the same subject too many times in some period of time.

                                While I only ran into this once - while testing something - I did find it interesting that such rules are implemented for PAYING "hosting services" customers like me.

                                MCM
                                Michael Mattias
                                Tal Systems Inc. (retired)
                                Racine WI USA
                                [email protected]
                                http://www.talsystems.com

                                Comment


                                • #17
                                  Originally posted by Michael Mattias View Post
                                  It's not just gmail. Both my mail servers have rules to prevent me from sending mail with too many recipients or with the same subject too many times in some period of time.

                                  While I only ran into this once - while testing something - I did find it interesting that such rules are implemented for PAYING "hosting services" customers like me.
                                  When I purchased a commercial T1 connection from Megapath they would filter both in coming and outbound mail. There filtering was so primitive, dumb and restrictive that all kinds of messages in both direction would be lost without any notice or trail. This was a violation of their terms of service, but I had a long term contract and needed the bandwidth in those days. To get around the filtering I moved my mail service to a hosting company where they provided a mail server and mailing list.

                                  A neat feature with a mailing list is that it doesn't run up against the typical restrictive metrics many mail servers employ, and it makes sending mail to a large number of people a simple and reliable approach. It also didn't cost much at $6/mo. and that included 5-GIGs of web space.
                                  Roger...

                                  Comment


                                  • #18
                                    Originally posted by Shawn Anderson View Post
                                    mail2.nbson.com is our barracuda spam filter. It doesn't send any mail, it only recieves mail. We made the mx record entry anyway, but it didn't change anything. thanks though!
                                    But mail2 seems to be the only MX record present. That could explain the problems you experience, as mail can't be reverse resolved (making it an invalid mail server for some recepients).

                                    Perhaps mail isn't present in the MX record of all your name servers...

                                    Comment


                                    • #19
                                      Thanks Knuth, I'll show this to our admin.

                                      BTW, the spamArrest file server worked fine as the smtp server, it allowed me to send over 500 emails in a row no problem.

                                      Comment

                                      Working...
                                      X