[Mimedefang] Order of the fuctions?

James Ebright jebright at esisnet.com
Tue Jun 21 14:26:10 EDT 2005


Well, you detest my "at the top" style quoting, I detest your "pick it apart"
sentence by sentence style quoting, so I will go back to my style, refer to my
quote _if_ you need your memory refreshed ;)


On Tue, 21 Jun 2005 17:10:31 +0200, Jan Pieter Cornet wrote

> 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.
...snip...
> 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.
> 
...snip...
> delay_checks feature (which is not a "sendmail flag", by the way).

Looking at the recipients.c in the sendmail 8.13.4 source and at:
http://www.milter.org/milter_api/overview.html 

Sure makes it look like it breaks out during each callback to a milter then
back, at which a milter may reject or tempfail or modify the recipients list
at any point. Now I may not be reading it correctly or interpreting it
correctly but it sure looks like it to me (and makes more sense to me as
well). Due to your "pasion" about this subject I will not respond to the list
on this anymore, feel free to continue this via private email if you wish though. 

You confirmed my "test" which also seems to corroborate it though I must
admit, I only checked the scenario I described (which is the one that mattered
to my implementation), so you say filter_sender ran before filter_relay when
delay_checks is enabled in your testing? even though sendmail would check the
recipient first and relays afterwards?

according to the sendmail docs:
delay_checks-	 The rulesets check_mail and check_relay will not be called when
a client connects or issues a MAIL command, respectively. Instead, those
rulesets will be called by the check_rcpt  ruleset; they will be skipped under
certain circumstances.

Certain circumstances basically means a trusted auth mechanism or a
spamfriend/hater setup in most cases.

It is possible my test is skewed since my users do authenticate and I do check
for that in MD, thus might have skipped the other checks regardless?

And technically, the delay_checks setting in the mc file IS a flag... a flag
is just something set to activate or deactive a feature in the programming
sense... if I stepped on some sendmail specific nomenclature by calling it
that.. then I apologize.. but for all intents and purposes, everyone here
understood what I was referring to.

Jim
--
EsisNet.com Webmail Client




More information about the MIMEDefang mailing list