On Fri, 13 Sep 2002, Phil Chambers wrote:
> It was suggested that a message statement in a warn ACL specified the wording of the
> header line. I can't see that in the spec, so is that the case?
>
> i.e. warn message X-RBL-Warning: $sender_host_address is listed by $dnslist_domain
>
> would put that text as the header?
Yes.
> > I'm not sure why you want the routers to be involved in this. Why not
> > just do the check in the ACL?
>
> I had not thought I could do that. What I want is for users to be
> able to opt, individually, to either ignore RBL checking, divert
> messages with RBL warning headers into one of their folders or discard
> such messages. Though ACLs can have condition statements, it is too
> early to check recipients because aliasing, etc. has not happened and
> I can't see who the recipient users are.
OK, you can't do it if aliases are involved, that's true.
But the whole design of the ACLs was made as flexible as it is precisely
so that - in the absence of aliases - it could be configured on a
per-recipient or per-domain basis. For example, you even look up the
entire text of an ACL in a database on a per-recipient basis if you want
to.
> Ideally, in the discard case I would have made the response to the
> RCPT command a 550 rejection. That is why I wanted to detect the
> warning header in the verify routers in the same ACL.
This still wouldn't help you. An address verification does not go on to
verify all the generated addresses if the original is redirected by a
router. It only does so if there is precisely one new address - i.e. it
does for an "alias" but not for a mini-mailing list. The thinking is
that the existence of the list itself is good enough.
> If I can only see the added header in the next ACL then I could only
> reject at the DATA stage, which is too late (not all recipients would
> want to reject). It appears that what I need is an ACL that is
> applied before the first RCPT command has been received.
The reason you can't see headers before DATA is that the storage
structure for them does not yet exist. It only gets created once the
DATA command is passed - when Exim knows it is actually going to receive
a message. (Yes, this could be better - but I was modifying an existing
design when adding the ACLs.) An ACL before RCPT wouldn't help you.
> Rather like the .forward file, I plan on the presence of a file called
> .spam_divert to be picked up by a router to route to a suitable
> appendfile transport to deliver to the folder. The presence of a file
> called .spam_reject would route to an appendfile transport with
> /dev/null.
If you can live without the 550 rejections (i.e. just divert or discard
the spam), you can do things in a local_scan() function after adding
headers in the ACLs.
However: there may be a ray of hope for you in the next release of Exim.
One of the things I have done is to make the value of $address_data as
set by any router, be available in the rest of the ACL after an address
verification. This might do exactly what you want.
4.11 won't be out for some time, though.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
