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