iain wrote:
> I am trying to setup per-user configurations for spam scanning. In my
> acl_smtp_data checks I have the following:
>
> *** START ***
> accept condition = ${lookup mysql{SELECT spamscan FROM users WHERE
> email='${quote_mysql:$local_part}@${quote_mysql:$domain}' AND
> spamscan=0}{yes}{no}}
> *** END ***
>
> This query sometimes works correctly, but mostly fails to pass the
> recipient information to the DB:
>
> *** START ***
> 13141 Query SELECT spamscan FROM users WHERE email='@' AND spamscan=0
> 13148 Query SELECT spamscan FROM users WHERE
> email='iain@???' AND spamscan=0
> 13149 Query SELECT spamscan FROM users WHERE email='@' AND spamscan=0
> *** END ***
>
> The query is taking place once the data part of the SMTP process is
> being run, so I am at a loss as to why Exim does not pass this
> information in a consistent manner.
>
> Any ideas?
>
> Iain.
>
>
The issue seems to be WHERE you are expecting to grab the
'$local_part@$domain' selector.
And it may not matter if still 'IN' the acl_smtp_data phase anyway.....
Once into the acl_smtp_data phase, there is no mechanism in the normal
smtp process for independent handling on a per-recipient basis.
That resurfaces, 'post-smtp-session' in the (local) delivery
router/transport traversal.
Accordingly, Exim's built-in recipient-specific variables are
essentially nullified for the DATA phase. After all, *which* recipient
would one use when there is more than one? Generally the last value seen
in the variable - but that variable may not be 'offered' to you.
While you can utilize SQL to get around 'some' of that by
carrying-forward from the acl_smtp_recpt phase (and we have done..)
AFAIK the only way you can reject selectively per-recipient is when both
ends of the connection are running Courier-mta AND have Sam's
'extensions' feature to the data phase activated.
It is even a 'non-trivial' exercise to *accurately* run SA (for example)
more than once *during* smtp session, even though SA itslef has a simple
per-recipient preferences mechanism.
OTHERWISE: best you can do and remain smtp RFC compliant is to set acl_m
flags or concatenated strings, and/or X-headers for 'post smtp session'
use in router/transport sets.
On that score, SQL is a potentially 'expensive' luxury, not a necessity.
Downside is now having to generate out-of-band 'bounces', hence needing
safeguards against backscatter spam abuse.
Until that 'all-hands' characteristic of smtp's DATA phase is changed
(possibly never) the simple fix is to defer second and subsequent
recipients, thereby processing one message = one recipient at a time.
At which point scoring is a simple as can be.
CAVEAT: This violates the smtp RFC, which expects an MTA to take onboard
a hundred or more recipients per connection if offered.
MITIGATION: For many environments, especially a largely 'personal' user
community, rather than medium/large business or social organization,
legitimate multiple-recipient arrivals beyond two or three recipients or
even ONE - can be very rare, so only the zombots farms would be affected.
Other servers would finalize by the first or second retry in those rare
cases, and generally neither notice nor care by year's end, as 90%+ went
through on the first go.
CAVEAT 2: Sadly, even a 3-person office can find a large fraction of
incoming 'CC:' ed to all-hands.... who then want to know why they each
get the same message, but at time 0, time 0+5m, time 0+10m...
Family members, less often all at the screen at the same time, seldom
notice...
YMMV,
Bill
