Re: [exim] conditions for running spam tests

Pàgina inicial
Delete this message
Reply to this message
Autor: Todd Lyons
Data:  
A: Seth Dillingham
CC: exim-users
Assumpte: Re: [exim] conditions for running spam tests
On Thu, Nov 4, 2010 at 11:40 AM, Seth Dillingham
<seth.dillingham@???> wrote:
> Thank you for the help on the ACL issues. I have it working as I wanted,
> mostly, and am satisfied with it's current performance.
>
> I still find the ACL's to be rather confusing, but I'm probably just dumb.


Not dumb, it takes a bit to make sense if you have prior experience
with any other MTA. Exim is a lot like buying an office phone system.
When you buy it, it's a framework, and you configure each port and
menu from scratch (usually starting with a template, such as the
default exim.conf which provides basic settings and function, and is a
good starting point).

There are two concepts to wrap your head around:
1. the order that acl_* groups are called (i.e. at what phase of the
smtp conversation you are at)
2. what variables or statuses are available to your during each of these phases

I advise you to read Chapter 40 of the exim docs. Then read Chapter
11, specifically sections 11.5 to 11.9. Those two together are the
details you need to grasp and understand acl's and the variables they
can use/access.

As an example, let's consider a typical SMTP conversation. First
there is the acl_smtp_connect acl. This is the very first phase,
where the remote MTA has connected to your exim. At this point, you
do not yet know who the recipient is, who the sender is, helo
hostname, anything. You just know the IP they're connecting from and
the hostname that it reverse resolves to, so you can make decisions on
that.

Then immediately after that is the acl_smtp_helo acl. Again, you do
not yet know who the recipient is or who the sender is, but you've
just been given the HELO or EHLO command by the remote MTA, so now you
can do some testing of that value, if you choose. Personally I don't
do any tests in the helo acl, it's undefined on my systems.

Then immediately after that the remote MTA usually issues a MAIL FROM
command, which is processed by the acl_smtp_mail acl. So now you know
who it's from, but not yet who it is to. I don't use this acl either.

Immediately after that, the remote MTA usually issues a RCPT TO
command (we'll assume just one for this explanation). Now you know
who it's from and who it's too. This phase is handled by the
acl_smtp_rcpt acl. A lot of work is done in this phase of my acl's to
weed out undesirable emails. For example, I do my RBL checks here
because doing it earlier would mean I don't give SMTP Auth users a
chance to login, and I use whether or not they are authenticated as a
decision maker in many things, including whether to do RBL checks.

Then comes the data phase, which is where your spam/virus scanning
would be occurring.

There are also acl's available for non-smtp emails (when you send an
email using /usr/sbin/exim or the sendmail compabitibility wrapper).
I've constructed my system so that everything uses smtp and nothing
calls /usr/sbin/exim or /usr/sbin/sendmail, so I don't have to worry
about these non-smtp acls either.

I hope this helps to give a forest view, and reading chapters 40 and
11 repeatedly begins to make sense.
--
Regards...      Todd
I seek the truth...it is only persistence in self-delusion and
ignorance that does harm.  -- Marcus Aurealius