Discussion:
SMTP issue
(too old to reply)
Eric Broch
2014-09-22 19:38:41 UTC
Permalink
Hello list,

I'm having and issue and am not sure of the source of the problem.

My client's QMT accepts email from all of their clients; however, there
is one client from which I know we are receiving a connection, per
Wireshark, but the mail is not being transferred. There is a record of
the connection in the SMTP server log, but again, there is no mail
transferred.

Does anyone have any ideas why the connection would be 'stopped' or
'dropped' or whatever?

Eric


---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Tonix - Antonio Nati
2014-09-22 19:43:42 UTC
Permalink
One event which is not logged is exceeded size of incoming message.

You see all initial logs, and then nothing more, like disappeared.

Regards,

Tonino



Il 22/09/2014 21:38, Eric Broch ha scritto:
> Hello list,
>
> I'm having and issue and am not sure of the source of the problem.
>
> My client's QMT accepts email from all of their clients; however, there
> is one client from which I know we are receiving a connection, per
> Wireshark, but the mail is not being transferred. There is a record of
> the connection in the SMTP server log, but again, there is no mail
> transferred.
>
> Does anyone have any ideas why the connection would be 'stopped' or
> 'dropped' or whatever?
>
> Eric
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>


--
------------------------------------------------------------
***@zioni Interazioni di Antonio Nati
http://www.interazioni.it ***@interazioni.it
------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Broch
2014-09-22 21:54:58 UTC
Permalink
Sorry,

Maybe I should elaborate.

This is from the SMTP log--a connect and then it ends. I've included
line numbers for references. It is a connection from a client
(xxx.xxx.xxx.xxx) to the QMT host.

1: @40000000542067963417ea24 tcpserver: status: 1/100
2: @40000000542067963417f5dc tcpserver: pid 3499 from xxx.xxx.xxx.xxx
3: @40000000542067963417f9c4 tcpserver: ok 3499
mail.mydomain.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::10418
4: @40000000542067d233f7d734 tcpserver: end 3499 status 0
5: @40000000542067d233f7e2ec tcpserver: status: 1/100

Usually, immediately after line 3 (above) the message transmission takes
place where there is the sending domain and the recipient; however,
there is no transmission, the connection simply closes, or ends. The
email being sent is not large, they are simply test messages I've ask
their IT staff to send to determine the reason for the problems we are
having.

Eric




On 9/22/2014 1:43 PM, Tonix - Antonio Nati wrote:
> One event which is not logged is exceeded size of incoming message.
>
> You see all initial logs, and then nothing more, like disappeared.
>
> Regards,
>
> Tonino
>
>
>
> Il 22/09/2014 21:38, Eric Broch ha scritto:
>> Hello list,
>>
>> I'm having and issue and am not sure of the source of the problem.
>>
>> My client's QMT accepts email from all of their clients; however, there
>> is one client from which I know we are receiving a connection, per
>> Wireshark, but the mail is not being transferred. There is a record of
>> the connection in the SMTP server log, but again, there is no mail
>> transferred.
>>
>> Does anyone have any ideas why the connection would be 'stopped' or
>> 'dropped' or whatever?
>>
>> Eric
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Shubert
2014-09-22 22:43:50 UTC
Permalink
Nice info, Tonino. I know that SPF failures used to do that too, but I
think we have a log message for that now.

Sounds to me like TLS may be failing. I'd turn on spamdyke's detailed
logging. It'll show you the details of what's going on.

--
-Eric 'shubes'

On 09/22/2014 02:54 PM, Eric Broch wrote:
> Sorry,
>
> Maybe I should elaborate.
>
> This is from the SMTP log--a connect and then it ends. I've included
> line numbers for references. It is a connection from a client
> (xxx.xxx.xxx.xxx) to the QMT host.
>
> 1: @40000000542067963417ea24 tcpserver: status: 1/100
> 2: @40000000542067963417f5dc tcpserver: pid 3499 from xxx.xxx.xxx.xxx
> 3: @40000000542067963417f9c4 tcpserver: ok 3499
> mail.mydomain.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::10418
> 4: @40000000542067d233f7d734 tcpserver: end 3499 status 0
> 5: @40000000542067d233f7e2ec tcpserver: status: 1/100
>
> Usually, immediately after line 3 (above) the message transmission takes
> place where there is the sending domain and the recipient; however,
> there is no transmission, the connection simply closes, or ends. The
> email being sent is not large, they are simply test messages I've ask
> their IT staff to send to determine the reason for the problems we are
> having.
>
> Eric
>
>
>
>
> On 9/22/2014 1:43 PM, Tonix - Antonio Nati wrote:
>> One event which is not logged is exceeded size of incoming message.
>>
>> You see all initial logs, and then nothing more, like disappeared.
>>
>> Regards,
>>
>> Tonino
>>
>>
>>
>> Il 22/09/2014 21:38, Eric Broch ha scritto:
>>> Hello list,
>>>
>>> I'm having and issue and am not sure of the source of the problem.
>>>
>>> My client's QMT accepts email from all of their clients; however, there
>>> is one client from which I know we are receiving a connection, per
>>> Wireshark, but the mail is not being transferred. There is a record of
>>> the connection in the SMTP server log, but again, there is no mail
>>> transferred.
>>>
>>> Does anyone have any ideas why the connection would be 'stopped' or
>>> 'dropped' or whatever?
>>>
>>> Eric
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Broch
2014-09-22 23:39:08 UTC
Permalink
On 9/22/2014 4:43 PM, Eric Shubert wrote:
> Nice info, Tonino. I know that SPF failures used to do that too, but I
> think we have a log message for that now.
>
> Sounds to me like TLS may be failing. I'd turn on spamdyke's detailed
> logging. It'll show you the details of what's going on.
>
Thanks! I'll increase spamdyke log-level.

---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Broch
2014-09-23 16:28:39 UTC
Permalink
On 9/22/2014 5:39 PM, Eric Broch wrote:
> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>> Nice info, Tonino. I know that SPF failures used to do that too, but I
>> think we have a log message for that now.
>>
>> Sounds to me like TLS may be failing. I'd turn on spamdyke's detailed
>> logging. It'll show you the details of what's going on.
>>
> Thanks! I'll increase spamdyke log-level.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>
Hello list,

I implemented the log-level setting in spamdyke to 'excessive' and the
log results are below:

@400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
@400000005421856d2ffa8244 tcpserver: ok 15364
mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
@400000005421856d3029c004 spamdyke[15364]:
DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
rdns: theirmail.theirdomain.com
@400000005421856d302a21ac spamdyke[15364]:
DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
whitelist file(s); rdns: theirmail.theirdomain.com
@400000005421856d302a9ac4 spamdyke[15364]:
DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
blacklist file(s); rdns: theirmail.theirdomain.com
@400000005421856d302b0c0c spamdyke[15364]:
DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
file(s); ip: xxx.xxx.xxx.xxx
@400000005421856d302bcb74 spamdyke[15364]:
DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
file(s); ip: xxx.xxx.xxx.xxx
@400000005421856d302c9e64 spamdyke[15364]:
DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
theirmail.theirdomain.com
@400000005421856d302d271c spamdyke[15364]:
DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
theirmail.theirdomain.com
@400000005421856d302d5214 spamdyke[15364]:
DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
theirmail.theirdomain.com
@400000005421856d33e291e4 spamdyke[15364]:
DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
delay: 1
@40000000542185a9306b495c tcpserver: end 15364 status 0

The connection seems to stop after the 'earlytalker' filter, but I'm not
sure this would be the cause. Any ideas?

Eric



---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Shubert
2014-09-24 00:49:32 UTC
Permalink
On 09/23/2014 09:28 AM, Eric Broch wrote:
> On 9/22/2014 5:39 PM, Eric Broch wrote:
>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>> Nice info, Tonino. I know that SPF failures used to do that too, but I
>>> think we have a log message for that now.
>>>
>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's detailed
>>> logging. It'll show you the details of what's going on.
>>>
>> Thanks! I'll increase spamdyke log-level.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>
> Hello list,
>
> I implemented the log-level setting in spamdyke to 'excessive' and the
> log results are below:
>
> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
> @400000005421856d2ffa8244 tcpserver: ok 15364
> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
> @400000005421856d3029c004 spamdyke[15364]:
> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
> rdns: theirmail.theirdomain.com
> @400000005421856d302a21ac spamdyke[15364]:
> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
> whitelist file(s); rdns: theirmail.theirdomain.com
> @400000005421856d302a9ac4 spamdyke[15364]:
> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
> blacklist file(s); rdns: theirmail.theirdomain.com
> @400000005421856d302b0c0c spamdyke[15364]:
> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
> file(s); ip: xxx.xxx.xxx.xxx
> @400000005421856d302bcb74 spamdyke[15364]:
> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
> file(s); ip: xxx.xxx.xxx.xxx
> @400000005421856d302c9e64 spamdyke[15364]:
> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
> theirmail.theirdomain.com
> @400000005421856d302d271c spamdyke[15364]:
> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
> theirmail.theirdomain.com
> @400000005421856d302d5214 spamdyke[15364]:
> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
> theirmail.theirdomain.com
> @400000005421856d33e291e4 spamdyke[15364]:
> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
> delay: 1
> @40000000542185a9306b495c tcpserver: end 15364 status 0
>
> The connection seems to stop after the 'earlytalker' filter, but I'm not
> sure this would be the cause. Any ideas?
>
> Eric
>
>
>
> ---------------------------------------------------------------------

I meant detail logging, where it logs each session to a separate file.
You'll see every part of the smtp dialog.


--
-Eric 'shubes'


---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Broch
2014-09-24 01:37:48 UTC
Permalink
On 9/23/2014 6:49 PM, Eric Shubert wrote:
> On 09/23/2014 09:28 AM, Eric Broch wrote:
>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>> Nice info, Tonino. I know that SPF failures used to do that too, but I
>>>> think we have a log message for that now.
>>>>
>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's detailed
>>>> logging. It'll show you the details of what's going on.
>>>>
>>> Thanks! I'll increase spamdyke log-level.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>> For additional commands, e-mail:
>>> qmailtoaster-list-***@qmailtoaster.com
>>>
>> Hello list,
>>
>> I implemented the log-level setting in spamdyke to 'excessive' and the
>> log results are below:
>>
>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>> @400000005421856d2ffa8244 tcpserver: ok 15364
>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>> @400000005421856d3029c004 spamdyke[15364]:
>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>> rdns: theirmail.theirdomain.com
>> @400000005421856d302a21ac spamdyke[15364]:
>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>> whitelist file(s); rdns: theirmail.theirdomain.com
>> @400000005421856d302a9ac4 spamdyke[15364]:
>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>> blacklist file(s); rdns: theirmail.theirdomain.com
>> @400000005421856d302b0c0c spamdyke[15364]:
>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>> file(s); ip: xxx.xxx.xxx.xxx
>> @400000005421856d302bcb74 spamdyke[15364]:
>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>> file(s); ip: xxx.xxx.xxx.xxx
>> @400000005421856d302c9e64 spamdyke[15364]:
>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>> theirmail.theirdomain.com
>> @400000005421856d302d271c spamdyke[15364]:
>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>> theirmail.theirdomain.com
>> @400000005421856d302d5214 spamdyke[15364]:
>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>> theirmail.theirdomain.com
>> @400000005421856d33e291e4 spamdyke[15364]:
>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>> delay: 1
>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>
>> The connection seems to stop after the 'earlytalker' filter, but I'm not
>> sure this would be the cause. Any ideas?
>>
>> Eric
>>
>>
>>
>> ---------------------------------------------------------------------
>
> I meant detail logging, where it logs each session to a separate file.
> You'll see every part of the smtp dialog.
>
>
Thanks again, EricS.

---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Tonix - Antonio Nati
2014-09-24 07:07:40 UTC
Permalink
Il 23/09/2014 18:28, Eric Broch ha scritto:
> On 9/22/2014 5:39 PM, Eric Broch wrote:
>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>> Nice info, Tonino. I know that SPF failures used to do that too, but I
>>> think we have a log message for that now.
>>>
>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's detailed
>>> logging. It'll show you the details of what's going on.
>>>
>> Thanks! I'll increase spamdyke log-level.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>
> Hello list,
>
> I implemented the log-level setting in spamdyke to 'excessive' and the
> log results are below:
>
> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
> @400000005421856d2ffa8244 tcpserver: ok 15364
> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
> @400000005421856d3029c004 spamdyke[15364]:
> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
> rdns: theirmail.theirdomain.com
> @400000005421856d302a21ac spamdyke[15364]:
> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
> whitelist file(s); rdns: theirmail.theirdomain.com
> @400000005421856d302a9ac4 spamdyke[15364]:
> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
> blacklist file(s); rdns: theirmail.theirdomain.com
> @400000005421856d302b0c0c spamdyke[15364]:
> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
> file(s); ip: xxx.xxx.xxx.xxx
> @400000005421856d302bcb74 spamdyke[15364]:
> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
> file(s); ip: xxx.xxx.xxx.xxx
> @400000005421856d302c9e64 spamdyke[15364]:
> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
> theirmail.theirdomain.com
> @400000005421856d302d271c spamdyke[15364]:
> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
> theirmail.theirdomain.com
> @400000005421856d302d5214 spamdyke[15364]:
> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
> theirmail.theirdomain.com
> @400000005421856d33e291e4 spamdyke[15364]:
> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
> delay: 1
> @40000000542185a9306b495c tcpserver: end 15364 status 0
>
> The connection seems to stop after the 'earlytalker' filter, but I'm not
> sure this would be the cause. Any ideas?
>
> Eric
>

Eric,

who is sending: a remote server, or a remote client?

Tonino


>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>


--
------------------------------------------------------------
***@zioni Interazioni di Antonio Nati
http://www.interazioni.it ***@interazioni.it
------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Broch
2014-09-24 13:01:45 UTC
Permalink
On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:
> Il 23/09/2014 18:28, Eric Broch ha scritto:
>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>> Nice info, Tonino. I know that SPF failures used to do that too, but I
>>>> think we have a log message for that now.
>>>>
>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's detailed
>>>> logging. It'll show you the details of what's going on.
>>>>
>>> Thanks! I'll increase spamdyke log-level.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>> For additional commands, e-mail:
>>> qmailtoaster-list-***@qmailtoaster.com
>>>
>> Hello list,
>>
>> I implemented the log-level setting in spamdyke to 'excessive' and the
>> log results are below:
>>
>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>> @400000005421856d2ffa8244 tcpserver: ok 15364
>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>> @400000005421856d3029c004 spamdyke[15364]:
>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>> rdns: theirmail.theirdomain.com
>> @400000005421856d302a21ac spamdyke[15364]:
>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>> whitelist file(s); rdns: theirmail.theirdomain.com
>> @400000005421856d302a9ac4 spamdyke[15364]:
>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>> blacklist file(s); rdns: theirmail.theirdomain.com
>> @400000005421856d302b0c0c spamdyke[15364]:
>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>> file(s); ip: xxx.xxx.xxx.xxx
>> @400000005421856d302bcb74 spamdyke[15364]:
>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>> file(s); ip: xxx.xxx.xxx.xxx
>> @400000005421856d302c9e64 spamdyke[15364]:
>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>> theirmail.theirdomain.com
>> @400000005421856d302d271c spamdyke[15364]:
>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>> theirmail.theirdomain.com
>> @400000005421856d302d5214 spamdyke[15364]:
>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>> theirmail.theirdomain.com
>> @400000005421856d33e291e4 spamdyke[15364]:
>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>> delay: 1
>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>
>> The connection seems to stop after the 'earlytalker' filter, but I'm not
>> sure this would be the cause. Any ideas?
>>
>> Eric
>>
>
> Eric,
>
> who is sending: a remote server, or a remote client?
>
> Tonino
>
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>
>
>
Hi Tonino,

I think I understand your question. The sender is an MS Exchange server.

And, I don't think I've stated this before, but we're having trouble
both sending and receiving email. When they send email from their
Exchange server it connects to our QMT host and disconnects right away
without delivering the mail only to be delivered some time later from
hours to up to a day and a half. And, this is true when we send email to
them from our QMT host to their Exchange server. It makes me believe
something is going on in-between the two hosts. One email sat in the QMT
queue for hours.

In testing, when I telnet to their Exchange server on port 25 there is a
very long delay--up to 75 seconds, which indicates to me that something
is wrong on their end or something is blocking the connection. Using
Wireshark to examine this test, our QMT host sends 5 SYN packets (when
there should only be one) and then is responded to with a SYN, ACK
packet by their Exchange server after the 5th; then our QMT host sends
an RST packet. During this delay if I open up another terminal and
telnet to their Exchange server on port 25, I receive their SMTP
greeting immediately. Upon subsequent telnet(s) on port 25 it always
connects. If I wait 5 minutes or more in between telnet(ing) on port 25
their is a long delay, again.

I hope all of this makes sense to you. It is quite disconcerting to be
able to send and receive email from or to anywhere except one host.
Their IT staff claims the same thing, that is, that our QMT host is the
only host they are having trouble with in send/receiving email.

I'm going to set up spamdyke as EricS has recommended and see what happens.

EricB






---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Shubert
2014-09-24 13:54:20 UTC
Permalink
On 09/24/2014 06:01 AM, Eric Broch wrote:
> On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:
>> Il 23/09/2014 18:28, Eric Broch ha scritto:
>>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>>> Nice info, Tonino. I know that SPF failures used to do that too, but I
>>>>> think we have a log message for that now.
>>>>>
>>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's detailed
>>>>> logging. It'll show you the details of what's going on.
>>>>>
>>>> Thanks! I'll increase spamdyke log-level.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>> For additional commands, e-mail:
>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>
>>> Hello list,
>>>
>>> I implemented the log-level setting in spamdyke to 'excessive' and the
>>> log results are below:
>>>
>>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>>> @400000005421856d2ffa8244 tcpserver: ok 15364
>>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>>> @400000005421856d3029c004 spamdyke[15364]:
>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>>> rdns: theirmail.theirdomain.com
>>> @400000005421856d302a21ac spamdyke[15364]:
>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>> whitelist file(s); rdns: theirmail.theirdomain.com
>>> @400000005421856d302a9ac4 spamdyke[15364]:
>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>> blacklist file(s); rdns: theirmail.theirdomain.com
>>> @400000005421856d302b0c0c spamdyke[15364]:
>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>> file(s); ip: xxx.xxx.xxx.xxx
>>> @400000005421856d302bcb74 spamdyke[15364]:
>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>> file(s); ip: xxx.xxx.xxx.xxx
>>> @400000005421856d302c9e64 spamdyke[15364]:
>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
>>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>>> theirmail.theirdomain.com
>>> @400000005421856d302d271c spamdyke[15364]:
>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
>>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>>> theirmail.theirdomain.com
>>> @400000005421856d302d5214 spamdyke[15364]:
>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>> theirmail.theirdomain.com
>>> @400000005421856d33e291e4 spamdyke[15364]:
>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>> delay: 1
>>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>>
>>> The connection seems to stop after the 'earlytalker' filter, but I'm not
>>> sure this would be the cause. Any ideas?
>>>
>>> Eric
>>>
>>
>> Eric,
>>
>> who is sending: a remote server, or a remote client?
>>
>> Tonino
>>
>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>
>>
>>
> Hi Tonino,
>
> I think I understand your question. The sender is an MS Exchange server.
>
> And, I don't think I've stated this before, but we're having trouble
> both sending and receiving email. When they send email from their
> Exchange server it connects to our QMT host and disconnects right away
> without delivering the mail only to be delivered some time later from
> hours to up to a day and a half. And, this is true when we send email to
> them from our QMT host to their Exchange server. It makes me believe
> something is going on in-between the two hosts. One email sat in the QMT
> queue for hours.
>
> In testing, when I telnet to their Exchange server on port 25 there is a
> very long delay--up to 75 seconds, which indicates to me that something
> is wrong on their end or something is blocking the connection. Using
> Wireshark to examine this test, our QMT host sends 5 SYN packets (when
> there should only be one) and then is responded to with a SYN, ACK
> packet by their Exchange server after the 5th; then our QMT host sends
> an RST packet. During this delay if I open up another terminal and
> telnet to their Exchange server on port 25, I receive their SMTP
> greeting immediately. Upon subsequent telnet(s) on port 25 it always
> connects. If I wait 5 minutes or more in between telnet(ing) on port 25
> their is a long delay, again.
>
> I hope all of this makes sense to you. It is quite disconcerting to be
> able to send and receive email from or to anywhere except one host.
> Their IT staff claims the same thing, that is, that our QMT host is the
> only host they are having trouble with in send/receiving email.
>
> I'm going to set up spamdyke as EricS has recommended and see what happens.
>
> EricB
>
> ---------------------------------------------------------------------

It sounds to me as though there's a proxy device of some sort sitting
between exchange and QMT. The behavior sounds a bit like graylisting.

Do you have graylisting implemented? I've quit using it, and I think
SamC (spamdyke author) has as well. The effectiveness of graylisting is
very difficult to measure in real terms. We believe that it's not very
effective these days, given other filters that are implemented. Plus
it's a real pain for users at time. I recommend you disable it. I doubt
you'll see any noticeable increase in spam after you do.

Thanks.

--
-Eric 'shubes'


---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Broch
2014-09-24 14:12:35 UTC
Permalink
On 9/24/2014 7:54 AM, Eric Shubert wrote:
> On 09/24/2014 06:01 AM, Eric Broch wrote:
>> On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:
>>> Il 23/09/2014 18:28, Eric Broch ha scritto:
>>>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>>>> Nice info, Tonino. I know that SPF failures used to do that too,
>>>>>> but I
>>>>>> think we have a log message for that now.
>>>>>>
>>>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's
>>>>>> detailed
>>>>>> logging. It'll show you the details of what's going on.
>>>>>>
>>>>> Thanks! I'll increase spamdyke log-level.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>> For additional commands, e-mail:
>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>
>>>> Hello list,
>>>>
>>>> I implemented the log-level setting in spamdyke to 'excessive' and the
>>>> log results are below:
>>>>
>>>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>>>> @400000005421856d2ffa8244 tcpserver: ok 15364
>>>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>>>> @400000005421856d3029c004 spamdyke[15364]:
>>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>>>> rdns: theirmail.theirdomain.com
>>>> @400000005421856d302a21ac spamdyke[15364]:
>>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>>> whitelist file(s); rdns: theirmail.theirdomain.com
>>>> @400000005421856d302a9ac4 spamdyke[15364]:
>>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>>> blacklist file(s); rdns: theirmail.theirdomain.com
>>>> @400000005421856d302b0c0c spamdyke[15364]:
>>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>> @400000005421856d302bcb74 spamdyke[15364]:
>>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>> @400000005421856d302c9e64 spamdyke[15364]:
>>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
>>>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>>>> theirmail.theirdomain.com
>>>> @400000005421856d302d271c spamdyke[15364]:
>>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
>>>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>>>> theirmail.theirdomain.com
>>>> @400000005421856d302d5214 spamdyke[15364]:
>>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>>> theirmail.theirdomain.com
>>>> @400000005421856d33e291e4 spamdyke[15364]:
>>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>>> delay: 1
>>>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>>>
>>>> The connection seems to stop after the 'earlytalker' filter, but
>>>> I'm not
>>>> sure this would be the cause. Any ideas?
>>>>
>>>> Eric
>>>>
>>>
>>> Eric,
>>>
>>> who is sending: a remote server, or a remote client?
>>>
>>> Tonino
>>>
>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>> For additional commands, e-mail:
>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>
>>>
>>>
>> Hi Tonino,
>>
>> I think I understand your question. The sender is an MS Exchange server.
>>
>> And, I don't think I've stated this before, but we're having trouble
>> both sending and receiving email. When they send email from their
>> Exchange server it connects to our QMT host and disconnects right away
>> without delivering the mail only to be delivered some time later from
>> hours to up to a day and a half. And, this is true when we send email to
>> them from our QMT host to their Exchange server. It makes me believe
>> something is going on in-between the two hosts. One email sat in the QMT
>> queue for hours.
>>
>> In testing, when I telnet to their Exchange server on port 25 there is a
>> very long delay--up to 75 seconds, which indicates to me that something
>> is wrong on their end or something is blocking the connection. Using
>> Wireshark to examine this test, our QMT host sends 5 SYN packets (when
>> there should only be one) and then is responded to with a SYN, ACK
>> packet by their Exchange server after the 5th; then our QMT host sends
>> an RST packet. During this delay if I open up another terminal and
>> telnet to their Exchange server on port 25, I receive their SMTP
>> greeting immediately. Upon subsequent telnet(s) on port 25 it always
>> connects. If I wait 5 minutes or more in between telnet(ing) on port 25
>> their is a long delay, again.
>>
>> I hope all of this makes sense to you. It is quite disconcerting to be
>> able to send and receive email from or to anywhere except one host.
>> Their IT staff claims the same thing, that is, that our QMT host is the
>> only host they are having trouble with in send/receiving email.
>>
>> I'm going to set up spamdyke as EricS has recommended and see what
>> happens.
>>
>> EricB
>>
>> ---------------------------------------------------------------------
>
> It sounds to me as though there's a proxy device of some sort sitting
> between exchange and QMT. The behavior sounds a bit like graylisting.
>
> Do you have graylisting implemented? I've quit using it, and I think
> SamC (spamdyke author) has as well. The effectiveness of graylisting
> is very difficult to measure in real terms. We believe that it's not
> very effective these days, given other filters that are implemented.
> Plus it's a real pain for users at time. I recommend you disable it. I
> doubt you'll see any noticeable increase in spam after you do.
>
> Thanks.
>
Hey EricS,

