[Mimedefang] Order of the fuctions?

[Jan Pieter Cornet]

On Tue, Jun 21, 2005 at 10:00:25AM -0400, James Ebright wrote:
> I think you are confused as to what I was replying to, for ALL of the default
> fuctions you are 100% correct, but for filter_relay, filter_sender and
> filter_recipient they are definately run WHEN SENDMAIL runs that part of the
> code as the milter calls are dependant on those functions in sendmail (I

No, I know for a fact that you are confused. filter_relay, filter_sender
and filter_recipient are run independent on the `delay_checks' feature
in sendmail.mc.

> believe it was another on this list that pointed out that it was hooked
> there). 

I think you might be referring to my own post to this list, and in that
post I only talked about the order of processing at a somewhat higher
level, talking about ruleset calls from the sendmail source, not about
the actual rulesets themselves (remember: delay_checks is ONLY a sendmail
rulesets tweak!).

> This is my guess as to why those are also possibly run in diff MD
> slaves and globals cannot be set there (unless you save to a state file or
> some such).

Your guess is not quite good enough. The reason they are run in different
slaves has nothing to do with the order in which things are processed
per se, they have to do with the way the SMTP protocol works, and because
mimedefang (correctly) does not tie up a perl slave to an idle SMTP thread.

> It is relatively easy to prove this is the case, reject something outright you
> can test from (like your offsite hotmail address) in your access.db and log
> how far it gets in each stage enabling all the filters in MD, then change the
> delay checks and notice you get further (or less far depending on how you look
> at it.)

Yes, indeed, it is relatively easy to prove it. Which is exactly what I did :)

See, I actually _tried_ this, because I had a sneaking suspicion of being
flamed on this list if I got it wrong. So I setup several ways to block
a message, both from MIMEDefang and from access.db, and tried that with
and without FEATURE(`delay_checks'). And it worked exactly like I said before:

Without delay_checks, both MIMEDefang and sendmail ruleset invoked tests
(like access.db) react immediately.

WITH delay_checks, tests like access.db delay until after RCPT To:, but
MIMEDefang checks still react immediately.

> This is the specific reason you MUST examine the access file manually in MD if
> you delay checks (and have a need to like we do) as the access file will NOT
> be examined by sendmail until after filter_recipient (when normally it would
> be before).

Well, yes. Almost. Actually sendmail will, even with delay_checks enabled,
refuse the connection directly after RCPT To:, before sending that recipient
to any milters (via xxfi_envrcpt).

So, indeed: if you are doing something in filter_relay or filter_sender,
and you want to know "in advance" that sendmail is going to block the connection
because of access.db restrictions, but you use FEATURE(`delay_checks') in
your sendmail.mc file, then, yes, you might want to do the access.db lookup
from within MD to know if this connection is going to be blocked later by
sendmail.

... but that is not what you claimed. You wrote, and I'm redoing your
ugly top-quoting style into a more sane style:
> On Fri, 17 Jun 2005 12:43:04 -0700, Kelson wrote
> > You're missing filter_relay, which comes before filter_sender and 
> > filter_recipient.
> The order of those three is also dependant on the "delay_checks" flag
> in sendmail.
> 
> Jim

My problem with this is: that is not true. The order of filter_relay,
filter_sender and filter_recipient has NOTHING to do with the
delay_checks feature (which is not a "sendmail flag", by the way).

-- 
#!perl -wpl # mmfppfmpmmpp mmpffm <pmmppfmfpppppfmmmf at fpffmm4mmmpmfpmf.ppppmf>
$p=3-2*/[^\W\dmpf_]/i;s.[a-z]{$p}.vec($f=join('',$p-1?chr(sub{$_[0]*9+$_[1]*3+
$_[2]}->(map{/p|f/i+/f/i}split//,$&)+97):qw(m p f)[map{((ord$&)%32-1)/$_%3}(9,
3,1)]),5,1)='`'lt$&;$f.eig;                                # Jan-Pieter Cornet