Mike Cardwell wrote:
> On 21/10/2010 23:49, Brian Spraker wrote:
>
>> I posted a bit back about trying to figure out how I can allow users to modify
>> their own spam settings.
>>
>> A database is setup with three fields - 'spam_enable', 'spam_flag', and
>> 'spam_delete'.
>>
>> under acl_check_rcpt, this has been added - and it does work appropriately
>> (because this occurs with each "rcpt to" command and can reject recipients):
>>
>> accept
>> condition = ${if eq{${lookup mysql{SELECT spam_enable FROM users WHERE
>> account="${local_part}@${domain}"}}}{N}}
>>
>> The above condition checks to see if the user has the 'spam_enable' feature set
>> to "N" for No. If so, then it will accept the mail and skip checking blacklists
>> and such.
>>
>> The same line was added into the acl_check_data area.
>>
>> However, as another newsgroup member posted, the ${local_part} and ${domain} do
>> not work here - because the possibility of having multiple recipients.
>>
>> This is also causing a snag in the same area (acl_check_data) where I'm not able
>> to pull the spam_flag and spam_delete values. The spam_flag item is the
>> user-set threshold that will just flag the e-mail as spam in the subject line.
>> The spam_delete item is the user-set threshold that will delete the mail.
>>
>> So, I basically am wondering if there is some kind of way - like a while loop -
>> that will go through each of the recipients and check these three things in the
>> acl_check_data routine.
>>
>> I'm quite lost with trying to figure out some kind of solution for this. The
>> Exim config file isn't like scripting PHP or anything like that :)
>>
>> Thank you for any advice!
>
> In your DATA acl, you can either accept for all recipients, or reject
> for all recipients. You can't accept/reject on a per recipient basis.
> This is a very common problem, and is a limitation of SMTP it's self
> rather than any sort of limitation in Exim.
>
> The simplest method is to just only allow emails to have one recipient,
> by defering subsequent recipients in the rcpt acl. Then use $recipients
> in the DATA acl. I believe there might be cases were broken mail servers
> don't like this behaviour though.
>
> If you're going to allow multiple recipients, there are two possibilities:
>
> 1.) All recipients have the same spam filtering requirements
> 2.) Some of the recipients have differing filtering requirements
>
> If (1) happens, then you just store this information in the rcpt acl,
> and then re-use it in the data acl. If (2) happens, you have to decide
> how you're going to treat that case and then use that information in the
> data acl.
>
> There's another option but it's not great. If 1 or more of the
> recipients don't want spam filtering, but 1 or more do. Then do the spam
> filtering, but don't reject in the DATA acl. Just record whether or not
> the message is spam. Then in the routers, check if the message was
> marked as spam, and if so, let it through for the non-spam-filtering
> users, and blackhole or bounce it for the rest. Bouncing will get you
> added to blacklists for generating backscatter. Blackholing is bad
> behaviour because neither the sender nor the recipient is informed of
> the message delivery failure.
>
> It's not simple.
>
For the world at large or ISP's or corporate/social entities with large
user-communities it ain't simple, no.
But for many, many, of those who run services for predominantly sole
individuals, families, or even corporate/social entities with smaller
organizations, or those with small departments or user-groups within a larger
entity, limiting to one recipient at a time is effectively transparent..
... because 'nearly all' arrivals have only one recipient anyway. Check your
logs to see if that is your case..
We've been doing it that way for years.
Here are the downsides:
- The RFC's want a server to be able to accept at least 100 recipients per
message. BUT - when they do not, retry is ordinarily automagic. While that shows
in typical logs, I have not yet seen a server (or admin) who actually cared, as
it is ordinarily a minimally-problematic edge-case.
CAVEAT: Possible exception a mass-mailer. Take that situation as you will..
;-)
- more pragmatically, if you have a department or workgroup with multiple
members, and a member, customer, or supervisor addresses a message to all of
them, one will get it 'at once'. The others arrive at intervals as the retry
works down. Typically a spread of a few seconds to 4 or 5 minutes per each
recipient.
That may matter commercially. Or not.
However, when it DOES matter, it is often the case that all recipients in that
organization can/do use the same spam settings.
So ...a bit of logic in the acl w/r per-domain or per-'group' rules, and those
can be exempted from the single-recipient rule. This because arrivals for
multiple recipients that ALSO have a mix of domains.tld are likewise rare and/or
limited to mailing-list origination.
Bottom Line:
If one does not have significant multiple-recipient arrivals, or if those that
do exist are most commonly short lists (five or so), limiting to
single-recipients works very well.
HTH,
Bill Hacker