They have a Sonicwall AntiSpam unit, which we had at one time, and it
never acted like this. And, graylisting should only 'reject' delivery
once per user and all email from a user should deliver with no problem
after that, right. It seems this is different.

EricB

---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Tonix - Antonio Nati
2014-09-24 14:08:43 UTC
Permalink
Il 24/09/2014 15:01, Eric Broch ha scritto:
> On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:
>> Il 23/09/2014 18:28, Eric Broch ha scritto:
>>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>>> Nice info, Tonino. I know that SPF failures used to do that too, but I
>>>>> think we have a log message for that now.
>>>>>
>>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's detailed
>>>>> logging. It'll show you the details of what's going on.
>>>>>
>>>> Thanks! I'll increase spamdyke log-level.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>> For additional commands, e-mail:
>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>
>>> Hello list,
>>>
>>> I implemented the log-level setting in spamdyke to 'excessive' and the
>>> log results are below:
>>>
>>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>>> @400000005421856d2ffa8244 tcpserver: ok 15364
>>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>>> @400000005421856d3029c004 spamdyke[15364]:
>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>>> rdns: theirmail.theirdomain.com
>>> @400000005421856d302a21ac spamdyke[15364]:
>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>> whitelist file(s); rdns: theirmail.theirdomain.com
>>> @400000005421856d302a9ac4 spamdyke[15364]:
>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>> blacklist file(s); rdns: theirmail.theirdomain.com
>>> @400000005421856d302b0c0c spamdyke[15364]:
>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>> file(s); ip: xxx.xxx.xxx.xxx
>>> @400000005421856d302bcb74 spamdyke[15364]:
>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>> file(s); ip: xxx.xxx.xxx.xxx
>>> @400000005421856d302c9e64 spamdyke[15364]:
>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
>>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>>> theirmail.theirdomain.com
>>> @400000005421856d302d271c spamdyke[15364]:
>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
>>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>>> theirmail.theirdomain.com
>>> @400000005421856d302d5214 spamdyke[15364]:
>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>> theirmail.theirdomain.com
>>> @400000005421856d33e291e4 spamdyke[15364]:
>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>> delay: 1
>>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>>
>>> The connection seems to stop after the 'earlytalker' filter, but I'm not
>>> sure this would be the cause. Any ideas?
>>>
>>> Eric
>>>
>> Eric,
>>
>> who is sending: a remote server, or a remote client?
>>
>> Tonino
>>
>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>
>>
> Hi Tonino,
>
> I think I understand your question. The sender is an MS Exchange server.
>
> And, I don't think I've stated this before, but we're having trouble
> both sending and receiving email. When they send email from their
> Exchange server it connects to our QMT host and disconnects right away
> without delivering the mail only to be delivered some time later from
> hours to up to a day and a half. And, this is true when we send email to
> them from our QMT host to their Exchange server. It makes me believe
> something is going on in-between the two hosts. One email sat in the QMT
> queue for hours.
>
> In testing, when I telnet to their Exchange server on port 25 there is a
> very long delay--up to 75 seconds, which indicates to me that something
> is wrong on their end or something is blocking the connection. Using
> Wireshark to examine this test, our QMT host sends 5 SYN packets (when
> there should only be one) and then is responded to with a SYN, ACK
> packet by their Exchange server after the 5th; then our QMT host sends
> an RST packet. During this delay if I open up another terminal and
> telnet to their Exchange server on port 25, I receive their SMTP
> greeting immediately. Upon subsequent telnet(s) on port 25 it always
> connects. If I wait 5 minutes or more in between telnet(ing) on port 25
> their is a long delay, again.
>
> I hope all of this makes sense to you. It is quite disconcerting to be
> able to send and receive email from or to anywhere except one host.
> Their IT staff claims the same thing, that is, that our QMT host is the
> only host they are having trouble with in send/receiving email.
>
> I'm going to set up spamdyke as EricS has recommended and see what happens.

Just thinking loudly...

1) It looks like they could have DNS problems. If first connection is
slow, and second is quick, it looks like a dns query slow in first
attempo, but already in cache in the second... and then again slow on
third attempot after a few minutes because cache life is too short.
2) Check on exhange server
http://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
3) if they have firewall, check command EHLO is accepted.

Regards,

Tonino


>
> EricB
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>


--
------------------------------------------------------------
***@zioni Interazioni di Antonio Nati
http://www.interazioni.it ***@interazioni.it
------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Tonix - Antonio Nati
2014-09-24 14:18:14 UTC
Permalink
Il 24/09/2014 16:08, Tonix - Antonio Nati ha scritto:
> Il 24/09/2014 15:01, Eric Broch ha scritto:
>> On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:
>>> Il 23/09/2014 18:28, Eric Broch ha scritto:
>>>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>>>> Nice info, Tonino. I know that SPF failures used to do that too,
>>>>>> but I
>>>>>> think we have a log message for that now.
>>>>>>
>>>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's
>>>>>> detailed
>>>>>> logging. It'll show you the details of what's going on.
>>>>>>
>>>>> Thanks! I'll increase spamdyke log-level.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>> For additional commands, e-mail:
>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>
>>>> Hello list,
>>>>
>>>> I implemented the log-level setting in spamdyke to 'excessive' and the
>>>> log results are below:
>>>>
>>>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>>>> @400000005421856d2ffa8244 tcpserver: ok 15364
>>>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>>>> @400000005421856d3029c004 spamdyke[15364]:
>>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>>>> rdns: theirmail.theirdomain.com
>>>> @400000005421856d302a21ac spamdyke[15364]:
>>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>>> whitelist file(s); rdns: theirmail.theirdomain.com
>>>> @400000005421856d302a9ac4 spamdyke[15364]:
>>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>>> blacklist file(s); rdns: theirmail.theirdomain.com
>>>> @400000005421856d302b0c0c spamdyke[15364]:
>>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>> @400000005421856d302bcb74 spamdyke[15364]:
>>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>> @400000005421856d302c9e64 spamdyke[15364]:
>>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
>>>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>>>> theirmail.theirdomain.com
>>>> @400000005421856d302d271c spamdyke[15364]:
>>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
>>>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>>>> theirmail.theirdomain.com
>>>> @400000005421856d302d5214 spamdyke[15364]:
>>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>>> theirmail.theirdomain.com
>>>> @400000005421856d33e291e4 spamdyke[15364]:
>>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>>> delay: 1
>>>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>>>
>>>> The connection seems to stop after the 'earlytalker' filter, but
>>>> I'm not
>>>> sure this would be the cause. Any ideas?
>>>>
>>>> Eric
>>>>
>>> Eric,
>>>
>>> who is sending: a remote server, or a remote client?
>>>
>>> Tonino
>>>
>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>> For additional commands, e-mail:
>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>
>>>
>> Hi Tonino,
>>
>> I think I understand your question. The sender is an MS Exchange server.
>>
>> And, I don't think I've stated this before, but we're having trouble
>> both sending and receiving email. When they send email from their
>> Exchange server it connects to our QMT host and disconnects right away
>> without delivering the mail only to be delivered some time later from
>> hours to up to a day and a half. And, this is true when we send email to
>> them from our QMT host to their Exchange server. It makes me believe
>> something is going on in-between the two hosts. One email sat in the QMT
>> queue for hours.
>>
>> In testing, when I telnet to their Exchange server on port 25 there is a
>> very long delay--up to 75 seconds, which indicates to me that something
>> is wrong on their end or something is blocking the connection. Using
>> Wireshark to examine this test, our QMT host sends 5 SYN packets (when
>> there should only be one) and then is responded to with a SYN, ACK
>> packet by their Exchange server after the 5th; then our QMT host sends
>> an RST packet. During this delay if I open up another terminal and
>> telnet to their Exchange server on port 25, I receive their SMTP
>> greeting immediately. Upon subsequent telnet(s) on port 25 it always
>> connects. If I wait 5 minutes or more in between telnet(ing) on port 25
>> their is a long delay, again.
>>
>> I hope all of this makes sense to you. It is quite disconcerting to be
>> able to send and receive email from or to anywhere except one host.
>> Their IT staff claims the same thing, that is, that our QMT host is the
>> only host they are having trouble with in send/receiving email.
>>
>> I'm going to set up spamdyke as EricS has recommended and see what
>> happens.
>
> Just thinking loudly...

Just to avoid confusion, all problems here listed are referred to
exchange server side, not your side :-)

>
> 1) It looks like they could have DNS problems. If first connection is
> slow, and second is quick, it looks like a dns query slow in first
> attempo, but already in cache in the second... and then again slow on
> third attempot after a few minutes because cache life is too short.
> 2) Check on exhange server
> http://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
> 3) if they have firewall, check command EHLO is accepted.
>
> Regards,
>
> Tonino
>
>
>>
>> EricB
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>
>
>


--
------------------------------------------------------------
***@zioni Interazioni di Antonio Nati
http://www.interazioni.it ***@interazioni.it
------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Broch
2014-09-24 14:28:47 UTC
Permalink
On 9/24/2014 8:18 AM, Tonix - Antonio Nati wrote:
> Il 24/09/2014 16:08, Tonix - Antonio Nati ha scritto:
>> Il 24/09/2014 15:01, Eric Broch ha scritto:
>>> On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:
>>>> Il 23/09/2014 18:28, Eric Broch ha scritto:
>>>>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>>>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>>>>> Nice info, Tonino. I know that SPF failures used to do that too,
>>>>>>> but I
>>>>>>> think we have a log message for that now.
>>>>>>>
>>>>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's
>>>>>>> detailed
>>>>>>> logging. It'll show you the details of what's going on.
>>>>>>>
>>>>>> Thanks! I'll increase spamdyke log-level.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail:
>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>> For additional commands, e-mail:
>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>
>>>>> Hello list,
>>>>>
>>>>> I implemented the log-level setting in spamdyke to 'excessive' and
>>>>> the
>>>>> log results are below:
>>>>>
>>>>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>>>>> @400000005421856d2ffa8244 tcpserver: ok 15364
>>>>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>>>>> @400000005421856d3029c004 spamdyke[15364]:
>>>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>>>>> rdns: theirmail.theirdomain.com
>>>>> @400000005421856d302a21ac spamdyke[15364]:
>>>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>>>> whitelist file(s); rdns: theirmail.theirdomain.com
>>>>> @400000005421856d302a9ac4 spamdyke[15364]:
>>>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>>>> blacklist file(s); rdns: theirmail.theirdomain.com
>>>>> @400000005421856d302b0c0c spamdyke[15364]:
>>>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>> @400000005421856d302bcb74 spamdyke[15364]:
>>>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>> @400000005421856d302c9e64 spamdyke[15364]:
>>>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for
>>>>> IP in
>>>>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>> theirmail.theirdomain.com
>>>>> @400000005421856d302d271c spamdyke[15364]:
>>>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for
>>>>> IP in
>>>>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>> theirmail.theirdomain.com
>>>>> @400000005421856d302d5214 spamdyke[15364]:
>>>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>>>> theirmail.theirdomain.com
>>>>> @400000005421856d33e291e4 spamdyke[15364]:
>>>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>>>> delay: 1
>>>>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>>>>
>>>>> The connection seems to stop after the 'earlytalker' filter, but
>>>>> I'm not
>>>>> sure this would be the cause. Any ideas?
>>>>>
>>>>> Eric
>>>>>
>>>> Eric,
>>>>
>>>> who is sending: a remote server, or a remote client?
>>>>
>>>> Tonino
>>>>
>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>> For additional commands, e-mail:
>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>
>>>>
>>> Hi Tonino,
>>>
>>> I think I understand your question. The sender is an MS Exchange
>>> server.
>>>
>>> And, I don't think I've stated this before, but we're having trouble
>>> both sending and receiving email. When they send email from their
>>> Exchange server it connects to our QMT host and disconnects right away
>>> without delivering the mail only to be delivered some time later from
>>> hours to up to a day and a half. And, this is true when we send
>>> email to
>>> them from our QMT host to their Exchange server. It makes me believe
>>> something is going on in-between the two hosts. One email sat in the
>>> QMT
>>> queue for hours.
>>>
>>> In testing, when I telnet to their Exchange server on port 25 there
>>> is a
>>> very long delay--up to 75 seconds, which indicates to me that something
>>> is wrong on their end or something is blocking the connection. Using
>>> Wireshark to examine this test, our QMT host sends 5 SYN packets (when
>>> there should only be one) and then is responded to with a SYN, ACK
>>> packet by their Exchange server after the 5th; then our QMT host sends
>>> an RST packet. During this delay if I open up another terminal and
>>> telnet to their Exchange server on port 25, I receive their SMTP
>>> greeting immediately. Upon subsequent telnet(s) on port 25 it always
>>> connects. If I wait 5 minutes or more in between telnet(ing) on port 25
>>> their is a long delay, again.
>>>
>>> I hope all of this makes sense to you. It is quite disconcerting to be
>>> able to send and receive email from or to anywhere except one host.
>>> Their IT staff claims the same thing, that is, that our QMT host is the
>>> only host they are having trouble with in send/receiving email.
>>>
>>> I'm going to set up spamdyke as EricS has recommended and see what
>>> happens.
>>
>> Just thinking loudly...
>
> Just to avoid confusion, all problems here listed are referred to
> exchange server side, not your side :-)
>
>>
>> 1) It looks like they could have DNS problems. If first connection is
>> slow, and second is quick, it looks like a dns query slow in first
>> attempo, but already in cache in the second... and then again slow on
>> third attempot after a few minutes because cache life is too short.
>> 2) Check on exhange server
>> http://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
>>
>> 3) if they have firewall, check command EHLO is accepted.
>>
>> Regards,
>>
>> Tonino
>>
>>
>>>
>>> EricB
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>> For additional commands, e-mail:
>>> qmailtoaster-list-***@qmailtoaster.com
>>>
>>
>>
>
>
Thanks Tonino, I don't think it our side either.

---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Bharath Chari
2014-09-24 15:06:49 UTC
Permalink
On 09/24/2014 05:28 PM, Eric Broch wrote:
> On 9/24/2014 8:18 AM, Tonix - Antonio Nati wrote:
>> Il 24/09/2014 16:08, Tonix - Antonio Nati ha scritto:
>>> Il 24/09/2014 15:01, Eric Broch ha scritto:
>>>> On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:
>>>>> Il 23/09/2014 18:28, Eric Broch ha scritto:
>>>>>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>>>>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>>>>>> Nice info, Tonino. I know that SPF failures used to do that too,
>>>>>>>> but I
>>>>>>>> think we have a log message for that now.
>>>>>>>>
>>>>>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's
>>>>>>>> detailed
>>>>>>>> logging. It'll show you the details of what's going on.
>>>>>>>>
>>>>>>> Thanks! I'll increase spamdyke log-level.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail:
>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>> For additional commands, e-mail:
>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>
>>>>>> Hello list,
>>>>>>
>>>>>> I implemented the log-level setting in spamdyke to 'excessive' and
>>>>>> the
>>>>>> log results are below:
>>>>>>
>>>>>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>>>>>> @400000005421856d2ffa8244 tcpserver: ok 15364
>>>>>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>>>>>> @400000005421856d3029c004 spamdyke[15364]:
>>>>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>>>>>> rdns: theirmail.theirdomain.com
>>>>>> @400000005421856d302a21ac spamdyke[15364]:
>>>>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>>>>> whitelist file(s); rdns: theirmail.theirdomain.com
>>>>>> @400000005421856d302a9ac4 spamdyke[15364]:
>>>>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>>>>> blacklist file(s); rdns: theirmail.theirdomain.com
>>>>>> @400000005421856d302b0c0c spamdyke[15364]:
>>>>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>>> @400000005421856d302bcb74 spamdyke[15364]:
>>>>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>>> @400000005421856d302c9e64 spamdyke[15364]:
>>>>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for
>>>>>> IP in
>>>>>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>>> theirmail.theirdomain.com
>>>>>> @400000005421856d302d271c spamdyke[15364]:
>>>>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for
>>>>>> IP in
>>>>>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>>> theirmail.theirdomain.com
>>>>>> @400000005421856d302d5214 spamdyke[15364]:
>>>>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>>>>> theirmail.theirdomain.com
>>>>>> @400000005421856d33e291e4 spamdyke[15364]:
>>>>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>>>>> delay: 1
>>>>>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>>>>>
>>>>>> The connection seems to stop after the 'earlytalker' filter, but
>>>>>> I'm not
>>>>>> sure this would be the cause. Any ideas?
>>>>>>
>>>>>> Eric
>>>>>>
>>>>> Eric,
>>>>>
>>>>> who is sending: a remote server, or a remote client?
>>>>>
>>>>> Tonino
>>>>>
>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:
>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>> For additional commands, e-mail:
>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>
>>>> Hi Tonino,
>>>>
>>>> I think I understand your question. The sender is an MS Exchange
>>>> server.
>>>>
>>>> And, I don't think I've stated this before, but we're having trouble
>>>> both sending and receiving email. When they send email from their
>>>> Exchange server it connects to our QMT host and disconnects right away
>>>> without delivering the mail only to be delivered some time later from
>>>> hours to up to a day and a half. And, this is true when we send
>>>> email to
>>>> them from our QMT host to their Exchange server. It makes me believe
>>>> something is going on in-between the two hosts. One email sat in the
>>>> QMT
>>>> queue for hours.
>>>>
>>>> In testing, when I telnet to their Exchange server on port 25 there
>>>> is a
>>>> very long delay--up to 75 seconds, which indicates to me that something
>>>> is wrong on their end or something is blocking the connection. Using
>>>> Wireshark to examine this test, our QMT host sends 5 SYN packets (when
>>>> there should only be one) and then is responded to with a SYN, ACK
>>>> packet by their Exchange server after the 5th; then our QMT host sends
>>>> an RST packet. During this delay if I open up another terminal and
>>>> telnet to their Exchange server on port 25, I receive their SMTP
>>>> greeting immediately. Upon subsequent telnet(s) on port 25 it always
>>>> connects. If I wait 5 minutes or more in between telnet(ing) on port 25
>>>> their is a long delay, again.
>>>>
>>>> I hope all of this makes sense to you. It is quite disconcerting to be
>>>> able to send and receive email from or to anywhere except one host.
>>>> Their IT staff claims the same thing, that is, that our QMT host is the
>>>> only host they are having trouble with in send/receiving email.
>>>>
>>>> I'm going to set up spamdyke as EricS has recommended and see what
>>>> happens.
>>> Just thinking loudly...
>> Just to avoid confusion, all problems here listed are referred to
>> exchange server side, not your side :-)
>>
>>> 1) It looks like they could have DNS problems. If first connection is
>>> slow, and second is quick, it looks like a dns query slow in first
>>> attempo, but already in cache in the second... and then again slow on
>>> third attempot after a few minutes because cache life is too short.
>>> 2) Check on exhange server
>>> http://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
>>>
>>> 3) if they have firewall, check command EHLO is accepted.
>>>
>>> Regards,
>>>
>>> Tonino
>>>
>>>
>>>> EricB
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>> For additional commands, e-mail:
>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>
>>>
>>
> Thanks Tonino, I don't think it our side either.
>
Just shooting in the dark here, but can you check if they are behind a
Cisco PIX firewall? - that is known to cause issues with some MTAs. I
know Postfix has issues with it, and there's a specific work around.

Bharath

---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Broch
2014-09-24 14:27:17 UTC
Permalink
On 9/24/2014 8:08 AM, Tonix - Antonio Nati wrote:
> Il 24/09/2014 15:01, Eric Broch ha scritto:
>> On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:
>>> Il 23/09/2014 18:28, Eric Broch ha scritto:
>>>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>>>> Nice info, Tonino. I know that SPF failures used to do that too,
>>>>>> but I
>>>>>> think we have a log message for that now.
>>>>>>
>>>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's
>>>>>> detailed
>>>>>> logging. It'll show you the details of what's going on.
>>>>>>
>>>>> Thanks! I'll increase spamdyke log-level.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>> For additional commands, e-mail:
>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>
>>>> Hello list,
>>>>
>>>> I implemented the log-level setting in spamdyke to 'excessive' and the
>>>> log results are below:
>>>>
>>>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>>>> @400000005421856d2ffa8244 tcpserver: ok 15364
>>>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>>>> @400000005421856d3029c004 spamdyke[15364]:
>>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>>>> rdns: theirmail.theirdomain.com
>>>> @400000005421856d302a21ac spamdyke[15364]:
>>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>>> whitelist file(s); rdns: theirmail.theirdomain.com
>>>> @400000005421856d302a9ac4 spamdyke[15364]:
>>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>>> blacklist file(s); rdns: theirmail.theirdomain.com
>>>> @400000005421856d302b0c0c spamdyke[15364]:
>>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>> @400000005421856d302bcb74 spamdyke[15364]:
>>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>> @400000005421856d302c9e64 spamdyke[15364]:
>>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
>>>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>>>> theirmail.theirdomain.com
>>>> @400000005421856d302d271c spamdyke[15364]:
>>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
>>>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>>>> theirmail.theirdomain.com
>>>> @400000005421856d302d5214 spamdyke[15364]:
>>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>>> theirmail.theirdomain.com
>>>> @400000005421856d33e291e4 spamdyke[15364]:
>>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>>> delay: 1
>>>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>>>
>>>> The connection seems to stop after the 'earlytalker' filter, but
>>>> I'm not
>>>> sure this would be the cause. Any ideas?
>>>>
>>>> Eric
>>>>
>>> Eric,
>>>
>>> who is sending: a remote server, or a remote client?
>>>
>>> Tonino
>>>
>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>> For additional commands, e-mail:
>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>
>>>
>> Hi Tonino,
>>
>> I think I understand your question. The sender is an MS Exchange server.
>>
>> And, I don't think I've stated this before, but we're having trouble
>> both sending and receiving email. When they send email from their
>> Exchange server it connects to our QMT host and disconnects right away
>> without delivering the mail only to be delivered some time later from
>> hours to up to a day and a half. And, this is true when we send email to
>> them from our QMT host to their Exchange server. It makes me believe
>> something is going on in-between the two hosts. One email sat in the QMT
>> queue for hours.
>>
>> In testing, when I telnet to their Exchange server on port 25 there is a
>> very long delay--up to 75 seconds, which indicates to me that something
>> is wrong on their end or something is blocking the connection. Using
>> Wireshark to examine this test, our QMT host sends 5 SYN packets (when
>> there should only be one) and then is responded to with a SYN, ACK
>> packet by their Exchange server after the 5th; then our QMT host sends
>> an RST packet. During this delay if I open up another terminal and
>> telnet to their Exchange server on port 25, I receive their SMTP
>> greeting immediately. Upon subsequent telnet(s) on port 25 it always
>> connects. If I wait 5 minutes or more in between telnet(ing) on port 25
>> their is a long delay, again.
>>
>> I hope all of this makes sense to you. It is quite disconcerting to be
>> able to send and receive email from or to anywhere except one host.
>> Their IT staff claims the same thing, that is, that our QMT host is the
>> only host they are having trouble with in send/receiving email.
>>
>> I'm going to set up spamdyke as EricS has recommended and see what
>> happens.
>
> Just thinking loudly...
>
> 1) It looks like they could have DNS problems. If first connection is
> slow, and second is quick, it looks like a dns query slow in first
> attempo, but already in cache in the second... and then again slow on
> third attempot after a few minutes because cache life is too short.
> 2) Check on exhange server
> http://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
> 3) if they have firewall, check command EHLO is accepted.
>
> Regards,
>
> Tonino
>
>
>>
>> EricB
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>
>
Thanks Tonino,

