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: >>>>>> [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... > > 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: [email protected] >>> For additional commands, e-mail: >>> [email protected] >>> >> >> > > Thanks Tonino, I don't think it our side either.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
