On Tue, 25 Mar 2003, Rick Ennis wrote:
> But "verify = ..." isn't valid in the "acl_not_smtp".
That's an oversight. It should be possible to verify a sender in that
ACL (it is possible to verify header lines). The fix is really trivial.
At line 619 of acl.c you will find this code:
else if (strncmpic(ss, US"sender", 6) == 0)
{
uschar *s = ss + 6;
if (where != ACL_WHERE_MAIL &&
where != ACL_WHERE_RCPT &&
where != ACL_WHERE_DATA)
{
*log_msgptr = string_sprintf("cannot verify sender in ACL for %s "
"(only possible for MAIL, RCPT, or DATA)", acl_wherenames[where]);
return ERROR;
}
Just stick in the additional
where != ACL_WHERE_NOTSMTP &&
after the first or second "where" line (and fix the error message if you
feel pedantic). I'll create a proper patch when I get back to my office
next week.
> I guess the rewrite mentioned above is really just skirting the trusted user
> concept. Is that what I'm doing differently from everyone else? It should
> be either a trusted user --which should bypass the "verify=sender" check,
Trusted users don't bypass any verification checks. They just enable -f
to be used to set the sender (which is then checked, if a check is set
up). For untrusted users, -f is ignored. So is the address supplied on a
MAIL command for -bs input ... but - I've just noticed - there's an
interesting quirk there. An ACL for MAIL will check the given address,
verifying it if requested. However this address will be ignored later if
the user is not trusted. Maybe this is a bug; maybe it's a facility....
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