I'll check this all out.

I did the advanced logging EricS recommended and it looks like this:

Begin:

09/24/2014 08:14:36 LOG OUTPUT
DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
rdns: mail.theirdom.com^M
DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
whitelist file(s); rdns: mail.theirdom.com^M
DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
blacklist file(s); rdns: mail.theirdom.com^M
DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
file(s); ip: yyy.yyy.yyy.yyy^M
DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
file(s); ip: yyy.yyy.yyy.yyy^M
DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
rDNS +keyword(s) in whitelist file; ip: yyy.yyy.yyy.yyy rdns:
mail.theirdom.com^M
DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
rDNS +keyword(s) in blacklist file; ip: yyy.yyy.yyy.yyy rdns:
mail.theirdom.com^M
DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
yyy.yyy.yyy.yyy^M
DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
delay: 2^M

09/24/2014 08:14:38 FROM CHILD TO REMOTE: 93 bytes
220 mail.ourdom.com - Welcome to OUR DOMAIN'S QMT SMTP Server ESMTP^M

09/24/2014 08:15:36 CLOSED

End:


I'm not sure who closed the connection.

Eric




---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Shubert
2014-09-24 15:35:30 UTC
Permalink
On 09/24/2014 07:27 AM, Eric Broch wrote:
> On 9/24/2014 8:08 AM, Tonix - Antonio Nati wrote:
>> Il 24/09/2014 15:01, Eric Broch ha scritto:
>>> On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:
>>>> Il 23/09/2014 18:28, Eric Broch ha scritto:
>>>>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>>>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>>>>> Nice info, Tonino. I know that SPF failures used to do that too,
>>>>>>> but I
>>>>>>> think we have a log message for that now.
>>>>>>>
>>>>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's
>>>>>>> detailed
>>>>>>> logging. It'll show you the details of what's going on.
>>>>>>>
>>>>>> Thanks! I'll increase spamdyke log-level.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:
>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>> For additional commands, e-mail:
>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>
>>>>> Hello list,
>>>>>
>>>>> I implemented the log-level setting in spamdyke to 'excessive' and the
>>>>> log results are below:
>>>>>
>>>>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>>>>> @400000005421856d2ffa8244 tcpserver: ok 15364
>>>>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>>>>> @400000005421856d3029c004 spamdyke[15364]:
>>>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>>>>> rdns: theirmail.theirdomain.com
>>>>> @400000005421856d302a21ac spamdyke[15364]:
>>>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>>>> whitelist file(s); rdns: theirmail.theirdomain.com
>>>>> @400000005421856d302a9ac4 spamdyke[15364]:
>>>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>>>> blacklist file(s); rdns: theirmail.theirdomain.com
>>>>> @400000005421856d302b0c0c spamdyke[15364]:
>>>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>> @400000005421856d302bcb74 spamdyke[15364]:
>>>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>> @400000005421856d302c9e64 spamdyke[15364]:
>>>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
>>>>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>> theirmail.theirdomain.com
>>>>> @400000005421856d302d271c spamdyke[15364]:
>>>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
>>>>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>> theirmail.theirdomain.com
>>>>> @400000005421856d302d5214 spamdyke[15364]:
>>>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>>>> theirmail.theirdomain.com
>>>>> @400000005421856d33e291e4 spamdyke[15364]:
>>>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>>>> delay: 1
>>>>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>>>>
>>>>> The connection seems to stop after the 'earlytalker' filter, but
>>>>> I'm not
>>>>> sure this would be the cause. Any ideas?
>>>>>
>>>>> Eric
>>>>>
>>>> Eric,
>>>>
>>>> who is sending: a remote server, or a remote client?
>>>>
>>>> Tonino
>>>>
>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>> For additional commands, e-mail:
>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>
>>>>
>>> Hi Tonino,
>>>
>>> I think I understand your question. The sender is an MS Exchange server.
>>>
>>> And, I don't think I've stated this before, but we're having trouble
>>> both sending and receiving email. When they send email from their
>>> Exchange server it connects to our QMT host and disconnects right away
>>> without delivering the mail only to be delivered some time later from
>>> hours to up to a day and a half. And, this is true when we send email to
>>> them from our QMT host to their Exchange server. It makes me believe
>>> something is going on in-between the two hosts. One email sat in the QMT
>>> queue for hours.
>>>
>>> In testing, when I telnet to their Exchange server on port 25 there is a
>>> very long delay--up to 75 seconds, which indicates to me that something
>>> is wrong on their end or something is blocking the connection. Using
>>> Wireshark to examine this test, our QMT host sends 5 SYN packets (when
>>> there should only be one) and then is responded to with a SYN, ACK
>>> packet by their Exchange server after the 5th; then our QMT host sends
>>> an RST packet. During this delay if I open up another terminal and
>>> telnet to their Exchange server on port 25, I receive their SMTP
>>> greeting immediately. Upon subsequent telnet(s) on port 25 it always
>>> connects. If I wait 5 minutes or more in between telnet(ing) on port 25
>>> their is a long delay, again.
>>>
>>> I hope all of this makes sense to you. It is quite disconcerting to be
>>> able to send and receive email from or to anywhere except one host.
>>> Their IT staff claims the same thing, that is, that our QMT host is the
>>> only host they are having trouble with in send/receiving email.
>>>
>>> I'm going to set up spamdyke as EricS has recommended and see what
>>> happens.
>>
>> Just thinking loudly...
>>
>> 1) It looks like they could have DNS problems. If first connection is
>> slow, and second is quick, it looks like a dns query slow in first
>> attempo, but already in cache in the second... and then again slow on
>> third attempot after a few minutes because cache life is too short.
>> 2) Check on exhange server
>> http://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
>> 3) if they have firewall, check command EHLO is accepted.
>>
>> Regards,
>>
>> Tonino
>>
>>
>>>
>>> EricB
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>
>>
> Thanks Tonino,
>
> I'll check this all out.
>
> I did the advanced logging EricS recommended and it looks like this:
>
> Begin:
>
> 09/24/2014 08:14:36 LOG OUTPUT
> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
> rdns: mail.theirdom.com^M
> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
> whitelist file(s); rdns: mail.theirdom.com^M
> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
> blacklist file(s); rdns: mail.theirdom.com^M
> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
> file(s); ip: yyy.yyy.yyy.yyy^M
> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
> file(s); ip: yyy.yyy.yyy.yyy^M
> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
> rDNS +keyword(s) in whitelist file; ip: yyy.yyy.yyy.yyy rdns:
> mail.theirdom.com^M
> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
> rDNS +keyword(s) in blacklist file; ip: yyy.yyy.yyy.yyy rdns:
> mail.theirdom.com^M
> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
> yyy.yyy.yyy.yyy^M
> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
> delay: 2^M
>
> 09/24/2014 08:14:38 FROM CHILD TO REMOTE: 93 bytes
> 220 mail.ourdom.com - Welcome to OUR DOMAIN'S QMT SMTP Server ESMTP^M
>
> 09/24/2014 08:15:36 CLOSED
>
> End:
>
>
> I'm not sure who closed the connection.
>
> Eric
>
>
> ---------------------------------------------------------------------

Hmmmm. Is it always exactly one minute from begin to end? That would
appear to indicate some timer cutting out. It could be spamdyke closing
the session depending on your idle-timeout-secs= value. I'm guessing 60,
which is probably ok. I've upped mine to 180, and I don't recall exactly
why I did that. Wouldn't hurt to bump it up I suppose.

Still, the other end should have replied to your 220 message before 58
seconds elapsed.

I wonder if there's a routing table misconfigured somewhere along the
way. I've seen instances where an errant routing table entry can cause
every nth packet to get dropped along the way. Are you seeing reliable
pings over a period of a minute or so? If not, I'd suspect a network issue.

At this point, I'd guess that QMT may be terminating a little soon, and
there's also a network problem somewhere along the way.

Again, just a guess.

P.S. Nice to see such accomplished people as Tonino and Bharath helping
out. Thanks guys!

--
-Eric 'shubes'


---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Broch
2014-09-25 14:50:18 UTC
Permalink
On 9/24/2014 9:35 AM, Eric Shubert wrote:
> On 09/24/2014 07:27 AM, Eric Broch wrote:
>> On 9/24/2014 8:08 AM, Tonix - Antonio Nati wrote:
>>> Il 24/09/2014 15:01, Eric Broch ha scritto:
>>>> On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:
>>>>> Il 23/09/2014 18:28, Eric Broch ha scritto:
>>>>>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>>>>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>>>>>> Nice info, Tonino. I know that SPF failures used to do that too,
>>>>>>>> but I
>>>>>>>> think we have a log message for that now.
>>>>>>>>
>>>>>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's
>>>>>>>> detailed
>>>>>>>> logging. It'll show you the details of what's going on.
>>>>>>>>
>>>>>>> Thanks! I'll increase spamdyke log-level.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail:
>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>> For additional commands, e-mail:
>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>
>>>>>> Hello list,
>>>>>>
>>>>>> I implemented the log-level setting in spamdyke to 'excessive'
>>>>>> and the
>>>>>> log results are below:
>>>>>>
>>>>>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>>>>>> @400000005421856d2ffa8244 tcpserver: ok 15364
>>>>>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>>>>>> @400000005421856d3029c004 spamdyke[15364]:
>>>>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing
>>>>>> rDNS;
>>>>>> rdns: theirmail.theirdomain.com
>>>>>> @400000005421856d302a21ac spamdyke[15364]:
>>>>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>>>>> whitelist file(s); rdns: theirmail.theirdomain.com
>>>>>> @400000005421856d302a9ac4 spamdyke[15364]:
>>>>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>>>>> blacklist file(s); rdns: theirmail.theirdomain.com
>>>>>> @400000005421856d302b0c0c spamdyke[15364]:
>>>>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>>> @400000005421856d302bcb74 spamdyke[15364]:
>>>>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>>> @400000005421856d302c9e64 spamdyke[15364]:
>>>>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for
>>>>>> IP in
>>>>>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>>> theirmail.theirdomain.com
>>>>>> @400000005421856d302d271c spamdyke[15364]:
>>>>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for
>>>>>> IP in
>>>>>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>>> theirmail.theirdomain.com
>>>>>> @400000005421856d302d5214 spamdyke[15364]:
>>>>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>>>>> theirmail.theirdomain.com
>>>>>> @400000005421856d33e291e4 spamdyke[15364]:
>>>>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>>>>> delay: 1
>>>>>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>>>>>
>>>>>> The connection seems to stop after the 'earlytalker' filter, but
>>>>>> I'm not
>>>>>> sure this would be the cause. Any ideas?
>>>>>>
>>>>>> Eric
>>>>>>
>>>>> Eric,
>>>>>
>>>>> who is sending: a remote server, or a remote client?
>>>>>
>>>>> Tonino
>>>>>
>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail:
>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>> For additional commands, e-mail:
>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>
>>>>>
>>>> Hi Tonino,
>>>>
>>>> I think I understand your question. The sender is an MS Exchange
>>>> server.
>>>>
>>>> And, I don't think I've stated this before, but we're having trouble
>>>> both sending and receiving email. When they send email from their
>>>> Exchange server it connects to our QMT host and disconnects right away
>>>> without delivering the mail only to be delivered some time later from
>>>> hours to up to a day and a half. And, this is true when we send
>>>> email to
>>>> them from our QMT host to their Exchange server. It makes me believe
>>>> something is going on in-between the two hosts. One email sat in
>>>> the QMT
>>>> queue for hours.
>>>>
>>>> In testing, when I telnet to their Exchange server on port 25 there
>>>> is a
>>>> very long delay--up to 75 seconds, which indicates to me that
>>>> something
>>>> is wrong on their end or something is blocking the connection. Using
>>>> Wireshark to examine this test, our QMT host sends 5 SYN packets (when
>>>> there should only be one) and then is responded to with a SYN, ACK
>>>> packet by their Exchange server after the 5th; then our QMT host sends
>>>> an RST packet. During this delay if I open up another terminal and
>>>> telnet to their Exchange server on port 25, I receive their SMTP
>>>> greeting immediately. Upon subsequent telnet(s) on port 25 it always
>>>> connects. If I wait 5 minutes or more in between telnet(ing) on
>>>> port 25
>>>> their is a long delay, again.
>>>>
>>>> I hope all of this makes sense to you. It is quite disconcerting to be
>>>> able to send and receive email from or to anywhere except one host.
>>>> Their IT staff claims the same thing, that is, that our QMT host is
>>>> the
>>>> only host they are having trouble with in send/receiving email.
>>>>
>>>> I'm going to set up spamdyke as EricS has recommended and see what
>>>> happens.
>>>
>>> Just thinking loudly...
>>>
>>> 1) It looks like they could have DNS problems. If first connection is
>>> slow, and second is quick, it looks like a dns query slow in first
>>> attempo, but already in cache in the second... and then again slow on
>>> third attempot after a few minutes because cache life is too short.
>>> 2) Check on exhange server
>>> http://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
>>>
>>> 3) if they have firewall, check command EHLO is accepted.
>>>
>>> Regards,
>>>
>>> Tonino
>>>
>>>
>>>>
>>>> EricB
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>> For additional commands, e-mail:
>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>
>>>
>> Thanks Tonino,
>>
>> I'll check this all out.
>>
>> I did the advanced logging EricS recommended and it looks like this:
>>
>> Begin:
>>
>> 09/24/2014 08:14:36 LOG OUTPUT
>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>> rdns: mail.theirdom.com^M
>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>> whitelist file(s); rdns: mail.theirdom.com^M
>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>> blacklist file(s); rdns: mail.theirdom.com^M
>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>> file(s); ip: yyy.yyy.yyy.yyy^M
>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>> file(s); ip: yyy.yyy.yyy.yyy^M
>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
>> rDNS +keyword(s) in whitelist file; ip: yyy.yyy.yyy.yyy rdns:
>> mail.theirdom.com^M
>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
>> rDNS +keyword(s) in blacklist file; ip: yyy.yyy.yyy.yyy rdns:
>> mail.theirdom.com^M
>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>> yyy.yyy.yyy.yyy^M
>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>> delay: 2^M
>>
>> 09/24/2014 08:14:38 FROM CHILD TO REMOTE: 93 bytes
>> 220 mail.ourdom.com - Welcome to OUR DOMAIN'S QMT SMTP Server ESMTP^M
>>
>> 09/24/2014 08:15:36 CLOSED
>>
>> End:
>>
>>
>> I'm not sure who closed the connection.
>>
>> Eric
>>
>>
>> ---------------------------------------------------------------------
>
> Hmmmm. Is it always exactly one minute from begin to end? That would
> appear to indicate some timer cutting out. It could be spamdyke
> closing the session depending on your idle-timeout-secs= value. I'm
> guessing 60, which is probably ok. I've upped mine to 180, and I don't
> recall exactly why I did that. Wouldn't hurt to bump it up I suppose.
>
> Still, the other end should have replied to your 220 message before 58
> seconds elapsed.
>
> I wonder if there's a routing table misconfigured somewhere along the
> way. I've seen instances where an errant routing table entry can cause
> every nth packet to get dropped along the way. Are you seeing reliable
> pings over a period of a minute or so? If not, I'd suspect a network
> issue.
>
> At this point, I'd guess that QMT may be terminating a little soon,
> and there's also a network problem somewhere along the way.
>
> Again, just a guess.
>
> P.S. Nice to see such accomplished people as Tonino and Bharath
> helping out. Thanks guys!
>
No, it is not always one minute, sometimes it is up to thirty seconds
longer. I don't think spamdyke is closing the session as my
idle-timeout-secs is set to 480, and I don't recall either why I set
mine so high. While telnet(ing) to their host on port 25 initially and
it is 'trying' to connect, I can open another terminal and run the same
telnet command and I'll get their greeting right away.

I agree, their host should have replied faster than 58 seconds after the
SMTP greeting, unless the greeting is never getting to there host. There
host does not have ICMP protocol turned on. I could ask them to do so.

If I have spamdyke set to terminate after 480 seconds what else would be
terminating the connection?

And, ditto. Thanks for the help Tonino and Bharath!!!




---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Shubert
2014-09-25 15:19:29 UTC
Permalink
On 09/25/2014 07:50 AM, Eric Broch wrote:
> On 9/24/2014 9:35 AM, Eric Shubert wrote:
>> On 09/24/2014 07:27 AM, Eric Broch wrote:
>>> On 9/24/2014 8:08 AM, Tonix - Antonio Nati wrote:
>>>> Il 24/09/2014 15:01, Eric Broch ha scritto:
>>>>> On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:
>>>>>> Il 23/09/2014 18:28, Eric Broch ha scritto:
>>>>>>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>>>>>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>>>>>>> Nice info, Tonino. I know that SPF failures used to do that too,
>>>>>>>>> but I
>>>>>>>>> think we have a log message for that now.
>>>>>>>>>
>>>>>>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's
>>>>>>>>> detailed
>>>>>>>>> logging. It'll show you the details of what's going on.
>>>>>>>>>
>>>>>>>> Thanks! I'll increase spamdyke log-level.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail:
>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>> For additional commands, e-mail:
>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>
>>>>>>> Hello list,
>>>>>>>
>>>>>>> I implemented the log-level setting in spamdyke to 'excessive'
>>>>>>> and the
>>>>>>> log results are below:
>>>>>>>
>>>>>>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>>>>>>> @400000005421856d2ffa8244 tcpserver: ok 15364
>>>>>>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>>>>>>> @400000005421856d3029c004 spamdyke[15364]:
>>>>>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing
>>>>>>> rDNS;
>>>>>>> rdns: theirmail.theirdomain.com
>>>>>>> @400000005421856d302a21ac spamdyke[15364]:
>>>>>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>>>>>> whitelist file(s); rdns: theirmail.theirdomain.com
>>>>>>> @400000005421856d302a9ac4 spamdyke[15364]:
>>>>>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>>>>>> blacklist file(s); rdns: theirmail.theirdomain.com
>>>>>>> @400000005421856d302b0c0c spamdyke[15364]:
>>>>>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>>>> @400000005421856d302bcb74 spamdyke[15364]:
>>>>>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>>>> @400000005421856d302c9e64 spamdyke[15364]:
>>>>>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for
>>>>>>> IP in
>>>>>>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>>>> theirmail.theirdomain.com
>>>>>>> @400000005421856d302d271c spamdyke[15364]:
>>>>>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for
>>>>>>> IP in
>>>>>>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>>>> theirmail.theirdomain.com
>>>>>>> @400000005421856d302d5214 spamdyke[15364]:
>>>>>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>>>>>> theirmail.theirdomain.com
>>>>>>> @400000005421856d33e291e4 spamdyke[15364]:
>>>>>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>>>>>> delay: 1
>>>>>>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>>>>>>
>>>>>>> The connection seems to stop after the 'earlytalker' filter, but
>>>>>>> I'm not
>>>>>>> sure this would be the cause. Any ideas?
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>> Eric,
>>>>>>
>>>>>> who is sending: a remote server, or a remote client?
>>>>>>
>>>>>> Tonino
>>>>>>
>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail:
>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>> For additional commands, e-mail:
>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>
>>>>>>
>>>>> Hi Tonino,
>>>>>
>>>>> I think I understand your question. The sender is an MS Exchange
>>>>> server.
>>>>>
>>>>> And, I don't think I've stated this before, but we're having trouble
>>>>> both sending and receiving email. When they send email from their
>>>>> Exchange server it connects to our QMT host and disconnects right away
>>>>> without delivering the mail only to be delivered some time later from
>>>>> hours to up to a day and a half. And, this is true when we send
>>>>> email to
>>>>> them from our QMT host to their Exchange server. It makes me believe
>>>>> something is going on in-between the two hosts. One email sat in
>>>>> the QMT
>>>>> queue for hours.
>>>>>
>>>>> In testing, when I telnet to their Exchange server on port 25 there
>>>>> is a
>>>>> very long delay--up to 75 seconds, which indicates to me that
>>>>> something
>>>>> is wrong on their end or something is blocking the connection. Using
>>>>> Wireshark to examine this test, our QMT host sends 5 SYN packets (when
>>>>> there should only be one) and then is responded to with a SYN, ACK
>>>>> packet by their Exchange server after the 5th; then our QMT host sends
>>>>> an RST packet. During this delay if I open up another terminal and
>>>>> telnet to their Exchange server on port 25, I receive their SMTP
>>>>> greeting immediately. Upon subsequent telnet(s) on port 25 it always
>>>>> connects. If I wait 5 minutes or more in between telnet(ing) on
>>>>> port 25
>>>>> their is a long delay, again.
>>>>>
>>>>> I hope all of this makes sense to you. It is quite disconcerting to be
>>>>> able to send and receive email from or to anywhere except one host.
>>>>> Their IT staff claims the same thing, that is, that our QMT host is
>>>>> the
>>>>> only host they are having trouble with in send/receiving email.
>>>>>
>>>>> I'm going to set up spamdyke as EricS has recommended and see what
>>>>> happens.
>>>>
>>>> Just thinking loudly...
>>>>
>>>> 1) It looks like they could have DNS problems. If first connection is
>>>> slow, and second is quick, it looks like a dns query slow in first
>>>> attempo, but already in cache in the second... and then again slow on
>>>> third attempot after a few minutes because cache life is too short.
>>>> 2) Check on exhange server
>>>> http://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
>>>>
>>>> 3) if they have firewall, check command EHLO is accepted.
>>>>
>>>> Regards,
>>>>
>>>> Tonino
>>>>
>>>>
>>>>>
>>>>> EricB
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>> For additional commands, e-mail:
>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>
>>>>
>>> Thanks Tonino,
>>>
>>> I'll check this all out.
>>>
>>> I did the advanced logging EricS recommended and it looks like this:
>>>
>>> Begin:
>>>
>>> 09/24/2014 08:14:36 LOG OUTPUT
>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>>> rdns: mail.theirdom.com^M
>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>> whitelist file(s); rdns: mail.theirdom.com^M
>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>> blacklist file(s); rdns: mail.theirdom.com^M
>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>> file(s); ip: yyy.yyy.yyy.yyy^M
>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>> file(s); ip: yyy.yyy.yyy.yyy^M
>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
>>> rDNS +keyword(s) in whitelist file; ip: yyy.yyy.yyy.yyy rdns:
>>> mail.theirdom.com^M
>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
>>> rDNS +keyword(s) in blacklist file; ip: yyy.yyy.yyy.yyy rdns:
>>> mail.theirdom.com^M
>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>> yyy.yyy.yyy.yyy^M
>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>> delay: 2^M
>>>
>>> 09/24/2014 08:14:38 FROM CHILD TO REMOTE: 93 bytes
>>> 220 mail.ourdom.com - Welcome to OUR DOMAIN'S QMT SMTP Server ESMTP^M
>>>
>>> 09/24/2014 08:15:36 CLOSED
>>>
>>> End:
>>>
>>>
>>> I'm not sure who closed the connection.
>>>
>>> Eric
>>>
>>>
>>> ---------------------------------------------------------------------
>>
>> Hmmmm. Is it always exactly one minute from begin to end? That would
>> appear to indicate some timer cutting out. It could be spamdyke
>> closing the session depending on your idle-timeout-secs= value. I'm
>> guessing 60, which is probably ok. I've upped mine to 180, and I don't
>> recall exactly why I did that. Wouldn't hurt to bump it up I suppose.
>>
>> Still, the other end should have replied to your 220 message before 58
>> seconds elapsed.
>>
>> I wonder if there's a routing table misconfigured somewhere along the
>> way. I've seen instances where an errant routing table entry can cause
>> every nth packet to get dropped along the way. Are you seeing reliable
>> pings over a period of a minute or so? If not, I'd suspect a network
>> issue.
>>
>> At this point, I'd guess that QMT may be terminating a little soon,
>> and there's also a network problem somewhere along the way.
>>
>> Again, just a guess.
>>
>> P.S. Nice to see such accomplished people as Tonino and Bharath
>> helping out. Thanks guys!
>>
> No, it is not always one minute, sometimes it is up to thirty seconds
> longer. I don't think spamdyke is closing the session as my
> idle-timeout-secs is set to 480, and I don't recall either why I set
> mine so high. While telnet(ing) to their host on port 25 initially and
> it is 'trying' to connect, I can open another terminal and run the same
> telnet command and I'll get their greeting right away.
>
> I agree, their host should have replied faster than 58 seconds after the
> SMTP greeting, unless the greeting is never getting to there host. There
> host does not have ICMP protocol turned on. I could ask them to do so.
>
> If I have spamdyke set to terminate after 480 seconds what else would be
> terminating the connection?
>
> And, ditto. Thanks for the help Tonino and Bharath!!!
>
>
> ---------------------------------------------------------------------

