Received-SPF: pass (Last token {include:_spf.customer.net} (res=PASS)) client-ip=64.235.154.223; envelope-from=<bob@serve.net>; x-ip-name=15pmail.ess.barracuda.com;
X-Received: from 15pmail.ess.barracuda.com (15pmail.ess.barracuda.com [64.235.154.223])
by netwin.co.nz (SurgeMail 7.3p) with ESMTP (TLS) id 7358321-1391920
for <surgemail-list@netwin.co.nz>; Wed, 16 Jan 2019 04:11:13 +0000
X-Return-Path: bob
X-Received: from ganymede.customer.net (ganymede.customer.net [136.179.32.230]) by mx1413.ess.rzc.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Jan 2019 04:11:08 +0000
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=192.168.10.11;
X-Received: from [192.168.10.11] (unverified [192.168.10.11])
by ganymede.customer.net (SurgeMail 7.2i) with ESMTP (TLS) id 6693174-1879441
for <surgemail-list@netwin.co.nz>; Tue, 15 Jan 2019 20:11:08 -0800
X-Return-Path: bob
Subject: Re: [SurgeMail List] G_SEND_MAX_PERDOM blocking outbound mail
To: surgemail-list@netwin.co.nz
References: <56d8da0f-496f-f539-e781-8ada64da1aa7@serve.net>
<f0ed3e41-7329-8e65-0ba7-148ebbdc1352@netwinsite.com>
From: Bob Fera
Message-ID: <c9b9b016-9b70-bb43-bb29-e27c272e43d7@serve.net>
Date: Tue, 15 Jan 2019 20:11:01 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <f0ed3e41-7329-8e65-0ba7-148ebbdc1352@netwinsite.com>
Content-Language: en-US
X-X-Authenticated-User: rmf@zis.com
X-BESS-ID: 1547611868-531715-18322-4940-1
X-BESS-VER: 2018.16-r1901160211
X-BESS-Apparent-Source-IP: 136.179.32.230
X-BESS-Outbound-Spam-Score: 0.00
X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.207774
Rule breakdown below
pts rule name description
---- ---------------------- --------------------------------
0.00 HTML_MESSAGE BODY: HTML included in
message
0.00 BSF_BESS_OUTBOUND META: BESS Outbound
X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS63616 scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND
X-BESS-BRTS-Status:1
X-Originating-IP: 64.235.154.223
X-Country: code=US country="UNITED STATES" ip=64.235.154.223
X-ORBS-Accept: hostkarma_white, hostkarma_quitok
X-Rcpt-To: <surgemail-list@netwin.co.nz>
X-SpamDetect: *: 1.8 sd=1.8 lv=0.00 nok=1/0 m=1 nf=0 Close 0.04(X-myrbl:Color=white) 0.90(X-Phrase:isspam) 0.27(StandardTLD) 0.29(X-Verify-Helo:+OK) 0.38(X-NotAscii:utf) 0.44(spfpass) 0.44(X-LangGuess:English) Saned 5.0 Sval 1.8 bsan 5.0 Moved 5.0->1.8 Sval 1.8
X-NotAscii: charset=utf-8
X-LangGuess: English
X-Probe: +OK nothing bad found
X-Phrase: IsSpam score=1.00
X-Verify-Helo: +OK 15pmail.ess.barracuda.com
X-Encryption: SSL encrypted
X-MyRbl: Color=White Age=510 Spam=1 Notspam=7 Stars=4 Good=4267 Friend=6229 Surbl=2 Catch=0 r=0.0019 ip=64.235.154.223
X-IP-stats: No info recorded yet ip=64.235.154.223
List-Unsubscribe: <mailto:surgemail-list-leave@netwin.co.nz?subject=unsubscribe>
X-Mailing-List: surgemail-list@netwin.co.nz
List-ID: <surgemail-list@netwin.co.nz>
Precedence: bulk
Reply-To: surgemail-list@netwin.co.nz
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Hi Chris,
It looks like my second email didn't ever make it through to the
list. You're correct, there was another (unrelated) issue that I
found after much hair pulling that was causing the message backlog.
So, a false alarm for sure. But I do appreciate the explanation
about what the setting does. It makes total sense and does what I
would naturally have expected.
Thanks!
Bob
Bob Fera
I.T. Manager
Zenith Information Group
18757 Burbank Blvd., Suite 116
Tarzana, CA 91356
Phone: 818-206-8634 Ext. 160
Fax: 818-345-2605
www.zis.com
Members of NACHA
The Electronic Payments Association
On 1/15/2019 5:26 PM, Surgemail Support
wrote:
That isn't strictly speaking an error, and shouldn't block
anything on the back end application. it's more of an
informational message within surgemail to say it's queueing a
message internally until it as less channels open to that
destination. You can safely increase it usually the limit of 2
is very conservative. Try 5.
But, like I say, it doesn't explain a backlog on the
application end? that error shouldn't be seen by a sending
server.
I would check for another error at the sending end, or in the
logs...
ChriSP
On 16/01/2019 12:11 PM, Bob Fera
wrote:
Hi all,
I'm suddenly having a terrible time with outbound messages
generated by a back end application being stopped by Surgemail
with "G_SEND_MAX_PERDOM exceeded 2>2 example.com" errors
being logged. (The back end application server uses Surgemail as
its smart host.) It's happening for multiple outbound domains,
and there is nothing unusual about today in terms of mail
volume. Surgemail's mail queue has only a few entries, with none
of them going to the domains I'm having trouble sending to. I've
even tried restarting Surgemail to no avail. Can't say I've ever
run into this before. I've had mail stuck on my back end
application server for hours...
Does anyone have any ideas? Am I missing something?
(I'm kind of behind on Surgemail updates, unfortunately --
SurgeMail Version 7.2i-1)
Thanks,
Bob
--
Bob Fera
I.T. Manager
Zenith Information Group
18757 Burbank Blvd., Suite 116
Tarzana, CA 91356
Phone: 818-206-8634 Ext. 160
Fax: 818-345-2605
www.zis.com
Members of NACHA
The Electronic Payments Association