Patrick - South Valley Internet wrote: > I added the +log to log_selector and had the guy send another email to > that address...
You need to go back further. Find the *start* of that transaction, It should resemble this (altered on a guess..); 2006-10-23 16:14:30 SMTP connection from [216.171.132.22]:29767 I=[<your IP>]:25 (TCP/IP connection count = 1) - track it to the end (below). If no details, go in and add lines such as: 'logwrite = H2 entering HELO verify test' where 'H2' is the second acl clause in acl_smtp_helo ... and 'log_message = H2 Failed HELO test delaying 3m30s Or whatever each acl clause is expected to do. Use a 'warn' verb just before and/or just after or the 'logwruites' if you ant them to be unconditional. The log_message will only appear when any conditional it shares a blanket with is turned-on. Once you have ID'ed the area where the problem is showing up, remove or comment-out the surplus messages, add extra detail, such as putting into the message: $sender_host_address To make it easier to grep the offending log lines. > > 2006-10-23 16:15:59 H=(ecsz5es46gil0q) [216.171.132.22] incomplete > transaction (RSET) from <[EMAIL PROTECTED]> for [EMAIL PROTECTED] > 2006-10-23 16:16:02 1Gc91W-0007Yq-LW <= [EMAIL PROTECTED] > H=(ecsz5es46gil0q) [216.171.132.22] P=smtp S=1275 > [EMAIL PROTECTED] T="RE: > RFQ" from <[EMAIL PROTECTED]> for [EMAIL PROTECTED] > 2006-10-23 16:16:04 1Gc91W-0007Yq-LW => [EMAIL PROTECTED] > F=<[EMAIL PROTECTED]> R=lookuphost T=remote_smtp S=1326 > H=mx1c7.megamailservers.com [69.49.109.34] C="250 2.0.0 k9NNGwFP027796 > Message accepted for delivery" > 2006-10-24 09:36:59 1GcPGs-0004ez-LA <= [EMAIL PROTECTED] > H=sequoia.garlic.com [216.139.0.84]:60107 I=[216.139.50.4]:25 P=esmtp > S=6358 [EMAIL PROTECTED] T="[Fwd: Warning: could not send > message for past 4 hours]" from <[EMAIL PROTECTED]> for > [EMAIL PROTECTED] > 2006-10-24 09:37:00 1GcPGs-0004ey-5G <= [EMAIL PROTECTED] > H=sequoia.garlic.com [216.139.0.84]:60104 I=[216.139.50.4]:25 P=esmtp > S=688886 [EMAIL PROTECTED] T="[Fwd: Warning: could not send > message for past 4 hours]" from <[EMAIL PROTECTED]> for > [EMAIL PROTECTED] > > I appended the +all to the beginning of the other variables for > log_selector - will that not output more detailed information if I leave > the other settings enabled? 'log_selector = +all' full stop. Keep It Simple (and) Stupid Move the customized stuff to another line and comment it out for now. > > Any ideas what might be going wrong? As always, thanks in advance! :) > > Patrick > > No new info yet. Turn up the logging and try again. Bill > > > W B Hacker wrote: > >> Patrick - South Valley Internet wrote: >> >> >> >>> Hello all, >>> >>> We are running DirectAdmin on one of our machines here, and we're >>> having issues with some mail not being delivered. I was just >>> notified of this today, and decided to tail the logs for 'incomplete >>> transaction', and came up with a bunch of them. I am mainly >>> concerned with the following two errors: >>> >>> 2006-10-23 12:31:46 H=(ecsz5es46gil0q) [216.171.132.22] incomplete >>> transaction (RSET) from <[EMAIL PROTECTED]> for [EMAIL PROTECTED] >>> 2006-10-23 16:15:59 H=(ecsz5es46gil0q) [216.171.132.22] incomplete >>> transaction (RSET) from <[EMAIL PROTECTED]> for [EMAIL PROTECTED] >>> >>> >> >> >> Host for 216.171.132.22 resolves to transedge-132-22.transedge.com. >> >> Incoming mail for royalcircuits.com is handled on a different host, >> not necessarily involved in outboud. >> >> No idea what HELO was used. >> >> Presuming no obfuscation, that looks suspiciously like an acl checking >> for forward/reverse lookup and/or HELO, not find what it wants, and >> the sending server going away mad when it is so informed. >> >> log_selector = +all - at least temporarily - might show you a good >> deal more. >> >> >> >>> Here are some from the log that don't have anything inside the 'from >>> <>': >>> >>> 2006-10-23 16:08:51 H=ns5.hostinghk.com [210.184.113.5] incomplete >>> transaction (QUIT) from <> >>> 2006-10-23 16:09:14 H=smtp.zie.pg.gda.pl [153.19.33.3] incomplete >>> transaction (RSET) from <> >>> 2006-10-23 16:09:20 H=elyria-ppp-32.eriecoast.com (friend) >>> [67.129.203.51] incomplete transaction (connection lost) from >>> <[EMAIL PROTECTED]> >>> 2006-10-23 16:09:41 H=janus.mcg.co.jp [61.199.158.67] incomplete >>> transaction (QUIT) from <> >>> 2006-10-23 16:10:07 H=apac.rqa-inc.com (MAIL.RQA-INC.COM) >>> [207.227.21.174] incomplete transaction (RSET) from <> >>> 2006-10-23 16:10:28 H=mail.prettlus.com >>> (CENTAUR.GREENVILLE.PRETTLUS.COM) [208.49.62.162] incomplete >>> transaction (RSET) from <> >>> 2006-10-23 16:10:36 H=mail.gptek.co.za (gateway.gptek.co.za) >>> [196.38.234.234] incomplete transaction (RSET) from <> >>> >>> >> >> >> Several of those are in (at least our) blacklists. >> >> The empty-sender indicates these may be bogus 'bounce' messages >> attempting splatter-distribution. >> >> Exim is probably configured correctly to NOT play that game. >> >> Check, for example the timestamps between the 'smtp connection from.' >> or TCP/IP connection..' and time for these disconnects on the same >> callers. >> >> There may be delays being imposed to encourage them to begone. >> >> >> >>> Please forgive me, as my knowledge of Exim is little. I normally >>> work with Postfix servers. If there is anything I need to provide >>> you folks with in order to help fix the problem, please let me know >>> and I will get you that information. >>> >>> Thanks to all in advance. >>> >>> Patrick >>> >>> >> >> >> Enhancing your logging for a time should help. Aside from turning up >> verbosity, as above, you can also add 'logwrite' and 'log_message' >> lines in speciifc acl's that you wish to keep an eye on. >> >> - Then turn it back down to a low-roar once you have a comfort level >> established. >> >> HTH, >> >> Bill >> >> >> >> > > > -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