I would bet on a network problem at this point, such as packets being
dropped due to a bad routing table somewhere. Might need to get UDP
going to diagnose that.


--
-Eric 'shubes'


---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Tonix - Antonio Nati
2014-09-25 15:23:11 UTC
Permalink
Il 25/09/2014 16:50, Eric Broch ha scritto:
> On 9/24/2014 9:35 AM, Eric Shubert wrote:
>> On 09/24/2014 07:27 AM, Eric Broch wrote:
>>> On 9/24/2014 8:08 AM, Tonix - Antonio Nati wrote:
>>>> Il 24/09/2014 15:01, Eric Broch ha scritto:
>>>>> On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:
>>>>>> Il 23/09/2014 18:28, Eric Broch ha scritto:
>>>>>>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>>>>>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>>>>>>> Nice info, Tonino. I know that SPF failures used to do that too,
>>>>>>>>> but I
>>>>>>>>> think we have a log message for that now.
>>>>>>>>>
>>>>>>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's
>>>>>>>>> detailed
>>>>>>>>> logging. It'll show you the details of what's going on.
>>>>>>>>>
>>>>>>>> Thanks! I'll increase spamdyke log-level.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail:
>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>> For additional commands, e-mail:
>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>
>>>>>>> Hello list,
>>>>>>>
>>>>>>> I implemented the log-level setting in spamdyke to 'excessive'
>>>>>>> and the
>>>>>>> log results are below:
>>>>>>>
>>>>>>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>>>>>>> @400000005421856d2ffa8244 tcpserver: ok 15364
>>>>>>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>>>>>>> @400000005421856d3029c004 spamdyke[15364]:
>>>>>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing
>>>>>>> rDNS;
>>>>>>> rdns: theirmail.theirdomain.com
>>>>>>> @400000005421856d302a21ac spamdyke[15364]:
>>>>>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>>>>>> whitelist file(s); rdns: theirmail.theirdomain.com
>>>>>>> @400000005421856d302a9ac4 spamdyke[15364]:
>>>>>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>>>>>> blacklist file(s); rdns: theirmail.theirdomain.com
>>>>>>> @400000005421856d302b0c0c spamdyke[15364]:
>>>>>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>>>> @400000005421856d302bcb74 spamdyke[15364]:
>>>>>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>>>> @400000005421856d302c9e64 spamdyke[15364]:
>>>>>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for
>>>>>>> IP in
>>>>>>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>>>> theirmail.theirdomain.com
>>>>>>> @400000005421856d302d271c spamdyke[15364]:
>>>>>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for
>>>>>>> IP in
>>>>>>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>>>> theirmail.theirdomain.com
>>>>>>> @400000005421856d302d5214 spamdyke[15364]:
>>>>>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>>>>>> theirmail.theirdomain.com
>>>>>>> @400000005421856d33e291e4 spamdyke[15364]:
>>>>>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>>>>>> delay: 1
>>>>>>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>>>>>>
>>>>>>> The connection seems to stop after the 'earlytalker' filter, but
>>>>>>> I'm not
>>>>>>> sure this would be the cause. Any ideas?
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>> Eric,
>>>>>>
>>>>>> who is sending: a remote server, or a remote client?
>>>>>>
>>>>>> Tonino
>>>>>>
>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail:
>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>> For additional commands, e-mail:
>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>
>>>>> Hi Tonino,
>>>>>
>>>>> I think I understand your question. The sender is an MS Exchange
>>>>> server.
>>>>>
>>>>> And, I don't think I've stated this before, but we're having trouble
>>>>> both sending and receiving email. When they send email from their
>>>>> Exchange server it connects to our QMT host and disconnects right away
>>>>> without delivering the mail only to be delivered some time later from
>>>>> hours to up to a day and a half. And, this is true when we send
>>>>> email to
>>>>> them from our QMT host to their Exchange server. It makes me believe
>>>>> something is going on in-between the two hosts. One email sat in
>>>>> the QMT
>>>>> queue for hours.
>>>>>
>>>>> In testing, when I telnet to their Exchange server on port 25 there
>>>>> is a
>>>>> very long delay--up to 75 seconds, which indicates to me that
>>>>> something
>>>>> is wrong on their end or something is blocking the connection. Using
>>>>> Wireshark to examine this test, our QMT host sends 5 SYN packets (when
>>>>> there should only be one) and then is responded to with a SYN, ACK
>>>>> packet by their Exchange server after the 5th; then our QMT host sends
>>>>> an RST packet. During this delay if I open up another terminal and
>>>>> telnet to their Exchange server on port 25, I receive their SMTP
>>>>> greeting immediately. Upon subsequent telnet(s) on port 25 it always
>>>>> connects. If I wait 5 minutes or more in between telnet(ing) on
>>>>> port 25
>>>>> their is a long delay, again.
>>>>>
>>>>> I hope all of this makes sense to you. It is quite disconcerting to be
>>>>> able to send and receive email from or to anywhere except one host.
>>>>> Their IT staff claims the same thing, that is, that our QMT host is
>>>>> the
>>>>> only host they are having trouble with in send/receiving email.
>>>>>
>>>>> I'm going to set up spamdyke as EricS has recommended and see what
>>>>> happens.
>>>> Just thinking loudly...
>>>>
>>>> 1) It looks like they could have DNS problems. If first connection is
>>>> slow, and second is quick, it looks like a dns query slow in first
>>>> attempo, but already in cache in the second... and then again slow on
>>>> third attempot after a few minutes because cache life is too short.
>>>> 2) Check on exhange server
>>>> http://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
>>>>
>>>> 3) if they have firewall, check command EHLO is accepted.
>>>>
>>>> Regards,
>>>>
>>>> Tonino
>>>>
>>>>
>>>>> EricB
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>> For additional commands, e-mail:
>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>
>>> Thanks Tonino,
>>>
>>> I'll check this all out.
>>>
>>> I did the advanced logging EricS recommended and it looks like this:
>>>
>>> Begin:
>>>
>>> 09/24/2014 08:14:36 LOG OUTPUT
>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>>> rdns: mail.theirdom.com^M
>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>> whitelist file(s); rdns: mail.theirdom.com^M
>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>> blacklist file(s); rdns: mail.theirdom.com^M
>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>> file(s); ip: yyy.yyy.yyy.yyy^M
>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>> file(s); ip: yyy.yyy.yyy.yyy^M
>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
>>> rDNS +keyword(s) in whitelist file; ip: yyy.yyy.yyy.yyy rdns:
>>> mail.theirdom.com^M
>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
>>> rDNS +keyword(s) in blacklist file; ip: yyy.yyy.yyy.yyy rdns:
>>> mail.theirdom.com^M
>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>> yyy.yyy.yyy.yyy^M
>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>> delay: 2^M
>>>
>>> 09/24/2014 08:14:38 FROM CHILD TO REMOTE: 93 bytes
>>> 220 mail.ourdom.com - Welcome to OUR DOMAIN'S QMT SMTP Server ESMTP^M
>>>
>>> 09/24/2014 08:15:36 CLOSED
>>>
>>> End:
>>>
>>>
>>> I'm not sure who closed the connection.
>>>
>>> Eric
>>>
>>>
>>> ---------------------------------------------------------------------
>> Hmmmm. Is it always exactly one minute from begin to end? That would
>> appear to indicate some timer cutting out. It could be spamdyke
>> closing the session depending on your idle-timeout-secs= value. I'm
>> guessing 60, which is probably ok. I've upped mine to 180, and I don't
>> recall exactly why I did that. Wouldn't hurt to bump it up I suppose.
>>
>> Still, the other end should have replied to your 220 message before 58
>> seconds elapsed.
>>
>> I wonder if there's a routing table misconfigured somewhere along the
>> way. I've seen instances where an errant routing table entry can cause
>> every nth packet to get dropped along the way. Are you seeing reliable
>> pings over a period of a minute or so? If not, I'd suspect a network
>> issue.
>>
>> At this point, I'd guess that QMT may be terminating a little soon,
>> and there's also a network problem somewhere along the way.
>>
>> Again, just a guess.
>>
>> P.S. Nice to see such accomplished people as Tonino and Bharath
>> helping out. Thanks guys!
>>
> No, it is not always one minute, sometimes it is up to thirty seconds
> longer. I don't think spamdyke is closing the session as my
> idle-timeout-secs is set to 480, and I don't recall either why I set
> mine so high. While telnet(ing) to their host on port 25 initially and
> it is 'trying' to connect, I can open another terminal and run the same
> telnet command and I'll get their greeting right away.
>
> I agree, their host should have replied faster than 58 seconds after the
> SMTP greeting, unless the greeting is never getting to there host. There
> host does not have ICMP protocol turned on. I could ask them to do so.
>
> If I have spamdyke set to terminate after 480 seconds what else would be
> terminating the connection?

Eric,

ask them to check for their DNS, I'm quite sure they have DNS latency
problems.
Ask them to put your server IP and name in their hosts file (windows
server has one too), and problems could disappear (only for your server)-

Regard,

Tonino

> And, ditto. Thanks for the help Tonino and Bharath!!!
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>


--
------------------------------------------------------------
***@zioni Interazioni di Antonio Nati
http://www.interazioni.it ***@interazioni.it
------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Bharath Chari
2014-09-25 15:44:07 UTC
Permalink
On 09/25/2014 05:50 PM, Eric Broch wrote:
> On 9/24/2014 9:35 AM, Eric Shubert wrote:
>> On 09/24/2014 07:27 AM, Eric Broch wrote:
>>> On 9/24/2014 8:08 AM, Tonix - Antonio Nati wrote:
>>>> Il 24/09/2014 15:01, Eric Broch ha scritto:
>>>>> On 9/24/2014 1:07 AM, Tonix - Antonio Nati wrote:
>>>>>> Il 23/09/2014 18:28, Eric Broch ha scritto:
>>>>>>> On 9/22/2014 5:39 PM, Eric Broch wrote:
>>>>>>>> On 9/22/2014 4:43 PM, Eric Shubert wrote:
>>>>>>>>> Nice info, Tonino. I know that SPF failures used to do that too,
>>>>>>>>> but I
>>>>>>>>> think we have a log message for that now.
>>>>>>>>>
>>>>>>>>> Sounds to me like TLS may be failing. I'd turn on spamdyke's
>>>>>>>>> detailed
>>>>>>>>> logging. It'll show you the details of what's going on.
>>>>>>>>>
>>>>>>>> Thanks! I'll increase spamdyke log-level.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail:
>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>> For additional commands, e-mail:
>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>
>>>>>>> Hello list,
>>>>>>>
>>>>>>> I implemented the log-level setting in spamdyke to 'excessive'
>>>>>>> and the
>>>>>>> log results are below:
>>>>>>>
>>>>>>> @400000005421856d2ff92a84 tcpserver: pid 15364 from xxx.xxx.xxx.xxx
>>>>>>> @400000005421856d2ffa8244 tcpserver: ok 15364
>>>>>>> mail.acemt.com:yyy.yyy.yyy.yyy:25 :xxx.xxx.xxx.xxx::26232
>>>>>>> @400000005421856d3029c004 spamdyke[15364]:
>>>>>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing
>>>>>>> rDNS;
>>>>>>> rdns: theirmail.theirdomain.com
>>>>>>> @400000005421856d302a21ac spamdyke[15364]:
>>>>>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>>>>>> whitelist file(s); rdns: theirmail.theirdomain.com
>>>>>>> @400000005421856d302a9ac4 spamdyke[15364]:
>>>>>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>>>>>> blacklist file(s); rdns: theirmail.theirdomain.com
>>>>>>> @400000005421856d302b0c0c spamdyke[15364]:
>>>>>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>>>> @400000005421856d302bcb74 spamdyke[15364]:
>>>>>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>>>>>> file(s); ip: xxx.xxx.xxx.xxx
>>>>>>> @400000005421856d302c9e64 spamdyke[15364]:
>>>>>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for
>>>>>>> IP in
>>>>>>> rDNS +keyword(s) in whitelist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>>>> theirmail.theirdomain.com
>>>>>>> @400000005421856d302d271c spamdyke[15364]:
>>>>>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for
>>>>>>> IP in
>>>>>>> rDNS +keyword(s) in blacklist file; ip: xxx.xxx.xxx.xxx rdns:
>>>>>>> theirmail.theirdomain.com
>>>>>>> @400000005421856d302d5214 spamdyke[15364]:
>>>>>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>>>>>> theirmail.theirdomain.com
>>>>>>> @400000005421856d33e291e4 spamdyke[15364]:
>>>>>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>>>>>> delay: 1
>>>>>>> @40000000542185a9306b495c tcpserver: end 15364 status 0
>>>>>>>
>>>>>>> The connection seems to stop after the 'earlytalker' filter, but
>>>>>>> I'm not
>>>>>>> sure this would be the cause. Any ideas?
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>> Eric,
>>>>>>
>>>>>> who is sending: a remote server, or a remote client?
>>>>>>
>>>>>> Tonino
>>>>>>
>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail:
>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>> For additional commands, e-mail:
>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>
>>>>> Hi Tonino,
>>>>>
>>>>> I think I understand your question. The sender is an MS Exchange
>>>>> server.
>>>>>
>>>>> And, I don't think I've stated this before, but we're having trouble
>>>>> both sending and receiving email. When they send email from their
>>>>> Exchange server it connects to our QMT host and disconnects right away
>>>>> without delivering the mail only to be delivered some time later from
>>>>> hours to up to a day and a half. And, this is true when we send
>>>>> email to
>>>>> them from our QMT host to their Exchange server. It makes me believe
>>>>> something is going on in-between the two hosts. One email sat in
>>>>> the QMT
>>>>> queue for hours.
>>>>>
>>>>> In testing, when I telnet to their Exchange server on port 25 there
>>>>> is a
>>>>> very long delay--up to 75 seconds, which indicates to me that
>>>>> something
>>>>> is wrong on their end or something is blocking the connection. Using
>>>>> Wireshark to examine this test, our QMT host sends 5 SYN packets (when
>>>>> there should only be one) and then is responded to with a SYN, ACK
>>>>> packet by their Exchange server after the 5th; then our QMT host sends
>>>>> an RST packet. During this delay if I open up another terminal and
>>>>> telnet to their Exchange server on port 25, I receive their SMTP
>>>>> greeting immediately. Upon subsequent telnet(s) on port 25 it always
>>>>> connects. If I wait 5 minutes or more in between telnet(ing) on
>>>>> port 25
>>>>> their is a long delay, again.
>>>>>
>>>>> I hope all of this makes sense to you. It is quite disconcerting to be
>>>>> able to send and receive email from or to anywhere except one host.
>>>>> Their IT staff claims the same thing, that is, that our QMT host is
>>>>> the
>>>>> only host they are having trouble with in send/receiving email.
>>>>>
>>>>> I'm going to set up spamdyke as EricS has recommended and see what
>>>>> happens.
>>>> Just thinking loudly...
>>>>
>>>> 1) It looks like they could have DNS problems. If first connection is
>>>> slow, and second is quick, it looks like a dns query slow in first
>>>> attempo, but already in cache in the second... and then again slow on
>>>> third attempot after a few minutes because cache life is too short.
>>>> 2) Check on exhange server
>>>> http://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
>>>>
>>>> 3) if they have firewall, check command EHLO is accepted.
>>>>
>>>> Regards,
>>>>
>>>> Tonino
>>>>
>>>>
>>>>> EricB
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>> For additional commands, e-mail:
>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>
>>> Thanks Tonino,
>>>
>>> I'll check this all out.
>>>
>>> I did the advanced logging EricS recommended and it looks like this:
>>>
>>> Begin:
>>>
>>> 09/24/2014 08:14:36 LOG OUTPUT
>>> DEBUG(filter_rdns_missing()@filter.c:986): checking for missing rDNS;
>>> rdns: mail.theirdom.com^M
>>> DEBUG(filter_rdns_whitelist_file()@filter.c:1094): searching rDNS
>>> whitelist file(s); rdns: mail.theirdom.com^M
>>> DEBUG(filter_rdns_blacklist_file()@filter.c:1198): searching rDNS
>>> blacklist file(s); rdns: mail.theirdom.com^M
>>> DEBUG(filter_ip_whitelist()@filter.c:1267): searching IP whitelist
>>> file(s); ip: yyy.yyy.yyy.yyy^M
>>> DEBUG(filter_ip_blacklist()@filter.c:1318): searching IP blacklist
>>> file(s); ip: yyy.yyy.yyy.yyy^M
>>> DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1419): checking for IP in
>>> rDNS +keyword(s) in whitelist file; ip: yyy.yyy.yyy.yyy rdns:
>>> mail.theirdom.com^M
>>> DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1372): checking for IP in
>>> rDNS +keyword(s) in blacklist file; ip: yyy.yyy.yyy.yyy rdns:
>>> mail.theirdom.com^M
>>> DEBUG(filter_dns_rbl()@filter.c:1684): checking DNS RBL(s); ip:
>>> yyy.yyy.yyy.yyy^M
>>> DEBUG(filter_earlytalker()@filter.c:1856): checking for earlytalker;
>>> delay: 2^M
>>>
>>> 09/24/2014 08:14:38 FROM CHILD TO REMOTE: 93 bytes
>>> 220 mail.ourdom.com - Welcome to OUR DOMAIN'S QMT SMTP Server ESMTP^M
>>>
>>> 09/24/2014 08:15:36 CLOSED
>>>
>>> End:
>>>
>>>
>>> I'm not sure who closed the connection.
>>>
>>> Eric
>>>
>>>
>>> ---------------------------------------------------------------------
>> Hmmmm. Is it always exactly one minute from begin to end? That would
>> appear to indicate some timer cutting out. It could be spamdyke
>> closing the session depending on your idle-timeout-secs= value. I'm
>> guessing 60, which is probably ok. I've upped mine to 180, and I don't
>> recall exactly why I did that. Wouldn't hurt to bump it up I suppose.
>>
>> Still, the other end should have replied to your 220 message before 58
>> seconds elapsed.
>>
>> I wonder if there's a routing table misconfigured somewhere along the
>> way. I've seen instances where an errant routing table entry can cause
>> every nth packet to get dropped along the way. Are you seeing reliable
>> pings over a period of a minute or so? If not, I'd suspect a network
>> issue.
>>
>> At this point, I'd guess that QMT may be terminating a little soon,
>> and there's also a network problem somewhere along the way.
>>
>> Again, just a guess.
>>
>> P.S. Nice to see such accomplished people as Tonino and Bharath
>> helping out. Thanks guys!
>>
> No, it is not always one minute, sometimes it is up to thirty seconds
> longer. I don't think spamdyke is closing the session as my
> idle-timeout-secs is set to 480, and I don't recall either why I set
> mine so high. While telnet(ing) to their host on port 25 initially and
> it is 'trying' to connect, I can open another terminal and run the same
> telnet command and I'll get their greeting right away.
>
> I agree, their host should have replied faster than 58 seconds after the
> SMTP greeting, unless the greeting is never getting to there host. There
> host does not have ICMP protocol turned on. I could ask them to do so.
>
> If I have spamdyke set to terminate after 480 seconds what else would be
> terminating the connection?
>
> And, ditto. Thanks for the help Tonino and Bharath!!!
>
Thanks hardly required. The problem still remains :(
OK, since you're having a problem even when doing a RAW telnet (the
initial connection), the MTA related issue can be ruled out for now.
However, it would be great if you could telnet from ANOTHER network and
see if the pattern remains the same (of the initial connection being
slow, and the next connection being fast).

Are you doing the telnet using IP or hostname? Let's rule out DNS lookup
related issues.

Bharath

Bharath

