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 <gary.roberts@???> for dvk@???
> 2006-10-23 16:16:02 1Gc91W-0007Yq-LW <= gary.roberts@???
> H=(ecsz5es46gil0q) [216.171.132.22] P=smtp S=1275
> id=FNEILPLJIEDKNHPKOFNDOEDECHAA.gary.roberts@??? T="RE:
> RFQ" from <gary.roberts@???> for dvk@???
> 2006-10-23 16:16:04 1Gc91W-0007Yq-LW => dvk@???
> F=<gary.roberts@???> 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 <= spunky35@???
> H=sequoia.garlic.com [216.139.0.84]:60107 I=[216.139.50.4]:25 P=esmtp
> S=6358 id=453E31FF.9000103@??? T="[Fwd: Warning: could not send
> message for past 4 hours]" from <spunky35@???> for
> gary.roberts@???
> 2006-10-24 09:37:00 1GcPGs-0004ey-5G <= spunky35@???
> H=sequoia.garlic.com [216.139.0.84]:60104 I=[216.139.50.4]:25 P=esmtp
> S=688886 id=453E31C7.302@??? T="[Fwd: Warning: could not send
> message for past 4 hours]" from <spunky35@???> for
> gary.roberts@???
>
> 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 <gary.roberts@???> for dvk@???
>>> 2006-10-23 16:15:59 H=(ecsz5es46gil0q) [216.171.132.22] incomplete
>>> transaction (RSET) from <gary.roberts@???> for dvk@???
>>>
>>>
>>
>>
>> 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
>>> <alexander@???>
>>> 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
>>
>>
>>
>>
>
>
>
