Mike Barnard wrote:
> hi, i run exim 4.52 on a freebsd box. i recently picked up strange logs
> about an ACL i never configured or doesnt exist in my configure file. it
> looks somewhat like this:
>
> 2006-07-24 15:22:06 1G4zRl-000GFW-Oo H=(USERNAME) [xxx.xxx.xxx.xxx] F=<
> isaac@xxxxxxxxxxxxxxxxx> temporarily rejected after DATA: failed to expand
> ACL string "C U R R E N T _ P R I C E : $ 2 . 3 4 G E T I T N 0 W !": $
> not followed by letter, digit, or {
>
>
> what is amazing is that i have received junk mail with a somewhat close text
> as this ACL its trying to expand. this is the line:
>
> The alert is ON!
>
> Get QEGY First Thing Today!
> This Is Going To Explode!
> Check out for HOT NEWS!
>
>
> QUANTUM ENERGY INC (QEGY)
> CURRENT_PRICE: $2.34 GET IT N0W!
>
> this is the body of the email, why it gets to expand it as an ACL beats
> me....any one seen this before.
>
>
> Mike
No, but here is how you can find the code that is involved:
- Add an ID code to the comments preceding each acl. You can leave that in place.
- temporarily add a 'logwrite' to each acl. Include in it *at least* the above code.
- optionally add (or modify) a log_message string, which should also include the
code.
- use 'log_selector = +all' in your configure.
Note that the position of of the above has different results in rejection verbs
than in accept, and arrange accordingly.
In some places you may wish to add 'warn' verbs that do nothing more than flag
the place in the smtp cycle being traversed.
EX:
warn
logwrite = R0 entering routers
Restart Exim.
Now note in your logs that as an acl is traversed, the 'logwrite' string will
appear, but the log_message will only appear if/as/when the acl is actually
'triggered'.
The message you cited, above, should now be accompanied by a code number ELSE
will have one just before or just after it. Check IP's and Exim message-ID
numbers to sort interleaved traffic.
Once the log has given you the code number, a search with whatever editor you
use to maintain the ~/configure file will take you directly to the code in question.
When finished, set your log_selector back to whatever you consider 'normal' and
comment-out most of the logwrite and log_message until next time you need to
chase a problem. Or keep two versions of ~/configure, one for production one
for troubleshooting (harder to keep in sync).
Resulting log might resemble this fragments:
2006-07-24 15:20:50 H=[201.250.14.54]:1429 I=[203.194.153.81]:25 Warning: C3
invalid rDNS
2006-07-24 15:20:51 H=(203.194.153.81) [201.250.14.54]:1429
I=[203.194.153.81]:25 Warning: H3 203.194.153.81 201.250.14.54 is using IP in EHLO!
2006-07-24 15:20:51 H=(203.194.153.81) [201.250.14.54]:1429
I=[203.194.153.81]:25 Warning: H4A Imposter! 201.250.14.54 Claims to be
203.194.153.81!
2006-07-24 15:20:51 H=(203.194.153.81) [201.250.14.54]:1429
I=[203.194.153.81]:25 Warning: H5 201.250.14.54 mismatched ID's in HELO/EHLO
- Where C3 is my third step in 'CONNECT' phase test, 'H3', H4A, H5' are steps in
"HELO' phase tests...
The cause my not always be obvious, but at least you will know exactly where to
look.
Separately - check Exim's timestamps and ID's in the logs to see if the spam you
cite is the same one that gave rise to the odd log entry, or if it was a
(forged/collateral) bounce.
Then look at the full headers of the message and see if the 'body' was (also)
crammed into a header.
acl's that look directly at message-body content are uncommon.
HTH,
Bill