---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Bharath Chari
2014-10-02 07:32:40 UTC
Permalink
On 09/25/2014 06:44 PM, Bharath Chari wrote:
> On 09/25/2014 05:50 PM, Eric Broch wrote:
>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>> appear to indicate some timer cutting out. It could be spamdyke
>>> closing the session depending on your idle-timeout-secs= value. I'm
>>> guessing 60, which is probably ok. I've upped mine to 180, and I don't
>>> recall exactly why I did that. Wouldn't hurt to bump it up I suppose.
>>>
>>> Still, the other end should have replied to your 220 message before 58
>>> seconds elapsed.
>>>
>>> I wonder if there's a routing table misconfigured somewhere along the
>>> way. I've seen instances where an errant routing table entry can cause
>>> every nth packet to get dropped along the way. Are you seeing reliable
>>> pings over a period of a minute or so? If not, I'd suspect a network
>>> issue.
>>>
>>> At this point, I'd guess that QMT may be terminating a little soon,
>>> and there's also a network problem somewhere along the way.
>>>
>>> Again, just a guess.
>>>
>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>> helping out. Thanks guys!
>>>
>> No, it is not always one minute, sometimes it is up to thirty seconds
>> longer. I don't think spamdyke is closing the session as my
>> idle-timeout-secs is set to 480, and I don't recall either why I set
>> mine so high. While telnet(ing) to their host on port 25 initially and
>> it is 'trying' to connect, I can open another terminal and run the same
>> telnet command and I'll get their greeting right away.
>>
>> I agree, their host should have replied faster than 58 seconds after the
>> SMTP greeting, unless the greeting is never getting to there host. There
>> host does not have ICMP protocol turned on. I could ask them to do so.
>>
>> If I have spamdyke set to terminate after 480 seconds what else would be
>> terminating the connection?
>>
>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>
> Thanks hardly required. The problem still remains :(
> OK, since you're having a problem even when doing a RAW telnet (the
> initial connection), the MTA related issue can be ruled out for now.
> However, it would be great if you could telnet from ANOTHER network
> and see if the pattern remains the same (of the initial connection
> being slow, and the next connection being fast).
>
> Are you doing the telnet using IP or hostname? Let's rule out DNS
> lookup related issues.
>
> Bharath

@Eric Broch: Curious to know how this issue panned out. Did it resolve
itself?

Bharath

---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Broch
2014-10-02 13:16:19 UTC
Permalink
On 10/2/2014 1:32 AM, Bharath Chari wrote:
> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>> guessing 60, which is probably ok. I've upped mine to 180, and I don't
>>>> recall exactly why I did that. Wouldn't hurt to bump it up I suppose.
>>>>
>>>> Still, the other end should have replied to your 220 message before 58
>>>> seconds elapsed.
>>>>
>>>> I wonder if there's a routing table misconfigured somewhere along the
>>>> way. I've seen instances where an errant routing table entry can cause
>>>> every nth packet to get dropped along the way. Are you seeing reliable
>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>> issue.
>>>>
>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>> and there's also a network problem somewhere along the way.
>>>>
>>>> Again, just a guess.
>>>>
>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>> helping out. Thanks guys!
>>>>
>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>> longer. I don't think spamdyke is closing the session as my
>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>> mine so high. While telnet(ing) to their host on port 25 initially and
>>> it is 'trying' to connect, I can open another terminal and run the same
>>> telnet command and I'll get their greeting right away.
>>>
>>> I agree, their host should have replied faster than 58 seconds after
>>> the
>>> SMTP greeting, unless the greeting is never getting to there host.
>>> There
>>> host does not have ICMP protocol turned on. I could ask them to do so.
>>>
>>> If I have spamdyke set to terminate after 480 seconds what else
>>> would be
>>> terminating the connection?
>>>
>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>
>> Thanks hardly required. The problem still remains :(
>> OK, since you're having a problem even when doing a RAW telnet (the
>> initial connection), the MTA related issue can be ruled out for now.
>> However, it would be great if you could telnet from ANOTHER network
>> and see if the pattern remains the same (of the initial connection
>> being slow, and the next connection being fast).
>>
>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>> lookup related issues.
>>
>> Bharath
>
> @Eric Broch: Curious to know how this issue panned out. Did it resolve
> itself?
>
> Bharath
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>
Thanks for asking Bharath.

I'm having trouble getting the IT staff on the other side to help me
test. They've been silent for almost a week now, but the problem still
persists and the users are frustrated.

Eric

---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Broch
2014-10-02 13:59:47 UTC
Permalink
On 10/2/2014 1:32 AM, Bharath Chari wrote:
> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>> guessing 60, which is probably ok. I've upped mine to 180, and I don't
>>>> recall exactly why I did that. Wouldn't hurt to bump it up I suppose.
>>>>
>>>> Still, the other end should have replied to your 220 message before 58
>>>> seconds elapsed.
>>>>
>>>> I wonder if there's a routing table misconfigured somewhere along the
>>>> way. I've seen instances where an errant routing table entry can cause
>>>> every nth packet to get dropped along the way. Are you seeing reliable
>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>> issue.
>>>>
>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>> and there's also a network problem somewhere along the way.
>>>>
>>>> Again, just a guess.
>>>>
>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>> helping out. Thanks guys!
>>>>
>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>> longer. I don't think spamdyke is closing the session as my
>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>> mine so high. While telnet(ing) to their host on port 25 initially and
>>> it is 'trying' to connect, I can open another terminal and run the same
>>> telnet command and I'll get their greeting right away.
>>>
>>> I agree, their host should have replied faster than 58 seconds after
>>> the
>>> SMTP greeting, unless the greeting is never getting to there host.
>>> There
>>> host does not have ICMP protocol turned on. I could ask them to do so.
>>>
>>> If I have spamdyke set to terminate after 480 seconds what else
>>> would be
>>> terminating the connection?
>>>
>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>
>> Thanks hardly required. The problem still remains :(
>> OK, since you're having a problem even when doing a RAW telnet (the
>> initial connection), the MTA related issue can be ruled out for now.
>> However, it would be great if you could telnet from ANOTHER network
>> and see if the pattern remains the same (of the initial connection
>> being slow, and the next connection being fast).
>>
>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>> lookup related issues.
>>
>> Bharath
>
> @Eric Broch: Curious to know how this issue panned out. Did it resolve
> itself?
>
> Bharath
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>
Bharath,

And, also, it doesn't matter whether I use the hostname of the IP
Address same results.

I can telnet on port 25 to the problem host from [an]other location(s)
and it works just fine.

Eric

---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Bharath Chari
2014-10-02 14:30:11 UTC
Permalink
On 10/02/2014 04:59 PM, Eric Broch wrote:
> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I don't
>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I suppose.
>>>>>
>>>>> Still, the other end should have replied to your 220 message before 58
>>>>> seconds elapsed.
>>>>>
>>>>> I wonder if there's a routing table misconfigured somewhere along the
>>>>> way. I've seen instances where an errant routing table entry can cause
>>>>> every nth packet to get dropped along the way. Are you seeing reliable
>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>> issue.
>>>>>
>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>> and there's also a network problem somewhere along the way.
>>>>>
>>>>> Again, just a guess.
>>>>>
>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>> helping out. Thanks guys!
>>>>>
>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>> longer. I don't think spamdyke is closing the session as my
>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>> mine so high. While telnet(ing) to their host on port 25 initially and
>>>> it is 'trying' to connect, I can open another terminal and run the same
>>>> telnet command and I'll get their greeting right away.
>>>>
>>>> I agree, their host should have replied faster than 58 seconds after
>>>> the
>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>> There
>>>> host does not have ICMP protocol turned on. I could ask them to do so.
>>>>
>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>> would be
>>>> terminating the connection?
>>>>
>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>
>>> Thanks hardly required. The problem still remains :(
>>> OK, since you're having a problem even when doing a RAW telnet (the
>>> initial connection), the MTA related issue can be ruled out for now.
>>> However, it would be great if you could telnet from ANOTHER network
>>> and see if the pattern remains the same (of the initial connection
>>> being slow, and the next connection being fast).
>>>
>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>> lookup related issues.
>>>
>>> Bharath
>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>> itself?
>>
>> Bharath
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>
> Bharath,
>
> And, also, it doesn't matter whether I use the hostname of the IP
> Address same results.
>
> I can telnet on port 25 to the problem host from [an]other location(s)
> and it works just fine.
>
>
There you go. There's probably nothing you can do from your end - it's
most likely a firewall at their end. However, as a last ditch test, can
you also try to telnet to port 25 on their mail server from ANOTHER
machine on the same network as the QMT machine.

Wishing you the best :)

Bharath

---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Broch
2014-10-02 15:10:26 UTC
Permalink
On 10/2/2014 8:30 AM, Bharath Chari wrote:
> On 10/02/2014 04:59 PM, Eric Broch wrote:
>> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I
>>>>>> don't
>>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I
>>>>>> suppose.
>>>>>>
>>>>>> Still, the other end should have replied to your 220 message
>>>>>> before 58
>>>>>> seconds elapsed.
>>>>>>
>>>>>> I wonder if there's a routing table misconfigured somewhere along
>>>>>> the
>>>>>> way. I've seen instances where an errant routing table entry can
>>>>>> cause
>>>>>> every nth packet to get dropped along the way. Are you seeing
>>>>>> reliable
>>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>>> issue.
>>>>>>
>>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>>> and there's also a network problem somewhere along the way.
>>>>>>
>>>>>> Again, just a guess.
>>>>>>
>>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>>> helping out. Thanks guys!
>>>>>>
>>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>>> longer. I don't think spamdyke is closing the session as my
>>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>>> mine so high. While telnet(ing) to their host on port 25 initially
>>>>> and
>>>>> it is 'trying' to connect, I can open another terminal and run the
>>>>> same
>>>>> telnet command and I'll get their greeting right away.
>>>>>
>>>>> I agree, their host should have replied faster than 58 seconds after
>>>>> the
>>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>>> There
>>>>> host does not have ICMP protocol turned on. I could ask them to do
>>>>> so.
>>>>>
>>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>>> would be
>>>>> terminating the connection?
>>>>>
>>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>>
>>>> Thanks hardly required. The problem still remains :(
>>>> OK, since you're having a problem even when doing a RAW telnet (the
>>>> initial connection), the MTA related issue can be ruled out for now.
>>>> However, it would be great if you could telnet from ANOTHER network
>>>> and see if the pattern remains the same (of the initial connection
>>>> being slow, and the next connection being fast).
>>>>
>>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>>> lookup related issues.
>>>>
>>>> Bharath
>>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>>> itself?
>>>
>>> Bharath
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>> For additional commands, e-mail:
>>> qmailtoaster-list-***@qmailtoaster.com
>>>
>> Bharath,
>>
>> And, also, it doesn't matter whether I use the hostname of the IP
>> Address same results.
>>
>> I can telnet on port 25 to the problem host from [an]other location(s)
>> and it works just fine.
>>
>>
> There you go. There's probably nothing you can do from your end - it's
> most likely a firewall at their end. However, as a last ditch test,
> can you also try to telnet to port 25 on their mail server from
> ANOTHER machine on the same network as the QMT machine.
>
> Wishing you the best :)
>
> Bharath
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>
Thanks again, Bharath

I've done that too (from ANOTHER machine on the same network) with the
same results--delay or no connection at all.

Eric


---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Eric Broch
2014-10-02 16:02:11 UTC
Permalink
On 10/2/2014 9:10 AM, Eric Broch wrote:
> On 10/2/2014 8:30 AM, Bharath Chari wrote:
>> On 10/02/2014 04:59 PM, Eric Broch wrote:
>>> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>>>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I
>>>>>>> don't
>>>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I
>>>>>>> suppose.
>>>>>>>
>>>>>>> Still, the other end should have replied to your 220 message
>>>>>>> before 58
>>>>>>> seconds elapsed.
>>>>>>>
>>>>>>> I wonder if there's a routing table misconfigured somewhere along
>>>>>>> the
>>>>>>> way. I've seen instances where an errant routing table entry can
>>>>>>> cause
>>>>>>> every nth packet to get dropped along the way. Are you seeing
>>>>>>> reliable
>>>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>>>> issue.
>>>>>>>
>>>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>>>> and there's also a network problem somewhere along the way.
>>>>>>>
>>>>>>> Again, just a guess.
>>>>>>>
>>>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>>>> helping out. Thanks guys!
>>>>>>>
>>>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>>>> longer. I don't think spamdyke is closing the session as my
>>>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>>>> mine so high. While telnet(ing) to their host on port 25 initially
>>>>>> and
>>>>>> it is 'trying' to connect, I can open another terminal and run the
>>>>>> same
>>>>>> telnet command and I'll get their greeting right away.
>>>>>>
>>>>>> I agree, their host should have replied faster than 58 seconds after
>>>>>> the
>>>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>>>> There
>>>>>> host does not have ICMP protocol turned on. I could ask them to do
>>>>>> so.
>>>>>>
>>>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>>>> would be
>>>>>> terminating the connection?
>>>>>>
>>>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>>>
>>>>> Thanks hardly required. The problem still remains :(
>>>>> OK, since you're having a problem even when doing a RAW telnet (the
>>>>> initial connection), the MTA related issue can be ruled out for now.
>>>>> However, it would be great if you could telnet from ANOTHER network
>>>>> and see if the pattern remains the same (of the initial connection
>>>>> being slow, and the next connection being fast).
>>>>>
>>>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>>>> lookup related issues.
>>>>>
>>>>> Bharath
>>>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>>>> itself?
>>>>
>>>> Bharath
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>> For additional commands, e-mail:
>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>
>>> Bharath,
>>>
>>> And, also, it doesn't matter whether I use the hostname of the IP
>>> Address same results.
>>>
>>> I can telnet on port 25 to the problem host from [an]other location(s)
>>> and it works just fine.
>>>
>>>
>> There you go. There's probably nothing you can do from your end - it's
>> most likely a firewall at their end. However, as a last ditch test,
>> can you also try to telnet to port 25 on their mail server from
>> ANOTHER machine on the same network as the QMT machine.
>>
>> Wishing you the best :)
>>
>> Bharath
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>
> Thanks again, Bharath
>
> I've done that too (from ANOTHER machine on the same network) with the
> same results--delay or no connection at all.
>
> Eric
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>
Hi Bharath,

I just received an email from the problematic mx host's IT department.
They've done a test with SmtpDiag from their mx host and they cannot
connect to our mx host from their side either.

Eric

---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Tonix - Antonio Nati
2014-10-02 16:29:36 UTC
Permalink
Il 02/10/2014 18:02, Eric Broch ha scritto:
> On 10/2/2014 9:10 AM, Eric Broch wrote:
>> On 10/2/2014 8:30 AM, Bharath Chari wrote:
>>> On 10/02/2014 04:59 PM, Eric Broch wrote:
>>>> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>>>>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>>>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I
>>>>>>>> don't
>>>>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I
>>>>>>>> suppose.
>>>>>>>>
>>>>>>>> Still, the other end should have replied to your 220 message
>>>>>>>> before 58
>>>>>>>> seconds elapsed.
>>>>>>>>
>>>>>>>> I wonder if there's a routing table misconfigured somewhere along
>>>>>>>> the
>>>>>>>> way. I've seen instances where an errant routing table entry can
>>>>>>>> cause
>>>>>>>> every nth packet to get dropped along the way. Are you seeing
>>>>>>>> reliable
>>>>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>>>>> issue.
>>>>>>>>
>>>>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>>>>> and there's also a network problem somewhere along the way.
>>>>>>>>
>>>>>>>> Again, just a guess.
>>>>>>>>
>>>>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>>>>> helping out. Thanks guys!
>>>>>>>>
>>>>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>>>>> longer. I don't think spamdyke is closing the session as my
>>>>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>>>>> mine so high. While telnet(ing) to their host on port 25 initially
>>>>>>> and
>>>>>>> it is 'trying' to connect, I can open another terminal and run the
>>>>>>> same
>>>>>>> telnet command and I'll get their greeting right away.
>>>>>>>
>>>>>>> I agree, their host should have replied faster than 58 seconds after
>>>>>>> the
>>>>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>>>>> There
>>>>>>> host does not have ICMP protocol turned on. I could ask them to do
>>>>>>> so.
>>>>>>>
>>>>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>>>>> would be
>>>>>>> terminating the connection?
>>>>>>>
>>>>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>>>>
>>>>>> Thanks hardly required. The problem still remains :(
>>>>>> OK, since you're having a problem even when doing a RAW telnet (the
>>>>>> initial connection), the MTA related issue can be ruled out for now.
>>>>>> However, it would be great if you could telnet from ANOTHER network
>>>>>> and see if the pattern remains the same (of the initial connection
>>>>>> being slow, and the next connection being fast).
>>>>>>
>>>>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>>>>> lookup related issues.
>>>>>>
>>>>>> Bharath
>>>>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>>>>> itself?
>>>>>
>>>>> Bharath
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>> For additional commands, e-mail:
>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>
>>>> Bharath,
>>>>
>>>> And, also, it doesn't matter whether I use the hostname of the IP
>>>> Address same results.
>>>>
>>>> I can telnet on port 25 to the problem host from [an]other location(s)
>>>> and it works just fine.
>>>>
>>>>
>>> There you go. There's probably nothing you can do from your end - it's
>>> most likely a firewall at their end. However, as a last ditch test,
>>> can you also try to telnet to port 25 on their mail server from
>>> ANOTHER machine on the same network as the QMT machine.
>>>
>>> Wishing you the best :)
>>>
>>> Bharath
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>
>> Thanks again, Bharath
>>
>> I've done that too (from ANOTHER machine on the same network) with the
>> same results--delay or no connection at all.
>>
>> Eric
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>
> Hi Bharath,
>
> I just received an email from the problematic mx host's IT department.
> They've done a test with SmtpDiag from their mx host and they cannot
> connect to our mx host from their side either.
>
> Eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>

I suppose all your network comes out using the same IP, or more IP which
are mapped to same domain.

Check if you have reverse IP issues...

You have the IP address which is connecting to external exchange server.
That IP should match the IP of the name declared in HELO (o EHLO).

Check also if name associated with that IP corresponds to HELO name
(some servers are making paranoic controls).

Tonino




--
------------------------------------------------------------
***@zioni Interazioni di Antonio Nati
http://www.interazioni.it ***@interazioni.it
------------------------------------------------------------
Eric Broch
2014-10-02 16:52:00 UTC
Permalink
On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:
> Il 02/10/2014 18:02, Eric Broch ha scritto:
>> On 10/2/2014 9:10 AM, Eric Broch wrote:
>>> On 10/2/2014 8:30 AM, Bharath Chari wrote:
>>>> On 10/02/2014 04:59 PM, Eric Broch wrote:
>>>>> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>>>>>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>>>>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>>>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I
>>>>>>>>> don't
>>>>>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I
>>>>>>>>> suppose.
>>>>>>>>>
>>>>>>>>> Still, the other end should have replied to your 220 message
>>>>>>>>> before 58
>>>>>>>>> seconds elapsed.
>>>>>>>>>
>>>>>>>>> I wonder if there's a routing table misconfigured somewhere along
>>>>>>>>> the
>>>>>>>>> way. I've seen instances where an errant routing table entry can
>>>>>>>>> cause
>>>>>>>>> every nth packet to get dropped along the way. Are you seeing
>>>>>>>>> reliable
>>>>>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>>>>>> issue.
>>>>>>>>>
>>>>>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>>>>>> and there's also a network problem somewhere along the way.
>>>>>>>>>
>>>>>>>>> Again, just a guess.
>>>>>>>>>
>>>>>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>>>>>> helping out. Thanks guys!
>>>>>>>>>
>>>>>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>>>>>> longer. I don't think spamdyke is closing the session as my
>>>>>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>>>>>> mine so high. While telnet(ing) to their host on port 25 initially
>>>>>>>> and
>>>>>>>> it is 'trying' to connect, I can open another terminal and run the
>>>>>>>> same
>>>>>>>> telnet command and I'll get their greeting right away.
>>>>>>>>
>>>>>>>> I agree, their host should have replied faster than 58 seconds after
>>>>>>>> the
>>>>>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>>>>>> There
>>>>>>>> host does not have ICMP protocol turned on. I could ask them to do
>>>>>>>> so.
>>>>>>>>
>>>>>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>>>>>> would be
>>>>>>>> terminating the connection?
>>>>>>>>
>>>>>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>>>>>
>>>>>>> Thanks hardly required. The problem still remains :(
>>>>>>> OK, since you're having a problem even when doing a RAW telnet (the
>>>>>>> initial connection), the MTA related issue can be ruled out for now.
>>>>>>> However, it would be great if you could telnet from ANOTHER network
>>>>>>> and see if the pattern remains the same (of the initial connection
>>>>>>> being slow, and the next connection being fast).
>>>>>>>
>>>>>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>>>>>> lookup related issues.
>>>>>>>
>>>>>>> Bharath
>>>>>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>>>>>> itself?
>>>>>>
>>>>>> Bharath
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>> For additional commands, e-mail:
>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>
>>>>> Bharath,
>>>>>
>>>>> And, also, it doesn't matter whether I use the hostname of the IP
>>>>> Address same results.
>>>>>
>>>>> I can telnet on port 25 to the problem host from [an]other location(s)
>>>>> and it works just fine.
>>>>>
>>>>>
>>>> There you go. There's probably nothing you can do from your end - it's
>>>> most likely a firewall at their end. However, as a last ditch test,
>>>> can you also try to telnet to port 25 on their mail server from
>>>> ANOTHER machine on the same network as the QMT machine.
>>>>
>>>> Wishing you the best :)
>>>>
>>>> Bharath
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>
>>> Thanks again, Bharath
>>>
>>> I've done that too (from ANOTHER machine on the same network) with the
>>> same results--delay or no connection at all.
>>>
>>> Eric
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>
>> Hi Bharath,
>>
>> I just received an email from the problematic mx host's IT department.
>> They've done a test with SmtpDiag from their mx host and they cannot
>> connect to our mx host from their side either.
>>
>> Eric
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>
>
Tonino,
> I suppose all your network comes out using the same IP, or more IP
> which are mapped to same domain.
Yes. On our end we have a NAT(ed) firewall. We also have an MPLS circuit
for certain private address ranges on the WAN interface.
>
> Check if you have reverse IP issues...
Reverse DNS checks out Okay on both ends.
>
> You have the IP address which is connecting to external exchange server.
> That IP should match the IP of the name declared in HELO (o EHLO).
There seems to be a Sonicwall email security appliance on their end
between our hosts--which, I think, may be the problem--which has a name
different than their MX record.
>
> Check also if name associated with that IP corresponds to HELO name
> (some servers are making paranoic controls).
The name associated with the IP on their end is different than the
response of the HELO command.
>
> Tonino
Thanks again!
>
>
>
>
> --
> ------------------------------------------------------------
> ***@zioni Interazioni di Antonio Nati
> http://www.interazioni.it ***@interazioni.it
> ------------------------------------------------------------
Tonix - Antonio Nati
2014-10-02 17:16:12 UTC
Permalink
Il 02/10/2014 18:52, Eric Broch ha scritto:
> On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:
>> Il 02/10/2014 18:02, Eric Broch ha scritto:
>>> On 10/2/2014 9:10 AM, Eric Broch wrote:
>>>> On 10/2/2014 8:30 AM, Bharath Chari wrote:
>>>>> On 10/02/2014 04:59 PM, Eric Broch wrote:
>>>>>> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>>>>>>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>>>>>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>>>>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>>>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>>>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>>>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I
>>>>>>>>>> don't
>>>>>>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I
>>>>>>>>>> suppose.
>>>>>>>>>>
>>>>>>>>>> Still, the other end should have replied to your 220 message
>>>>>>>>>> before 58
>>>>>>>>>> seconds elapsed.
>>>>>>>>>>
>>>>>>>>>> I wonder if there's a routing table misconfigured somewhere along
>>>>>>>>>> the
>>>>>>>>>> way. I've seen instances where an errant routing table entry can
>>>>>>>>>> cause
>>>>>>>>>> every nth packet to get dropped along the way. Are you seeing
>>>>>>>>>> reliable
>>>>>>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>>>>>>> issue.
>>>>>>>>>>
>>>>>>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>>>>>>> and there's also a network problem somewhere along the way.
>>>>>>>>>>
>>>>>>>>>> Again, just a guess.
>>>>>>>>>>
>>>>>>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>>>>>>> helping out. Thanks guys!
>>>>>>>>>>
>>>>>>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>>>>>>> longer. I don't think spamdyke is closing the session as my
>>>>>>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>>>>>>> mine so high. While telnet(ing) to their host on port 25 initially
>>>>>>>>> and
>>>>>>>>> it is 'trying' to connect, I can open another terminal and run the
>>>>>>>>> same
>>>>>>>>> telnet command and I'll get their greeting right away.
>>>>>>>>>
>>>>>>>>> I agree, their host should have replied faster than 58 seconds after
>>>>>>>>> the
>>>>>>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>>>>>>> There
>>>>>>>>> host does not have ICMP protocol turned on. I could ask them to do
>>>>>>>>> so.
>>>>>>>>>
>>>>>>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>>>>>>> would be
>>>>>>>>> terminating the connection?
>>>>>>>>>
>>>>>>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>>>>>>
>>>>>>>> Thanks hardly required. The problem still remains :(
>>>>>>>> OK, since you're having a problem even when doing a RAW telnet (the
>>>>>>>> initial connection), the MTA related issue can be ruled out for now.
>>>>>>>> However, it would be great if you could telnet from ANOTHER network
>>>>>>>> and see if the pattern remains the same (of the initial connection
>>>>>>>> being slow, and the next connection being fast).
>>>>>>>>
>>>>>>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>>>>>>> lookup related issues.
>>>>>>>>
>>>>>>>> Bharath
>>>>>>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>>>>>>> itself?
>>>>>>>
>>>>>>> Bharath
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>> For additional commands, e-mail:
>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>
>>>>>> Bharath,
>>>>>>
>>>>>> And, also, it doesn't matter whether I use the hostname of the IP
>>>>>> Address same results.
>>>>>>
>>>>>> I can telnet on port 25 to the problem host from [an]other location(s)
>>>>>> and it works just fine.
>>>>>>
>>>>>>
>>>>> There you go. There's probably nothing you can do from your end - it's
>>>>> most likely a firewall at their end. However, as a last ditch test,
>>>>> can you also try to telnet to port 25 on their mail server from
>>>>> ANOTHER machine on the same network as the QMT machine.
>>>>>
>>>>> Wishing you the best :)
>>>>>
>>>>> Bharath
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>
>>>> Thanks again, Bharath
>>>>
>>>> I've done that too (from ANOTHER machine on the same network) with the
>>>> same results--delay or no connection at all.
>>>>
>>>> Eric
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>
>>> Hi Bharath,
>>>
>>> I just received an email from the problematic mx host's IT department.
>>> They've done a test with SmtpDiag from their mx host and they cannot
>>> connect to our mx host from their side either.
>>>
>>> Eric
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>
>>
> Tonino,
>> I suppose all your network comes out using the same IP, or more IP
>> which are mapped to same domain.
> Yes. On our end we have a NAT(ed) firewall. We also have an MPLS
> circuit for certain private address ranges on the WAN interface.
>>
>> Check if you have reverse IP issues...
> Reverse DNS checks out Okay on both ends.
>>
>> You have the IP address which is connecting to external exchange server.
>> That IP should match the IP of the name declared in HELO (o EHLO).
> There seems to be a Sonicwall email security appliance on their end
> between our hosts--which, I think, may be the problem--which has a
> name different than their MX record.
>>
>> Check also if name associated with that IP corresponds to HELO name
>> (some servers are making paranoic controls).
> The name associated with the IP on their end is different than the
> response of the HELO command.

