Announcement

**Joe Byrne** · 19 Oct 2007, 02:17 AM

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.

**Shawn Anderson** · 19 Oct 2007, 06:10 AM

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!

**Martin Draper** · 24 Oct 2007, 05:29 AM

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.

**Shawn Anderson** · 24 Oct 2007, 07:05 AM

it does according to:

Free Tools - Software Reviews, Opinions, and Tips - DNSstuff

http://www.dnsstuff.com/tools/ptr.ch?ip=mail.nbson.net

**Roger Rines** · 24 Oct 2007, 11:03 AM

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.

**Shawn Anderson** · 24 Oct 2007, 01:45 PM

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.

**Roger Rines** · 24 Oct 2007, 02:23 PM

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.

**Knuth Konrad** · 24 Oct 2007, 05:47 PM

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).

**Roger Rines** · 24 Oct 2007, 06:12 PM

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.

**Bud Durland** · 27 Oct 2007, 08:44 AM

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.

**Martin Draper** · 29 Oct 2007, 02:40 AM

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 <-------

**Shawn Anderson** · 29 Oct 2007, 07:00 AM

Thanks Martin,
are you tracert'ing to the correct IP?
It should be 12.163.40.4 but you have 12.162.40.4.

**Knuth Konrad** · 29 Oct 2007, 12:44 PM

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	mail[B][color=red]2[/color][/B].nbson.net	12.163.40.43	3600

Is there perhaps a missing entry for mail.nbson.net and that might be the problem?

**Shawn Anderson** · 2 Nov 2007, 08:22 PM

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!

**Michael Mattias** · 3 Nov 2007, 09:13 AM

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

**Roger Rines** · 3 Nov 2007, 10:21 AM

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.

**Knuth Konrad** · 3 Nov 2007, 12:13 PM

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...

**Shawn Anderson** · 6 Nov 2007, 04:55 AM

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.

Announcement

email problem

email problem

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment