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: >>>>>>> [email protected] >>>>>>> For additional commands, e-mail: >>>>>>> [email protected] >>>>>>> >>>>>> 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: >>>>>> [email protected] >>>>>> For additional commands, e-mail: >>>>>> [email protected] >>>>>> >>>>> >>>> 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: [email protected] >>>> For additional commands, e-mail: >>>> [email protected] >>>> >>> >> 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: [email protected] For additional commands, e-mail: [email protected]