This could be a potential problem for them, because some senders could
refuse to send, but this is another story.



What makes me think is the fact their answer to your telnet is very slow
from your network, but fast from other networks.

I'continue checking if it is a DNS issue.

Please double checK: your external IP to name, then again name to IP,
checking all nameservers.

http://www.dnsstuff.com/tools is very helpful for a complete DNS report,
and the IP section may go even further, checking all paths of all
nameservers.

Regards,

Tonino


>>
>>
>>
>> --
>> ------------------------------------------------------------
>> ***@zioni Interazioni di Antonio Nati
>> http://www.interazioni.it ***@interazioni.it
>> ------------------------------------------------------------
>


--
------------------------------------------------------------
***@zioni Interazioni di Antonio Nati
http://www.interazioni.it ***@interazioni.it
------------------------------------------------------------
Tonix - Antonio Nati
2014-10-02 17:19:41 UTC
Permalink
Il 02/10/2014 19:16, Tonix - Antonio Nati ha scritto:
> Il 02/10/2014 18:52, Eric Broch ha scritto:
>> On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:
>>> Il 02/10/2014 18:02, Eric Broch ha scritto:
>>>> On 10/2/2014 9:10 AM, Eric Broch wrote:
>>>>> On 10/2/2014 8:30 AM, Bharath Chari wrote:
>>>>>> On 10/02/2014 04:59 PM, Eric Broch wrote:
>>>>>>> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>>>>>>>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>>>>>>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>>>>>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>>>>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>>>>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>>>>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I
>>>>>>>>>>> don't
>>>>>>>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I
>>>>>>>>>>> suppose.
>>>>>>>>>>>
>>>>>>>>>>> Still, the other end should have replied to your 220 message
>>>>>>>>>>> before 58
>>>>>>>>>>> seconds elapsed.
>>>>>>>>>>>
>>>>>>>>>>> I wonder if there's a routing table misconfigured somewhere along
>>>>>>>>>>> the
>>>>>>>>>>> way. I've seen instances where an errant routing table entry can
>>>>>>>>>>> cause
>>>>>>>>>>> every nth packet to get dropped along the way. Are you seeing
>>>>>>>>>>> reliable
>>>>>>>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>>>>>>>> issue.
>>>>>>>>>>>
>>>>>>>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>>>>>>>> and there's also a network problem somewhere along the way.
>>>>>>>>>>>
>>>>>>>>>>> Again, just a guess.
>>>>>>>>>>>
>>>>>>>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>>>>>>>> helping out. Thanks guys!
>>>>>>>>>>>
>>>>>>>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>>>>>>>> longer. I don't think spamdyke is closing the session as my
>>>>>>>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>>>>>>>> mine so high. While telnet(ing) to their host on port 25 initially
>>>>>>>>>> and
>>>>>>>>>> it is 'trying' to connect, I can open another terminal and run the
>>>>>>>>>> same
>>>>>>>>>> telnet command and I'll get their greeting right away.
>>>>>>>>>>
>>>>>>>>>> I agree, their host should have replied faster than 58 seconds after
>>>>>>>>>> the
>>>>>>>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>>>>>>>> There
>>>>>>>>>> host does not have ICMP protocol turned on. I could ask them to do
>>>>>>>>>> so.
>>>>>>>>>>
>>>>>>>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>>>>>>>> would be
>>>>>>>>>> terminating the connection?
>>>>>>>>>>
>>>>>>>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>>>>>>>
>>>>>>>>> Thanks hardly required. The problem still remains :(
>>>>>>>>> OK, since you're having a problem even when doing a RAW telnet (the
>>>>>>>>> initial connection), the MTA related issue can be ruled out for now.
>>>>>>>>> However, it would be great if you could telnet from ANOTHER network
>>>>>>>>> and see if the pattern remains the same (of the initial connection
>>>>>>>>> being slow, and the next connection being fast).
>>>>>>>>>
>>>>>>>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>>>>>>>> lookup related issues.
>>>>>>>>>
>>>>>>>>> Bharath
>>>>>>>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>>>>>>>> itself?
>>>>>>>>
>>>>>>>> Bharath
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>> For additional commands, e-mail:
>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>
>>>>>>> Bharath,
>>>>>>>
>>>>>>> And, also, it doesn't matter whether I use the hostname of the IP
>>>>>>> Address same results.
>>>>>>>
>>>>>>> I can telnet on port 25 to the problem host from [an]other location(s)
>>>>>>> and it works just fine.
>>>>>>>
>>>>>>>
>>>>>> There you go. There's probably nothing you can do from your end - it's
>>>>>> most likely a firewall at their end. However, as a last ditch test,
>>>>>> can you also try to telnet to port 25 on their mail server from
>>>>>> ANOTHER machine on the same network as the QMT machine.
>>>>>>
>>>>>> Wishing you the best :)
>>>>>>
>>>>>> Bharath
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>
>>>>> Thanks again, Bharath
>>>>>
>>>>> I've done that too (from ANOTHER machine on the same network) with the
>>>>> same results--delay or no connection at all.
>>>>>
>>>>> Eric
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>
>>>> Hi Bharath,
>>>>
>>>> I just received an email from the problematic mx host's IT department.
>>>> They've done a test with SmtpDiag from their mx host and they cannot
>>>> connect to our mx host from their side either.
>>>>
>>>> Eric
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>
>>>
>> Tonino,
>>> I suppose all your network comes out using the same IP, or more IP
>>> which are mapped to same domain.
>> Yes. On our end we have a NAT(ed) firewall. We also have an MPLS
>> circuit for certain private address ranges on the WAN interface.
>>>
>>> Check if you have reverse IP issues...
>> Reverse DNS checks out Okay on both ends.
>>>
>>> You have the IP address which is connecting to external exchange server.
>>> That IP should match the IP of the name declared in HELO (o EHLO).
>> There seems to be a Sonicwall email security appliance on their end
>> between our hosts--which, I think, may be the problem--which has a
>> name different than their MX record.
>>>
>>> Check also if name associated with that IP corresponds to HELO name
>>> (some servers are making paranoic controls).
>> The name associated with the IP on their end is different than the
>> response of the HELO command.
>
> This could be a potential problem for them, because some senders could
> refuse to send, but this is another story.
>
>
>
> What makes me think is the fact their answer to your telnet is very
> slow from your network, but fast from other networks.
>
> I'continue checking if it is a DNS issue.
>
> Please double checK: your external IP to name, then again name to IP,
> checking all nameservers.
>
> http://www.dnsstuff.com/tools is very helpful for a complete DNS
> report, and the IP section may go even further, checking all paths of
> all nameservers.


Reverse IP resolution uses different servers than name resolution, and I
had problems due to different configurations on reverse IP nameservers,
and that problem was only towards a specific server which was making a
paranoic control.

Regards,

Tonino



>
> Regards,
>
> Tonino
>
>
>>>
>>>
>>>
>>> --
>>> ------------------------------------------------------------
>>> ***@zioni Interazioni di Antonio Nati
>>> http://www.interazioni.it ***@interazioni.it
>>> ------------------------------------------------------------
>>
>
>
> --
> ------------------------------------------------------------
> ***@zioni Interazioni di Antonio Nati
> http://www.interazioni.it ***@interazioni.it
> ------------------------------------------------------------


--
------------------------------------------------------------
***@zioni Interazioni di Antonio Nati
http://www.interazioni.it ***@interazioni.it
------------------------------------------------------------
Cecil Yother, Jr.
2014-10-02 18:11:40 UTC
Permalink
On 10/02/2014 10:19 AM, Tonix - Antonio Nati wrote:
> Il 02/10/2014 19:16, Tonix - Antonio Nati ha scritto:
>> Il 02/10/2014 18:52, Eric Broch ha scritto:
>>> On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:
>>>> Il 02/10/2014 18:02, Eric Broch ha scritto:
>>>>> On 10/2/2014 9:10 AM, Eric Broch wrote:
>>>>>> On 10/2/2014 8:30 AM, Bharath Chari wrote:
>>>>>>> On 10/02/2014 04:59 PM, Eric Broch wrote:
>>>>>>>> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>>>>>>>>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>>>>>>>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>>>>>>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>>>>>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>>>>>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>>>>>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I
>>>>>>>>>>>> don't
>>>>>>>>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I
>>>>>>>>>>>> suppose.
>>>>>>>>>>>>
>>>>>>>>>>>> Still, the other end should have replied to your 220 message
>>>>>>>>>>>> before 58
>>>>>>>>>>>> seconds elapsed.
>>>>>>>>>>>>
>>>>>>>>>>>> I wonder if there's a routing table misconfigured somewhere along
>>>>>>>>>>>> the
>>>>>>>>>>>> way. I've seen instances where an errant routing table entry can
>>>>>>>>>>>> cause
>>>>>>>>>>>> every nth packet to get dropped along the way. Are you seeing
>>>>>>>>>>>> reliable
>>>>>>>>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>>>>>>>>> issue.
>>>>>>>>>>>>
>>>>>>>>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>>>>>>>>> and there's also a network problem somewhere along the way.
>>>>>>>>>>>>
>>>>>>>>>>>> Again, just a guess.
>>>>>>>>>>>>
>>>>>>>>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>>>>>>>>> helping out. Thanks guys!
>>>>>>>>>>>>
>>>>>>>>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>>>>>>>>> longer. I don't think spamdyke is closing the session as my
>>>>>>>>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>>>>>>>>> mine so high. While telnet(ing) to their host on port 25 initially
>>>>>>>>>>> and
>>>>>>>>>>> it is 'trying' to connect, I can open another terminal and run the
>>>>>>>>>>> same
>>>>>>>>>>> telnet command and I'll get their greeting right away.
>>>>>>>>>>>
>>>>>>>>>>> I agree, their host should have replied faster than 58 seconds after
>>>>>>>>>>> the
>>>>>>>>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>>>>>>>>> There
>>>>>>>>>>> host does not have ICMP protocol turned on. I could ask them to do
>>>>>>>>>>> so.
>>>>>>>>>>>
>>>>>>>>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>>>>>>>>> would be
>>>>>>>>>>> terminating the connection?
>>>>>>>>>>>
>>>>>>>>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>>>>>>>>
>>>>>>>>>> Thanks hardly required. The problem still remains :(
>>>>>>>>>> OK, since you're having a problem even when doing a RAW telnet (the
>>>>>>>>>> initial connection), the MTA related issue can be ruled out for now.
>>>>>>>>>> However, it would be great if you could telnet from ANOTHER network
>>>>>>>>>> and see if the pattern remains the same (of the initial connection
>>>>>>>>>> being slow, and the next connection being fast).
>>>>>>>>>>
>>>>>>>>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>>>>>>>>> lookup related issues.
>>>>>>>>>>
>>>>>>>>>> Bharath
>>>>>>>>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>>>>>>>>> itself?
>>>>>>>>>
>>>>>>>>> Bharath
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>> For additional commands, e-mail:
>>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>
>>>>>>>> Bharath,
>>>>>>>>
>>>>>>>> And, also, it doesn't matter whether I use the hostname of the IP
>>>>>>>> Address same results.
>>>>>>>>
>>>>>>>> I can telnet on port 25 to the problem host from [an]other location(s)
>>>>>>>> and it works just fine.
>>>>>>>>
>>>>>>>>
>>>>>>> There you go. There's probably nothing you can do from your end - it's
>>>>>>> most likely a firewall at their end. However, as a last ditch test,
>>>>>>> can you also try to telnet to port 25 on their mail server from
>>>>>>> ANOTHER machine on the same network as the QMT machine.
>>>>>>>
>>>>>>> Wishing you the best :)
>>>>>>>
>>>>>>> Bharath
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>
>>>>>> Thanks again, Bharath
>>>>>>
>>>>>> I've done that too (from ANOTHER machine on the same network) with the
>>>>>> same results--delay or no connection at all.
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>
>>>>> Hi Bharath,
>>>>>
>>>>> I just received an email from the problematic mx host's IT department.
>>>>> They've done a test with SmtpDiag from their mx host and they cannot
>>>>> connect to our mx host from their side either.
>>>>>
>>>>> Eric
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>
>>>>
>>> Tonino,
>>>> I suppose all your network comes out using the same IP, or more IP
>>>> which are mapped to same domain.
>>> Yes. On our end we have a NAT(ed) firewall. We also have an MPLS
>>> circuit for certain private address ranges on the WAN interface.
>>>>
>>>> Check if you have reverse IP issues...
>>> Reverse DNS checks out Okay on both ends.
>>>>
>>>> You have the IP address which is connecting to external exchange
>>>> server.
>>>> That IP should match the IP of the name declared in HELO (o EHLO).
>>> There seems to be a Sonicwall email security appliance on their end
>>> between our hosts--which, I think, may be the problem--which has a
>>> name different than their MX record.
>>>>
>>>> Check also if name associated with that IP corresponds to HELO name
>>>> (some servers are making paranoic controls).
>>> The name associated with the IP on their end is different than the
>>> response of the HELO command.
>>
>> This could be a potential problem for them, because some senders
>> could refuse to send, but this is another story.
>>
>>
>>
>> What makes me think is the fact their answer to your telnet is very
>> slow from your network, but fast from other networks.
>>
>> I'continue checking if it is a DNS issue.
>>
>> Please double checK: your external IP to name, then again name to IP,
>> checking all nameservers.
>>
>> http://www.dnsstuff.com/tools is very helpful for a complete DNS
>> report, and the IP section may go even further, checking all paths of
>> all nameservers.
>
>
> Reverse IP resolution uses different servers than name resolution, and
> I had problems due to different configurations on reverse IP
> nameservers, and that problem was only towards a specific server
> which was making a paranoic control.
>
> Regards,
>
> Tonino
>
>
>
>>
>> Regards,
>>
>> Tonino
>>
>>
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------------------------------------------
>>>> ***@zioni Interazioni di Antonio Nati
>>>> http://www.interazioni.it ***@interazioni.it
>>>> ------------------------------------------------------------
>>>
>>
>>
>> --
>> ------------------------------------------------------------
>> ***@zioni Interazioni di Antonio Nati
>> http://www.interazioni.it ***@interazioni.it
>> ------------------------------------------------------------
>
>
> --
> ------------------------------------------------------------
> ***@zioni Interazioni di Antonio Nati
> http://www.interazioni.it ***@interazioni.it
> ------------------------------------------------------------

--
Check your DNS by putting an entry in your hosts file. If it connects
instantly you've found your problem.
Tonix - Antonio Nati
2014-10-04 06:25:20 UTC
Permalink
Il 02/10/2014 20:11, Cecil Yother, Jr. ha scritto:
>
> On 10/02/2014 10:19 AM, Tonix - Antonio Nati wrote:
>> Il 02/10/2014 19:16, Tonix - Antonio Nati ha scritto:
>>> Il 02/10/2014 18:52, Eric Broch ha scritto:
>>>> On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:
>>>>> Il 02/10/2014 18:02, Eric Broch ha scritto:
>>>>>> On 10/2/2014 9:10 AM, Eric Broch wrote:
>>>>>>> On 10/2/2014 8:30 AM, Bharath Chari wrote:
>>>>>>>> On 10/02/2014 04:59 PM, Eric Broch wrote:
>>>>>>>>> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>>>>>>>>>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>>>>>>>>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>>>>>>>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>>>>>>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>>>>>>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>>>>>>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I
>>>>>>>>>>>>> don't
>>>>>>>>>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I
>>>>>>>>>>>>> suppose.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Still, the other end should have replied to your 220 message
>>>>>>>>>>>>> before 58
>>>>>>>>>>>>> seconds elapsed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I wonder if there's a routing table misconfigured somewhere along
>>>>>>>>>>>>> the
>>>>>>>>>>>>> way. I've seen instances where an errant routing table entry can
>>>>>>>>>>>>> cause
>>>>>>>>>>>>> every nth packet to get dropped along the way. Are you seeing
>>>>>>>>>>>>> reliable
>>>>>>>>>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>>>>>>>>>> and there's also a network problem somewhere along the way.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Again, just a guess.
>>>>>>>>>>>>>
>>>>>>>>>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>>>>>>>>>> helping out. Thanks guys!
>>>>>>>>>>>>>
>>>>>>>>>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>>>>>>>>>> longer. I don't think spamdyke is closing the session as my
>>>>>>>>>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>>>>>>>>>> mine so high. While telnet(ing) to their host on port 25 initially
>>>>>>>>>>>> and
>>>>>>>>>>>> it is 'trying' to connect, I can open another terminal and run the
>>>>>>>>>>>> same
>>>>>>>>>>>> telnet command and I'll get their greeting right away.
>>>>>>>>>>>>
>>>>>>>>>>>> I agree, their host should have replied faster than 58 seconds after
>>>>>>>>>>>> the
>>>>>>>>>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>>>>>>>>>> There
>>>>>>>>>>>> host does not have ICMP protocol turned on. I could ask them to do
>>>>>>>>>>>> so.
>>>>>>>>>>>>
>>>>>>>>>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>>>>>>>>>> would be
>>>>>>>>>>>> terminating the connection?
>>>>>>>>>>>>
>>>>>>>>>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>>>>>>>>>
>>>>>>>>>>> Thanks hardly required. The problem still remains :(
>>>>>>>>>>> OK, since you're having a problem even when doing a RAW telnet (the
>>>>>>>>>>> initial connection), the MTA related issue can be ruled out for now.
>>>>>>>>>>> However, it would be great if you could telnet from ANOTHER network
>>>>>>>>>>> and see if the pattern remains the same (of the initial connection
>>>>>>>>>>> being slow, and the next connection being fast).
>>>>>>>>>>>
>>>>>>>>>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>>>>>>>>>> lookup related issues.
>>>>>>>>>>>
>>>>>>>>>>> Bharath
>>>>>>>>>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>>>>>>>>>> itself?
>>>>>>>>>>
>>>>>>>>>> Bharath
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>
>>>>>>>>> Bharath,
>>>>>>>>>
>>>>>>>>> And, also, it doesn't matter whether I use the hostname of the IP
>>>>>>>>> Address same results.
>>>>>>>>>
>>>>>>>>> I can telnet on port 25 to the problem host from [an]other location(s)
>>>>>>>>> and it works just fine.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> There you go. There's probably nothing you can do from your end - it's
>>>>>>>> most likely a firewall at their end. However, as a last ditch test,
>>>>>>>> can you also try to telnet to port 25 on their mail server from
>>>>>>>> ANOTHER machine on the same network as the QMT machine.
>>>>>>>>
>>>>>>>> Wishing you the best :)
>>>>>>>>
>>>>>>>> Bharath
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>
>>>>>>> Thanks again, Bharath
>>>>>>>
>>>>>>> I've done that too (from ANOTHER machine on the same network) with the
>>>>>>> same results--delay or no connection at all.
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>
>>>>>> Hi Bharath,
>>>>>>
>>>>>> I just received an email from the problematic mx host's IT department.
>>>>>> They've done a test with SmtpDiag from their mx host and they cannot
>>>>>> connect to our mx host from their side either.
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>
>>>>>
>>>> Tonino,
>>>>> I suppose all your network comes out using the same IP, or more IP
>>>>> which are mapped to same domain.
>>>> Yes. On our end we have a NAT(ed) firewall. We also have an MPLS
>>>> circuit for certain private address ranges on the WAN interface.
>>>>>
>>>>> Check if you have reverse IP issues...
>>>> Reverse DNS checks out Okay on both ends.
>>>>>
>>>>> You have the IP address which is connecting to external exchange
>>>>> server.
>>>>> That IP should match the IP of the name declared in HELO (o EHLO).
>>>> There seems to be a Sonicwall email security appliance on their end
>>>> between our hosts--which, I think, may be the problem--which has a
>>>> name different than their MX record.
>>>>>
>>>>> Check also if name associated with that IP corresponds to HELO
>>>>> name (some servers are making paranoic controls).
>>>> The name associated with the IP on their end is different than the
>>>> response of the HELO command.
>>>
>>> This could be a potential problem for them, because some senders
>>> could refuse to send, but this is another story.
>>>
>>>
>>>
>>> What makes me think is the fact their answer to your telnet is very
>>> slow from your network, but fast from other networks.
>>>
>>> I'continue checking if it is a DNS issue.
>>>
>>> Please double checK: your external IP to name, then again name to
>>> IP, checking all nameservers.
>>>
>>> http://www.dnsstuff.com/tools is very helpful for a complete DNS
>>> report, and the IP section may go even further, checking all paths
>>> of all nameservers.
>>
>>
>> Reverse IP resolution uses different servers than name resolution,
>> and I had problems due to different configurations on reverse IP
>> nameservers, and that problem was only towards a specific server
>> which was making a paranoic control.
>>
>> Regards,
>>
>> Tonino
>>
>>
>>
>>>
>>> Regards,
>>>
>>> Tonino
>>>
>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------------------------------------------
>>>>> ***@zioni Interazioni di Antonio Nati
>>>>> http://www.interazioni.it ***@interazioni.it
>>>>> ------------------------------------------------------------
>>>>
>>>
>>>
>>> --
>>> ------------------------------------------------------------
>>> ***@zioni Interazioni di Antonio Nati
>>> http://www.interazioni.it ***@interazioni.it
>>> ------------------------------------------------------------
>>
>>
>> --
>> ------------------------------------------------------------
>> ***@zioni Interazioni di Antonio Nati
>> http://www.interazioni.it ***@interazioni.it
>> ------------------------------------------------------------
>
> --
> Check your DNS by putting an entry in your hosts file. If it connects
> instantly you've found your problem.


It would be useful it he could put this entry in the remote server :-) .
In his server, this does not help in this case.




--
------------------------------------------------------------
***@zioni Interazioni di Antonio Nati
http://www.interazioni.it ***@interazioni.it
------------------------------------------------------------
Eric Broch
2014-10-07 19:31:15 UTC
Permalink
On 10/4/2014 12:25 AM, Tonix - Antonio Nati wrote:
> Il 02/10/2014 20:11, Cecil Yother, Jr. ha scritto:
>>
>> On 10/02/2014 10:19 AM, Tonix - Antonio Nati wrote:
>>> Il 02/10/2014 19:16, Tonix - Antonio Nati ha scritto:
>>>> Il 02/10/2014 18:52, Eric Broch ha scritto:
>>>>> On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:
>>>>>> Il 02/10/2014 18:02, Eric Broch ha scritto:
>>>>>>> On 10/2/2014 9:10 AM, Eric Broch wrote:
>>>>>>>> On 10/2/2014 8:30 AM, Bharath Chari wrote:
>>>>>>>>> On 10/02/2014 04:59 PM, Eric Broch wrote:
>>>>>>>>>> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>>>>>>>>>>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>>>>>>>>>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>>>>>>>>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>>>>>>>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>>>>>>>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>>>>>>>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I
>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I
>>>>>>>>>>>>>> suppose.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Still, the other end should have replied to your 220 message
>>>>>>>>>>>>>> before 58
>>>>>>>>>>>>>> seconds elapsed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I wonder if there's a routing table misconfigured somewhere along
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> way. I've seen instances where an errant routing table entry can
>>>>>>>>>>>>>> cause
>>>>>>>>>>>>>> every nth packet to get dropped along the way. Are you seeing
>>>>>>>>>>>>>> reliable
>>>>>>>>>>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>>>>>>>>>>> and there's also a network problem somewhere along the way.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Again, just a guess.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>>>>>>>>>>> helping out. Thanks guys!
>>>>>>>>>>>>>>
>>>>>>>>>>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>>>>>>>>>>> longer. I don't think spamdyke is closing the session as my
>>>>>>>>>>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>>>>>>>>>>> mine so high. While telnet(ing) to their host on port 25 initially
>>>>>>>>>>>>> and
>>>>>>>>>>>>> it is 'trying' to connect, I can open another terminal and run the
>>>>>>>>>>>>> same
>>>>>>>>>>>>> telnet command and I'll get their greeting right away.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I agree, their host should have replied faster than 58 seconds after
>>>>>>>>>>>>> the
>>>>>>>>>>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>>>>>>>>>>> There
>>>>>>>>>>>>> host does not have ICMP protocol turned on. I could ask them to do
>>>>>>>>>>>>> so.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>>>>>>>>>>> would be
>>>>>>>>>>>>> terminating the connection?
>>>>>>>>>>>>>
>>>>>>>>>>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>>>>>>>>>>
>>>>>>>>>>>> Thanks hardly required. The problem still remains :(
>>>>>>>>>>>> OK, since you're having a problem even when doing a RAW telnet (the
>>>>>>>>>>>> initial connection), the MTA related issue can be ruled out for now.
>>>>>>>>>>>> However, it would be great if you could telnet from ANOTHER network
>>>>>>>>>>>> and see if the pattern remains the same (of the initial connection
>>>>>>>>>>>> being slow, and the next connection being fast).
>>>>>>>>>>>>
>>>>>>>>>>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>>>>>>>>>>> lookup related issues.
>>>>>>>>>>>>
>>>>>>>>>>>> Bharath
>>>>>>>>>>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>>>>>>>>>>> itself?
>>>>>>>>>>>
>>>>>>>>>>> Bharath
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>>
>>>>>>>>>> Bharath,
>>>>>>>>>>
>>>>>>>>>> And, also, it doesn't matter whether I use the hostname of the IP
>>>>>>>>>> Address same results.
>>>>>>>>>>
>>>>>>>>>> I can telnet on port 25 to the problem host from [an]other location(s)
>>>>>>>>>> and it works just fine.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> There you go. There's probably nothing you can do from your end - it's
>>>>>>>>> most likely a firewall at their end. However, as a last ditch test,
>>>>>>>>> can you also try to telnet to port 25 on their mail server from
>>>>>>>>> ANOTHER machine on the same network as the QMT machine.
>>>>>>>>>
>>>>>>>>> Wishing you the best :)
>>>>>>>>>
>>>>>>>>> Bharath
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>
>>>>>>>> Thanks again, Bharath
>>>>>>>>
>>>>>>>> I've done that too (from ANOTHER machine on the same network) with the
>>>>>>>> same results--delay or no connection at all.
>>>>>>>>
>>>>>>>> Eric
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>
>>>>>>> Hi Bharath,
>>>>>>>
>>>>>>> I just received an email from the problematic mx host's IT department.
>>>>>>> They've done a test with SmtpDiag from their mx host and they cannot
>>>>>>> connect to our mx host from their side either.
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>
>>>>>>
>>>>> Tonino,
>>>>>> I suppose all your network comes out using the same IP, or more
>>>>>> IP which are mapped to same domain.
>>>>> Yes. On our end we have a NAT(ed) firewall. We also have an MPLS
>>>>> circuit for certain private address ranges on the WAN interface.
>>>>>>
>>>>>> Check if you have reverse IP issues...
>>>>> Reverse DNS checks out Okay on both ends.
>>>>>>
>>>>>> You have the IP address which is connecting to external exchange
>>>>>> server.
>>>>>> That IP should match the IP of the name declared in HELO (o EHLO).
>>>>> There seems to be a Sonicwall email security appliance on their
>>>>> end between our hosts--which, I think, may be the problem--which
>>>>> has a name different than their MX record.
>>>>>>
>>>>>> Check also if name associated with that IP corresponds to HELO
>>>>>> name (some servers are making paranoic controls).
>>>>> The name associated with the IP on their end is different than the
>>>>> response of the HELO command.
>>>>
>>>> This could be a potential problem for them, because some senders
>>>> could refuse to send, but this is another story.
>>>>
>>>>
>>>>
>>>> What makes me think is the fact their answer to your telnet is very
>>>> slow from your network, but fast from other networks.
>>>>
>>>> I'continue checking if it is a DNS issue.
>>>>
>>>> Please double checK: your external IP to name, then again name to
>>>> IP, checking all nameservers.
>>>>
>>>> http://www.dnsstuff.com/tools is very helpful for a complete DNS
>>>> report, and the IP section may go even further, checking all paths
>>>> of all nameservers.
>>>
>>>
>>> Reverse IP resolution uses different servers than name resolution,
>>> and I had problems due to different configurations on reverse IP
>>> nameservers, and that problem was only towards a specific server
>>> which was making a paranoic control.
>>>
>>> Regards,
>>>
>>> Tonino
>>>
>>>
>>>
>>>>
>>>> Regards,
>>>>
>>>> Tonino
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------------------------------------------
>>>>>> ***@zioni Interazioni di Antonio Nati
>>>>>> http://www.interazioni.it ***@interazioni.it
>>>>>> ------------------------------------------------------------
>>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------------------------------------------
>>>> ***@zioni Interazioni di Antonio Nati
>>>> http://www.interazioni.it ***@interazioni.it
>>>> ------------------------------------------------------------
>>>
>>>
>>> --
>>> ------------------------------------------------------------
>>> ***@zioni Interazioni di Antonio Nati
>>> http://www.interazioni.it ***@interazioni.it
>>> ------------------------------------------------------------
>>
>> --
>> Check your DNS by putting an entry in your hosts file. If it
>> connects instantly you've found your problem.
>
>
> It would be useful it he could put this entry in the remote server :-)
> . In his server, this does not help in this case.
>
>
>
>
> --
> ------------------------------------------------------------
> ***@zioni Interazioni di Antonio Nati
> http://www.interazioni.it ***@interazioni.it
> ------------------------------------------------------------
Thanks all for your help in this. It seems that our respective sites
have Riverbed Optimization Systems (RiOS) in operation, one set to
optimize WAN traffic to other RiOSes, the other not. It was this
conflict between optimizing and not optimizing that was causing the problem.

Eric
Eric Shubert
2014-10-07 21:10:26 UTC
Permalink
On 10/07/2014 12:31 PM, Eric Broch wrote:
> On 10/4/2014 12:25 AM, Tonix - Antonio Nati wrote:
>> Il 02/10/2014 20:11, Cecil Yother, Jr. ha scritto:
>>>
>>> On 10/02/2014 10:19 AM, Tonix - Antonio Nati wrote:
>>>> Il 02/10/2014 19:16, Tonix - Antonio Nati ha scritto:
>>>>> Il 02/10/2014 18:52, Eric Broch ha scritto:
>>>>>> On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:
>>>>>>> Il 02/10/2014 18:02, Eric Broch ha scritto:
>>>>>>>> On 10/2/2014 9:10 AM, Eric Broch wrote:
>>>>>>>>> On 10/2/2014 8:30 AM, Bharath Chari wrote:
>>>>>>>>>> On 10/02/2014 04:59 PM, Eric Broch wrote:
>>>>>>>>>>> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>>>>>>>>>>>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>>>>>>>>>>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>>>>>>>>>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>>>>>>>>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>>>>>>>>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>>>>>>>>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I
>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I
>>>>>>>>>>>>>>> suppose.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Still, the other end should have replied to your 220 message
>>>>>>>>>>>>>>> before 58
>>>>>>>>>>>>>>> seconds elapsed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I wonder if there's a routing table misconfigured somewhere along
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> way. I've seen instances where an errant routing table entry can
>>>>>>>>>>>>>>> cause
>>>>>>>>>>>>>>> every nth packet to get dropped along the way. Are you seeing
>>>>>>>>>>>>>>> reliable
>>>>>>>>>>>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>>>>>>>>>>>> and there's also a network problem somewhere along the way.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Again, just a guess.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>>>>>>>>>>>> helping out. Thanks guys!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>>>>>>>>>>>> longer. I don't think spamdyke is closing the session as my
>>>>>>>>>>>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>>>>>>>>>>>> mine so high. While telnet(ing) to their host on port 25 initially
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> it is 'trying' to connect, I can open another terminal and run the
>>>>>>>>>>>>>> same
>>>>>>>>>>>>>> telnet command and I'll get their greeting right away.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree, their host should have replied faster than 58 seconds after
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>>>>>>>>>>>> There
>>>>>>>>>>>>>> host does not have ICMP protocol turned on. I could ask them to do
>>>>>>>>>>>>>> so.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>> terminating the connection?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks hardly required. The problem still remains :(
>>>>>>>>>>>>> OK, since you're having a problem even when doing a RAW telnet (the
>>>>>>>>>>>>> initial connection), the MTA related issue can be ruled out for now.
>>>>>>>>>>>>> However, it would be great if you could telnet from ANOTHER network
>>>>>>>>>>>>> and see if the pattern remains the same (of the initial connection
>>>>>>>>>>>>> being slow, and the next connection being fast).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>>>>>>>>>>>> lookup related issues.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bharath
>>>>>>>>>>>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>>>>>>>>>>>> itself?
>>>>>>>>>>>>
>>>>>>>>>>>> Bharath
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>>>
>>>>>>>>>>> Bharath,
>>>>>>>>>>>
>>>>>>>>>>> And, also, it doesn't matter whether I use the hostname of the IP
>>>>>>>>>>> Address same results.
>>>>>>>>>>>
>>>>>>>>>>> I can telnet on port 25 to the problem host from [an]other location(s)
>>>>>>>>>>> and it works just fine.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> There you go. There's probably nothing you can do from your end - it's
>>>>>>>>>> most likely a firewall at their end. However, as a last ditch test,
>>>>>>>>>> can you also try to telnet to port 25 on their mail server from
>>>>>>>>>> ANOTHER machine on the same network as the QMT machine.
>>>>>>>>>>
>>>>>>>>>> Wishing you the best :)
>>>>>>>>>>
>>>>>>>>>> Bharath
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>
>>>>>>>>> Thanks again, Bharath
>>>>>>>>>
>>>>>>>>> I've done that too (from ANOTHER machine on the same network) with the
>>>>>>>>> same results--delay or no connection at all.
>>>>>>>>>
>>>>>>>>> Eric
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>
>>>>>>>> Hi Bharath,
>>>>>>>>
>>>>>>>> I just received an email from the problematic mx host's IT department.
>>>>>>>> They've done a test with SmtpDiag from their mx host and they cannot
>>>>>>>> connect to our mx host from their side either.
>>>>>>>>
>>>>>>>> Eric
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>
>>>>>>>
>>>>>> Tonino,
>>>>>>> I suppose all your network comes out using the same IP, or more
>>>>>>> IP which are mapped to same domain.
>>>>>> Yes. On our end we have a NAT(ed) firewall. We also have an MPLS
>>>>>> circuit for certain private address ranges on the WAN interface.
>>>>>>>
>>>>>>> Check if you have reverse IP issues...
>>>>>> Reverse DNS checks out Okay on both ends.
>>>>>>>
>>>>>>> You have the IP address which is connecting to external exchange
>>>>>>> server.
>>>>>>> That IP should match the IP of the name declared in HELO (o EHLO).
>>>>>> There seems to be a Sonicwall email security appliance on their
>>>>>> end between our hosts--which, I think, may be the problem--which
>>>>>> has a name different than their MX record.
>>>>>>>
>>>>>>> Check also if name associated with that IP corresponds to HELO
>>>>>>> name (some servers are making paranoic controls).
>>>>>> The name associated with the IP on their end is different than the
>>>>>> response of the HELO command.
>>>>>
>>>>> This could be a potential problem for them, because some senders
>>>>> could refuse to send, but this is another story.
>>>>>
>>>>>
>>>>>
>>>>> What makes me think is the fact their answer to your telnet is very
>>>>> slow from your network, but fast from other networks.
>>>>>
>>>>> I'continue checking if it is a DNS issue.
>>>>>
>>>>> Please double checK: your external IP to name, then again name to
>>>>> IP, checking all nameservers.
>>>>>
>>>>> http://www.dnsstuff.com/tools is very helpful for a complete DNS
>>>>> report, and the IP section may go even further, checking all paths
>>>>> of all nameservers.
>>>>
>>>>
>>>> Reverse IP resolution uses different servers than name resolution,
>>>> and I had problems due to different configurations on reverse IP
>>>> nameservers, and that problem was only towards a specific server
>>>> which was making a paranoic control.
>>>>
>>>> Regards,
>>>>
>>>> Tonino
>>>>
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Tonino
>>>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------------------------------------------
>>>>>>> ***@zioni Interazioni di Antonio Nati
>>>>>>> http://www.interazioni.it ***@interazioni.it
>>>>>>> ------------------------------------------------------------
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------------------------------------------
>>>>> ***@zioni Interazioni di Antonio Nati
>>>>> http://www.interazioni.it ***@interazioni.it
>>>>> ------------------------------------------------------------
>>>>
>>>>
>>>> --
>>>> ------------------------------------------------------------
>>>> ***@zioni Interazioni di Antonio Nati
>>>> http://www.interazioni.it ***@interazioni.it
>>>> ------------------------------------------------------------
>>>
>>> --
>>> Check your DNS by putting an entry in your hosts file. If it
>>> connects instantly you've found your problem.
>>
>>
>> It would be useful it he could put this entry in the remote server :-)
>> . In his server, this does not help in this case.
>>
>>
>>
>>
>> --
>> ------------------------------------------------------------
>> ***@zioni Interazioni di Antonio Nati
>> http://www.interazioni.it ***@interazioni.it
>> ------------------------------------------------------------
> Thanks all for your help in this. It seems that our respective sites
> have Riverbed Optimization Systems (RiOS) in operation, one set to
> optimize WAN traffic to other RiOSes, the other not. It was this
> conflict between optimizing and not optimizing that was causing the problem.
>
> Eric

aHa!
Thanks for the update EricB. Good to know!

--
-Eric 'shubes'


---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
Tonix - Antonio Nati
2014-10-08 07:26:28 UTC
Permalink
Il 07/10/2014 21:31, Eric Broch ha scritto:
> On 10/4/2014 12:25 AM, Tonix - Antonio Nati wrote:
>> Il 02/10/2014 20:11, Cecil Yother, Jr. ha scritto:
>>>
>>> On 10/02/2014 10:19 AM, Tonix - Antonio Nati wrote:
>>>> Il 02/10/2014 19:16, Tonix - Antonio Nati ha scritto:
>>>>> Il 02/10/2014 18:52, Eric Broch ha scritto:
>>>>>> On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:
>>>>>>> Il 02/10/2014 18:02, Eric Broch ha scritto:
>>>>>>>> On 10/2/2014 9:10 AM, Eric Broch wrote:
>>>>>>>>> On 10/2/2014 8:30 AM, Bharath Chari wrote:
>>>>>>>>>> On 10/02/2014 04:59 PM, Eric Broch wrote:
>>>>>>>>>>> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>>>>>>>>>>>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>>>>>>>>>>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>>>>>>>>>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>>>>>>>>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>>>>>>>>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>>>>>>>>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I
>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I
>>>>>>>>>>>>>>> suppose.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Still, the other end should have replied to your 220 message
>>>>>>>>>>>>>>> before 58
>>>>>>>>>>>>>>> seconds elapsed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I wonder if there's a routing table misconfigured somewhere along
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> way. I've seen instances where an errant routing table entry can
>>>>>>>>>>>>>>> cause
>>>>>>>>>>>>>>> every nth packet to get dropped along the way. Are you seeing
>>>>>>>>>>>>>>> reliable
>>>>>>>>>>>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>>>>>>>>>>>> and there's also a network problem somewhere along the way.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Again, just a guess.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>>>>>>>>>>>> helping out. Thanks guys!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>>>>>>>>>>>> longer. I don't think spamdyke is closing the session as my
>>>>>>>>>>>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>>>>>>>>>>>> mine so high. While telnet(ing) to their host on port 25 initially
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> it is 'trying' to connect, I can open another terminal and run the
>>>>>>>>>>>>>> same
>>>>>>>>>>>>>> telnet command and I'll get their greeting right away.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree, their host should have replied faster than 58 seconds after
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>>>>>>>>>>>> There
>>>>>>>>>>>>>> host does not have ICMP protocol turned on. I could ask them to do
>>>>>>>>>>>>>> so.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>> terminating the connection?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks hardly required. The problem still remains :(
>>>>>>>>>>>>> OK, since you're having a problem even when doing a RAW telnet (the
>>>>>>>>>>>>> initial connection), the MTA related issue can be ruled out for now.
>>>>>>>>>>>>> However, it would be great if you could telnet from ANOTHER network
>>>>>>>>>>>>> and see if the pattern remains the same (of the initial connection
>>>>>>>>>>>>> being slow, and the next connection being fast).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>>>>>>>>>>>> lookup related issues.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bharath
>>>>>>>>>>>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>>>>>>>>>>>> itself?
>>>>>>>>>>>>
>>>>>>>>>>>> Bharath
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>>>
>>>>>>>>>>> Bharath,
>>>>>>>>>>>
>>>>>>>>>>> And, also, it doesn't matter whether I use the hostname of the IP
>>>>>>>>>>> Address same results.
>>>>>>>>>>>
>>>>>>>>>>> I can telnet on port 25 to the problem host from [an]other location(s)
>>>>>>>>>>> and it works just fine.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> There you go. There's probably nothing you can do from your end - it's
>>>>>>>>>> most likely a firewall at their end. However, as a last ditch test,
>>>>>>>>>> can you also try to telnet to port 25 on their mail server from
>>>>>>>>>> ANOTHER machine on the same network as the QMT machine.
>>>>>>>>>>
>>>>>>>>>> Wishing you the best :)
>>>>>>>>>>
>>>>>>>>>> Bharath
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>
>>>>>>>>> Thanks again, Bharath
>>>>>>>>>
>>>>>>>>> I've done that too (from ANOTHER machine on the same network) with the
>>>>>>>>> same results--delay or no connection at all.
>>>>>>>>>
>>>>>>>>> Eric
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>
>>>>>>>> Hi Bharath,
>>>>>>>>
>>>>>>>> I just received an email from the problematic mx host's IT department.
>>>>>>>> They've done a test with SmtpDiag from their mx host and they cannot
>>>>>>>> connect to our mx host from their side either.
>>>>>>>>
>>>>>>>> Eric
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>
>>>>>>>
>>>>>> Tonino,
>>>>>>> I suppose all your network comes out using the same IP, or more
>>>>>>> IP which are mapped to same domain.
>>>>>> Yes. On our end we have a NAT(ed) firewall. We also have an MPLS
>>>>>> circuit for certain private address ranges on the WAN interface.
>>>>>>>
>>>>>>> Check if you have reverse IP issues...
>>>>>> Reverse DNS checks out Okay on both ends.
>>>>>>>
>>>>>>> You have the IP address which is connecting to external exchange
>>>>>>> server.
>>>>>>> That IP should match the IP of the name declared in HELO (o EHLO).
>>>>>> There seems to be a Sonicwall email security appliance on their
>>>>>> end between our hosts--which, I think, may be the problem--which
>>>>>> has a name different than their MX record.
>>>>>>>
>>>>>>> Check also if name associated with that IP corresponds to HELO
>>>>>>> name (some servers are making paranoic controls).
>>>>>> The name associated with the IP on their end is different than
>>>>>> the response of the HELO command.
>>>>>
>>>>> This could be a potential problem for them, because some senders
>>>>> could refuse to send, but this is another story.
>>>>>
>>>>>
>>>>>
>>>>> What makes me think is the fact their answer to your telnet is
>>>>> very slow from your network, but fast from other networks.
>>>>>
>>>>> I'continue checking if it is a DNS issue.
>>>>>
>>>>> Please double checK: your external IP to name, then again name to
>>>>> IP, checking all nameservers.
>>>>>
>>>>> http://www.dnsstuff.com/tools is very helpful for a complete DNS
>>>>> report, and the IP section may go even further, checking all paths
>>>>> of all nameservers.
>>>>
>>>>
>>>> Reverse IP resolution uses different servers than name resolution,
>>>> and I had problems due to different configurations on reverse IP
>>>> nameservers, and that problem was only towards a specific server
>>>> which was making a paranoic control.
>>>>
>>>> Regards,
>>>>
>>>> Tonino
>>>>
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Tonino
>>>>>
>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------------------------------------------
>>>>>>> ***@zioni Interazioni di Antonio Nati
>>>>>>> http://www.interazioni.it ***@interazioni.it
>>>>>>> ------------------------------------------------------------
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------------------------------------------
>>>>> ***@zioni Interazioni di Antonio Nati
>>>>> http://www.interazioni.it ***@interazioni.it
>>>>> ------------------------------------------------------------
>>>>
>>>>
>>>> --
>>>> ------------------------------------------------------------
>>>> ***@zioni Interazioni di Antonio Nati
>>>> http://www.interazioni.it ***@interazioni.it
>>>> ------------------------------------------------------------
>>>
>>> --
>>> Check your DNS by putting an entry in your hosts file. If it
>>> connects instantly you've found your problem.
>>
>>
>> It would be useful it he could put this entry in the remote server
>> :-) . In his server, this does not help in this case.
>>
>>
>>
>>
>> --
>> ------------------------------------------------------------
>> ***@zioni Interazioni di Antonio Nati
>> http://www.interazioni.it ***@interazioni.it
>> ------------------------------------------------------------
> Thanks all for your help in this. It seems that our respective sites
> have Riverbed Optimization Systems (RiOS) in operation, one set to
> optimize WAN traffic to other RiOSes, the other not. It was this
> conflict between optimizing and not optimizing that was causing the
> problem.

Which was the practical effect of this misconfiguration? Wrong IP routing?

Regards,

Tonino


>
> Eric


--
------------------------------------------------------------
***@zioni Interazioni di Antonio Nati
http://www.interazioni.it ***@interazioni.it
------------------------------------------------------------
Eric Broch
2014-10-08 13:04:34 UTC
Permalink
On 10/8/2014 1:26 AM, Tonix - Antonio Nati wrote:
> Il 07/10/2014 21:31, Eric Broch ha scritto:
>> On 10/4/2014 12:25 AM, Tonix - Antonio Nati wrote:
>>> Il 02/10/2014 20:11, Cecil Yother, Jr. ha scritto:
>>>>
>>>> On 10/02/2014 10:19 AM, Tonix - Antonio Nati wrote:
>>>>> Il 02/10/2014 19:16, Tonix - Antonio Nati ha scritto:
>>>>>> Il 02/10/2014 18:52, Eric Broch ha scritto:
>>>>>>> On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:
>>>>>>>> Il 02/10/2014 18:02, Eric Broch ha scritto:
>>>>>>>>> On 10/2/2014 9:10 AM, Eric Broch wrote:
>>>>>>>>>> On 10/2/2014 8:30 AM, Bharath Chari wrote:
>>>>>>>>>>> On 10/02/2014 04:59 PM, Eric Broch wrote:
>>>>>>>>>>>> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>>>>>>>>>>>>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>>>>>>>>>>>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>>>>>>>>>>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>>>>>>>>>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>>>>>>>>>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>>>>>>>>>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I
>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I
>>>>>>>>>>>>>>>> suppose.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Still, the other end should have replied to your 220 message
>>>>>>>>>>>>>>>> before 58
>>>>>>>>>>>>>>>> seconds elapsed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I wonder if there's a routing table misconfigured somewhere along
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> way. I've seen instances where an errant routing table entry can
>>>>>>>>>>>>>>>> cause
>>>>>>>>>>>>>>>> every nth packet to get dropped along the way. Are you seeing
>>>>>>>>>>>>>>>> reliable
>>>>>>>>>>>>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>>>>>>>>>>>>> and there's also a network problem somewhere along the way.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Again, just a guess.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>>>>>>>>>>>>> helping out. Thanks guys!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>>>>>>>>>>>>> longer. I don't think spamdyke is closing the session as my
>>>>>>>>>>>>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>>>>>>>>>>>>> mine so high. While telnet(ing) to their host on port 25 initially
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> it is 'trying' to connect, I can open another terminal and run the
>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>> telnet command and I'll get their greeting right away.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I agree, their host should have replied faster than 58 seconds after
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>>>>>>>>>>>>> There
>>>>>>>>>>>>>>> host does not have ICMP protocol turned on. I could ask them to do
>>>>>>>>>>>>>>> so.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>> terminating the connection?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks hardly required. The problem still remains :(
>>>>>>>>>>>>>> OK, since you're having a problem even when doing a RAW telnet (the
>>>>>>>>>>>>>> initial connection), the MTA related issue can be ruled out for now.
>>>>>>>>>>>>>> However, it would be great if you could telnet from ANOTHER network
>>>>>>>>>>>>>> and see if the pattern remains the same (of the initial connection
>>>>>>>>>>>>>> being slow, and the next connection being fast).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>>>>>>>>>>>>> lookup related issues.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Bharath
>>>>>>>>>>>>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>>>>>>>>>>>>> itself?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bharath
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>>>>
>>>>>>>>>>>> Bharath,
>>>>>>>>>>>>
>>>>>>>>>>>> And, also, it doesn't matter whether I use the hostname of the IP
>>>>>>>>>>>> Address same results.
>>>>>>>>>>>>
>>>>>>>>>>>> I can telnet on port 25 to the problem host from [an]other location(s)
>>>>>>>>>>>> and it works just fine.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> There you go. There's probably nothing you can do from your end - it's
>>>>>>>>>>> most likely a firewall at their end. However, as a last ditch test,
>>>>>>>>>>> can you also try to telnet to port 25 on their mail server from
>>>>>>>>>>> ANOTHER machine on the same network as the QMT machine.
>>>>>>>>>>>
>>>>>>>>>>> Wishing you the best :)
>>>>>>>>>>>
>>>>>>>>>>> Bharath
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>>
>>>>>>>>>> Thanks again, Bharath
>>>>>>>>>>
>>>>>>>>>> I've done that too (from ANOTHER machine on the same network) with the
>>>>>>>>>> same results--delay or no connection at all.
>>>>>>>>>>
>>>>>>>>>> Eric
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>
>>>>>>>>> Hi Bharath,
>>>>>>>>>
>>>>>>>>> I just received an email from the problematic mx host's IT department.
>>>>>>>>> They've done a test with SmtpDiag from their mx host and they cannot
>>>>>>>>> connect to our mx host from their side either.
>>>>>>>>>
>>>>>>>>> Eric
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>> For additional commands, e-mail: qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>
>>>>>>>>
>>>>>>> Tonino,
>>>>>>>> I suppose all your network comes out using the same IP, or more
>>>>>>>> IP which are mapped to same domain.
>>>>>>> Yes. On our end we have a NAT(ed) firewall. We also have an MPLS
>>>>>>> circuit for certain private address ranges on the WAN interface.
>>>>>>>>
>>>>>>>> Check if you have reverse IP issues...
>>>>>>> Reverse DNS checks out Okay on both ends.
>>>>>>>>
>>>>>>>> You have the IP address which is connecting to external
>>>>>>>> exchange server.
>>>>>>>> That IP should match the IP of the name declared in HELO (o EHLO).
>>>>>>> There seems to be a Sonicwall email security appliance on their
>>>>>>> end between our hosts--which, I think, may be the problem--which
>>>>>>> has a name different than their MX record.
>>>>>>>>
>>>>>>>> Check also if name associated with that IP corresponds to HELO
>>>>>>>> name (some servers are making paranoic controls).
>>>>>>> The name associated with the IP on their end is different than
>>>>>>> the response of the HELO command.
>>>>>>
>>>>>> This could be a potential problem for them, because some senders
>>>>>> could refuse to send, but this is another story.
>>>>>>
>>>>>>
>>>>>>
>>>>>> What makes me think is the fact their answer to your telnet is
>>>>>> very slow from your network, but fast from other networks.
>>>>>>
>>>>>> I'continue checking if it is a DNS issue.
>>>>>>
>>>>>> Please double checK: your external IP to name, then again name to
>>>>>> IP, checking all nameservers.
>>>>>>
>>>>>> http://www.dnsstuff.com/tools is very helpful for a complete DNS
>>>>>> report, and the IP section may go even further, checking all
>>>>>> paths of all nameservers.
>>>>>
>>>>>
>>>>> Reverse IP resolution uses different servers than name resolution,
>>>>> and I had problems due to different configurations on reverse IP
>>>>> nameservers, and that problem was only towards a specific server
>>>>> which was making a paranoic control.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Tonino
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Tonino
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ------------------------------------------------------------
>>>>>>>> ***@zioni Interazioni di Antonio Nati
>>>>>>>> http://www.interazioni.it ***@interazioni.it
>>>>>>>> ------------------------------------------------------------
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------------------------------------------
>>>>>> ***@zioni Interazioni di Antonio Nati
>>>>>> http://www.interazioni.it ***@interazioni.it
>>>>>> ------------------------------------------------------------
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------------------------------------------
>>>>> ***@zioni Interazioni di Antonio Nati
>>>>> http://www.interazioni.it ***@interazioni.it
>>>>> ------------------------------------------------------------
>>>>
>>>> --
>>>> Check your DNS by putting an entry in your hosts file. If it
>>>> connects instantly you've found your problem.
>>>
>>>
>>> It would be useful it he could put this entry in the remote server
>>> :-) . In his server, this does not help in this case.
>>>
>>>
>>>
>>>
>>> --
>>> ------------------------------------------------------------
>>> ***@zioni Interazioni di Antonio Nati
>>> http://www.interazioni.it ***@interazioni.it
>>> ------------------------------------------------------------
>> Thanks all for your help in this. It seems that our respective sites
>> have Riverbed Optimization Systems (RiOS) in operation, one set to
>> optimize WAN traffic to other RiOSes, the other not. It was this
>> conflict between optimizing and not optimizing that was causing the
>> problem.
>
> Which was the practical effect of this misconfiguration? Wrong IP routing?
>
> Regards,
>
> Tonino
>
If I understand your question, there was no issue with routing. Simply,
the other site had their RiOS set to opportunistically (with respect to
other RiOSes) compress (optimize) internet traffic. In other words, they
are sending traffic to us in a compressed state and we are sending
traffic to them in an uncompressed state. When our device received their
compressed traffic it was dropped, as it was not configured to receive
compressed traffic across the internet--it was configured only to
receive data in its normal state across the internet.

As it turns out, it is normal practice to NOT compress traffic to other
sites with RiOSes unless arrangements are made to do so. Their changing
this setting, whether through firmware upgrade or otherwise, is what
caused the problem as we WERE sending and receiving email with no problems.
>
>>
>> Eric
>
>
> --
> ------------------------------------------------------------
> ***@zioni Interazioni di Antonio Nati
> http://www.interazioni.it ***@interazioni.it
> ------------------------------------------------------------
Tonix - Antonio Nati
2014-10-08 14:41:41 UTC
Permalink
Il 08/10/2014 15:04, Eric Broch ha scritto:
> On 10/8/2014 1:26 AM, Tonix - Antonio Nati wrote:
>> Il 07/10/2014 21:31, Eric Broch ha scritto:
>>> On 10/4/2014 12:25 AM, Tonix - Antonio Nati wrote:
>>>> Il 02/10/2014 20:11, Cecil Yother, Jr. ha scritto:
>>>>>
>>>>> On 10/02/2014 10:19 AM, Tonix - Antonio Nati wrote:
>>>>>> Il 02/10/2014 19:16, Tonix - Antonio Nati ha scritto:
>>>>>>> Il 02/10/2014 18:52, Eric Broch ha scritto:
>>>>>>>> On 10/2/2014 10:29 AM, Tonix - Antonio Nati wrote:
>>>>>>>>> Il 02/10/2014 18:02, Eric Broch ha scritto:
>>>>>>>>>> On 10/2/2014 9:10 AM, Eric Broch wrote:
>>>>>>>>>>> On 10/2/2014 8:30 AM, Bharath Chari wrote:
>>>>>>>>>>>> On 10/02/2014 04:59 PM, Eric Broch wrote:
>>>>>>>>>>>>> On 10/2/2014 1:32 AM, Bharath Chari wrote:
>>>>>>>>>>>>>> On 09/25/2014 06:44 PM, Bharath Chari wrote:
>>>>>>>>>>>>>>> On 09/25/2014 05:50 PM, Eric Broch wrote:
>>>>>>>>>>>>>>>> Hmmmm. Is it always exactly one minute from begin to end? That would
>>>>>>>>>>>>>>>>> appear to indicate some timer cutting out. It could be spamdyke
>>>>>>>>>>>>>>>>> closing the session depending on your idle-timeout-secs= value. I'm
>>>>>>>>>>>>>>>>> guessing 60, which is probably ok. I've upped mine to 180, and I
>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>> recall exactly why I did that. Wouldn't hurt to bump it up I
>>>>>>>>>>>>>>>>> suppose.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Still, the other end should have replied to your 220 message
>>>>>>>>>>>>>>>>> before 58
>>>>>>>>>>>>>>>>> seconds elapsed.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I wonder if there's a routing table misconfigured somewhere along
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> way. I've seen instances where an errant routing table entry can
>>>>>>>>>>>>>>>>> cause
>>>>>>>>>>>>>>>>> every nth packet to get dropped along the way. Are you seeing
>>>>>>>>>>>>>>>>> reliable
>>>>>>>>>>>>>>>>> pings over a period of a minute or so? If not, I'd suspect a network
>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> At this point, I'd guess that QMT may be terminating a little soon,
>>>>>>>>>>>>>>>>> and there's also a network problem somewhere along the way.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Again, just a guess.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> P.S. Nice to see such accomplished people as Tonino and Bharath
>>>>>>>>>>>>>>>>> helping out. Thanks guys!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, it is not always one minute, sometimes it is up to thirty seconds
>>>>>>>>>>>>>>>> longer. I don't think spamdyke is closing the session as my
>>>>>>>>>>>>>>>> idle-timeout-secs is set to 480, and I don't recall either why I set
>>>>>>>>>>>>>>>> mine so high. While telnet(ing) to their host on port 25 initially
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> it is 'trying' to connect, I can open another terminal and run the
>>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>> telnet command and I'll get their greeting right away.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I agree, their host should have replied faster than 58 seconds after
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> SMTP greeting, unless the greeting is never getting to there host.
>>>>>>>>>>>>>>>> There
>>>>>>>>>>>>>>>> host does not have ICMP protocol turned on. I could ask them to do
>>>>>>>>>>>>>>>> so.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If I have spamdyke set to terminate after 480 seconds what else
>>>>>>>>>>>>>>>> would be
>>>>>>>>>>>>>>>> terminating the connection?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And, ditto. Thanks for the help Tonino and Bharath!!!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks hardly required. The problem still remains :(
>>>>>>>>>>>>>>> OK, since you're having a problem even when doing a RAW telnet (the
>>>>>>>>>>>>>>> initial connection), the MTA related issue can be ruled out for now.
>>>>>>>>>>>>>>> However, it would be great if you could telnet from ANOTHER network
>>>>>>>>>>>>>>> and see if the pattern remains the same (of the initial connection
>>>>>>>>>>>>>>> being slow, and the next connection being fast).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Are you doing the telnet using IP or hostname? Let's rule out DNS
>>>>>>>>>>>>>>> lookup related issues.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Bharath
>>>>>>>>>>>>>> @Eric Broch: Curious to know how this issue panned out. Did it resolve
>>>>>>>>>>>>>> itself?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Bharath
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>> qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Bharath,
>>>>>>>>>>>>>
>>>>>>>>>>>>> And, also, it doesn't matter whether I use the hostname of the IP
>>>>>>>>>>>>> Address same results.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can telnet on port 25 to the problem host from [an]other location(s)
>>>>>>>>>>>>> and it works just fine.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> There you go. There's probably nothing you can do from your end - it's
>>>>>>>>>>>> most likely a firewall at their end. However, as a last ditch test,
>>>>>>>>>>>> can you also try to telnet to port 25 on their mail server from
>>>>>>>>>>>> ANOTHER machine on the same network as the QMT machine.
>>>>>>>>>>>>
>>>>>>>>>>>> Wishing you the best :)
>>>>>>>>>>>>
>>>>>>>>>>>> Bharath
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>>>
>>>>>>>>>>> Thanks again, Bharath
>>>>>>>>>>>
>>>>>>>>>>> I've done that too (from ANOTHER machine on the same network) with the
>>>>>>>>>>> same results--delay or no connection at all.
>>>>>>>>>>>
>>>>>>>>>>> Eric
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>>
>>>>>>>>>> Hi Bharath,
>>>>>>>>>>
>>>>>>>>>> I just received an email from the problematic mx host's IT department.
>>>>>>>>>> They've done a test with SmtpDiag from their mx host and they cannot
>>>>>>>>>> connect to our mx host from their side either.
>>>>>>>>>>
>>>>>>>>>> Eric
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>> For additional commands, e-mail:qmailtoaster-list-***@qmailtoaster.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> Tonino,
>>>>>>>>> I suppose all your network comes out using the same IP, or
>>>>>>>>> more IP which are mapped to same domain.
>>>>>>>> Yes. On our end we have a NAT(ed) firewall. We also have an
>>>>>>>> MPLS circuit for certain private address ranges on the WAN
>>>>>>>> interface.
>>>>>>>>>
>>>>>>>>> Check if you have reverse IP issues...
>>>>>>>> Reverse DNS checks out Okay on both ends.
>>>>>>>>>
>>>>>>>>> You have the IP address which is connecting to external
>>>>>>>>> exchange server.
>>>>>>>>> That IP should match the IP of the name declared in HELO (o EHLO).
>>>>>>>> There seems to be a Sonicwall email security appliance on their
>>>>>>>> end between our hosts--which, I think, may be the
>>>>>>>> problem--which has a name different than their MX record.
>>>>>>>>>
>>>>>>>>> Check also if name associated with that IP corresponds to HELO
>>>>>>>>> name (some servers are making paranoic controls).
>>>>>>>> The name associated with the IP on their end is different than
>>>>>>>> the response of the HELO command.
>>>>>>>
>>>>>>> This could be a potential problem for them, because some senders
>>>>>>> could refuse to send, but this is another story.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> What makes me think is the fact their answer to your telnet is
>>>>>>> very slow from your network, but fast from other networks.
>>>>>>>
>>>>>>> I'continue checking if it is a DNS issue.
>>>>>>>
>>>>>>> Please double checK: your external IP to name, then again name
>>>>>>> to IP, checking all nameservers.
>>>>>>>
>>>>>>> http://www.dnsstuff.com/tools is very helpful for a complete DNS
>>>>>>> report, and the IP section may go even further, checking all
>>>>>>> paths of all nameservers.
>>>>>>
>>>>>>
>>>>>> Reverse IP resolution uses different servers than name
>>>>>> resolution, and I had problems due to different configurations on
>>>>>> reverse IP nameservers, and that problem was only towards a
>>>>>> specific server which was making a paranoic control.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Tonino
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Tonino
>>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>> ***@zioni Interazioni di Antonio Nati
>>>>>>>>> http://www.interazioni.it ***@interazioni.it
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------------------------------------------
>>>>>>> ***@zioni Interazioni di Antonio Nati
>>>>>>> http://www.interazioni.it ***@interazioni.it
>>>>>>> ------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------------------------------------------
>>>>>> ***@zioni Interazioni di Antonio Nati
>>>>>> http://www.interazioni.it ***@interazioni.it
>>>>>> ------------------------------------------------------------
>>>>>
>>>>> --
>>>>> Check your DNS by putting an entry in your hosts file. If it
>>>>> connects instantly you've found your problem.
>>>>
>>>>
>>>> It would be useful it he could put this entry in the remote server
>>>> :-) . In his server, this does not help in this case.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------------------------------------------
>>>> ***@zioni Interazioni di Antonio Nati
>>>> http://www.interazioni.it ***@interazioni.it
>>>> ------------------------------------------------------------
>>> Thanks all for your help in this. It seems that our respective sites
>>> have Riverbed Optimization Systems (RiOS) in operation, one set to
>>> optimize WAN traffic to other RiOSes, the other not. It was this
>>> conflict between optimizing and not optimizing that was causing the
>>> problem.
>>
>> Which was the practical effect of this misconfiguration? Wrong IP
>> routing?
>>
>> Regards,
>>
>> Tonino
>>
> If I understand your question, there was no issue with routing.
> Simply, the other site had their RiOS set to opportunistically (with
> respect to other RiOSes) compress (optimize) internet traffic. In
> other words, they are sending traffic to us in a compressed state and
> we are sending traffic to them in an uncompressed state. When our
> device received their compressed traffic it was dropped, as it was not
> configured to receive compressed traffic across the internet--it was
> configured only to receive data in its normal state across the internet.
>
> As it turns out, it is normal practice to NOT compress traffic to
> other sites with RiOSes unless arrangements are made to do so. Their
> changing this setting, whether through firmware upgrade or otherwise,
> is what caused the problem as we WERE sending and receiving email with
> no problems.

Ok, thank you a lot. So, finally, the problem was something completely
outside of our suggestions. :-)

Regards,

Tonino


>>
>>>
>>> Eric
>>
>>
>> --
>> ------------------------------------------------------------
>> ***@zioni Interazioni di Antonio Nati
>> http://www.interazioni.it ***@interazioni.it
>> ------------------------------------------------------------
>


--
------------------------------------------------------------
***@zioni Interazioni di Antonio Nati
http://www.interazioni.it ***@interazioni.it
------------------------------------------------------------
Bharath Chari
2014-10-08 07:38:43 UTC
Permalink
On 10/07/2014 10:31 PM, Eric Broch wrote:
> ------------------------------------------------------------
>>>
>>> --
>>> Check your DNS by putting an entry in your hosts file. If it
>>> connects instantly you've found your problem.
>>
>>
>> It would be useful it he could put this entry in the remote server
>> :-) . In his server, this does not help in this case.
>>
>>
>>
>>
>> --
>> ------------------------------------------------------------
>> ***@zioni Interazioni di Antonio Nati
>> http://www.interazioni.it ***@interazioni.it
>> ------------------------------------------------------------
> Thanks all for your help in this. It seems that our respective sites
> have Riverbed Optimization Systems (RiOS) in operation, one set to
> optimize WAN traffic to other RiOSes, the other not. It was this
> conflict between optimizing and not optimizing that was causing the
> problem.
>
> Eric
Glad it worked out. I really doubt if we would have come up with this as
the cause of the problem :)

Bharath
Eric Broch
2014-10-08 12:18:42 UTC
Permalink
On 10/8/2014 1:38 AM, Bharath Chari wrote:
> On 10/07/2014 10:31 PM, Eric Broch wrote:
>> ------------------------------------------------------------
>>>>
>>>> --
>>>> Check your DNS by putting an entry in your hosts file. If it
>>>> connects instantly you've found your problem.
>>>
>>>
>>> It would be useful it he could put this entry in the remote server
>>> :-) . In his server, this does not help in this case.
>>>
>>>
>>>
>>>
>>> --
>>> ------------------------------------------------------------
>>> ***@zioni Interazioni di Antonio Nati
>>> http://www.interazioni.it ***@interazioni.it
>>> ------------------------------------------------------------
>> Thanks all for your help in this. It seems that our respective sites
>> have Riverbed Optimization Systems (RiOS) in operation, one set to
>> optimize WAN traffic to other RiOSes, the other not. It was this
>> conflict between optimizing and not optimizing that was causing the
>> problem.
>>
>> Eric
> Glad it worked out. I really doubt if we would have come up with this
> as the cause of the problem :)
>
> Bharath
>
Thanks! None the less, you guys helped in the process of elimination.
Loading...